Standardized PUF-based Solution for Device eID

By Dr. Albert Jeng, PUFSecurity

1. Introduction

Generally speaking IoT/AIoT networks require strong identification /authentication, secure update, secure boot, secure communication, and data encryption for IoT devices [1]. Typically, the IoT device logs in on its own and sends data on its own. Consequently, authenticating the potentially billions of IoT devices to the server and among themselves becomes a big concern. Thus, securing distributed IoT networks requires verifying the authenticity of data and identities of devices. Since eID is normally used to describe the distinct and non-ambiguous properties and characteristics of a person, by analogy, we’ll use the name “Device eID (DeID)” to represent a unique, trusted and non-forgeable identity of a machine or device.

There are many well-known attacks and growing identity thefts that make identities on either the Internet or IoT vulnerable to unauthorized use, abuse, or misuse. Since the use of identities is the key for much policy-based security control such as permissions, access-controls and authorization, there have been a few works in proposing how to standardize the device identification including IEEE 802.1AR, IETF RFC 4423 Host Identity Protocol (HIP) Architecture, I3, etc. [2][3][4] The most well-known one is IEEE 802.1AR.

Conceptually, 802.1AR standard advocated a privacy-preserving and trusted network-based identity called Secure Device Identifier (DevID) provision at the trusted network layer, which consists of three parts: Public Attributes (Public Key, Serial Number, Certificate, …), Secret Attributes (Private Key, …), and Crypto Functions (AES, RSA, ECC, …). The secret attributes need to satisfy many requirements since they are used for three major purposes: 1) Proofing the authenticity/integrity of public attributes; 2) Deriving keys to enable the crypto functions; and 3) Provision of the authentication credentials to authenticate devices. Furthermore, there is also a need for a device’s DevID module which stores each of its DevID secrets securely and supports signing operations that prove possession of the secret, while ensuring that the secret remains confidential so the device cannot be impersonated by others.

PUF is a physically defined “fingerprint” that serves as a unique identity for a semiconductor device. The inborn secrets of PUF are resilient to reverse engineering. A PUF generates a secret device ID for a chip (PUF-ID) due to the intrinsic device variations. The digital ID generated by a PUF has the same property as a conventional “random number”-based Unique Identifier (UID). Although a conventional UID is only used to identify an object for inventory control and tracking purposes, a PUF-ID can enable the “device eID” or IEEE DevID solution because: 1) It is an inborn identity for each device; 2) It is truly random (i.e., generated by physical entropy source), and 3) It is physically secured – against cloning and tampering. Thus, designing a verifiably authentic digital identity using PUF is a basic capability in networked IoT devices.

In this column, after a background introduction, we will first discuss IEEE 802.1AR standard on secure device identity. Next, we’ll assert PUF is an enabling solution for the device eID. Third, we will discuss PUF related international standards. Fourth, we will present a short tutorial on PUFiot. Fifth, we will assert that PUFiot is an ideal Device eID with wide applications. Finally, we will draw a conclusion on the future trend of Device eID development.

2. IEEE 802.1AR on Secure Device Identity

The IEEE 802.1AR standard specifies an identifier that is generally useful across IEEE 802 networks. Per IEEE 802.1AR-2018 [2], it defines a standard identifier for IEEE 802 devices that is cryptographically bound to that device, and defines a standard mechanism to authenticate a device’s identity in order to facilitate a secure device provisioning. A standardized device identity facilitates interoperable secure device authentication and simplifies secure device deployment and management for LAN, MAN, Internet and IoT.

The key concept of a standard identifier by 802.1AR are highlighted as follows:

1. A device with DevID capability incorporates a globally unique manufacturer-provided Initial Device Identifier (IDevID), stored in a way that protects it from modification.
2. The device may support the creation of Locally Significant Device Identifiers (LDevIDs) by a network administrator.
3. Each LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different IDevID without knowledge of the private key used to affect the cryptographic binding.
4. LDevIDs can incorporate, and fully protect, additional information specified by the network administrator to support local authorization conventions.
5. LDevIDs can also be used as the sole identifier to assure the privacy of the user of a DevID and the equipment in which it is installed.

In summary, 802.1AR advocated a privacy preserving and trusted network identity called Secure Device Identifier (DevID). A DevID comprises of the following:

1. A DevID secret that is the private key portion of a public-private key pair;
2. A DevID certificate containing the corresponding public key and a subject name that identifies the device; and
3. The certificate chain from the DevID certificate up to a trust anchor contained in the DevID trust anchor store available to potential authenticators. (However, if the DevID trust anchor store includes the certificate of the CA that signed the DevID certificate, there need not be an explicit certificate chain on the device).

