Security value of processor-driven configuration for FPGA-SoCs
BlogJune 01, 2015
Ryan Kenny
Altera
With the massive increase in content and IP options made available in the modern field programmable gate array (FPGA) system-on-chip (SoC) device, the last true frontier in flexibility is the configuration process itself. Expect to see next-generation FPGA SoCs that make this flexibility in security, configuration times, and single-event upset (SEU) responses a reality.
More powerful FPGAs mean more complicated configurations
Product offerings from FPGA companies are becoming more sophisticated every year, including a variety of hardened IP, processors, and digital acceleration functions. These new offerings promise increased functional integration in a smaller number of microcircuits. However, this integration also means complicated SoC configuration.
Many other SoC and application-specific standard parts (ASSP) products have turned to a dedicated microprocessor for their boot-up and configuration management. More importantly, military and other security-conscious customers have already used external microprocessor solutions to manage the configurations of FPGAs and other microelectronics to verify configurations, check signatures, and just ensure ”steady state” in the configuration process.
How configuration is done today
The configuration process for FPGAs today is primarily performed by a complex state machine (referred to in Altera devices as "Control Logic.") Bit stream information is loaded serially into the FPGA, variably decompressed, decrypted, and authenticated depending on the device selected and user options; the entire device is then configured prior to being released into operational mode. At the risk of oversimplifying the technologies of a handful of companies, the configuration process is mostly fixed, which means that security vulnerabilities in one FPGA’s configuration process becomes a vulnerability in all other devices.
Solution: Add dedicated microprocessor for configuration
With the addition of SoC FPGA products, designers continue to be provided either a fixed boot order, or at least a first order of flexibility in choosing the boot order of the device (either FPGA first or ARM processor first).
True flexibility in configuration, however, comes with a dedicated microprocessor built in to the FPGA device, that manages all configuration decisions, decryption and authentication of configuration files, partial configuration, responses to SEUs, and all of the security monitors on the device. If the configuration script, or processor instructions for the configuration processor, can itself be loaded on the device and updated in the field, this offers a powerful set of tools that allow designers to explore a trade space between security and configuration time.
Customized boot order
The Arria 10 SoC provides the selection of boot order between FPGA and SoC device. However, a fully scripted configuration process would be able to prioritize portions of design in FPGA or SoC, using configuration via protocol and the variety of fast v. efficient methods available to FPGAs today. The configuration process and order can thereby be managed at a very granular level and can be tailored to the design. This set-up is made even more flexible by dividing up the FPGA fabric into logical configuration regions or sectors.
Using a scripted configuration, tailored to a user’s application, can limit the commonality of configuration vulnerabilities across designs. What this means is that attacks on one design no longer necessarily work on all designs using the same FPGA/SoC.
A highly scripted configuration process, aided by hard decryption and authentication accelerators, can decide whether to protect none, some, or all of a user design. In the age of design and logic re-use, not every part of a design necessarily needs to be protected or authenticated. However, that is a decision that can be made as part of the user design in order to trade security for configuration time.
The design tradeoff in securing and authenticating configuration data is configuration time. Even with fast fabric and high-speed decryption accelerators, there are configuration time impacts associated with security (both decryption and authentication). By enabling granular levels of security, a user design will be able to take advantage of a full spectrum of tradeoffs between security and configuration time.
Responses to environmental monitors and single event upsets
The last important element of configuration is how to recover data and device operation in case of a radiation event, and how to eliminate sensitive configuration information in case of a perceived attack on an FPGA SoC.
A dedicated processor for configuration can also provide scripted and conditional responses to SEU events. These can include reconfiguring an entire device or portions of a design, failover of operations to another part of the device, or security responses such as erasures of keys and sensitive data. Like-wise, a dedicated configuration processor can generate highly scripted responses to environmental monitors like temperature and voltage, responding with ordered, controlled, and verified zeroization of keys and configuration data in the FPGA SoC. In large designs, it can be important in what order data is zeroized.
Ryan Kenny is a Senior Strategic Marketing Manager, Military Business Unit, for Altera Corp.
