What if we use FPGA in conjunction with DSP to improve security capabilities?

fish001

What if we use FPGA in conjunction with DSP to improve security capabilities? [Copy link]

      Designs based on digital signal processors (DSPs) are particularly vulnerable to intrusion if the DSP does not have adequate security capabilities. In many applications, advanced security features can be easily implemented if an FPGA is used in conjunction to offload some of the work from the DSP. Furthermore, if the accompanying FPGA uses flash storage technology to store the configuration bitstream and critical key information in the structure on the chip, inherent security against copying or cloning can be achieved, allowing designers to automatically protect the design from these types of theft. DSP and FPGA System Architecture In a system using FPGAs or DSPs, the DSP implements advanced signal processing algorithms while the FPGA implements front-end extraction functions. A high-speed serial RapidIO bus is used to connect the FPGA and DSP; the FPGA is also connected to the PCIe bus and used as a remote access management port via the Internet. The PCIe bus can also bridge traffic entering and leaving the RapidIO bus in order to connect extended remote management to the DSP. The FPGA controls an external DDR3 DRAM, which is used as a buffer for data packets sent and received by the wireless interface and allows the FPGA to offload any low-level data protocol processing and buffer management functions from the DSP. The FPGA will also be responsible for "booting" the DSP from the external SPI Flash. The FPGA uses its own SPI memory as the source of DSP code and mirrors the boot process through the boot function from the DSP's SPI port. Once the code transfer is complete, the FPGA allows the DSP to begin execution. Secure Root If the system does not protect the boot process, an intruder can replace it with their own code and effectively hijack the entire system, which may lead to damage to the system, significant financial loss, and possible personal liability. We must use a secure boot process to minimize such attacks, and a hardware root of trust is a prerequisite for implementing a secure boot process. The hardware root of trust supports the verification of system data integrity and confidentiality, while extending this trust to internal and external entities. The hardware root of trust can prevent intrusion or modification, and can also serve as a starting point for safely laying higher-level functions. In embedded systems, the root of trust works with other system components to ensure that the main processor only uses authorized code for secure booting, thereby extending the trust zone to the processor and its applications. The hardware root of trust must be built on a secure FPGA, and its configuration bitstream must be protected from copying or reverse engineering to prevent malicious intruders from compromising the root of trust. Therefore, protecting the intellectual property (IP) of the FPGA device is a prerequisite for protecting the rest of the embedded system. The security requirement of the multi-stage boot process Initialization of the embedded processing system from other parts requires a secure boot process to execute trusted code that is not susceptible to malicious content or leakage. Figure 2 shows the different stages that the secure boot process must pass through to fully protect the initialization of the embedded system. Each stage must be verified by the previous successful stage to ensure the "chain-of-trust" all the way to the top application layer. The unmodifiable boot loader (stage 0) code can be embedded in the FPGA device and verified by the secure root of trust using protected security keys and related security algorithms to ensure the integrity and authenticity of the code. Each of the sequential stages of the secure boot must be verified by the previously trusted system before the code and execution are transferred to each stage. Implementing Secure Embedded Systems Encrypting bitstream data is a common method to protect the configuration bitstream used for power-up (such as the configuration bitstream used for SRAM-based FPGAs). This makes it more difficult to capture the bitstream by simply observing it during the configuration startup process. The decryption key is stored in the FPGA and is used to decrypt the data before configuring the FPGA. A battery is often required to preserve the security key when power is lost. Another way to protect the FPGA configuration bitstream is to store it completely on-chip using non-volatile memory to avoid exposure during boot-up. Some FPGA devices, such as Microsemi's SmartFusion2 and IGLOO2 families, also provide additional protection by encrypting the bitstream when it is programmed during manufacturing. This also protects the design from unscrupulous contract manufacturers copying or reverse engineering, which could compromise the required hardware root of trust. Once we have created a secure FPGA, the next major requirement is to implement a hardware root of trust. The FPGA must protect the security key and the on-chip immutable initial phase (Phase 0) boot loader, making them completely impossible for malicious intruders to attack or modify. If using Flash-based FPGAs to store immutable code and security keys on-chip, the configuration bitstream can also be loaded during the configuration process for security. The security key is only a small part of the entire design, however, it is very important to protect the design from other forms of attack. Preventing AttacksA common attack method is to use side-channel analysis (such as observing power or timing signatures during operations related to security keys) to try to discover security information on-chip. This side-channel method is similar to the method by which a safecracker repeatedly manipulates the lock and listens for noise in the mechanism to discover the safe combination. In this case, the side channel is the sound caused by the physical implementation of the security "feature". Implementing a decryption algorithm that is designed to be resistant to side-channel attacks can be resistant to more advanced side-channel attacks in the form of differential power analysis (DPA). Without using DPA-resistant techniques, an observer can measure the power used by the design when processing keys and algorithms. In addition, frequently changing security keys will limit the number of measurements an attacker can use for data analysis, making it difficult for them to use this type of attack. Furthermore, circuit design techniques such as precharging registers and buses will limit the "noise" that an intruder can exploit. OverviewNow that the FPGA IP is secured and our design has a root of trust established, we can look at the entire embedded system implementation in more detail. Figure 3 shows an implementation of a secure embedded system, depicting the different components of the secure boot process. The unalterable boot code and keys are stored on-chip, and external SPI memory stores the rest of the DSP code (including any required OS loaders and OS code, as well as application code), all authenticated using a secure challenge and response system managed by the root of trust. At the end of the process, the secure code is loaded into the DSP's on-chip SRAM, and the FPGA allows the DSP to begin operation, confident that only authorized code is being executed. In addition, low-cost PCB tamper detection schemes can be easily implemented using the FPGA I/O to detect any attempts to drill or cut traces and implement protection measures. Once the secure boot is complete, the FPGA can implement other functions required by the system, such as bridging PCIe and RapidIO interfaces, connecting to the JESD204x bus, pre-processing wireless signals through the FPGA module, and controlling the DDR3 buffer. When additional algorithm processing power is required, SmartFusion2 has an on-chip processor option; when the FPGA module is sufficient to implement the required control functions, IGLOO2 can also be selected. Securing New DSP Designs for the Internet of Things Flash-based FPGAs provide secure IP and hardware root of trust for building higher-level security functions such as secure boot to protect the design from intrusion. Future security requirements will build on these capabilities, for example, transmitting secure data and authorizing secure devices will become a major requirement for emerging IoT and M2M applications, which will target many new DSP-related designs. This will require several additional design security layers to protect embedded system design IP. In addition, new data security requirements are expected to grow significantly, requiring advanced security technologies and methods to fully meet the requirements of lower power, smaller footprint and higher processing efficiency in order to succeed in these new markets.