Easily Ensure IoT Security with SRAM-Based PUF Keys and TrustZone Isolation

Designs built around the Internet of Things (IoT) are increasingly complex, requiring improved solutions to ensure system security and to check the relentless onslaught of local and remote attacks. However, the adoption of security on resource-constrained IoT devices has been slow and confined to either loosely constructed software patch-ups or highly sophisticated and expensive chips built around complex cryptographic algorithms. Developers need a more comprehensive yet easier-to-use solution if they are to more quickly adopt and implement security.

Technologies such as static random access memory (SRAM)-based physical unclonable functions (PUFs) and Arm’s TrustZone have emerged and evolved to meet the security needs of embedded and IoT developers. This article introduces PUF and TrustZone and how they can be applied using solutions from NXP Semiconductors, Microchip Technology, and Maxim Integrated.

SRAM PUF technology

The SRAM PUF, a lightweight authentication alternative to traditional cryptography, is being integrated into security-centric chips such as NXP’s LPC55S6x family where it adds root of trust and provisioning (Figure 1).

Figure 1: The block diagram of the LPC55S6x family of MCUs shows the integration of security building blocks like SRAM-based PUF technology. (Image source: NXP)

PUF technology is unlike traditional key storage in non-volatile memory where OEMs inject security keys either through a traditional fuse-based methodology or via one-time programmable (OTP) memory techniques. Instead, PUF technology takes natural, random electrical variations intrinsic to the SRAM bit cells and turns that unique “fingerprint” into a secret cryptographic key that serves as the foundation of a security subsystem. This secure, high-quality key can be reconstructed as the same cryptographic key every time and under all circumstances. There are a number of advantages to this approach:

• It eliminates the need for third-party key handling in potentially insecure environments
• The key storage and provision system doesn’t have to be loaded at the time of chip production
• It can be installed at a later stage in the supply chain or can even be retrofitted on deployed devices
• Without physical access to an individual SRAM chip, deciphering these security keys becomes a nearly impossible task
• Keys are generated only when required and don’t remain stored on the system
• The fact that the key is not permanently stored and is not present when the device isn’t active makes it very hard for an attacker to physically attempt to compromise the memory contents

Arm TrustZone

Optimized for ultra-low-power embedded applications, the TrustZone technology, available in Arm Cortex®-M23 and Cortex-M33 processing platforms, places safety critical routines such as boot code, secure configuration, security keys, encryption libraries, and firmware updates in a protected environment (Figure 2). In a TrustZone-enabled microcontroller, for instance, the mission critical code is fully tested after being separated from large code stacks to prevent it from being affected by a bug generated by the developers.

Figure 2: TrustZone enables multiple software security domains that each restrict access to secure memory and I/O to only trusted software environments. (Image source: NXP)

With regard to confidential data and code, TrustZone ensures its safety by isolating the critical parts of the software design and running that software on a hardware supervisor in an environment that is read and write protected from user-level software.

TrustZone lets developers divide memory into secure and non-secure regions such that even a debug attempt can be blocked from secure code and data when not authenticated. Also, a CPU in a non-secure state can only access data from non-secure memory and thus only execute from non-secure program memory.

Importantly, TrustZone provides these security features yet still preserves low interrupt latencies for both secure and non-secure domains. Furthermore, it doesn’t impose code overhead, cycle overhead, or the complexity of a virtualization-based solution.

Physical implementation of PUF and TrustZone

NXP has integrated hard IP—and supporting software libraries—from PUF inventor Intrinsic ID to implement PUFs in its LPC55Sxx microcontrollers (Figure 3). Intrinsic ID’s embedded hardware IP, QuiddiKey, handles key generation, key storage, device authentication, key provisioning, and chip asset management.

Figure 3: NXP has integrated hard IP and supporting software libraries from Intrinsic ID to implement PUFs in its LPC55Sxx microcontrollers. The IP handles key generation and management. (Image source: Intrinsic ID)

NXP has also adopted TrustZone for its LPC55Sxx microcontrollers. TrustZone’s CPU-centric approach to IoT security creates isolation between the secure and non-secure parts of the embedded design.

For example, as implemented on Microchip Technology’s SAM L10/11 microcontrollers, TrustZone provides a system-wide protection arrangement in which IoT designs can be divided into secure and non-secure states. However, both secure and non-secure code run on a single CPU for efficient embedded implementation.

