Finally, there are attacks that get right down to the hardware level, and try to steal the IP right out of a device. This may involve first extracting cryptographic keys from the device that are used to protect the IP, perhaps together with capturing a new configuration file being downloaded to a device in the field. Extracting processor firmware and reverse engineering it is another real threat.
Attacks only get better with time. Security that was considered good enough for many applications a few years ago may now be considered too vulnerable to use in the same applications today.
An example of attack at the device level that is becoming more prevalent and less expensive to perform is ‘differential power analysis’ (DPA). In it, the power supply consumption of an integrated circuit like a microcontroller or FPGA is monitored while it performs cryptographic operations on data using a secret key. It is assumed that the adversary has access to the encrypted form of the data—or else why encrypt it in the first place? With that data and enough power supply measurements collected during the time the key was being used, the adversary can compute the value of the key even without depackaging the chip. Depending on the rate of information leakage via the power supply and the sophistication of the attack, keys may be extracted in timeframes ranging from days down to milliseconds.
Without countermeasures, all electronic systems performing cryptography are subject to DPA-type attacks. These include most of the microcontrollers and all the FPGAs currently on the market. Reports published over the last several years have demonstrated attacks where the keys used to load encrypted bitstreams into several brands of FPGAs were extracted using DPA. With the keys, it is usually possible then, and in some cases easy, to decrypt the bitstream. It is believed that every FPGA on the market as of mid-2012 was vulnerable to differential power analysis.
Other types of hardware tampering are more invasive. In some, called semi-invasive, only the package is removed. So the device can emit or respond to light but the silicon device is not mechanically disturbed. Even more invasive are attacks where the miniscule traces on an IC are cut or probed, or where the device is de-processed layer-by-layer to determine how it works. Generally, as an attack becomes more invasive, it is more expensive to mount, requiring expensive equipment like electron microscopes and focused ion beam machines. These attacks are also harder to defend against.
There are two main technologies used for commercial FPGAs today: SRAM and Flash. In addition, anti-fuse FPGAs are still used in space applications, which require enhanced tolerance to background radiation.
SRAM FPGAs, including those from Xilinx and Altera, hold device configuration bits in volatile SRAM cells. These bits determine the logic functions that the FPGA performs. However, since the configuration memory is volatile, it forgets the configuration whenever power is removed, and must be reloaded from external sources after each power-up. In low-end devices, the configuration bitstream moves from the external non-volatile memory where it is held, to the SRAM FPGA, in unencrypted form. This provides virtually no security, as anyone with a storage scope or logic analyser can easily record the data. Also, it is often trivially easy to copy the external memory chip to create clones of the system.
To address some of these weaknesses, higher-end SRAM FPGAs utilise encryption of the configuration bitstream. In these, if the option is used, the bitstream is stored in encrypted form in the external non-volatile memory, and decrypted on the fly by the FPGA upon loading each time. For this to work, at least the decryption key needs to be stored in non-volatile memory in the predominantly volatile FPGA. This is sometimes done using a few bits of one-time programmable anti-fuse memory, or by using a battery to keep part of the chip alive at all times. Of course, if the battery goes dead or is disconnected even for a few milliseconds, the key is forgotten and the system won’t boot up.
In flash-based FPGAs, configuration bits are held in non-volatile flash memory. Thus the configuration needs to be loaded only once—typically during the board assembly process. However, since flash memory is also reprogrammable, flash FPGAs can be reconfigured multiple times over their lifetime, if desired.
Flash-based cSoC devices also have on-chip embedded non-volatile memory (eNVM) for holding the processor firmware securely on-chip. For secure field upgrades of the FPGA fabric configuration and/or the eNVM array, most flash FPGAs also offer built-in bitstream decryption functionality. Unlike SRAM FPGAs that use decryption on every power-up cycle, flash FPGAs need to exercise this feature only when doing an upgrade. For higher security, these and related features can be permanently disabled.
Trends in advanced security architecture and countermeasures
With attacks continuously improving, FPGA countermeasures also must advance to keep ahead. The threat environment is daunting, but all hope is not lost. No security is absolute, but with proper architecture and design, next-generation FPGAs will be significantly stronger than those currently on the market.
Next-generation FPGAs and cSoCs would incorporate DPA countermeasures for all built-in ‘bitstream’ cryptographic operations. Over time, it is expected that deployment of DPA countermeasures will become the norm in the FPGA industry, as is the case with microcontrollers used in financial applications, set-top boxes and the trusted platform module chips used in computers.
Over the next few years, we can expect to see the protocols used to initially configure and upgrade FPGAs and cSoCs improve to provide more features and improved security. New use models that help reduce costs will become available, especially where security demands are elevated, such as when board and system manufacturing is done by contract manufacturers, or in more sensitive applications such as systems used for national defence or homeland security. Field reprogramming will become more automated, simpler and more secure. In addition, supply chain issues such as counterfeit devices will be largely mitigated by appropriate countermeasures.
End users implementing data security applications will find new features aimed at making their designs more efficient. Implementing DPA countermeasures at the data security application level will also become the norm over time. A nascent industry of specialised third-party IP providers is developing to produce high-quality, proven DPA-resistant soft cryptographic logic and firmware IP.
Some FPGAs and cSoCs will be developed with more highly evolved anti-tamper countermeasures, akin to smartcard microcontrollers. These devices will be self-contained single-chip security modules and highly flexible security processors that can be used where design and data security demands are highest. Coupled with board-level countermeasures, they will be able to satisfy the needs of all but the very highest security applications, without the need for developing an ASIC.
In a nutshell
The threat level for FPGAs and cSoCs will continue to increase as attacks get better. At the same time, more applications are demanding enhanced data security. For example, industrial controls and medical devices that in the past barely considered security are more and more considering it a prime design requirement. This trend is being accelerated by machine-to-machine applications and the ‘Internet of Things.’ Anti-tamper requirements in both defence and commercial applications are on the rise as everyone tries to stem the tide of IP theft and protect his company and country from the potentially disastrous consequences.
FPGAs and cSoCs are evolving to address current and anticipated device and system vulnerabilities. A new breed of devices that incorporate logic flexibility of a traditional FPGA, software flexibility of a microcontroller and security of a smartcard IC will be available within a few device generations. It’s an exciting time for FPGA security!
The author is senior principal for product architect at Microsemi SoC Group