Introduction
Today, there is general agreement amongst most stakeholders that IoT is not going to take off and reach its full potential unless we come up with a solid approach to securing both the “Things” in IoT and the communication between them. An Arm-led initiative which is specifically relevant to device OEMs and silicon manufacturers is the Platform Security Architecture or PSA. PSA is a framework that aims to secure a trillion connected devices by providing a scalable and hardware-backed approach to threat analysis, system architecture and reference implementations for IoT devices.
In this article we will show how SRAM PUF technology is a very good fit to some of the most fundamental PSA objectives. In particular it enables a strong and flexible protection for the heart of the Root of Trust: the immutable Root of Trust – the part that stays unchanged over the lifetime of a device.
PSA Requirements
The following definition is taken from PSA Security Model:
The Root of Trust of a PSA device is a multi-tier Root of Trust made up of immutable and updatable components working together to ensure:
- The integrity of the device and its updatable components
- The integrity of trust chains, both within the device and within an ecosystem
- The privacy and integrity of secrets, and of operations performed using secrets
- Separation and isolation of more trusted components from less trusted components
The PSA Root of Trust is itself partitioned into an immutable portion and an updatable portion. The immutable PSA Root of Trust is the initial Root of Trust for all PSA Root of Trust services and never changes on a production device. The updatable PSA Root of Trust represents all of the most trusted software components, providing a common trusted platform.
The Immutable Root of Trust consists of fixed and tamper resistant hardware security resources, such as boot ROM and root parameters. This is the true “anchor” on which all subsequent trust necessarily depends. It follows that the security of the complete system can only be as strong as this Immutable Root of Trust itself (weakest link principle).
As an example of such immutable Root of Trust, consider the picture below:
In this picture we see the most crucial ingredients to a Root of Trust: TRNG, Boot ROM, Key derivation functions and Root Key. Let’s zoom in on the part that can be rightfully be considered the crown jewels: the Root Key. This Root Key is a value that determines what is device unique: compromise of this Root Key opens the way to potential cloning of the device as well as intercepting encrypted communications and spoofing authentication. It follows that the way this root key is stored is highly relevant to overall system security. Let’s therefore have a look at the options we have available for protecting this Root Key.
Traditional Key Generation and Storage Methods
Several methods for generating a Root Key and storing it on a device exist. Let’s discuss the most widely used traditional methods for getting keys on IoT devices.
Secure Elements 
Globalplatform.org defines a Secure Element (SE) as a tamper-resistant platform (typically a one-chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.
Secure elements destined for IoT devices are typically purchased from a silicon vendor with all required keys pre-provisioned on the chip by this vendor. This means that the IoT device maker does not need to deal with provisioning keys for his device, but the SE approach comes with significant downsides, such as increased costs and complexity in purchasing, supply chain and inter-chip interfacing.
Key Injection 
Another option for storing keys on IoT devices is injecting keys into your device, which can happen at any of a number of places in the supply chain. Using this approach, the Root Key is generated outside the electronic device and injected during the production process. Typically, this needs to take place at an early stage in the supply chain (e.g. at the chip maker), because many parties in the supply will need to make use of the Root Key, for example at chip distribution or device manufacturing. After injection, the Root Key is stored on the device. Most widely used embedded key storage methods are based on Non-Volatile Memory (NVM) such as EEPROM and Flash, or on One-Time Programmable (OTP) memory such as fuses and anti-fuses. With these memory types, the provisioning of Root Keys comes with trade-offs among flexibility, key-exposure liability, cost, reliability and security.
Random Number Generation 
The third method for provisioning keys for IoT devices is to use an internal random number generator (RNG) on the chip that requires a Root Key, let it derive a random secret and store this in NVM or OTP. This means key generation is handled internally, but key storage remains the same as with the method of key injection. Using this method increases the flexibility within the supply chain compared to key injection (assuming the target chip contains a random number generator), but it does not make any difference regarding how the Root Key is actually stored.
Each of the above methods comes with downsides in terms of cost (SE), flexibility (OTP/(anti-)fuses) or security (NVM/(anti-)fuses). They all have in common that some physical alteration is made to the silicon which represents the Root Key material. This implies a vulnerability to ever more powerful reverse-engineering attacks.
The Alternative: Securely Generating and Storing Keys with SRAM PUFs
An alternative approach (developed at Intrinsic ID) to these traditional methods of generating and storing Root Keys is an SRAM Physical Unclonable Function, or SRAM PUF. This uses the behavior of standard SRAM memory available in any digital chip, to extract a unique pattern or “silicon fingerprint.” They are virtually impossible to clone or predict. This makes them very suitable for applications such as secure key generation and storage, device authentication, flexible key provisioning and chip asset management.
Due to inherent deep sub-micron process variations in the production process, every transistor in SRAM cells has slightly random electric properties. This randomness is expressed in the start-up values of uninitialized SRAM memory. These values form a unique chip fingerprint, called the SRAM PUF response. Even though these values are slightly noisy between start-ups of the same device, they are turned into stable keys and form an excellent basis for the trust for your system.
Key Generation and Storage based on SRAM PUF 
Intrinsic ID provides the IP, both as hardware IP and software library, that turns this slightly noisy fingerprint of the chip into a reliable Root Key. Whenever the Root Key is needed by the system, the IP reliably reconstructs it without the need for storing this Root Key in any form of memory. This means that when the device is powered off, no secret key can be found in any memory; in effect, the Root Key is “invisible” to hackers. So a tree of cryptographic keys (starting from the PUF Root Key) can be (re-)created without storing them in a memory, removing the need for a device to have any physical form of secure storage. This takes care of some of the problems inherent to the traditional key storage methods. More details about the basic functionality of SRAM PUF can be found in the White Paper “SRAM PUF The Secure Silicon Fingerprint”, while details about how to use this technology for key provisioning can be found in “Flexible Key Provisioning with SRAM PUF”.
As a recent example, NXP has announced 2 new chips based on Cortex-M33. In these devices, PSA-principles and SRAM PUF are combined to achieve a strong protection. These devices are perfect examples of how SRAM PUF can be used as solid foundation for PSA-based devices. For more background information on using the technology and its application for protecting the IoT please refer to the latest Whitepaper. You can also learn more about Intrinsic ID below.
Leave a Reply