There is also a need for a device’s DevID module with the following capabilities:

1. Stores and uses each of its DevID secrets securely within a controlled boundary (the cryptographic boundary);
2. Supports the mandatory service interface operations by limiting its use to specific service interface operations and preventing exfiltration;
3. Supports signing operations that prove possession of the secret (and thus that the device is the subject of the associated DevID certificate); and
4. Ensuring that the secret remains confidential so the device cannot be impersonated by others.

A device in possession of a DevID asserts its identity in authentication protocols. Once a device has been enrolled in a customer network it can use a DevID for authentication and as an input to authorization decisions. During the authentication phase, a device proves the identity associated with a DevID certificate by performing a signing operation that uses the DevID secret and sends the signature to the authenticator. The authenticator verifies the signature and if valid, then authentication is completed and the device gets authenticated.

There are a couple of things in [2] that require our special attention:

1. It’s clearly stated in 802.1AR that it draws on and intends to be compatible with two major standards: 1). Trusted Platform Module (TPM); and 2). Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). Notably, it specifically mentioned that TPM Keys for Platform Identity describes how TPM 1.2 can be used to provide DevID functionality.
2. Clause 7 of 802.1AR describes the functionality provided by a DevID
3. Module. It is stressed that a DevID module is a logical security component that stores and operates on the DevID associated with a device. The mandatory and optional functionality provided by the module including: storage for one or more DevIDs; asymmetric cryptography for signing, decryption, and integrity checking with a DevID secret; and random number generation for DevID secret (private key) generation. Each DevID module supports one or more of the signature suites specified in Clause 9.
4. It’s also stated that IETF RFC 7030 (Enrollment over Secure Transport) describes a certificate management protocol for Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. A client can use an IDevID, as defined 802.1AR, to participate in the enrollment protocol which supports both clients generated and CA generated public/private key pairs (LDevIDs).

If we use 802.1AR DevID as our model for DeID, based on the above concise description of 8o2.1AR and the analysis of DevIDs and their use as well as the DevID module and its operation, we can confidently conclude that PUF is an enabling solution for the device eID in the next section.

3. PUF is an enabling solution for a Device eID

This section presents a concise introduction to PUF and explains why PUF is an enabling solution for a Device eID.

Per popular definitions [1] [5], PUF is a unique physical characteristic derived from the intrinsic physical microstructure which was due to the manufacturing variations of the IC. Instead of embodying a single cryptographic key, PUFs directly support implementation of authentication. PUF provides a series of unpredictable bits which, is the inborn silicon “fingerprint” (or secret) of the IC. Therefore, the device’s identity could be established by employing the PUF properties embedded in the microstructure itself. Since the ‘‘secret’’ is derived from physical characteristics of the IC, any physical attack attempting to extract digital information from the chip must do so while the chip is powered on, this guarantees that the microstructure is not directly revealed and a PUF equipped device (i.e., the PUF-ID) is resistant to both invasive and non-invasive attacks.

Generally speaking, a PUF must meet the following requirements:

1. Randomness, Uniqueness: No relation between two PUF elements;
2. Unclonability, Unpredictability: Extremely hard to obtain and reproduce a PUF using the same physical implementation;
3. Robustness / Reliability: Reliable over the whole product lifecycle of a PUF.

In summary, PUF can generate a unique secret key / ID with the following advantages:

1. Highly secure: e.g., NeoPUF is invisible with quantum tunneling mechanism, no need for externally generated security parameters pre-stored in embedded non-volatile memory elements;
2. Inexpensive: no special fabrication technique.

Actually, the usage of PUFs ranges from device IDs all the way to security parameters (keys) management without storing such parameters such as: 1) Random key generation; 2) Low-cost key “storage”; 3) Tamper-resistant hardware security module (HSM).

According to the above abstract of PUF and the requirements of a representative DeID (i.e., IEEE 802.1AR) description, we can see clearly that all the required DeID features can be met by PUF-ID as shown in the table below.

Table 1. PUF-IDs meet the required DeID features

Since PUF-ID could meet all the required DeID features, it is obvious that PUF could be used as an enabling solution for a Device eID.

4. PUF Related International Standards