This CPU-centric approach is important as the amount of software is rapidly growing in modern microcontrollers, with protocol stacks serving connectivity technologies like Wi-Fi, Bluetooth, and Transport Layer Security (TLS). This increasing codebase significantly increases an IoT device’s exposure to malicious attacks. For instance, in smart homes and buildings, a corrupted protocol stack can make connected door locks, garage door openers, and security cameras highly vulnerable.

However, if IoT developers move the mission-critical code to a TrustZone protected environment, even a bug in a third party protocol stack won’t seriously impact the device functionality.

Board-level security

Another clear pattern in the IoT security paradigm relates to the availability of reference designs that simplify edge-to-edge and cloud-to-edge communications by overcoming the complexities associated with security and communication protocols. The MAXREFDES155#DeepCover® reference design from Maxim Integrated and Microchip’s AC164164PIC®-IoT WG development board are a case in point.

In the MAXREFDES155# security design, an Arm mbed™ shield is connected to a sensor endpoint using a 300 millimeter (mm) cable. The sensor endpoint comprises a DS28C36 DeepCover secure authenticator, an infrared (IR) thermal sensor, and an aiming laser for the IR sensor (Figure 4).

Figure 4: Maxim Integrated’s MAXREFDES155# DeepCover IoT embedded security reference design comprises an Arm mbed shield, a sensor endpoint connected over I²C, and connectivity to the cloud over Wi-Fi. (Image source: Maxim Integrated)

The DS28C36 security chip provides two authenticated general purpose input/output (GPIO) pins with optional secure state control and level sensing. This allows IoT developers to monitor and limit the peripheral usage with authenticated electrically erasable programmable read-only memory (EEPROM) settings and a 17-bit decrement-only counter. The applications that the DS28C36 facilitates are bi-directional authentication, secure storage of system data like cryptographic keys, verification of mission-critical data, secure boot, and end-product usage control.

The mbed shield in the MAXREFDES155# reference design includes a DeepCover security coprocessor, Wi-Fi communication, liquid crystal display (LCD), push-button controls, and status light-emitting diodes (LEDs). The reference design uses the MAX32600MBED# mbed development board for immediate testing and the shield’s Wi-Fi circuitry facilitates communication with the web server.

In the MAXREFDES155# design, a security coprocessor on the mbed shield serves as a companion to the DS28C36 authenticator chip. It facilitates requirements related to the Hash-based Message Authentication Code (HMAC) and Elliptic Curve Digital Signature Algorithm (ECDSA) computations that are part of the DS28C36’s security operations.

The coprocessor provides a core set of cryptographic tools to help IoT designers implement crypto engines and integrate a Federal Information Processing Standards/National Institute of Standards and Technology (FIPS/NIST) true random number generator (RNG). The public and private security keys operate according to the standards defined by NIST, which includes FIPS 186, the ECDSA signature generation and verification mechanism that supports a bidirectional asymmetric key authentication model.

Simplifying cloud link security

Microchip’s AC164164 PIC-IoT WG development board has similar elements but focuses on simplifying the IoT node’s link to cloud platforms like Google Cloud. Built around the company’s PIC microcontrollers, the development platform uses the ATECC608A coprocessor to address security vulnerabilities that come with large software frameworks and real-time operating system (RTOS) platforms.

The AC164164 is an IoT design platform in which the security of the edge-to-cloud link has been ensured with a secure element that comes pre-registered for the Google Cloud IoT Core service and is ready for use with zero-touch provisioning. Along with the ATECC608A security coprocessor, the development board features the PIC24FJ128GA705 microcontroller, which handles complex applications with less code and with lower power consumption.

A fully-certified IEEE 802.11b/g/n IoT Wi-Fi controller links the IoT node to Google Cloud. As a result, IoT developers don’t require expertise in wireless networking protocols, security, and hardware compatibility to realize a secure IoT product design.

Conclusion

The availability of specialized security chips, which act as a companion chip to the main processor or microcontroller in IoT designs, allows developers to secure IoT nodes and links to endpoints as well as to cloud platforms without being security experts. The integration of complementary technologies like PUF and TrustZone further boosts the security credentials of these low-power, low-cost microcontrollers as IoT security requirements increase.

On top of that, reference designs and development boards further simplify the security equation by employing multiple levels of embedded protection in a wide variety of IoT applications.