Mach-NX: the cornerstone of a trusted system, realizing strong encryption

“A reliable system security mechanism requires a combination of multiple methods, and the root of trust must begin with a secure boot process. With its leading position in this field, Lattice has launched a new generation of Mach-NX series products, further developing its safety control platform. These new devices can quickly respond to potential threats, ensure platform security, and simplify customer design. This white paper is sponsored by Lattice, but the opinions and analysis in the article belong to the author of this article.

“

A reliable system security mechanism requires a combination of multiple methods, and the root of trust must begin with a secure boot process. With its leading position in this field, Lattice has launched a new generation of Mach-NX series products, further developing its safety control platform. These new devices can quickly respond to potential threats, ensure platform security, and simplify customer design. This white paper is sponsored by Lattice, but the opinions and analysis in the article belong to the author of this article.

Ensuring system security starts with firmware

To deal with today’s various threats, complex systems require security mechanisms throughout the entire life cycle. This needs to start with ensuring the security of the supply chain to ensure that the system will not be damaged during the process of device programming, system manufacturing, transportation and installation. Once put into use, the system also needs secure OTA updates to patch vulnerabilities or update security protocols. Finally, the system needs to be scrapped safely to prevent data loss.

Traditional markets that focus on system security mainly include data centers, service providers, and critical infrastructure. Since many attacks can be launched from within the system, the security mechanisms of multi-tenant and public cloud data centers have become very important. In contrast, security at the edge of the network is slightly outdated. Therefore, the data center system must be able to defend against software attacks launched from within the system. Attack targets include computing servers, storage systems, and network switches and routers. In the service provider’s network, base stations, broadband access equipment, routers, and various gateways are also potential targets for attacks. Even if the user plane data is encrypted, these attacks may compromise the management plane and open the back door to the system.

Broadly speaking, industrial control systems include those deployed in critical infrastructure, such as national defense, public utilities, power grids, and transportation. Governments have taken early actions to protect the security of systems deployed in these areas, especially as malicious attackers are increasingly rampant. However, cybercriminals are increasingly targeting similar systems in other fields to obtain economic benefits. Just imagine how much damage a ransomware attack would cause a plant to stall. Another attack target is automobiles. The interconnection and automation of automobiles is increasing. Many automobiles now adopt OTA firmware updates.

The security of device startup starts with the firmware, and a complex system will have a multi-stage startup process, which also forms a larger attack surface. The system firmware needs to be authenticated at startup and OTA update encryption and verification. When the system detects an attack or failure, it must be able to quickly recover to a stable and safe state.

Some of these systems use Trusted Platform Module (TPM) to create a Root of Trust (RoT) that securely stores encryption keys. However, the implementation methods of TPM vary greatly. Some use dedicated hardware modules, while others are based on firmware and software. Researchers have found vulnerabilities in various implementations, some of which are even independently certified schemes, and can use these vulnerabilities to find private keys through precise methods. Therefore, even with TPM, all system firmware cannot be completely protected from damage.

Protection, detection and recovery

One way to protect the system firmware is to monitor the Serial Peripheral Interface (SPI) signals used to read and write the associated flash memory. Figure 1 shows an example of a server where flash memory is connected to both the South Bridge (or PCH) and the baseboard management controller (BMC). By placing the switch in the SPI path, the programmable logic device (PLD) can monitor the SPI signal. PLD can verify commands and addresses based on authorized and unauthorized access tables. When unauthorized access is detected, it will prevent the instruction from reaching the flash memory device through a switch. It can also record these activities to facilitate running management code on the BMC.

Figure 1. PFR system architecture. The safety control PLD can realize SPI monitoring and other PFR functions and control functions.

The PLD used to protect SPI access can also implement various system control functions, including power control, such as power-on sequence, fan control, panel buttons and LEDs, and many perception functions of power consumption, heat dissipation, and physical status. Since most of these functions use the I2C interface, PLD can also buffer and multiplex signals for the BMC.

The National Institute of Standards and Technology (NIST) is responsible for the development and formulation of algorithms, protocols, and frameworks to ensure network and system security. The organization recently launched the NIST SP 800-193 Platform Firmware Protection and Recovery Specification (PFR). Its core principles are to protect platform firmware from damage, detect firmware damage, and restore damaged firmware to a complete state.

In order to protect the boot image of BMC and CPU, the security control PLD can verify the firmware before allowing the associated host to exit the reset state, including reading firmware data from flash memory, generating digest, reading digital signature from flash memory, and using appropriate non- Symmetric encryption to verify the result. The PFR specification only recommends specified encryption algorithms, but in fact, since traditional algorithms require longer keys, elliptic curve encryption (ECC) is now the first choice. NIST’s benchmark requirement is equivalent to 112-bit security strength, which requires a 2048-bit RSA signature key. In contrast, the elliptic curve DSA