There are a couple of documents [6][7][8] attempting to govern the security requirements of PUF technologies as well as a set of accompanying test/evaluation methods/principles. ISO/IEC 20897 published by ISO/IEC JTC 1/SC 27 is the most authoritative document related to the international standardization of PUFs. This standard specifies the security requirements for PUFs for generating non-stored cryptographic parameters.

In ISO/IEC IS 20897-1 [6], many significant properties of PUF are specified to be the security requirement. Also, the typical applications of PUF are pointed out with the properties defined in the standard. The typical use cases of PUF include: 1) Security parameter generation; 2) Device identification; 3) Device authentication; and 4) Random number generation. However, since it declares “random number generation” is out of scope in 20897-1, it only describes which security requirements a PUF needs to meet for the applications belonging to the former three use cases. Overall, it specifies the security requirements which a PUF shall satisfy for security purposes: steadiness, randomness, uniqueness, tamper-resistance, mathematical unclonability and physical unclonability.

Please note that instead of using the terms reliability, reproducibility and stability, ISO 20897 uses the word “steadiness” to represent the stability of a given PUF response corresponding to a fixed challenge. That is to say, steadiness is the property that the response of the PUF is (almost) always the same if the same challenge is repeatedly given, irrespective of external manipulation within the allowed environmental conditions (e.g., temperature or voltage level) specified by the PUF.

For the purpose of this column, we’ll give special focus on the security requirements PUFs shall meet for their uses as DeIDs according to the specifications in ISO/IEC 20897, namely, only those which are specifically relevant to “Security parameter generation”, “Device identification” and “Device authentication” for DeID applications.

Specifically, those requirements are summarized as follows:

1. For security parameter generation: Steadiness, randomness, uniqueness, mathematically unclonability, tamper-resistant, physically unclonability are necessary. The rationales are the secure parameter (e.g., secret keys) used in cryptography should be steady to generate the same secret key when needed, unique to distinguish one key from the others, random so that keys are hard to guess or break by brute-force attacks, mathematically unclonable so that keys are not predictable, tamper-resistant so that keys are not leaked out or altered, and physically unclonable so that it is impossible to learn the key by pretending as a genuine device.
2. For device identification: Needs to be steady, unique, mathematically unclonable, tamper-resistant, physically unclonable but no need to be random. The rationales are the ID should be steady so that it will always disallow unauthorized access, the ID of one device should be unique to distinguish itself from others, mathematically unclonable so that the uniqueness of the ID is guaranteed, tamper-resistant so that IDs cannot be copied or forged, and physically unclonable so that to prevent device impersonation attacks. However, randomness is not needed because the conventional unique identifier (UID) marks an entity with character or number sequences that are globally unique and assign an ID (e.g., serial numbers, MAC address) to an object following certain policy with certain deterministic rules to assure global uniqueness but disregarding randomness. For device IDs used to support device authentication, global or local uniqueness is also absolutely essential but randomness is either secondary or unimportant at all.
3. For the device authentication: All those requirements, steadiness, randomness, uniqueness, mathematically unclonability, tamper-resistant, physically unclonability should be achieved. Again, the rationales are authentication needs to be steady to avoid authentication errors or failures, random / unique / mathematically unclonable to prevent the impersonation attack, tamper-resistant to prevent authentication credentials to be copied or forged, and physically unclonable so that to prevent device impersonation attacks.

Table 2 underlines the mapping between the security requirements of a PUF and its applications to DeID “Device identification” and “Device authentication” (i.e., DeID) applications.

Table 2. Mapping between security requirements and applications for PUF-based DeID

5. A Short Tutorial on PUFiot

PUFsecurity’s NeoPUF technology is based on eMemory’s physical unclonable function as its core. NeoPUF [9] passes the NIST 800-22 test for ideal performance without the need for any data post-processing or data helpers, overcoming the usual PUF-related concerns such as the additional costs of a complicated ECC (Error Correction Code) system, as well as avoiding the vulnerability of inconsistent results under different operating environments.

NeoPUF’s key features include:

1. High randomness (50% Hamming weight);
2. Ideal uniqueness (50% inter ID Hamming distance);
3. Passing full NIST 800-22;
4. No need for data post-processing (0 intra-ID Hamming distance);
5. High stability (-40~175°C);
6. No aging issue ( 10+year lifetime);
7. Wide process platforms availability;
8. Cost-effective with compact IP size, 0 masks added process, short testing time.

In short, NeoPUF is the ideal PUF and its security functions are statistically robust and reliable, unaffected by external influences including temperature and voltage.

