Hardware Security of FPGAs: Protect your Soft IP

Field Programmable Gate Arrays (FPGA) are reprogrammable circuits that behave like completely custom hardware. Because of that they combine advantages of the hardware world and software world: being reprogrammable and patchable as a software implementation, which gives full flexibility, but allowing truly parallel and short execution times as hardware implementations reaching the performance of an Application Specific Integrated Circuit (ASIC).

During startup, the configuration file denoted as the bit stream is loaded from an internal or external non-volatile memory into the FPGA. The bitstream is generated out of the Hardware Description Language (HDL) code, which is used to implement the hardware behavior. In general, there is no difference in writing HDL code, which is translated into a bitstream for an FPGA or into a real hardware layout built into an ASIC. Eventually, the bit stream is deployed to configure different parts of the FPGA. Depending on the functions implemented and the bit stream generation process, dedicated routing matrices will physically route signals and data accordingly in the actual hardware layer itself to mimic the intended hardware behavior. Typically, an FPGA’s hardware layer consists of the following configurable parts:

• Look-Up Tables (LUTs)
• Block RAMs
• Digital Signal Processing (DSP)-Slices
• Phase-Locked Loops (PLLs)
• I/O Blocks
•  Routing Matrices

The LUT is used to realize logic gates, e.g. NOT or AND, which previously have been implemented with the HDL code. The logic gates are translated into a table with fixed input and output. A typical four-bit-LUT consists of 16 SRAM bits (16 registers) and can be used to realize an arbitrary four-bit function. Depending on the four input bits, a multiplexer selects a distinct SRAM cell, and their content will be forwarded to the output while being modified to represent the correct calculation results. If functions with more than four input bits need to be implemented, either an even larger LUT with more input and output bits will be used, or several smaller LUTs are combined using routing matrices. Note that LUTs are combinatorial logic and not clock driven, i.e. they are working in an asynchronous manner, meaning the output signals will be available immediately.

Time critical or complex operations might require several LUTs to be implemented, which then results in a long critical signal path. The critical signal path describes the longest time a certain signal among all signals needs to pass all asynchronous logic between two synchronously clocked cells. For instance, the path of a signal from one clocked register through various combinatorial functional blocks to another clocked register. The critical path is quite important since it determines the maximum clock frequency the entire hardware design can run with. To prevent running an implementation with complex operations with a lower clock frequency, block RAM can be used instead of combining several LUTs to load huge pre-calculated tables and maintain a short critical path. The main difference between a LUT and the block RAM in this case is that the block RAM module is clocked, i.e. runs synchronously. That means, the result is not ready immediately but only after the next clock edge of the block RAM. Please note that the block RAM has its own clock and thus does not directly influence the critical path of the design. A second use case for the block RAM is to temporarily save data. This may be used for building a CPU RAM or data buffer.

A DSP Slice may be used for complex mathematical operations and is already built in silicon on the FPGA. A common use case for a DSP slice is a multiplier for big numbers. Using DSP slices for the multiplier instead of LUTs will likely save hundreds of LUTs on one hand and results in a much faster design on the other hand.

A PLL will be used to condition the internal clock signal for the FPGA. It has a fixed frequency input and a variable frequency output, which will be optimized based on the critical path of the bit stream.

An I/O block is necessary to establish a communication interface to other integrated circuits and maybe finally to a computer. For example, if the routing matrix connects a communication signal to the I/O block, it is visible on an external FPGA pin. In such a way SPI, I2C or UART interfaces might be implemented.

The routing matrix can be thought of as a large set of multiplexers. Within a single multiplexer, a control signal decides which of different input signals is connected to the output. Hence, the routing matrix has the capability to arbitrarily connect the inputs and outputs of different LUTs, I/O blocks, block-RAMs DSPs and PLLs.

The bitstream is the heart of the implementation and contains the complete intellectual property, often called Soft IP. In case the bitstream is not encrypted, the keys are extracted or passive attacks, e.g. side-channel attacks, are used to extract the bitstream, the Soft IP might be exposed to an attacker or third party. An FPGA must provide sufficient mechanisms to counteract those attacks like featuring a side-channel and fault resistant bit stream encryption using individual hardware bound keys and secure data transfer in silicon.

The bitstream is the heart of the implementation and contains the complete soft IP. In case the bit stream can be manipulated, logical vulnerabilities may be introduced, or implementation flaws open the door for physical attacks. To avoid such attacks, the FPGA must provide sufficient mechanisms like strong bitstream authentication mechanisms using hardware bound and individual keys in a side-channel and fault resistant way.