(ECDSA) Only a 224-bit prime number field is needed to achieve the same encryption strength. For the equivalent strength of 192 bits, ECDSA only needs 384 bits, while RSA needs 7680 bits.

Firmware protection also includes an updated verification mechanism. Although the PFR specification does not provide details, OTA updates can be encrypted for transmission. The firmware image encryption uses a symmetric algorithm, and the current implementation uses the Advanced Encryption Standard (AES). Baseline security strength requires a 128-bit key (AES-128), but today 256-bit keys are more common in security-sensitive applications. By using AES-256, bulk encryption exceeds the strength of 384-bit ECC hash (SHA-384) and message authentication (HMAC-384). After the image is decrypted, its digital signature can be verified before being written to the flash memory.

The PFR specification includes a root-of-trust detection (RTD) function. The idea behind this feature is: Attacks on system firmware or critical data should not harm the RTD. Through the above-mentioned SPI monitoring, the PLD can not only act as an RTD, but also prevent attacks that violate the preset flash access rules. At startup, it can detect intrusions by verifying a valid firmware image. When firmware damage is detected, the system preferentially uses the locally stored firmware image to restore to the previously authorized state. It should be noted here that the backup image cannot be static, because the previous firmware version may include known vulnerabilities.

Since Lattice has provided PLDs for system control functions, its chips, intellectual property (IP) and software have developed rapidly, and it is now possible to integrate RoT, system firmware protection and control functions into a single device. The new generation of Mach-NX is based on the proven MachXO3D, combined with dedicated IP, software and services to take it to the next level.

Mach-NX achieves strong encryption

To meet safety control requirements, Mach-NX provides programmable hard-core logic and abundant I/O. The chip configuration (bit stream) is stored in on-chip flash memory, which can manage two encrypted images. At startup, the main bit stream will be verified while being downloaded to the SRAM. If the verification fails, the device can automatically restart from the backup (gold version) bit stream. Mach-NX also includes Universal User Flash Memory (UFM), which can be used to store user encryption keys. The UFM is 1064Kb in size and encrypted. After the dual-boot function is disabled, the size becomes 2669Kb.

The Secure Enclave is an important module to ensure the security of the system. It can implement encryption protocols, a true random number generator (TRNG), and generate a unique unchangeable ID for each device. It also handles ECC protocols including ECDSA and ECDH, and supports up to 384 bit fields. It also supports AES bulk encryption using keys up to 256 bits. This area generates a public-private key pair through TRNG, and provides a standard authentication interface through the security protocol and data model (SPDM) transmitted under the Management Component Transmission Protocol (MCTP).

As shown in Figure 2, Mach-NX adds a RISC-V hard core to run management and control firmware. This compact 32-bit microcontroller implements the RV32I instruction set and integrates an interrupt controller, timer, and JTAG debugger. Lattice previously provided the core with soft IP, and now its implementation with hard core helps free up programmable logic and realize other functions. Mach-NX has a total of 11K logic units. The combination of available logic units and UFM provides space for field upgrades to meet the ever-evolving safety requirements in the future.

Figure 2. Mach-NX block diagram. This chip includes hard core RISC-V CPU, hard core security module, flash memory, programmable logic unit and abundant IO.

Another new feature of Mach-NX is the enhanced SPI (eSPI) interface, which replaces the traditional low pin count (LPC) bus to connect to the BMC. eSPI adds a new layer of new protocol on the basis of SPI’s electrical and timing specifications, so it can be backward compatible with SPI. Like the previous generation products, the new device includes flexible I/Os that implement control functions. It has up to 379 pins, can implement standards such as LVCMOS, LVTTL, and LVDS, and supports a voltage range of 1.2V to 3.3V. All packaging schemes use 0.8 mm pin pitch to simplify PCB layout.

Mach-NX is the latest product based on the Lattice Nexus platform and is manufactured using Samsung’s 28 nm fully depleted silicon-on-insulator (FD-SOI) process. Although FD-SOI is known for its low leakage current, power consumption is only a secondary consideration for most safety control applications. However, another benefit of this process is that it greatly reduces soft errors caused by radiation. Since the device configuration is stored in SRAM, single event upset (SEU) may cause failures that are difficult to recover. In this logic density device, the FD-SOI process can almost prevent the occurrence of SEU.

A more complete solution

