Using SRAM PUF for IoT Security

Article By : Geert-Jan Schrijen

This article covers the basics of what an SRAM PUF (physical unclonable function) is and how it works, as well as the functionality it offers in Internet of Things (IoT) security.

This article covers the basics of what an SRAM PUF (physical unclonable function) is and how it works, as well as the functionality it offers in internet of things (IoT) security as the trust anchor for any device.

In any given situation, security starts with trust. When you have an alarm system in your house, you give out its pin code only to people you trust. Whether it is a family member or your friendly neighbor, without trust you do not share your secret. And that is how it is supposed to be!

This matter of trust also translates to personal identification. Here the foundation of trust comes from formal documents, such as a passport or a birth certificate. However, these documents need to be “securely linked” to a specific person. This typically works with human biometrics. ID papers all have something that ties the document to the right person, whether it is merely a picture of the person or biometric identification through fingerprints, as in modern passports. So, the biometrics are the security anchor on which a system with permissions (do you get to cross the border?) is built.

This security anchor is necessary to prevent a simple document from being copied and used by unauthorized parties. If the document is anchored to something that cannot be copied or cloned, like fingerprints, the security becomes strong enough to turn a relatively simple document into a powerful authentication tool.

A similar challenge holds for the internet of things (IoT). Secure connection of billions of low-cost devices is only possible if every device has the capability to protect sensitive data and secure communications. This protection is provided by certificates and cryptographic keys, similar to the passport in the previous example. However, these keys and certificates also require a physical security anchor to make sure that they cannot be copied to a rogue device, impersonating a genuine one. A technology that provides this security anchor are physical unclonable functions (PUFs). A PUF is a physical structure from which a device-unique and unclonable cryptographic root key is generated. This root key is used to protect the application keys and certificates of a device.

While there are many different types of PUFs, we will focus on the SRAM PUF because of its reliability, scalability, and ease of use. The SRAM PUF is easy and flexible to implement in a way that scales over the many different technology nodes deployed across the IoT. It is also the only PUF type known today that can be implemented simply by loading software onto a chip (as an alternative to integrating a dedicated hardware IP block, which is also possible). The SRAM PUF is a hardware-based security anchor growing in popularity because of the ever-increasing number of connected devices.

What is an SRAM PUF?

A PUF utilizes deep submicron variations that occur naturally during semiconductor production, and which give each transistor slightly random electric properties.  These unique properties form the basis of a chip’s unique identity.

An SRAM PUF is based on the behavior of standard SRAM memory that is available in any digital chip. Every SRAM cell has its own preferred state every time the SRAM is powered, resulting from random differences in the transistor threshold voltages. Hence, when powering SRAM memories every memory will yield a unique and random pattern of 0s and 1s. These patterns are like chip fingerprints, because each one is unique to a particular SRAM and hence to a particular chip.

However, this so-called SRAM PUF response is a “noisy” fingerprint and turning it into a high-quality and secure cryptographic key requires further processing. By using so-called “Fuzzy Extractor” IP it is possible to reconstruct exactly the same cryptographic key every time and under all environmental circumstances.

This way of deriving a key from the SRAM properties has great security advantages compared to traditional key storage in non-volatile memory (NVM). Because the key is not permanently stored, it is not present when the device is not active (no key at rest), and hence cannot be found by an attacker who opens up the device and compromises its memory contents.

How can SRAM PUFs be used as a root of trust?

Devices, particularly devices that are part of the IoT, require keys to protect their data, IP, and operations. If the origin of these keys can be trusted and the keys are stored securely in hardware that protects against attacks, they form the so-called “root of trust” of the device.

The keys can either be provisioned onto the devices by the device manufacturers (also called OEMs) themselves or in an even earlier stage by a chip vendor. When chip vendors supply pre-provisioned chips, this increases the value of the product they are selling to the OEMs. If OEMs decide to do provisioning themselves, they can typically buy chips that cost less.

Regardless of which of the two parties takes on the responsibility of provisioning the cryptographic keys, it is never a trivial task to perform. Injecting secret keys into chips requires a trusted factory, it adds cost and complexity to the manufacturing process, and limits flexibility. This complexity can be avoided by having the keys be created inside the chip, either by using an internal random number generator (RNG) or a PUF.

Getting a cryptographic root key onto a device is not the only challenge. Securely storing sensitive data on devices is also far from trivial. Secret keys cannot be stored simply in NVM, as NVM is vulnerable to hardware attacks. Hardware attacks that allow adversaries to read NVM content are becoming increasingly more common, making unprotected key storage unviable. Hence, there is a need for alternative secure key storage. One approach would be to add a secure element to the device. However, adding hardware also comes with increased complexity and cost. A silicon PUF, such as the SRAM PUF, can securely store cryptographic keys without the need to add any additional hardware.

The table below summarizes the security level, supply-chain overhead, and cost of the technology options for provisioning and storing cryptographic keys:

Creating a key vault with an SRAM PUF

When we have this root key from the SRAM PUF, what is the next step to create the root of trust? The next step is to utilize the SRAM PUF key for creating an embedded key vault to protect all secret data on a device. The keys protected by this vault are required for the higher-level services and applications of the device. Thus, the key vault enables security applications such as authentication, message encryption, software/firmware encryption and much more.

With the SRAM PUF we can create a key vault with the following properties:

• No keys are ever stored in the plain – in particular the topmost or “root” key
• Different applications can store and use their own unique keys
• Key vault output can be sent directly to a hardware crypto engine