Side-channel attacks make use of passive information like timing, power consumption or electromagnetic radiation. This information can be used to extract sensitive information, e.g., keys during an encryption operation, even though the implemented encryption mechanism is standardized and cryptanalytic secure. For FPGAs this attack family has a twofold impact. First, an FPGA might implement cryptographic operations on silicon, especially for protecting the bitstream or as a service for the Soft IP. Those must be hardened sufficiently to build a resilient root of trust. Secondly, the Soft IP or rather the bitstream, which is loaded onto the FPGA, directly influences the data and signal flow in hardware. That said, implementation flaws or unprotected implementations will cause a huge passive information leakage which might be exploited eventually.

In case of a shared FPGA system, several vendors can program separated parts of the FPGA. It is possible to write HDL code in a way that a sensor is implemented, which collects side-channel information directly on the FPGA. In such a scenario, an untrusted party might extract information without having physical access to the FPGA.

Fault injection attacks exploit physical properties of the IC to manipulate the expected data flow. Fault sources might be sophisticated, like laser fault injection, or easier mechanisms like electromagnetic and voltage fault injection. Fault injection attacks can be used to skip critical operations like verification and authentication mechanism, or to enable differential fault analysis in case cryptographic operations are targeted. For FPGAs, this attack family has a twofold impact. First, an FPGA might implement cryptographic operations on silicon, especially for protecting the bitstream. Those must be hardened sufficiently to build a resilient root of trust. Secondly, the bitstream which is loaded onto the FPGA directly influences the data and signal flow in hardware. That said, implementation flaws or unprotected implementations might be exploited easily. Fault injection attacks might also cause permanent faults in the current configuration of the FPGA , i.e. resulting in changes of the soft IP itself.

In case of a shared FPGA system, several vendors can program separate parts of the FPGA. It is possible to write HDL code in a way that a fault source is implemented, which is able to manipulate the data and signal flow. In such a scenario an untrusted party might disturb the correct operation without having physical access to the FPGA.

Protecting the soft IP requires implementing countermeasures against passive side-channel analyses. Two kinds of side-channel countermeasures might be implemented and can be combined: Hiding and masking. Physical testing of the soft IP on the FPGA is unavoidable to verify the effectiveness of the implemented side-channel countermeasures.

Sensitive information can be hidden within the side-channel traces by adding noise. This might be achieved by running an unused part of the FPGA in parallel, e.g. during the decryption of the bitstream, the FPGA could hash random data. A different approach could be to shuffle the order of repetitive operations on parts of the sensitive information or to implement dummy executions of the same operation to hide the real execution.

The signature of sensitive data can be removed from side-channel traces by not processing them directly. Instead, the information is masked by adding random data. As a result, information about both shares (the masked value and the mask) is required to obtain information about sensitive data. Depending on the function during which sensitive information should be masked, Boolean or arithmetic sharing might be necessary, and secure conversions between both kinds might be required.

Protecting the soft IP requires implementing countermeasures against active fault injection attacks. Fault injection countermeasures typically require a form of redundancy. This can be either implemented in time or in area. Redundancy in area could be achieved by using a duplicate instance of the module to be protected and comparing the output of both for equality. However, more effort might be necessary as the very same fault could be injected into both instances. Especially for FPGA’s, countermeasures against permanent faults have to be implemented to ensure the integrity of the soft IP. This might be achieved by running an initial test routine on the module that is intended to be used next, e.g. conducting a known answer test. Physical testing of the soft IP on the FPGA is unavoidable to verify the effectiveness of the implemented fault injection countermeasures.

To secure the customers’ soft IP against theft and manipulation, an FPGA must provide a trusted execution environment for the HDL code. This starts with a hardware backed root-of-trust, containing non-malleable, non-extractable, customer individual keys. Having such trust anchor ensures that the bitstream can be encrypted and authenticated only by permitted FPGAs. In case the bitstream must be updated due to a security breach, it must be ensured that older bitstreams will no longer be executed by the FPGA, thus, sufficient rollback protection must be offered by the FPGA. Of course, the update mechanism itself must be designed in a secure manner and being aligned with the aforementioned security features.

As independent testing laboratory, we help FPGA developers to analyze and test their FPGA design, with focus on securing the customers’ soft IP. This can be done in workshops, independent security analyses or attested security allowing application for a certificate. Certifications like EUCC can be used as evidence for procurement requirements or regulatory standards like the cyber resilience act.

As independent testing laboratory, we help soft IP developers to analyze and test their design, with focus on securing the HDL code against logical as well as physical attacks. This can be done in workshops, independent security analyses or attested security allowing application for certification. Certifications like EUCC can be used as evidence for procurement requirements or regulatory standards like the cyber resilience act.