In order to simplify customer design, Lattice uses IP, software and various services to improve its security control platform to implement PFR and other more solutions. In order to facilitate the use of PFR IP to configure Mach-NX, Lattice provides Propel Builder, a drag-and-drop development tool. The soft IP required in PFR design includes SPI master, SPI monitor, I2C monitor, and register-based interface between RISC-V CPU and programmable logic. The SPI monitor is connected to an external SPI switch to monitor the access between SPI and flash memory and block unauthorized commands. The soft core PFR module requires 2.6 K logic units, and the remaining 8.4 K can be used for user logic.

Lattice also provides firmware source code running on the embedded RISC-V core as part of the Sentry PFR reference design. There are three main PFR software components responsible for security management, log management, and out-of-band communication. Each component provides a set of APIs for application code, and the low-level APIs provide access to soft/hard IP modules. Lattice provides an application example to demonstrate protection, detection, and recovery capabilities. Propel SDK allows customers to modify, compile and debug PFR firmware.

For the production process, the security of PFR design is closely related to the supply chain, so Lattice also provides a security service called SupplyGuard, which is used in conjunction with Mach-NX’s unchangeable ID. The company assigns a specific part number to each customer and uses an encryption key to program these devices at the factory. Customers can use this key and the signed and encrypted bit stream to program the device. The ID of the device allows the customer’s system to program the legal device while preventing illegal reading of the bit stream. This helps protect the integrity of the bitstream and the client’s IP. Without the customer-specific key, the device cannot be reprogrammed. Under this “locked” security mechanism, even if the security of the manufacturing site cannot be determined, there is no need to worry about the risk of tampering with the device.

Other options

Due to the particularity of Mach-NX, it does not face direct competition in PFR applications. If you use FPGAs from other manufacturers, customers need to obtain a third-party authorized encryption module as a soft IP. They need to use soft IP to instantiate the MCU and integrate it into a third-party module. Most FPGAs also require external flash configuration memory. As shown in Table 1, the system firmware certification performance of other FPGAs is much lower than that of Mach-NX. The longer the verification time, the longer the startup time, and the longer the startup time will reduce the system uptime.Many cloud services include a service level agreement

(SLA), which stipulates the normal operation time of the system. Therefore, the startup time will directly affect the SLA indicators. The “five nines” reliability (99.999%) requires less than 5.3 minutes of downtime per year, so system startup time is very important in cloud data centers.

Table 1. Comparison of PFR functions between Mach-NX and other solutions. Lattice’s chips perfectly combine high performance and strong security. * Time measured with 64 MB firmware image and 33 MHz SPI clock frequency. (Data source: Lattice)

When the system firmware verification fails, Mach-NX can quickly recover. The device supports dual SPI memory, one to store the main firmware, and the other to store the golden version of the firmware. If the verification fails, the Sentry firmware will switch from the primary SPI to the secondary SPI and continue the boot process. Then copy the authenticated firmware image to the main SPI flash memory in the background. Other solutions must copy the firmware image before booting.

Another PFR implementation is to use BMC, but this method has many limitations. First, manufacturers’ BMCs generally do not support elliptic curve encryption, so their verification is weak. Secondly, BMC relies on external flash memory and cannot avoid the supply chain vulnerabilities that Mach-NX and SupplyGuard can prevent. Finally, they do not support SPI monitoring and need to use an external PLD to add this function. Mach-NX can implement PFR and control functions, the latter requires the participation of PLD in any case.

A major recent trend is the development of customized platform security chips, but some of them are designed for smart phones, such as biometrics. Google developed the Titan security microcontroller for its cloud server. Although other large cloud operators can also develop similar chips, most OEMs are unwilling to undertake the huge resources required for custom chip development. Lattice’s customized solutions provide similar functions, and customers do not need to bear high custom chip development costs.

in conclusion

Lattice now not only provides FPGAs, but also provides a comprehensive security control platform, including optimized chips, software, tools and services. By providing security protection throughout the entire life cycle from system design to equipment obsolescence, Lattice’s solution can address vulnerabilities that occur at all stages. Mach-NX is based on the company’s many years of security control experience, and on the basis of the proven MachXO3D, the encryption function has been strengthened, the BMC interface has been upgraded, and more programmable logic that implements custom functions and on-site updates are provided. At the same time, the Sentry reference design reduces the customer’s time and resource requirements, and can quickly and easily integrate PFR into their systems.

Although servers have taken the lead in adopting a powerful platform security mechanism, as real-time online network connections continue to grow, more and more systems are exposed to network attacks, and the security market is still expanding. Network and communication equipment, industrial control systems, aerospace systems, and autonomous vehicles are increasingly becoming threat targets. Lattice can help customers in these fields ensure the safety of their designs during the entire cycle from manufacturing to field upgrades.