Editor’s Note: Part 1 of this two-part series examined how to optimize NXP Semiconductors’ LPC55S6x general-purpose microcontroller (MCU) for high performance at low power. Here, Part 2 shows how to optimize that same microcontroller for lifecycle security management.
For developers of microcontroller-based systems, the breadth of design requirements for fast-growing applications such as the Internet of Things (IoT), industrial automation, or personal electronics, too often forces a compromise between system functionality, performance, or power consumption. In the face of growing security threats, the need to tighten security in these designs adds a further challenge that can leave developers with even fewer viable microcontroller solutions. Developers need a microcontroller able to support not only more familiar requirements for reduced power consumption and high performance, but also escalating demands for security through all phases of the design lifecycle including provisioning, communications, secure boot, secure firmware update, and more.
Part 1 introduced the NXP’s LPC55S6x microcontroller family and described how its features address requirements for performance and low power consumption. Here, Part 2 discusses how extended security features integrated in LPC55S6x microcontrollers support lifecycle security from provisioning and communications through secure boot and secure firmware updates.
As described in Part 1, NXP’s single-core LPC55S66 and dual-core LPC55S69 microcontrollers combine the Arm® Cortex®-M33 general-purpose processor core with hardware capabilities designed to address more specialized application requirements. Among these capabilities, hardware-based accelerators for symmetric and asymmetric cryptography provide fundamental mechanisms needed for secure communications. In the past, cryptography accelerators were deemed sufficient for basic security features like data protection. Today, however, user expectations for more comprehensive security features have driven more complex requirements for lifecycle security extending from provisioning in manufacturing through commissioning in the field, along with secure boot and secure firmware update.
Achieving this extended protection requires a comprehensive set of security protocols and policies that lie well above the hardware level. Even so, the effectiveness of any security protocol depends critically on the availability of suitable hardware-based mechanisms that both speed execution and eliminate or reduce the threat surfaces that inevitably appear in any connected device.
The LPC55S6x architecture provides this kind of hardware-based support for lifecycle security with an array of capabilities, starting with its support for Arm TrustZone® technology and continuing with the multiple layers of protection required to achieve an effective level of security.
TrustZone support
TrustZone provides a foundation for security through its ability to isolate code execution and data to specific secure and non-secure domains. During program execution, the primary Cortex-M33 core switches between a number of different execution states associated with different code execution modes. These CPU states and code execution modes include:
- Secure privileged, for executing kernel level code or device handlers
- Secure non-privileged, for executing secure user code
- Non-secure privileged, for execution typical system calls
- Non-secure non-privileged, for executing typical user applications
The distinction between privileged and non-privileged execution is critically important for overall operating system robustness. For the purposes of this article, however, we can lump those execution modes together, focusing just on the difference between secure and non-secure operation. In the TrustZone architecture, the switch from secure to non-secure CPU states invokes hardware-supported limitations on the core to access program memory or data.
In its secure state, the core can access data in both secure and non-secure regions of memory but cannot access code stored in a non-secure region of memory (Figure 1, left). In its non-secure state, the core can only access code and data from non-secure regions of memory (Figure 1, right).
Figure 1: With their support for Arm TrustZone, NXP’s LPC55S6x microcontrollers ensure that a core operating in the secure (S) state (left) can only fetch instructions for S-state program memory, while a core operating in non-secure (NS) state (right) cannot reach code or data stored in S-state memory. (Image source: NXP Semiconductors)
The LPC55S6x MCU architecture exerts this control at the lowest level of bus access, mitigating common threat surfaces such as buffer overflows used by attackers to cause non-secure unprivileged code to gain backdoor access to “protected” regions. Here, NXP uses the Arm TrustZone Security Attribution Unit (SAU) with its own Implementation Defined Attribution Unit (IDAU) designed to completely isolate secure kernel code from application code. The SAU provides the security state (secure or non-secure) and identifies whether the instruction is from an allowed region of memory. The IDAU interfaces with the device attribution unit (DAU) to provide increased granularity, working with the SAU to determine the security attribute of a specific address. The result is a bus request delivered at the appropriate security and privilege levels (Figure 2).
Figure 2: NXP’s LPC55S6x microcontrollers protect access at the bus transaction level, using the Arm TrustZone SAU with its own IDAU to ensure that system bus requests operate at appropriate security and privilege levels. (Image source: NXP Semiconductors)
Secure storage and peripherals
TrustZone protection mechanisms isolate application code and data during runtime, addressing data in use (one of the classic data security principles), which also includes data at rest and data in transit. Although typically associated with enterprise level data issues, these same principles apply for code and data in an embedded system. Here, a typical embedded system’s use of a microcontroller’s integrated flash memory for storing firmware images, code, and data can arise as a significant attack vector. The LPC55S6x device mitigates this threat through an encryption/decryption algorithm called PRINCE. [Note to readers: PRINCE is not an acronym.]
The PRINCE algorithm is well-suited to security implementations in embedded systems thanks to its speed and minimal resource requirements. Implemented in hardware in LPC55S6x devices, the PRINCE algorithm operates in real time, decrypting or encrypting data on the fly as the data is read or written. Unlike many other crypto algorithms, the PRINCE algorithm does not need to use RAM to hold the original data or intermediate results, which eliminates another security vulnerability. As a result, developers can more safely store application code, firmware images, and even secure keys in the microcontroller’s internal flash.
Although crypto engines and secure flash storage lock down data exchange and storage, a secure embedded system needs the same level of security for its interactions with sensors and transducers. Along with its secure DMA capabilities, the LPC55S6x MCU architecture provides mechanisms that further secure exchange between the core or other bus masters and its integrated peripherals, memory, or GPIO (Figure 3).
Figure 3: NXP’s LPC55S6x microcontrollers combine their multilayer bus matrix with MSWs, MPCs, and PPCs to isolate and secure transactions between the devices’ different bus masters and their peripherals and memory. (Image source: NXP Semiconductors)
In this protection scheme, memory protection checkers (MPCs) limit memory access by less secure applications. Peripheral protection checkers (PPCs) provide the same type of access control for peripherals, allowing developers to set different access rules for different peripherals. Since the SAU/IDU mechanism is available only to the primary Cortex-M33 core, master security wrappers (MSWs) are used to provide similar access protection for other bus masters. Because the multilayer AHB matrix creates a dedicated path between bus masters and peripherals or memory, the result is a secure internal bus connection that is isolated from other bus transactions that might be occurring in the device.
The LPC55S6x MCU architecture further isolates secure and non-secure access to external devices through its secure GPIO system. This system extends the same sort of isolation to GPIO pins that the TrustZone mechanisms create between secure and non-secure CPU states and code execution modes. Thus, secure GPIO pins can be accessed only by the primary Cortex-M33 core operating in a secure state, enabling developers to secure signals from critical external devices.
Secure key management
The various protection mechanisms described thus far in this article provide the foundation of a secure embedded system. To connect that system securely to a network, smartphone, or other host, however, developers need the ability to authenticate the target of the connection during initial commissioning and ongoing transactions, and the ability to maintain a securely encrypted communications channel. In turn, the security of the asymmetric and symmetric cryptography algorithms at the heart of authentication protocols and encryption mechanisms ultimately depends on the security of the private keys used within these protocols and mechanisms.
Using its integrated Physical Unclonable Function (PUF), LPC55S6x microcontrollers provide a highly secure mechanism for securely storing existing keys and generating new ones. This approach revolves around the ability of the PUF hardware to create a unique PUF root key that is used to encrypt other user keys. The uniqueness of the PUF root key derives from the use of internal device functions along with SRAM startup data, which is derived from the random 0 and 1 contents of SRAM cells at power on. During the PUF enrollment stage, the device uses these two sources of random data to create a digital fingerprint and an associated 1192 byte activation code (Figure 4).
Figure 4: The NXP LPC55S6x microcontrollers’ integrated PUF uses the random state of SRAMs at startup and other internal functions to generate a digital fingerprint and activation code used for subsequent key generation and storage operations. (Image source: NXP Semiconductors)
During device provisioning at the factory or later in the field, this activation code is stored in the customer in-field programmable area (CFPA) in the device’s protected flash region. Each time the microcontroller is powered on and the PUF is activated with the PUF Start command, the PUF combines the existing activation code with the SRAM startup data to reconstruct the digital fingerprint.
After this PUF Start procedure, the PUF SetKey command causes the PUF to encode user keys such as shared master keys provisioned at the factory or private keys provided by developers for their applications. Here, the PUF generates a key code for the corresponding user key based on the key size, a key index, and the user key itself (Figure 5).
Figure 5: NXP’s LPC55S6x PUF provides a SetKey function that encodes a user key and key index using its digital fingerprint, providing a key code used later to access the original user key. (Image source: NXP Semiconductors)
Developers can also generate new keys using the PUF GenerateKey command, which uses the same generation process as SetKey but with unique, internally generated data replacing the KEYIN function show in Figure 5. Keys set or generated with key index = 0 gain further protection as noted below.
To use keys, developers invoke the PUF GetKey command to retrieve the original user key with two different output paths depending on the value of the key index used when the key was set or generated. If the key index is greater than zero, the user key is available through the PUF CODEOUTPUT register. If the key index equals zero, the user key is passed directly to the AES engine or to the PRINCE engine’s three supported flash memory regions as specified by the value of KEYENABLE (Figure 6). Although not directly involved in key retrieval, the PUF’s 4-bit KEYMASK register supports an internal mechanism designed to mitigate side-channel attacks.
Figure 6: To access keys, developers use the NXP LPC55S6x PUF GetKey command. This uses the key index and key code generated during SetKey (or GenerateKey) operations to output the original user key or send it through a private bus to the microcontroller’s crypto accelerators. (Image source: NXP Semiconductors)
Zero-index keys help harden lifecycle security even starting at the factory provisioning stage. Once provisioned through PUF SetKey, a shared master key used for symmetric cryptography or the private key used for asymmetric cryptography never leaves the device or even enters the system bus. Instead, key transfer to the AES or PRINCE engines occurs internally through a dedicated hardwired interface that is not accessible by software.
The PUF key management mechanism and the microcontroller’s other security features come together for other lifecycle security phases including secure boot and firmware update. For secure boot, the LPC55S6x supports multiple protection methods including authentication of RSA2048 signed images using validated X.509 certificates or decryption of images stored in a PRINCE flash region. In either case, the bootloader securely retrieves the necessary keys for certificate validation or image decryption from PUF key storage using PUF-generated key hashes stored with the images in the protected flash region.
Firmware update uses similar mechanisms to authenticate an over-the-air update firmware image, decrypt it, and ready it for boot.
Beyond the immediate needs of secure boot and firmware update, the device’s multiple key storage slots and key generation capabilities support ongoing security lifecycle requirements for revocation of keys and certificates. In turn, this key management capability supports higher level security policies such as firmware image revocation.
Developers can quickly explore the capabilities of LPC55S6x microcontrollers using the NXP LPCXpresso55S69 development board in combination with NXP’s MCUXpresso integrated development environment (IDE), IAR, or Keil IDEs. Integrated in the MCUXpresso IDE, MCUXpresso Config Tools helps developers set up MCU hardware and generate initialization code. Within this configuration toolset, the trusted execution environment (TEE) tool lets developers more easily configure the LPC55S6x MCU’s multi-level security access. Using the TEE tool’s graphical interface, developers can refine access privileges to memory, bus masters, and peripherals for each of the four CPU state and execution modes described earlier (Figure 7).
Figure 7: Within the NXP MCUXpresso Config Tools utility set, the trusted execution environment tool’s graphical interface lets developers set access privileges to memory, bus masters, and peripherals for code running in the four CPU states and execution modes (Image source: NXP Semiconductors)
For code development, NXP also provides a number of simple code examples that provide the basic design patterns for using the microcontroller’s security features such as secure GPIO, PUF key management, and other device capabilities. Even during the development phase, however, the LPC55S6x MCU helps maintain lifecycle security through its single wire debug (SWD)
authentication capability. With this capability, authorized developers can debug their secure code and disable any further SWD access to secure resources before turning development over to non-secure-software developers. In turn, after those developers finish their code debug, they can disable all debug access through the SWD port.
Conclusion
Developers face growing demand for low-power, high-performance designs able to maintain security throughout the entire lifecycle from provisioning in the factory to secure operation in the field. As described here, the NXP LPC55S6x family of microcontrollers offers an effective solution that combines general-purpose processing capabilities with an extensive set of specialized hardware features required to support lifecycle security.
