Best Practices for Security on RIO Systems: Part 3 Extreme


This article covers the 'extreme' set of best practices for securing RIO systems. These are practices that users with very strict security needs should consider. The 'extreme' practices require a significant investment in time and cost. Each best practice is organized into a separate section of this document. Links relevant to each of the recommended best practices, such as reference designs and knowledgebase articles, are presented within the section for each best practice. Each best practice will also be labelled with one of the following four tags to identify which layer as defined in the overview documentation is affected: [Network], [Physical], [OS], [Application]. This article is a part of the Best Practices for Security on RIO Systems documentation. You can return to the overview for this set documentation at: Overview of Best Practices for Security on RIO Systems.


Application Whitelisting [OS]

As an 'extreme' security measure, you can rely on application whitelisting on the host pc. Many software security vendors provide whitelisting solutions. Whitelisting is a concept that can consists of two parts. The first part is the setup, during which the hash/checksum of all executables, binaries, and other runnable files is computed when the computer in a known good state. Once a table of all the checksums has been assembled, the whitelisting application can begin to police the computer. In this second part, any application which tries to run is checked by the whitelisting application. If the whitelisting application finds that the checksum of the application doesn't match a known checksum, the application is denied from running. In this way, whitelisting can ensure that the only things running on the computer are known to be benign. 

The only drawback to whitelisting is cost and maintainability. In order to add a new application to the "acceptable list," one often has to go through some effort to roll back the whitelisting, modify the rules, and then re-enable the whitelisting. Various solutions provide different means of handling additions to the whitelisting rules, some easier than others.

Notable whitelisting solutions include: Bouncer from CoreTrace, Application Control from McAfee, Parity Suite from Bit9, and AppLocker from Microsoft. 

Software Checking [Application]

Somewhat similar to whitelisting on a host pc, you can implement software checking on the real-time controller of the RIO device. The strategy is to compute the checksum of key system files on the real-time controller and check them at startup against the stored values. 

A meaningful implementation would be to have the checksums computed and stored either on portable media, such as a USB drive, or on the host pc. The first step of the real-time application can be to compute the checksum of key files such as ni-rt.ini and return the value to the host pc for verification or to check the value against the value stored on  removable media such as a USB drive plugged into the controller. If the checksum differs from the value previously computed, you know that something on the real-time controller has been modified and can investigate the change further and take action, such as to reformat the real-time controller. 

For computing a checksum on key files, consider using the the MD5Checksum File.VI, which is a built in function which can run on LabVIEW Real-Time. You may also want to rely on tools already on the community such as the SHA-1 Cryptographic Hash Function.

Hardware Checking [Application]

A good addition to locking the RIO device in an enclosure would be to have a signal from the locked enclosure fed into the RIO device. The FPGA can check for this hardware signal, and if different than expected, can alert the real-time controller and enter an FPGA safe state.

In addition to a signal from the locked enclosure, you may want to have the FPGA check for other signals related to hardware necessary for the application. If the signals fail to return proper values (such as digital HI, etc.), you will be able to tell that the hardware setup for the application was tampered with. 

The implementation for hardware checking with change based on the application and the feedback signals that you incorporate into the locked enclosure and other required hardware elements.

Encrypt RT-FPGA Communication [Application]

To protect against the worst case scenario of an attacker gaining physical access to the RIO device and working to dismantle the device to reverse engineer the real-time application and the FPGA application, you can encrypt the communication between the real-time controller and the FPGA. This way, attackers trying to sniff the PCI bus which runs between the real-time controller and the FPGA will have a much harder time of trying to decode the application.

There are a variety of protocols that you can use to encrypt communication between the FPGA and real-time controller. For more information, please refer to FPGA IP (IPNet): LabVIEW FPGA Encryption Algorithms.


The best practices presented here are meant to be employed by extremely security-conscious users when developing a RIO system consisting of a host pc and a RIO device that has a real-time controller. More basic best-practices can be found at Best Practices for Security on RIO Systems: Part 1 Recommended and Best Practices for Security on RIO Systems: Part 2 Optional. Note that the best practices presented in this series of documentation is not exhaustive. There exist other measures which can be taken to secure RIO systems, but which come with a number of caveats. Given the complexity and nature of associated caveats, these measures have not been presented in the best practices documentation. To learn more about these additional measures, please contact NI. You can return to the central site for best practices for security on RIO systems at: Overview of Best Practices for Security on RIO Systems

Was this information helpful?