PUFsecurity provides basic, premium, and high-end options of uncompromising embedded silicon IP hardware security solutions for various markets.

The basic solution is PUFrt which is a tamper-proof PUF-based true root-of-trust (RoT) equipped with their security function IPs including chip identification (UID), true random number generator (tRNG), and Secure one-time programmable (OTP).

As shown in Figure 1 and introduced in [10], PUFrt is a highly integrated PUF-based HRoT. PUFrt is composed of PUFsecurity’s PUF-based products including PUFuid, PUFtrng and PUFkeyst plus dedicated PRTC in APB standard as well as a complete anti-tampering design with the following features:

1. PRTC: R/W Access Authority Control I/F
2. PUFuid: Instant Ready On-chip UIDs (by an easy but robust way to generate ID for production management from PUF)
3. PUFtrng: Instant Ready PUF-based TRNG (by a True random number generator with superb short initial time and low-power consumption)
4. PUFkeyst: Trusted Self-encrypted Storage (by secure key storage with built-in 4kbits OTP and logic designs of PUFtrng and PUF values)
5. Complete Anti-Tampering Design

With PUF as the core, PUFrt provides a foundation of trust and security for the chip system. It also provides a 1024-bit identification code with a physical unclonable function and a true random number generator that complies with the NIST SP800-90B/SP-800-22 standard specifications. These help meet the encryption/decryption requirements of sensitive information and data, and achieve a certain level of data security protection. An additional 4096-bit secure storage space with physical unclonable function is provided for the key or sensitive information injected by the customer, which makes the original security and NeoFuse OTP more resistant to physical attacks.

Figure 1: PUFrt Integrated Macro

On 9/1/2020, PUFsecurity launched the premium solution- PUFiot [11], which is a PUFrt-based secure co-processor with crypto accelerator supporting secure boot, OTA, TLS, key management.

As shown in Figure 2 and introduced in [11], PUFiot was built on PUFrt after considering the fact that IoT products have encryption requirements for them to be easy to use with a focus on authentication. In addition to inheriting the advantages of PUFrt standard type, PUFiot also supports a hash algorithm (DMA) and elliptic curve passwords for the security needs of the IoT. In response to the demand for chip integration, this product also supports general bus protocols such as AXI/AMBA and provides a more user-friendly interface.

A condensed introduction to PUFiot is summarized as follows:

First, it provides three primitives for the security system: chip identification (UID), true random number generator (tRNG) and XiP (eXecute in Place) encrypted one-time programmable memory (OTP) for storage of crypto keys that are available in a PUFiot is designed for a wide range of security applications existing PUFrt product from PUFsecurity.

Furthermore, for chip designers who need general security operations such as key generation, block cipher, integrity check and identity verification, PUFiot can provide corresponding functions. For example, the key derivation function (KDF) and the key protection function (KWP) support key generation. The Public Key Coprocessor (PKC) supports elliptic curve cryptography for asymmetric signing, validation, and key exchange. It also includes DMA channels, CMAC and HMAC to support integrity and authentication purposes. The block cipher of the NIST standard AES is also designed for data transmission. Most importantly, PUFiot is a complete tamper-proof circuit design in digital function and analog macro.

The main advantage of PUFiot is its secure boundary, known as the PUF realm, confining a key in a secure location where no software or CPU can touch it. In addition, PUFiot’s hardware accelerator functions can act as a coprocessor to support a CPU to perform security functions.

Figure 2: PUFiot Integrated Macro

To sum up, PUFiot is an easy security enhancement unit of NeoPUF

Technology family. It is an HW crypto-coprocessor with entropy protection on the data, keys and cryptographic operations designed with the following features:

1. Tamper-Proof OTP, UID and TRNG
2. Key Generation and Authority Control
3. Key Protection and Wrapping
4. Symmetric and Asymmetric Authentication
5. Key Exchange and Integrity MAC Check
6. SDK of API and Command
7. Secure Boot, TLS and Key Management

6. PUFiot is an ideal Device eID

Let us use 802.1AR DevID as our model for DeID. Based on the discussions in Sections 2, the key requirements of an ideal DeID can be summarized as follows:

1. A DeID identity consists of three parts: Public Attributes (Public Key, Serial Number, Certificate, …), Secret Attributes (Private Key, …), and Crypto Functions (AES, RSA, ECC, …);
2. The secret attributes are used for three major purposes: 1). Proofing the authenticity/integrity of public attributes; 2). Deriving keys to enable the crypto functions; and 3). Provision of the authentication credentials to authenticate devices.
3. The main streams prefer to use a bundling of a secret key, a public key and an X.509 certificate as the “authentication credentials” for their secure network or machine identities.
4. Need a device’s DeID module which stores each of its DeID secrets securely and supports signing operations that prove possession of the secret, while ensuring that the secret remains confidential so the device cannot be impersonated by others.

