Best Practices for Security on RIO Systems: Part 3 Extreme

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.

Whitelisting solutions are available from Microsoft, Cisco, and other security providers.

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 File Checksum VI, which is a built-in function which can run on LabVIEW Real-Time. For LabVIEW versions prior to LabVIEW 2020, consider using MD5Checksum File.VI. 

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.

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.

At startup, a RIO device loads the FPGA bitstream from the onboard EEPROM memory. For maximum code security, the following steps should be followed to ensure that the right FPGA bit stream file is used for the application.

1. Store no code in the non-volatile EEPROM RIO memory. This is done by disabling the “run at startup” option for the RIO device.
2. Create an application on the host device (Windows for RIO devices, NI Linux RT for cRIO devices) which calls “Open FPGA Reference.vi”. Calling the bit stream file with this VI will force the VI to include the bit stream in the VI binary file.
3. Create an application (.exe or .rtexe) from the host VI.
   
   
4. Prior to running the host application, run a checksum on the file to ensure that there have been no modifications to the application binary file.
5. When the host application runs, it will download the bitstream to the FPGA, overwriting any existing bitstream file. It will also perform a checksum to ensure that the code was safely delivered from the host to the FPGA.
    

Following these steps to deploy code to the FPGA at startup is the most secure way to ensure that the code running on the FPGA is the code that the developer intended without any modifications. 

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.