New Lattice FPGAs enable real-time hardware Root-of-Trust -

New Lattice FPGAs enable real-time hardware Root-of-Trust


Lattice Semiconductor has introduced its second-generation secure control FPGAs enabling real-time hardware Root-of-Trust (HRoT) to deliver enhanced security in server platforms and other connected device applications.

The new Mach-NX FPGA family builds on the first-generation Mach security devices introduced in 2019, to add improved 384-bit strength crypto engine, support for the enhanced serial peripheral interface (eSPI), secure device communication security protocols (MCTP-SPDM), a hardened RISC-V core running management and control firmware, and up to 8.4k available user logic cells.

The Mach-NX FPGAs combine a secure enclave, an advanced, 384-bit hardware-based crypto engine supporting reprogrammable bitstream protection, with a logic cell (LC) and I/O block. The secure enclave helps secure firmware, and the LC and I/O block enable system control functions such as power management and fan control.

Mach-NX secure FPGA block diagram. This shows the secure enclave with enhanced 384-bit crypto engine and hardened and configurable PFR. (Image: Lattice Semiconductor)

The new FPGAs can verify and install the over-the-air firmware updates to keep systems compliant with evolving security guidelines and protocols. The parallel processing architecture and dual-boot flash memory configuration provide the near instantaneous response times needed to detect and recover from attacks. In an interview with, Lattice executives highlighted the significance of real-time security capability to detect an attack and quickly recover to a stable and secure state. They said, that with firmware authentication in less than 5 seconds in the Mach-NX, this is the faster than other FPGA or MCU based solutions.

Mach-NX FPGAs will support the Lattice Sentry solutions stack, a combination of customizable embedded software, reference designs, IP, and development tools to accelerate the implementation of secure systems compliant with NIST Platform Firmware Resiliency (PFR) Guidelines (NIST SP-800-193). In addition, a customized PFR-compliant HRoT solution can be created with the Lattice Propel design environment, which uses a GUI-based design tool that allows developers to create PFR solutions while minimizing the need to write RTL code.

Analyst Patrick Moorhead, president and founder of Moor Insights & Strategy, said there is a constant race between bad actors trying to exploit firmware vulnerabilities and developers designing server platforms with the security features and performance to stop them. Hence, he commented, “Protecting systems better requires a real-time HRoT with support for stronger cryptography algorithms like ECC 384 and new, robust data security protocols like SPDM. I believe technologies like Lattice’s Mach FPGA families can simplify and accelerate implementation of these technologies for server OEMs looking to better secure their platforms against cyberattack and IP theft.”

Bob Wheeler, principal analyst at The Linley Group, said in a white paper prepared for Lattice that boot-time security has to start with firmware, and complex systems have multistage boot processes that create a larger attack surface. System firmware requires boot-time authentication and over-the-air (OTA) update encryption and authentication.

“When the system detects an attack or fault, it must quickly recover to a stable and secure state. Some of these systems employ a Trusted Platform Module (TPM) to create a root of trust (RoT) where cryptographic keys are securely stored. TPM implementations vary widely, however, from dedicated hardware modules to firmware- and software-based approaches. Researchers have discovered vulnerabilities in various implementations— even those that are independently certified—that enable discovery of private keys through practical means. Thus, even a TPM can’t fully protect all system firmware against compromise.”

Wheeler adds, “To meet secure-control requirements, Mach-NX combines programmable and hardened logic along with copious I/Os [editor’s note: up to 379]. The chip’s configuration (bitstream) is stored in on-chip Flash, which can manage two encrypted images. At boot time, the primary bitstream is authenticated while being downloaded into SRAM. If authentication fails, the device can automatically reboot from a secondary (golden) bitstream.”

Mach-NX also includes User Flash Memory (UFM) for general-purpose use as well as for storing user cryptographic keys. The 1,064Kb UFM is encrypted, and it grows to 2,669Kb when dual boot is disabled. A crucial block for system security, the secure enclave implements encryption protocols, a true random-number generator (TRNG), and an immutable ID unique to each device. It handles ECC protocols, including ECDSA and ECDH, with prime fields up to 384 bits. It also supports bulk encryption using AES with key lengths up to 256 bits. The block uses the TRNG in generating public and private key pairs. It provides a standard authentication interface through the Security Protocol and Data Model (SPDM) transported over the Management Component Transport Protocol (MCTP).

Mach-NX adds a hardened RISC-V core that runs management and control firmware. This compact 32-bit microcontroller executes the RV32I instruction set and integrates an interrupt controller, timers, and JTAG debugger. “Lattice previously supplied this core as soft IP, but hardening it frees programmable logic for other functions; Mach-NX sports a total of 11K logic cells. The combination of available logic cells and UFM provide headroom for field upgrades that handle future security requirements,” said Wheeler.

“To use an FPGA from another vendor, a customer would need to license an encryption block as soft IP from a third party. They would need to instantiate an MCU using soft IP and integrate it with the third-party block. Most FPGAs also require an external Flash configuration memory. Other FPGAs yield much lower performance for system-firmware authentication. Greater authentication time increases boot time, and boot time reduces uptime. Many cloud services include a service-level agreement (SLA) that specifies uptime, so boot time can directly impact SLA metrics. “Five nines” availability (99.999%) requires less than 5.3 minutes downtime per year, so system-boot time is important in cloud data centers.”

Lattice Mach-NX comparison table real-time protection
The PFR-feature comparison (table on left) for Mach-NX and other solutions like FPGAs and MCUs. Authentication time quoted is based on a 64MB firmware image at 33MHz. (Image: Lattice Semiconductor)

Mach-NX also enables rapid recovery when system-firmware authentication fails. The device supports dual SPI memories so that one can store primary firmware while the other keeps a golden version. If authentication fails, the Sentry firmware switches from the primary to the secondary SPI and allows the boot process to proceed. In the background, it then copies an authenticated firmware image to the primary SPI Flash. Alternative solutions must copy the firmware image before the boot process proceeds.

A key point that Wheeler makes is that while there has been a recent trend towards the development of custom platform-security chips, apart from the big players like Google and the potential to do so by other hyperscale cloud operators, most OEMs are unwilling to expend the resources that custom-chip development requires. “By providing a merchant but customizable solution, Lattice delivers similar capabilities without the burden of custom-silicon development.”

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.