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.


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 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. 

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.

Control Deployed FPGA Code [Application]

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”. 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

Was this information helpful?