Whether used as a self-contained processing element or in conjunction with adjunct processors, the SoC FPGA improves security for embedded processing. While it is possible to construct an embedded processor module with specialty security devices that perform monitoring and static key storage, consolidation of system-critical functions along with security features within an SoC FPGA provides much greater security, flexibility, and performance.

Linux has become an increasingly popular alternative to bare metal systems in embedded design. Its popularity is likely to grow as 32-bit computing becomes a commodity and projects like Yocto make it even easier to create, develop, and maintain Linux-based systems for embedded applications. Linux enables OEMs to become more like startups, whose agile hardware development teams can speed time to market by using operating systems to abstract the underlying hardware details. Despite its benefits, though, a Linux system can be vulnerable to rootkits without the proper approach to booting its embedded processor. Rootkits can be especially problematic for an emerging Internet of Things that will create billions of new, potentially insecure end points.

In general, rootkits try to access privileged (root) modes while hiding from system malware-detection tools. The malware may also try to install itself into a persistent state by modifying the boot process of the system. If successful, the infection is permanent or persists through power cycles. From there the malware does whatever its author intends it to do, including logging key strokes, forming a botnet, collecting personal information, and enabling unauthorized services. Once a system is infected, a complete operating system re-install may be required.

The problem starts at the embedded processor, which typically boots as indicated in Figure 1. The on-chip ROM on power-up will fetch the boot loader from an external non-volatile memory. The boot loader is application-specific and configures the processor during its startup for the specified application requirements. Clocks, caches, memory controllers, and peripherals are all configured. Once the processor has been initialized, the application is fetched from external nonvolatile memory, sometimes decompressed, and copied to fast external volatile memory where the application is started.

During the boot process, malware has the opportunity to attempt modifications to the boot loader of the embedded system. Figure 2 shows a simplified and typical block diagram of an embedded Linux System. UBOOT, the Linux kernel and the application layer are all stored in easy-to-access nonvolatile memory.

The only way to protect the boot process is to secure it with an entity that can be trusted to always behave in the expected manner. As a system element, this root-of-trust supports verification of system, software and data integrity and confidentiality, as well as the extension of trust to internal and external entities. It is the foundation upon which all further security layers are created and it is essential that its keys remain secret and the process it follows is immutable. In embedded systems, the root-of-trust works in conjunction with other system elements to ensure the primary processor boots securely using only authorized code, thus extending the trusted zone to the processor and its applications. Using cryptographic techniques, the trusted zone can be extended to cover all critical elements of the system at hand, or even to tie multiple trusted systems together over an intrinsically insecure network.

While many newer processors come with special features to support secure boot, intrinsic support for secure boot in processor chips is far from universal, and often requires a multi-chip solution. A better solution is a flash-based FPGA, which provides one of the best root-of-trust devices in a multi-chip embedded system, significantly raising the assurance level that any code the primary embedded processor is running is authentic.

Flash-based solutions are inherently more secure (once they are programmed, critical information never leaves the die), and today’s flash-based SoC FPGA solutions also offer a number of additional, advanced security features including on-chip oscillators, accelerators for cryptographic services, secure key storage, a true random number generator, on-chip boot code storage in secure embedded flash memory (eNVM), and at-speed serial peripheral interface (SPI) flash memory emulation to enable a secure boot of an external processor at speed. The devices also feature stronger design security than earlier solutions, and include differential power analysis (DPA) resistant anti-tamper measures. Coupled with an Embedded Linux CPU, they can be effectively used to prevent malware from attempting to modify the boot loader of the embedded system.

Figure 3 provides an example of a flash-based SoC that can be used for secure boot. The eNVM in Microsemi’s SmartFusion2 SoC is used to store UBOOT, and its FPGA fabric emulates an SPI flash memory at speed. The CPU is unaware that this SoC is between it and the SPI flash. On power-up, the SoC directs the SPI read request for UBOOT from the internal eNVM to the CPU. The CPU then goes through the normal UBOOT booting process and then fetches the remainder of the application image from the external SPI flash, during this latter stage the SoC is acting as a conduit to the external memory and passes the application image to the CPU. The SoC and its internal eNVM can only be programmed with an authenticated encrypted bitstream that can only be constructed by the SoC’s FPGA development environment. The bitstream file format is proprietary and not available to anyone, and resistant to DPA side channel attacks due to patent protected countermeasures licensed from Cryptography Research Incorporated (now Rambus). In other words, the only way malware can attempt to write to the flash is to have a bitstream that was designed for the SoC with the proper encryption and user-defined keys.

To ensure secure multi-stage boot, it is essential that the code be validated prior to delivery and execution. This ensures that no compromise has occurred that could subvert or damage the boot of each phase, and can be done using either symmetric or asymmetric key cryptographic techniques. Preferably, continual feedback to each prior stage is used to confirm that no tampering has occurred during boot load. Each phase can continue to execute if all anti-tamper (AT) monitors confirm a safe environment.

Today’s SoC FPGAs can also independently provide run-time monitoring and corrective action or a penalty, if called for. To do this, all application code would be in SPI flash memory, and optionally encrypted. The SoC would perform authenticity checks on the code for each stage, decrypt the code (if required) and feed it to the main MPU when requested via the MPU-to-FPGA SPI interface. For added security, the Boot Loader code would be stored in the eNVM of the SoC FPGA.

After power-up, the FPGA would hold the main MPU in reset until it had completed its own integrity self-tests. When ready, it would release the reset. The MPU would be configured to boot from the interface to the FPGA (e.g., via its SPI interface). The FPGA, acting as an SPI slave, would deliver the requested Phase-0 boot code to the MPU as it comes out of reset. Assuming the MPU does not inherently support secure boot, the challenge is to load some code into the MPU, with a high assurance that it hasn’t been tampered with.

If everything checks, the boot process would continue by branching to the now-trusted code in the MPU’s SRAM. This would contain the code needed to initiate the next phase, and could include a now-trusted RSA or ECC public key. Once the code in the MPU SRAM is trusted, additional security measures could be employed, such as establishing a shared key using public key methods, and encrypting all the subsequent boot code transmitted between the FPGA and the MPU with that shared key. Additionally, it may be possible to bind all the hardware components of the system together cryptographically so none would work without all the exact components of the original system.

The SoC can additionally provide real-time monitoring of module environmental conditions, such as temperature, voltage, clock frequency, and other factors. The FPGA fabric can be securely configured to provide I/O for external tamper sensors and intrusion detectors. These can be sensed by the SoC to prevent vulnerability to attack from known exploits that apply abnormal conditions to extract critical information. Much higher security levels can be achieved with proper design.

Tim Morin is Director of Product Marketing at Microsemi.