Furthermore, based on the introduction on PUFiot in Section 5, it clearly shows that PUFiot is an ideal Device eID because of the following two facts:

1. NeoPUF is the ideal PUF which meets all the security requirements from ISO/IEC 20897-1 specifically germane to DeID applications regarding “Security parameter generation”, “Device identification” and “Device authentication”;
2. The profound features of PUFiot can accommodate all the functional and security requirements of an ideal DeID with respect to unclonable machine identities, the need of a full functional DeID module, and a TPM 1.2 compliant crypto keys to provide DeID functionality for Platform Identity.
3. PUFiot offers not only secure OTP storage for key/sensitive information but also KA(key array) logic circuits. For the key management policy of KA, it is capable of handling session key, private key, and shared secret which can fit public attributes, secret attributes defined by 802.1AR DevID.
4. PUFiot is designed to support symmetric algorithms which deal with data-at-rest encryption/decryption and asymmetric algorithms to establish secure communication between client & server, and key handling policies through KDF (Key Derivation Function) and KWP(Key Wrapping), hence it is capable of handling authenticity/integrity of public attributes, key derivation to enable the crypto functions described by 802.1AR DevID.
5. PUFiot’s UID is derived from PUF inborn values with KDF-like methodology in order to prevent from UID tampering, and to securely store it as DeID.

PUFiot is a PUFrt-based secure co-processor with crypto accelerator supporting secure boot, OTA, TLS, key management. It’s the premium solution of the NeoPUF technology designed for a wide range of security applications. For example, PUFiot can be the HRoT and secure co-processor during secure boot. It has also been conceived that PUFiot can provide asset protection and update OTA as well. Since PUFiot has just been debuted on 9/1/2020, it is expected that many more innovative applications will be proposed for PUFiot in the near future.

7. Conclusion

Due to the requirements of verifying the authenticity of data and identities of devices in IoTs, there are growing interests in proposing how to standardize the device identification in IoT. The most notable and germane standard is IEEE 802.1AR, which defines a standard identifier for IEEE 802 devices that is cryptographically bound to that device, and defines a standard mechanism to authenticate a device’s identity in order to facilitate a secure device provisioning. However, it ran short of demanding a “PUF-ID” which is highly secure, inexpensive to fabricate as well as resistant to both invasive and non-invasive attacks.

This column advocates a PUF-ID based solution for the device eID standard and also introduces PUFiot as an ideal Device eID offer in the current PUF market.

Since standardized device identity facilitates interoperable secure device authentication and simplifies secure device deployment and management, and new standards for IoT security are being proposed by the EU and US regulating agencies, we’ll define a PUF-based device eID standard that meets all the major IoT security requirements. We firmly believe PUF is the ideal fit for IoT since IoT devices are low energy, and lightweight. We are also optimistic that ultimately, PUF will become a standard for 5G/IoT/AIoT security in the future.

8. References

1. Hsu, Charles, “A Must for AI/IOT Era PUF based Hardware Security”, A keynote speech to The 30^th VLSI Design/CAD Symposium, 8 August 2019.
2. Standard of IEEE: 802.1AR: Secure Device Identity [Link]
3. Moskowitz & Nikander, “Host Identity Protocol (HIP) Architecture”, May 2006 [Link]
4. Ion Stoica, Daniel Adkins, Shelley, Zhuang Scott Shenker, Sonesh Suran, “InternetIndirection Infrastructure” [Link]
5. PUF by Wikipedia [Link]
6. ISO/IEC DIS 20897-1: “Security requirements and test methods for physically unclonable functions for generating non-stored security parameters. Part 1: Security requirements”, Dec 2020.
7. UNIQUE Project Document 238811/ D1.2 | v1.0: “Security architectures, protocol design and evaluation principles for anti-counterfeiting/anti-tampering solutions”, 28 Feb 2011.
8. Nicolas Bruneau, et. al., “Development of the Unified Security Requirements of PUFs During the Standardization Process”, 9 Aug 2019 [Link]
9. NeoPUF Introduction [Link]
10. PUFrt Introduction [Link]
11. PUFiot Introduction [Link]