An SRAM PUF-based key vault implements the following functions:

• Enroll: The enroll operation is typically executed once in the device lifecycle. It establishes the PUF root key that can be reproduced over the device lifetime. The PUF root key never leaves the device and is never stored. It is used to derive a second layer of keys that can be output or used to wrap/unwrap sensitive data. Additionally, helper data for error correction is created. This data is non-sensitive – it does not provide any information on the PUF root key – and so can be stored in NVM accessible to the device. The helper data is only used to reliably reconstruct the same root key from the SRAM PUF upon subsequent read-outs of the inherently noisy PUF.

• Start: The start operation re-generates the internal PUF root key, using the helper data that was generated during Enroll, in combination with a fresh, “noisy” SRAM PUF measurement. The helper data that is generated on a device is unique to that device. Using helper data that is copied from a different device when executing a start operation leads to a failed operation with appropriate error indication.

• Wrap: The wrap operation converts an externally provided key to a key code (KC), which is an encrypted and authenticated version of the original key. Because of this protection, the KC can be stored unprotected in the plain. The KC will allow the original key to be accessed only on the device on which it was “wrapped.”

• Unwrap: The unwrap operation is the reverse of the wrap operation, so it converts a KC back into the original key that was wrapped, after verifying its authenticity.

• Stop: The stop operation can be issued whenever there is no imminent need to perform further key vault operations. It clears all sensitive data, including the root key, from the internal registers and can be used before entering sleep mode to reduce attack surface.

Deriving multiple keys from a PUF

An implementation of a security system typically requires more than a single cryptographic key. This is because:

• the compromise of a particular key for one application should not affect the security of secrets used by other applications in the same system, which requires that different applications in a system use different keys.
• different cryptographic algorithms in the system expect keys with different lengths or different structures which are incompatible with each other.
• different applications require secrets with different lifetimes, e.g., one application of the system needs several short-lived keys, while a second application requires a single long-lived key.
• keys are often associated with identities and used for authentication purposes, which is only meaningful if different users of the system have access to different keys.

For these and other reasons, it is a well-established best practice in security design to use a single key only for a single purpose and/or a single application. However, in many practical situations, an implementation of a security system only has access to a single root secret, as in this case, from the SRAM PUF. To meet the single-key-single-use requirement, a key management component with the ability to generate multiple application keys from that single root secret should be used.

A crucial property of multiple generated application keys is that they are cryptographically separated, i.e., they should be generated in such a way that the disclosure of a particular derived key does not affect the security strength of any other derived key. This means that simplistic generation methods (e.g., applying simple arithmetic operations or using overlapping portions of a secret) are out of the question. Instead, a cryptographically secure key derivation function (KDF) should be used, which uses cryptographic primitives (e.g., AES or SHA-256) to ensure cryptographic separation between its outputs. Hence, utilizing a well-implemented KDF will ensure that a virtually unlimited number of keys can be derived from a single SRAM PUF instance.

Implementing an SRAM PUF via software

One of the biggest benefits of an SRAM PUF that has not been addressed yet is that it is based on a physical structure that is available in virtually any chip: the SRAM memory. Because this PUF type uses standard “off-the-shelf” SRAM, it is the only hardware entropy source option for securing IoT products that does not need to be loaded at silicon fabrication. It can be installed later in the supply chain, and even remotely retrofitted on deployed devices. This enables a never-before-possible remote “brownfield” installation of a hardware root of trust and paves the way for scaling the IoT to billions of devices.

The functions described earlier for creating a key vault and for deriving multiple keys can be implemented as either hardware or software IP. The only hardware required in order to develop a PUF is the actual unique physical structure of the PUF itself. So, on any device where access to (uninitialized) SRAM is available to the PUF algorithms, a working SRAM PUF can be implemented. This property makes the SRAM PUF unique among the spectrum of different PUFs in the market. To the knowledge of the author, the SRAM PUF is the only currently existing type of PUF that can be implemented in hardware by simply loading software onto a device.

Conclusion

Without trust there is no security. Any security solution starts with something that will prove the identity of the subject – whether that subject is a person to be issued ID papers, or a chip to be deployed in the IoT – beyond a shadow of a doubt. In this article, we presented SRAM PUF technology as a reliable, scalable, and easy-to-use root of trust for any IoT device. Whether it is implemented as a dedicated hardware IP block or as software loaded onto a device, it creates a trusted cryptographic root key from tiny, device-unique variations in the silicon of chips. Using an SRAM PUF, it is guaranteed that the root key of a device is not known to anyone in the supply chain and cannot be altered or cloned if the device falls into untrusted hands. By extending security functionality on top of this root secret, a trusted vault for sensitive data and secret keys can be built and all additional keys required by the device can be derived and protected. That is why SRAM PUFs are a great way to secure your system from the ground (or the silicon) up.

This article was originally published on Embedded.

Geert-Jan Schrijen, CTO & co-founder of Intrinsic ID, received his master’s degree in electrical engineering from the University of Twente in 2000 on the topic of “active noise cancellation with multiple loudspeakers.” In 2001 he joined the security group of Philips Research in Eindhoven where he worked on digital rights management, low-power authentication protocols, private biometrics and physical unclonable functions (PUFs). The latter work resulted in the spin-off of Intrinsic ID in 2008. Geert-Jan focused on the development of signal processing algorithms and security architectures for embedded systems using PUF technology. In 2011 took on the role of VP engineering and was then appointed as CTO in 2016.

Subscribe to Newsletter