Lightweight Mutually Authenticated Key Exchange with Physical Unclonable Functions

Abstract

Authenticated key exchange is desired in scenarios where two participants must exchange sensitive information over an untrusted channel but do not trust each other at the outset of the exchange. As a unique hardware-based random oracle, physical unclonable functions (PUFs) can embed cryptographic hardness and binding properties needed for a secure, interactive authentication system. In this paper, we propose a lightweight protocol, termed PUF-MAKE, to achieve bilateral mutual authentication between two untrusted parties with the help of a trusted server and secure physical devices. At the end of the protocol, both parties are authenticated and possess a shared session key that they can use to encrypt sensitive information over an untrusted channel. The PUF’s underlying entropy hardness characteristics and the key-encryption-key (KEK) primitive act as the root of trust in the protocol’s construction. Other salient properties include a lightweight construction with minimal information stored on each device, a key refresh mechanism to ensure a fresh key is used for every authentication, and robustness against a wide range of attacks. We evaluate the protocol on a set of three FPGAs and a desktop server, with the computational complexity calculated as a function of primitive operations. A composable security model is proposed and analyzed considering a powerful adversary in control of all communications channels. In particular, session key confidentiality is proven through formal verification of the protocol under strong attacker (Dolev-Yao) assumptions, rendering it viable for high-security applications such as digital currency.

1. Introduction

Consumer devices increasingly communicate sensitive information directly to each other. Often, these communications are over untrusted channels where default security controls are either minimal (relying on a pre-shared secret) or nonexistent (information is sent in the clear). In such scenarios, passive attackers can steal secrets, while active attackers can gain control of the channel and engage in malicious activities. This problem is particularly prevalent in IoT systems where security may be weak or absent [1].

Establishing a secure channel is a two-stage process where parties typically first authenticate each other and then cooperate to generate a shared secret, which is used to encrypt the sensitive information traveling over the untrusted channel. Mutual authentication protocols tie the final shared secret to the authentication process, resulting in an authenticated key exchange. Doing so ensures that fraud and malfeasance can be traced back to the malicious participant, a property that is especially desirable for high-value and time-sensitive applications such as digital payments.

Strong PUFs embed a physical source of entropy that is a building block for a true random number generator and/or a one-way function. Secrets of a specific PUF instantiation are inextricably tied to the silicon; ergo, credentials cannot be stolen, and impersonating a device requires modeling the physical characteristics of the nanometer-sized devices and wires. As such, strong PUFs can play an important role as a hardware root of trust that is impervious to a variety of typical attack vectors, including supply-side threats, and can therefore mitigate large-scale system-wide risks in mission-critical applications.

Contributions

In this work, we propose a light-weight PUF-based mutual authentication and key exchange (PUF-MAKE) protocol that utilizes a set of hardware-based security primitives derived from a strong physical unclonable function (PUF). Facilitated by a trusted authority, the protocol explicitly authenticates both parties and establishes a shared session key between them. Additionally, the authentication challenge and response are updated on every successful authentication, and the server’s cache of per-device PUF challenges can be refreshed asynchronously, without requiring the devices to re-enroll or even connect to the system. Furthermore, the authentication completes in three rounds and is considered lightweight as it neither uses asymmetric cryptography primitives, nor does it require devices to carry any information about other devices.

The foundation of the proposed protocol is a composable security model where the protocol is as secure as its underlying building blocks [2]. The scheme is centered around two roots of trust: the PUF as a local root of trust and the enrollment process as a system root of trust. Both roots of trust must be compromised before an attacker can gain access to the secure channel. One-time use keys preserve the secrecy of future sessions. Quantum hardness is achieved by relying on mature, well-understood primitives, such as AES and SHA3, that are known to be quantum-safe. The chosen primitives can be replaced by equivalent block cipher or hash functions without impacting the protocol sequence or security goals. By relying on hardware PUF primitives, the scheme reduces the reliance on fixed, long-lived public-private key pairs or a public key infrastructure (PKI). While the proposed scheme is suited for high-security applications such as digital currency transactions, it can also be used in any type of client-server architecture to implement an authentication layer for secure communications or data transfer.

The remainder of the paper is organized as follows: Section 2 presents a review of related work, including the state of the art. Following that, the underlying primitives are covered in Section 3 and the proposed protocol in Section 4. Section 5 presents the formal security analysis of the protocol, while Section 6 covers other security aspects not discussed in the formal model. Section 7 describes the experimental methodology and performance analysis. Section 8 summarizes the findings and future work.

2. Related Work

Authenticated key exchange (AKE) is a mechanism that serves the dual purpose of (a) authenticating two parties with respect to each other and (b) building a secure communications channel between two parties over untrusted networks (e.g., the Internet) where active adversaries can be expected. In cases where (a) is satisfied for both parties, the protocol is considered to be mutually authenticated key exchange (MAKE). Early work by Diffie et al. [3] explores authenticated key exchanges as part of a station-to-station (STS) encryption protocol. The work is notable for establishing design principles for a secure protocol, with later work by Bellare and Rogaway [4] further formalizing this approach and extending it to arbitrary two-party protocols.

Bellare et al. [5,6] later proposed an authenticated key exchange protocol based on the standard model of an asymmetric encryption algorithm coupled with a trap-door function, but the scheme proved susceptible to chosen cipher-text attacks. Okamoto [7] improved upon this approach by introducing a pseudo-random function as a replacement for the trap-door function, proving IND-CCA indistinguishability under the standard model. In parallel, Law et al. [8] proposed an efficient protocol titled MQV (the author’s initials concatenated) combining Diffie-Hellman for forward secrecy and elliptic curve cryptography for efficient key generation. Authentication, however, was implicit as entities were not identified, leaving the scheme vulnerable to impersonation attacks. Security of the protocol was later upgraded by Krawczyk [9] by introducing a Schnorr signature scheme that serves the dual purpose of including identities and a building block to construct a challenge-response sequence for a three-round protocol. LaMacchia et al. [10] improved upon Krawczyk’s scheme with the NAXOS protocol by making stronger adversarial assumptions.

Hardware-based MAKE constructions utilize PUFs as a local root of trust. An extensive literature review on previously proposed light-weight PUF-based authentication protocols is given in [11]. Idriss et al. [12] propose a lightweight PUF-based mutual authentication and secret message exchange protocol. The protocol requires no cryptographic primitives and exchanges only challenges between the server and device. The proposed protocol authenticates during the connection establishment phase of WiFi using 3 CRPs. XOR operations in combination with a router-generated nonce are used to encrypt challenges and responses between device and router and to derive the next set of CRPs for the next authentication. The protocol is one-way, i.e., it does not authenticate the device. It also assumes that the router has a soft model of the PUF and can generate a response to any randomly generated challenge during the refresh CRP operation. Mahalat et al. [13] propose a scheme for secure WiFi authentication of IoT devices. This approach was later expanded to a PUF-based authentication and key sharing scheme that utilizes Pedersen’s commitment scheme coupled with Shamir’s secret sharing [14]. The mutual authentication and key sharing scheme proposed between user (server) and sink nodes can be implemented more easily using CRP-strong PUF-based schemes without the mathematical complexity of the secret sharing schemes [15].

A PUF-based authentication and key management protocol for IoT is proposed in [16], improving upon the attack resilience and performance overhead of the previous method [17]. The scheme relies on elliptic curve cryptography (ECC) and requires a trusted setup with tamper-resistant hardware to protect secret keys. Similarly, a controlled PUF that utilizes ECC is proposed as a lightweight authentication and key generation protocol for IoT nodes in [18], relying on zero knowledge proofs for device authentication; however, the authentication is one-way, and the server is not authenticated. A PUF-based ElGamal algorithm is proposed for message encryption as well as a PUF-based digital signature scheme.

A lightweight authentication protocol is proposed in [19] that is designed to prevent an adversary from obtaining sufficient CRPs to carry out model-building attacks. The protocol gives the device control over its own authentication by requiring the server to send half of a response to an authentication challenge to the device initially along with the challenge. The device does not respond with its half of the response unless the server’s response component is validated by the device. The main drawback is the limited number of authentications that are possible, which is constrained by the number of CRPs stored in the database. In [20], the authors propose a crossover ring oscillator (RO) PUF cloning technique that enables a group of IoT devices to all generate the same (shared) key, thereby eliminating the key distribution problem for devices engaging in multi-party shared key encrypted communication.

Zheng et al. [21] propose a peer-to-peer protocol in which two PUF devices can authenticate and generate a shared session key without the need to store CRPs and instead uses a one-time pad to generate a unique key mask for each pair of customer devices. Therefore, every enrolled device must store information on every other device. Another drawback relates to the use of ECC, where the protocol shows that the fuzzy extractor ‘Rep’ operation is performed by the device, which according to [22] is too expensive for lightweight authentication applications. Last, the security of their protocol is reliant on the security guarantees of the Diffie-Hellman key exchange. Although our protocol uses some of the same cryptographic primitives, it does not use ECC and is therefore more lightweight.

MAKE protocols between an IoT device and a secure server and between two IoT devices is proposed in [23]. The server is used in both protocols to authenticate the first device using CRPs stored on the server during provisioning. The device does not store any CRPs, requiring challenges and helper data (for a fuzzy extractor error correcting scheme) to be sent in the clear to the device. The proposed scheme, although secure against model-building attacks, requires a centralized authority and an on-line connection to carry out any type of authentication. The proposed device-server scheme is very similar to early work on PUF-based protocols described in [11]. The device-to-device scheme is unique but requires the server to pass an authentication credential, i.e., a CRP, for the second device to the first device, which, if compromised, might allow the first device to authenticate as the second device. The MAKE protocol proposed in this paper distributes the workload across multiple authentication servers, reducing the bottleneck that would result with a large scale deployment, and does not treat even authenticated devices as trusted.

In [24], the author proposes a PUF-based authentication protocol that leverages Paillier homomorphic encryption or ElGamal encryption with a plaintext equality test as a means of obfuscating the CRPs from the gateway routers and the verifier. The method addresses CRP depletion, machine learning, and impersonation attacks commonly carried out against authentication protocols. However, the device experiences high computational loads and power consumption when authenticating because of the modular operations associated with homomorphic encryption, in comparison with the linear operations employed in our proposed protocol.

3. Underlying Primitives

3.1. Physical Unclonable Function (PUF)

The protocol relies on a strong PUF hardware primitive as a local root of trust. In particular, the properties of a strong PUF variant, called a super-high information complexity (SHIC) PUF, as introduced by Ruhrmair [25], are essential to the security of the protocol. An idealized SHIC PUF has the following properties:

• It contains an exponential amount of response-relevant random information tied to an entropy source with a very high information density.
• The read-out speed of PUF responses is limited to low values. Moreover, the limitation is an inherent property of the PUF measurement process and not an arbitrary delay injected into the read-out circuit.
• The CRPs are mutually independent. Furthermore, the pairwise mutual information within any two responses is zero.

The protocol assumes that each participant is equipped with an instance of a SHIC PUF that is enrolled in the system. Furthermore, the authentication server, a component that facilitates authentication between two participants, is also equipped with a SHIC PUF to establish a PUF-based mutually authenticated secure channel with the issuing authority.

3.2. Key-Encryption-Key (KEK)

Key-encryption-key, or KEK, is traditionally used in reference to a master key that a device stores and uses to decrypt boot images at start-up and to generate other keys, e.g., ephemeral session keys and authentication bitstrings during system operation. Given its central role, it defines the root-of-trust in most systems. KEKs also need to be reproducible at any instance in time, potentially over the lifetime of the device, and are therefore also referred to as long-lived keys (LLK). The role of a KEK as the root-of-trust also imposes strong security constraints on the system to maintain its secrecy because an attack that is able to extract the KEK compromises the entire system.

A SHIC PUF is hardened against KEK extraction attacks as it stores only the challenges and helper data needed to reproduce the KEK, not the KEK itself, and can go a step further by harnessing the ability to generate an exponential number of KEKs. A SHIC PUF enables Alice and Bob to authenticate and generate a shared session key. In particular, a strong PUF’s LLK generation function provides an exponential number of unique KEKs as a means of meeting the one-time use constraint associated with authentication while simultaneously providing the ability to reliably regenerate any one of its KEKs on-demand.

4. The PUF-MAKE Protocol

The protocol assumes a minimum of four entities, namely an issuing authority (IA), an authentication server (AS), and a pair of devices (Alice and Bob) who wish to establish a secure channel with each other to exchange information. An example application is one of digital currency, where the IA is the central authority, AS is an intermediary, and Alice and Bob are devices that exchange electronic funds for goods and services. For example, Alice can be a customer wishing to buy something wirelessly from a brick-and-mortar or online store (Bob), or Alice and Bob may be two customer devices communicating through a Bluetooth or IR link to exchange funds. The AS in this scenario can be a trusted intermediary providing value-added services, ranging from a small embedded system in a coffee shop to a bespoke enterprise server installation tailored to high-traffic applications. Notably, the scale and scope of deployment are not restricted by protocol primitives.

The protocol encapsulates two core security properties: First, physical access to the PUF is required to participate in authentication and secure channel creation, thus establishing a hardware root of trust. Second, authentication tokens (AT) are used only once for a single successful authentication, thus enabling forward secrecy.

4.1. MAKE Enrollment Protocol

The enrollment process involves three entities: the device (Alice), IA and AS, as shown by the vertical partitions in the message exchange diagram of Figure 1. The IA utilizes a CRP database, ${\mathrm{CRP}}_{DB}$, generated during PUF provisioning (or alternatively, it can generate the PUF CRPs on-the-fly using a soft PUF model and soft PUF data [15]). The provisioning process is not shown because it varies depending on the SHIC PUF utilized. The IA interacts directly with the device to create a set of authentication tokens, AT. The requirement for the device to be involved in this three-party protocol prevents certain attacks that are discussed in Section 5. The IA runs on a multi-core server in a central, secure facility.

The AS is initialized and periodically refreshed with a compact representation of the AT, a core component of PUF-MAKE’s CRP-based authentication and session key generation process. The right side of Figure 1 shows the format of the database called ${\mathrm{AuTk}}_{DB}$ that stores AT. An AT is defined as including a customer device ID, e.g., ${\mathrm{ID}}_A$, a hashed version of a KEK response, ${\mathrm{HK}}_A$, a PUF challenge ${\mathrm{Chlng}}_A$ and helper data ${\mathrm{HD}}_A$. This information enables AS to validate Alice and Bob’s devices as enrolled, PUF-instantiated devices via an interactive protocol. The AS can also run on a multi-core server in a central, secure facility, or as a fielded device.

The ordered sequence of message exchanges and operations that comprise the enrollment process followed during the initialization phase are described below, in correspondence with the numbered annotations shown in Figure 1.

• The IA and AS mutually authenticate (MA) using a privacy-preserving PUF-based (P3B) protocol and then generate a session key (SKG), called ${\mathrm{SK}}_I$. An example P3B protocol suitable for PUF-MAKE is described in [26].
• The same MA and SKG process is carried out between Alice and the IA to authenticate and generate a shared session key ${\mathrm{SK}}_A$.
• The IA selects a CRP for Alice from its ${\mathrm{CRP}}_{DB}$ (constructed during provisioning), extracts ${\mathrm{Chlng}}_{Ax}$, and encrypts it using AES-256. The ciphertext ${\mathrm{C}}_1$ is transmitted to Alice.
• Alice decrypts ${\mathrm{C}}_1$ to obtain ${\mathrm{Chlng}}_{Ax}$. Alice applies the challenges to her hardware HPUF in enrollment mode to generate an authentication key, ${\mathrm{KK}}_{Ax}$ and helper data ${\mathrm{HD}}_{Ax}$. She hashes ${\mathrm{KK}}_{Ax}$ using a SHA-3 hashing function to produce ${\mathrm{HK}}_{Ax}$, and encrypts ${\mathrm{HK}}_{Ax}$ and ${\mathrm{HD}}_{Ax}$ with ${\mathrm{SK}}_A$ to produce ciphertext ${\mathrm{C}}_2$.
• Alice transmits ciphertext ${\mathrm{C}}_2$ to IA. On the first iteration of the enrollment process, Alice also stores the tuple [${\mathrm{Chlng}}_{A1}$, ${\mathrm{HD}}_{A1}$] to persistent memory. She will use this challenge and helper data to reproduce ${\mathrm{HK}}_{Ax}$ during her first in-field authentication, discussed below.
• IA decrypts ${\mathrm{C}}_2$, fetches the response component of the challenge ${\mathrm{Chlng}}_{Ax}$ from its CRP database, and assigns the response to ${\mathrm{KK}’}_{Ax}$. IS hashes ${\mathrm{KK}’}_{Ax}$ and compares the output ${\mathrm{HK}’}_{Ax}$ with the decrypted ${\mathrm{HK}}_{Ax}$ received from Alice. If they match then Alice’s ${\mathrm{HK}}_{Ax}$ is validated. IA then encrypts packet ${\mathrm{C}}_3$ with ${\mathrm{SK}}_I$, containing Alice’s ID, ${\mathrm{ID}}_A$, and AT components, namely ${\mathrm{HK}}_{Ax}$, ${\mathrm{Chlng}}_{Ax}$ and ${\mathrm{HD}}_{Ax}$.
• IA transmits the ${\mathrm{C}}_3$ to AS.
• AS decrypts the ${\mathrm{C}}_3$ and stores ${\mathrm{ID}}_A$, ${\mathrm{HK}}_{Ax}$, ${\mathrm{Chlng}}_{Ax}$ and ${\mathrm{HD}}_{Ax}$ in its ${\mathrm{AuTk}}_{DB}$ database. The AT elements in this table will be used by AS for in-field authentication operations carried out on behalf of Alice (and Bob) and to enable Alice and Bob to generate a shared session key.

A refresh phase is periodically carried out between the IA and AS to replenish AT stored by the AS. Although the protocol as shown stores CRP on IA in a database, the number of elements defining the CRP space for each device can be significantly increased using a more compact soft data representation of PUF CRPs as described in [15]. In such cases, the process described here is one of expansion from IA-stored PUF soft data to AS CRPs, which further justifies the need for a refresh phase.

4.2. PUF-MAKE In-Field Interactive Authentication Protocol

At the end of enrollment, Alice and Bob each store a challenge that they will use to generate a response, ${\mathrm{HK}}_{A1}$, for the first authentication request with AS. The in-field version of the protocol is sequenced such that Alice and Bob must first authenticate to AS with their existing challenge, and, as part of successful authentication, they receive and store a new challenge for the next authentication cycle, guaranteeing forward secrecy. The ${\mathrm{AuTk}}_{DB}$ maintained by AS is designed to facilitate multiple simultaneous transactions while retaining security against attacks. Each authentication uses a one-time credential that is replaced at the end of the authentication cycle. The session key is jointly derived by both participants, creating a binding partnership between devices for the duration of the session.

The Interactive Authentication message exchange diagram for MAKE is shown in Figure 2. The diagram shows the sequence of operations that occur when Alice and Bob wish to establish an authenticated and encrypted channel with each other, e.g., to exchange electronic cash for goods and services.

0.

The protocol begins with Alice and Bob sending a request to communicate to each other using an unencrypted packet with identifiers ${\mathrm{ID}}_A$ and ${\mathrm{ID}}_B$.

1.

Alice reads ${\mathrm{Chlng}}_{A1}$ from NVM and runs her PUF, ${\mathrm{HPUF}}_R$, in regeneration mode to regenerate response ${\mathrm{KK}}_{A1}$. She then calculates a hash ${\mathrm{HK}}_{A1}$ of ${\mathrm{KK}}_{A1}$ using a suitable hash function. Bob performs the same sequence of operations.

2.

Alice and Bob generate session key shards, ${\mathrm{SK}}_T$ and ${\mathrm{SK}’}_T$, using their PUF-based true-random-number-generators (TRNGs).

3.

Alice assembles packet ${\mathrm{C}}_1$ by concatenating authentication artifacts, ${\mathrm{Chlng}}_{A1}$, Bob’s device ID, ${\mathrm{ID}}_B$, and the session shard, ${\mathrm{SK}}_T$, which are then AES-encrypted with ${\mathrm{HK}}_{A1}$ as the key. Alice sends an authentication request to AS, along with ${\mathrm{ID}}_A$ and ${\mathrm{C}}_1$ as metadata. The server matches ${\mathrm{ID}}_A$ to the list of known devices in the database ${\mathrm{AuTk}}_{DB}$ populated by the issuing authority (IA) during enrollment. Upon match, the server uses the associated ${\mathrm{HK}}_{A1}$ to decrypt ${\mathrm{C}}_1$ and disassembles the ${\mathrm{Chlng}}_{A1}$, ${\mathrm{ID}}_B$ and ${\mathrm{SK}}_T$ fields. Authentication is a success if the extracted ${\mathrm{Chlng}}_{A1}$ matches the one stored for ${\mathrm{ID}}_A$ in the database; otherwise, this process repeats using each of the remaining ${\mathrm{ID}}_A$ elements. If no matches are found, the protocol aborts. Note that both ${\mathrm{HK}}_{A1}$ and ${\mathrm{Chlng}}_{A1}$ must be correct for authentication to succeed. If ${\mathrm{HK}}_{A1}$ does not match any of those stored in the ${\mathrm{AuTk}}_{DB}$, the packet will not be decrypted correctly and ${\mathrm{Chlng}}_{A1}$ will be random, causing a mismatch. Alternatively, if ${\mathrm{HK}}_{A1}$ is correct and ${\mathrm{Chlng}}_{A1}$ is not, the packet will decrypt correctly but ${\mathrm{Chlng}}_{A1}$ will fail to match. In either case, authentication fails and the server aborts the connection. Bob performs this same set of operations with AS.

4.

If Alice’s authentication succeeds, AS adds ${\mathrm{ID}}_A$ and ${\mathrm{SK}}_T$ to a ${\mathrm{SESSION}}_{DB}$ database. Similarly, if Bob’s authentication succeeds, AS adds ${\mathrm{ID}}_B$ and ${\mathrm{SK}’}_T$ to the ${\mathrm{SESSION}}_{DB}$. In both cases, AS first searches for a match to ${\mathrm{ID}}_B$ and ${\mathrm{ID}}_A$ supplied by Alice and Bob, respectively, to determine if a row already exists, and, if so, adds Alice or Bob’s information to the matching row element instead of creating a new row. Once Alice and Bob’s IDs and ${\mathrm{SK}}_T$ are both present, AS proceeds to the next step; otherwise, it stalls the thread waiting for Alice or Bob to complete the transaction. A time-out can also be included that aborts the entire transaction and deletes the ${\mathrm{SESSION}}_{DB}$ element.

5.

The first step of Alice and Bob’s key refresh operation is for AS to fetch new AT elements from the ${\mathrm{AuTk}}_{DB}$, e.g., it selects rows associated with ${\mathrm{HK}}_{A2}$ and ${\mathrm{HK}}_{B2}$ elements. The key update mechanism ensures that Alice and Bob are protected against both impersonation and replay attacks.

6.

AS constructs a packet ${\mathrm{C}}_A$ for Alice by encrypting Bob’s authentication artifacts ${\mathrm{ID}}_B$, ${\mathrm{SK}’}_T$ and Alice’s next challenge ${\mathrm{Chlng}}_{A2}$ and ${\mathrm{HD}}_{A2}$ with Alice’s ${\mathrm{HK}}_{A1}$ AES key. AS constructs a packet ${\mathrm{C}}_B$ for Bob in a similar fashion and transmits the packets to Alice and Bob.

7.

Alice decrypts her ${\mathrm{C}}_A$ with ${\mathrm{HK}}_{A1}$ to obtain Bob’s ID ${\mathrm{ID}}_B$, Bob’s ${\mathrm{SK}’}_T$ and her next authentication challenge. Bob does the same with his packet.

8.

Both Alice and Bob XOR the ${\mathrm{SK}}_T$ and ${\mathrm{SK}’}_T$ shards to obtain a shared session key $SK$, which they can use to encrypt communications between them.

9.

Alice and Bob validate their shared key by performing a test encryption operation, where Bob encrypts a test message “Hello World” with $SK$ and transmits it to Alice. Alice decrypts and validates. If the comparison fails, she sets her $abt1$ flag to 1. She then encrypts $msg$ with her version of $SK$ and transmits it to Bob. Bob decrypts and compares it to “Hello World”. If this fails, he sets $abt2$ to 1. Alice also encrypts her $abt1$ flag with ${\mathrm{HK}}_{A1}$ and transmits to AS as encrypted packet ${\mathrm{C}}_5$. Bob carries out the same operation with $abt2$.

10.

If Alice and Bob succeed in the test encryption comparison operation, they possess a valid shared key and can encrypt communications between them. They notify AS with ${\mathrm{C}}_5$ and ${\mathrm{C}}_6$, and AS marks the current AT as used. Alice and Bob also update their NVMs with the next Chlng and HD information under the condition that the ID’ values match the original ID values, which indicates they have received valid next challenge information.

5. Security Analysis

This section describes the formal static analysis of the PUF-MAKE protocol to demonstrate authentication properties. An automated solver is used to prove that the confidentiality and integrity properties of the generated session key are maintained as described. We build on the principle of universal composability to achieve the security goals of the protocol. Under a composable security model, the protocol is proven to be secure under a set of adversarial assumptions if the underlying building blocks are proven to be secure under those same assumptions and the protocol steps themselves preserve confidentiality and integrity of sensitive materials [2]. Two distinct security sub-models are defined, namely the hardness of the PUF primitive and the hardness of the protocol. The hardness of the PUF primitive is discussed in reference to prior work as follows: To ensure that the protocol is secure, we provide a formal proof of correctness generated by a formal prover/verification program conducting adversarial analysis on the protocol. The proof guarantees that confidentiality of the session key is preserved under all circumstances.

5.1. Formal Model

We start with a formalization of the physical strong-PUF primitive following notation from [27], additionally introducing a measurement time parameter as required for a SHIC PUF:

Definition 1.

Let a physical system, Σ be instantiated from a design $\widehat{\Sigma }$ such that:

• Σ holds a state $Xϵ{\{0,1\}}^l$, which can be sampled by a physical probe P at measurement points defined by vector $zϵ{\{0,1\}}^k$.
• Σ enables $y=f(X,P_z)\to {\{0,1\}}^n$ to be measured from z, where $f(X,P_z)$ denotes the measurement process.

Definition 2.

Let $f:{\{0,1\}}^l\times {\{0,1\}}^k\to {\{0,1\}}^n$ be a physical one-way function where:

1. 

$\exists y$ that represents a measurement made by P of the physical source Σ.

2. 

y is sampled in finite, positive, non-zero time t, which is tied to the intrinsic physical characteristics of Σ. The sampling time t is deterministic ($O\left(1\right)$) based on the design of Σ.

3. 

Recovering z from y requires $\Omega (exp(l\left)\right)$ queries to Σ, or expressed formally, the likelihood of guessing by brute-force is:

$$Pr\left[A^{\prime }\left(f(X,P_r)\right)outputsXor{P}_r\right]<{\displaystyle \frac{1}{exp\left(l\right)}}$$

(1)

4. 

Similarly, for two distinct physical instantiations, ${\Sigma }_i$ and ${\Sigma }_j$, the likelihood that a measurement vector z generates an identical response is:

$$Pr[f(X_i,P_z)=f(X_j,P_z)]<{\displaystyle \frac{1}{exp\left(l\right)}}$$

(2)

5. 

Simulating y, given X and P and non-zero $\Delta t$, requires $O\left(exp\right(l\left)\right)$ operations, where each operation requires duration t to complete.

Here, z is equivalent to a challenge bitstring, while y is equivalent to the corresponding response bitstring. It is noted that for practical instantiations, t may be on the order of seconds to satisfy the requirements of a SHIC PUF. Furthermore, it should not be based on an arbitrary delay injected into the circuit, as such a delay would be trivial to bypass. In the case where l could be exponentially large but n and k are bounded by P and f, respectively, an adversary could construct a look-up table of vectors z and y while ignoring X altogether. To counteract this, a strong PUF must embed an exponential search space for both challenges and responses, which can be expressed as follows:

Definition 3.

Building on Definitions 1 and 2, and given a set of challenges, $Chlg\subseteq {\{0,1\}}^{*}$, and responses, $Resp,\subseteq {\{0,1\}}^{*}$, a PUF is a physical system S that maps physical stimuli defined by challenges $Chl{g}_i$ to measured responses $Res{p}_i$ such that:

1. 

The PUF function $f\left(Chl{g}_i\right)\to Res{p}_i$ maps a unique unbounded challenge to a unique unbounded response.

2. 

The design is collision-resistant: $\forall R:Pr[Res{p}_i=Res{p}_j]\le {\displaystyle \frac{1}{2^N}}$, where $i\ne j$ and N is the number of response bits in $Res{p}_{*}$;

3. 

For a distinct physical device, ${\Sigma }^{\prime }$, two non-identical challenges, $Chl{g}_i$ and $Chl{g}_j$, will always generate responses $Res{p}_i=f\left(Chl{g}_i\right)$ and $Res{p}_j=f\left(Chl{g}_j\right)$ such that

$HD(Res{p}_i,Res{p}_j)=N/2$, where $HD\left(\right)$ is the hamming distance and N is the bit cardinality of $Res{p}_i$ and $Res{p}_j$, i.e., 50% of the bits are different between the two responses.

4. 

Two distinct physical devices based on the same design (${\Sigma }_i$ and ${\Sigma }_j$), a unique, identical challenge, $Chlg$, will generate responses $Res{p}_i=f_i\left(Chlg\right)$ and $Res{p}_i=f_j\left(Chlg\right)$ such that $HD(Res{p}_i,Res{p}_j)=N/2$.

5.2. Protocol Model

The protocol described in Figure 2 is a three-round interactive protocol between Alice and Bob, mediated by a third party, $AS$, that provides authentication services to both. Algorithm 1 describes the model in BAN notation, while predicates derived from the protocol are listed in Algorithm 2. Here, f denotes the hardware PUF function, while $Chl{g}_x$ and $Rs{p}_x$ are the challenges and associated responses, respectively, as per the model.

Algorithm 1: Formal description of the protocol

Common Input: $Chl{g}_x$ is well-formed 1. $A\to B:REQ,A$ 2. $B\to A:ACK,B$ 3. A computes: - $S{K}_t:={\{0,1\}}^l$ - $H{K}_{A1}$ := $Hash\left(f\left(Chl{g}_{A1}\right)\right)$ - $C_1$ := Enc$(H{K}_{A1},\{Chl{g}_{A1},B,S{K}_t\})$ 4. $A\to AS:REQ,A,C_1$ 5. B computes: - $S{K}_t^{\prime }:={\{0,1\}}^l$ - $H{K}_{B1}$ := $Hash\left(f\left(Chl{g}_{B1}\right)\right)$ - $C_2$ := Enc$(H{K}_{B1},\{Chl{g}_{B1},B,S{K}_t^{\prime }\})$ 6. $B\to AS:REQ,B,C_2$ 7. $AS$ computes: - $\{H{K}_{A1},H{K}_{B1}\}$ := $Lookup\left(A\right),Lookup\left(B\right)$ - $\{B,S{K}_t,Chl{g}_{A1}\}$ := Dec$(H{K}_{A1},C_1)$ - $\{A,S{K}_t^{\prime },Chl{g}_{B1}\}$ := Dec$(H{K}_{B1},C_2)$ - Verify $Match(Chl{g}_{A1}$, $H{K}_{A1})=Match(Chl{g}_{B1},H{K}_{B1})=true$ - For A, $Lookup(Chl{g}_{A2},H{K}_{A2})$. For B, $Lookup(Chl{g}_{B2},H{K}_{B2})$. - $C_A$ := Enc$(H{K}_{A1},\{B,S{K}_t^{\prime },Chl{g}_{A2}\})$ - $C_B$ := Enc$(H{K}_{B1},\{A,S{K}_t,Chl{g}_{B2}\})$ 8. $AS\to A$ : $C_A$, $AS\to B$ : $C_B$ 9. A computes: - $\{B,S{K}_t^{\prime },Chl{g}_{A2}\}$ = Dec$(H{K}_{A1},C_A)$ - $SK:=S{K}_t\oplus S{K}_t^{\prime }$ 10. B computes: - $\{A,S{K}_t^{\prime },Chl{g}_{B2}\}$ = Dec$(H{K}_{B1},C_B)$ - $SK:=S{K}_t^{\prime }\oplus S{K}_t$ 11. $A\to B$ : Enc$(SK,Test)$ 12. $B\to A$ : Enc$(SK,Confirm)$

Algorithm 2: Assertions derived from the PUF and protocol properties

Assertions $S{K}_t$ and $S{K}_t^{\prime }$ are fresh, $H{K}_{Ax}$ and $H{K}_{Bx}$ are one-time use. $H{K}_{A}1\ne H{K}_{A2}\wedge H{K}_{B1}\ne H{K}_{B2}$ (Definition 3.2). $H{K}_{A}1\ne H{K}_{B1}\wedge H{K}_{A2}\ne H{K}_{B2}$ (Definition 3.3). $Hash\left(f\left(Chl{g}_x\right)\right)$ obfuscates $Res{p}_x$, thwarting model-building attacks (Definition 2.5). A believes $AS$ is authentic since $AS$ can produce $H{K}_{A1}$ to decrypt $C_1$ ($Assumption:$ IND-CCA secure encryption). B believes $AS$ is authentic since $AS$ can produce $H{K}_{B1}$ to decrypt $C_2$ ($Assumption:$ IND-CCA secure encryption). $AS$ believes A is authentic since A knows $Chl{g}_{Ax}$ and possesses a physical PUF that can produce $H{K}_{Ax}$ from $Chl{g}_{Ax}$. (Definition 3.1). $AS$ believes B is authentic since B knows $Chl{g}_{Bx}$ and possesses a physical PUF that can produce $H{K}_{Bx}$ from $Chl{g}_{Bx}$. (Definition 3.1). A believes B is authentic since $AS$ asserts B and B has shared session key $SK$ B believes A is authentic since $AS$ asserts A and A has shared session key $SK$ Confidentiality of $SK$ is always preserved (Formal Verification Proof). An adversary cannot produce $H{K}_x$ even knowing $Chl{g}_x$ unless it possesses the specific physical PUF (Definition 2.4). $H{K}_A$ and $H{K}_A^{\prime }$ are unlinkable by an adversary (Definition 3.2). An adversary cannot recover $SK$ or $H{K}_x$ unless the $AS$ is dishonest or compromised.

6. Informal Security Analysis

The PUF device acts as a local root of trust, and as such, its security properties are crucial to the overall security posture of the scheme. All possible attacks to the device and underlying primitives are analyzed for completeness.

6.1. Challenge Response Search-Space

A SHIC PUF is a physical random oracle [28], such that the entropy pool of the challenge-response space is vast, yet the response is reproducible at the bit level for a given challenge, irrespective of the number of times the same challenge is presented. Our version of the protocol uses the SHIC PUF design from [29] and associated primitives from [26] to implement the protocol, although any SHIC PUF could be used.

6.2. Model-Building

A strong PUF can have its responses modeled and predicted using machine learning techniques, allowing a functional clone of a PUF device to be created by an adversary [30]. The results presented in [31,32] conclusively demonstrate it is possible to model certain PUF designs using evolutionary models or logistic regression (multi-layer perceptron) given only a subset of the CRPs. In particular, Arbiter XOR PUFs are shown to be broken by these techniques.

The SiRF PUF used in our experiments embeds certain properties that make model-building difficult. Primarily, the CRP search space is shown to possess LPN (Learning Parity with Noise) hardness, as discussed in [26]. Additionally, the delay in the response read-out is rooted in the process that measures and digitizes path delays at high precision, and cannot be circumvented. Finally, raw responses are never used without masking with one-way functions in CRP exchanges, a concept upon which PUF-MAKE extends.

The PUF-MAKE protocol uses obfuscated challenges and responses for authentication. Raw responses are ephemeral and discarded once the hash is computed. This requires the attacker to physically hack the hardware to extract the response bitstring, and to do so in a short interval of time before the response is deleted from memory. In particular, an attack of this nature would require an attacker to isolate the PUF read-out circuitry and probe the precise memory location where the response bits are stored.

The IA stores sufficient CRP information that, if compromised, would allow any PUF in the system to be cloned to the limit of provisioning information, at least until it is discovered that such an attack occurred and before the ${\mathrm{CRP}}_{DB}$ is replenished with new sets of CRP. For this reason, the IA is treated as a high-security infrastructure component that is kept in a highly controlled enterprise environment with explicit network segmentation and permission controls to restrict access. Similar arguments hold true for the AS, albeit the amount of information that would be compromised is smaller. AS needs only to connect periodically to the IA to refresh its authentication database. This interaction can be orchestrated carefully between two trusted entities using state-of-the art security, or dedicated channels, in addition to PUF-based authentication.

6.3. Unlinkability

We show the unlinkability of two distinct MAKE sessions through the following properties: Definition 2.4 guarantees that a SHIC PUF embeds sufficient entropy to generate an exponential number of challenge-response pairs, such that one-time use is possible for any reasonable time frame. Additionally, Definition 3.3 guarantees that any two keys generated by the same PUF are unlinkable to each other. Finally, Definition 3.4 guarantees that keys generated by two distinct physical instantiations of a PUF design will also be unlinkable to each other. Since all keys used in the protocol are derived from the PUF and only used for one iteration of the protocol, keys used in successive authentications are unlinkable.

6.4. Fault Injection

An attacker could attempt to flip one or more bits in the CPU during sensitive computations to change the control flow. The microprocessor component of system-on-chip (SoC) FPGAs is synthesized onto standard silicon processes and lacks specific tamper-resistant features. In the present approach, the difficulty of performing fault injection attacks is increased by implementing protocol steps at the FPGA synthesis level as Verilog state machines. In doing so, the attacker would be forced to first gain knowledge of the physical design; otherwise, randomly injecting faults would, with high probability, just cause state machine execution to halt or produce useless information. Execution of cryptographic primitives (AES, SHA-3) can be ported to hardware as well, and other necessary software functions (e.g., database query) can be transferred to a secure processing environment such as ARM TrustZone.

In terms of the core PUF primitives, fault injection is mitigated by the natural tamper-evident property of the PUF itself. Unlike cryptographic primitives, in which fault injection can be used to weaken the security, for instance by reducing the number of rounds in an AES encryption operation, fault injection performed during the PUF’s bitstring generation operations would only prevent the key material from being correctly generated or reproduced and result in a failed authentication attempt.

6.5. Stored Secret Exfiltration

An attacker could attempt to extract sensitive information stored on the PUF either at rest or during execution of the protocol. Timing and side-channel attacks have been exploited effectively against PUFs in the past [31]. All devices in the system (AS, Alice, and Bob) except for the IA are PUF devices. Each PUF device must be powered, activated, and presented an explicit challenge to elicit a corresponding response. Given the delicate nature and nanometer-sized features of the devices and wires embodying within-die variations, which represent the source of entropy for the PUF, it is impossible to ascertain the response by examining the silicon. Information stored in local non-volatile memory is encrypted at rest via a PUF-based KEK key. An attacker could attempt to exfiltrate the AES secret key during encryption/decryption operations via differential power analysis (DPA) techniques. While this is possible, it is noted that the window of opportunity to exfiltrate the key and make use of it in a single transaction is small, and the power transient information would be completely different for the next authentication cycle since each key is only used once before replacement.

An attacker could manipulate the communications channel to force Alice to make repeated authentication attempts with the same ${\mathrm{HK}}_A$. For the present work, we used the AES version implemented in the OpenSSL library, which is susceptible to side-channel attacks such as differential power analysis [33] on common processors, including ARM platforms. This attack can be mitigated by switching to a hardened hardware version of AES, with suitable care taken during implementation to prevent leakage [34]. Note that even if a key is compromised, it can only compromise a single authentication cycle as the scheme uses a brand new challenge for every authentication attempt, achieving perfect forward secrecy.

6.6. Bitstream Manipulation

An attacker could steal the device and attempt to read out all the CRPs by repeating the provisioning process. This attack is prevented by disabling the provisioning operation in the bitstream of fielded devices. An adversary can attempt to reverse engineer the in-field bitstream and re-enable the read-out functionality. However, the FPGA bitstream is encrypted in persistent storage on the device, and therefore the adversary would need to extract the bitstream decryption key from the FPGA to obtain an unencrypted bitstream and then go through a reverse engineering process to make changes to enable provisioning. Although possible, the process is designed to be very difficult by the FPGA manufacturer. Note that an ASIC version of the PUF entirely obviates this attack vector.

6.7. Cryptographic Primitives

The practical instantiation of the protocol relies on the mathematical operation XOR, the AES cryptographic primitive for symmetric encryption/decryption, and SHA-3 for hashing operations. Note that any symmetric encryption and hashing primitive are compatible with the protocol. Cryptographically secure implementations of AES and SHA-3 used in the experimental prototype are sourced from OpenSSL. The XOR operation is used for performance and is interchangeable with a symmetric block cipher primitive for added security if desired. The protocol is future-proof in that it does not rely on specific properties of AES and SHA-3, and any symmetric block cipher plus hash function can be used instead, in case these primitives happen to be broken in the future.

6.8. Enrollment

A local adversary could eavesdrop on the MAKE enrollment process. During initial enrollment, the customer device and IA carry out a P3B mutual authentication and session key generation process with IA. Therefore, it is not possible for an adversary to collect and manipulate plaintext information or insert new information between the customer device and IA. The same process is carried out between IA and AS during enrollment and refresh operations, and the same protections are afforded against MITM. Furthermore, enrollment would typically occur in a trusted environment with additional enterprise security controls in place.

6.9. Correctness of In-Field Authentication

The correctness of the in-field protocol was verified and proven by the use of a cryptographic protocol verification tool. A formal verification tool, Verifpal, was used to verify protocol correctness and ensure that security goals specified on the outset were satisfied by the protocol’s construction. Verifpal is an automated formal verification system that employs deductive reasoning to emulate both a passive and an active attacker [35]. It emulates a Dolev-Yao threat model [36] for the active attacker. Under this model, the attacker is a powerful adversary with a high computational capability, full knowledge of the protocol, and the ability to observe and manipulate all communications channels in use. To simulate this capability, the prover allows the attacker to perform the following actions:

• Perform all attacks available to a passive attacker
• Control all communications channels specified in the model
• Collect packets over multiple runs of the protocol
• Inject, manipulate, replay, or delete messages at any point with information gathered from previous runs

In the present work, the use of the tool was explicitly focused on proving channel security, namely that Alice and Bob are able to exchange session key shards securely and confidentially, without the attacker learning the secret key. Figure 3 illustrates the model constructed under Verifpal, mirroring Steps 0–7 in Figure 2, with all PUF-specific operations excised for clarity.

Confidentiality and equivalence are tested by specifying queries at the end of the model description, which the attacker attempts to falsify through repeated runs of the protocol. The protocol is deemed secure if confidentiality of the secret key is preserved and the only attack possible is a denial of service. Note that an adversary in complete control of the communications channels can always prevent Alice and Bob from receiving the necessary information required to authenticate each other, thus causing a denial of service, irrespective of security protections inherent to and external to the protocol.

Queries tested by Verifpal are depicted in Figure 4. The first two confidentiality queries establish secrecy of the session key shards, while the equivalence establishes that packets sent across the communications channel were not tampered with (denial of service). As expected, Verifpal successfully verifies the confidentiality statements and fails to verify the equivalence statement. Therefore, secrecy of the session was formally proven under all active and passive channel attacks. PUF-related information and key update steps could not be tested due to the tool’s inability to model PUF-based primitives. As such, it was not possible to formally prove key freshness, even though each $H{K}_x$ is used only once and static analysis confirms freshness guarantees.

6.10. Freshness and Replay

The key update mechanism relies on a unique (Chlg, HK) tuple, which is used only once per authentication and renewed on every authentication, mitigating all replay attacks. This use-only-once implementation practice is also utilized during enrollment, during the P3B MA and SKG operations, and one-time nonces are used at critical points throughout the protocol to ensure that all aspects of the in-field authentication are impervious to replay attacks.

Step 6 in Figure 2 refreshes $H{K}_x$ after each successful authentication, guaranteeing freshness and preventing replay attacks on Alice and Bob. Nonetheless, an attacker may delete AS’s response to Alice in Step 6. While this would cause the authentication attempt to fail, it would also prevent Alice from receiving the challenge information needed to generate ${\mathrm{HK}}_{A2}$, thus causing a synchronization error in the next iteration where Alice would use $H{K}_{A1}$ as the session key with AS whereas the AS expects to use $H{K}_{A2}$. The protocol prevents this attack via Step 10, where AS only updates the database entry for Alice once Alice confirms her receipt of $H{K}_{A2}$.

6.11. AS Spoofing and Key Exfiltration

An adversary could attempt to spoof the AS to manipulate Alice and Bob transactions. This attack would be detected by the AS at Step 3 during decryption of ${\mathrm{C}}_1$ or ${\mathrm{C}}_2$. A packet injected by the attacker using an unknown key would be detected by Alice and/or Bob during decryption. For an attacker to succeed, $H{K}_x$ keys would need to be leaked at either the device level or at the AS. Given that the AS is a trusted infrastructure component protected by enterprise security controls such as network segmentation and access control, the latter vector is deemed mitigated. In addition to typical enterprise-level controls, the AS is also equipped with a SHIC PUF; ergo, the ${\mathrm{AuTk}}_{DB}$ database is encrypted in persistent storage by a KEK key produced by the PUF at boot-up. The adversary would need to extract an in-memory copy of the KEK key to obtain a plaintext copy of ${\mathrm{AuTk}}_{DB}$ as PUFs do not store keys in persistent storage.

7. Experimental Results

The proposed protocol is implemented using a co-design methodology, with both software (C code) and hardware (Verilog) components defining various aspects of the protocol. The PUF and KEK algorithms are implemented entirely in Verilog, and synthesized to a Xilinx Zynq 7010 system-on-chip (SoC) FPGA embedded on the Digilent ZYBO Z7-10 board [37]. The PUF uses high-speed general-purpose input-output (GPIO) registers to exchange challenges and KEK bitstrings with software components of the protocol running on the embedded ARM microprocessor. The Linux operating system running on the microprocessor provides a TCP-IP network stack to enable communications between protocol entities.

The IA component is implemented on a Dell PowerEdge T440 server equipped with 32, 1.8 GHz processors and 128 GB of main memory. The implementation test bed possesses the following characteristics:

• The programmable logic (PL) component of the Zynq 7010 FPGA board is programmed with an instance of a SiRF PUF and KEK key generation algorithm, namely, those described for the SiRF PUF in [29]. A C program running under Linux coordinates communications between network entities and the PUF hardware. A microSD card provides NVM storage.
• The AS is also implemented on a ZYBO Z7-10 board, with the PL component programmed with an instance of the PUF. The C program implementation of AS is a multi-threaded application enabling concurrent communication through sockets with multiple customer devices, and with the IA. The AS utilizes sqlite3 databases to implement the ${\mathrm{AuTk}}_{DB}$ and ${\mathrm{SESSION}}_{DB}$ components of the MAKE protocol.
• The IA is implemented as a multi-threaded application with socket communication channels to customer devices and to AS. It also utilizes a sqlite3 database to implement the ${\mathrm{CRP}}_{DB}$ component.
• An openSSL implementation of the AES encryption algorithm is used for all protocol encryption and decryption operations. AES is configured to use a 256-bit key and CBC mode.
• An openSSL implementation of the SHA-3 256-bit hashing algorithm is used for all protocol hashing operations.

A series of experiments are carried out to evaluate the scalability of the protocol in which Enrollment and InField protocol operations are run with different numbers of AT. The time required to carry out the various steps of the authentication protocol is measured by having Alice and Bob’s device perform repeated authentications. Four experiments are performed with the AS ${\mathrm{AuTk}}_{DB}$ database configured with 10, 100, 1000, and 10,000 AT. The PUF KEK bitstrings collected over the duration of the run are analyzed to determine the statistical quality of the bitstrings.

7.1. KEK Bitstring Statistical Analysis

The Entropy and MinEntropy statistics associated with the KEK bitstrings produced during the execution of the ‘10,000 AuTk experiment’ are plotted as a function of time in Figure 5. The results for the 10,000 KEK bitstrings generated by Alice and Bob are plotted as two superimposed curves and are analyzed in groups according to the number generated during each 1 min time interval (x-axis) over the duration of the run. The duration of the protocol run is ∼270 min. Therefore, each group includes ∼37 KEK bitstrings. The equations for Entropy and MinEntropy are given by Equations (3) and (4), where p and q are the probabilities of 0 and 1 occurring in a KEK bitstring X of length 256 bits, respectively, and $max(p,q)$ returns the larger of p or q. Given the bits in the bitstring are either 0 or 1, it follows that q = 1 −p.

$$\mathbf{H}\left(\mathbf{X}\right)=-p\times lo{g}_2\left(p\right)-q\times lo{g}_2\left(q\right)$$

(3)

$${\mathbf{H}}_{\infty }\left(\mathbf{X}\right)=-lo{g}_2\left(max(p,q)\right)$$

(4)

The ideal value for Entropy and MinEntropy is 1.00, which is nearly achieved for Entropy with an average value of 0.997, computed using all 10,000 256-bit bitstrings concatenated as a 2,560,000-bit bitstring. MinEntropy varies over the range of 0.92 to 0.95, which indicates that in the worst case, each KEK bit generates on average 0.93 bits of Entropy. According to the literature, the Entropy and MinEntropy statistics obtained in these experiments indicate the KEK bitstrings are of cryptographic quality.

The inter-authentication bitstring hamming distances (${\mathrm{HD}}_{IAB}$) of the KEK bitstrings are plotted in Figure 6, also as a function of one-minute time intervals. The sequences of KKs produced by Alice and Bob are analyzed separately. ${\mathrm{HD}}_{IAB}$ is computed by pairing the bitstrings within each group from the same device under all combinations. The number of bit-wise differences is summed across all pairing combinations and then divided by the total number of bits in the bitstrings from the group. Equation (5) gives the expression for ${\mathrm{HD}}_{IAB}$, converted to a percentage as shown in the figure. Here, $NBS$ represents the number of bitstrings (approx. 37 per group), $NB$ is the number of bits per bitstring (256), $TNB$ is the total number of bits in each bitstring group, and $BS$ denotes the bitstrings themselves.

$${\mathbf{HD}}_{\mathbf{IAB}}={\displaystyle \frac{\sum _{i=1}^{NBS}\sum _{j=i+1}^{NBS}\sum _{k=1}^{NB}(B{S}_{i,k}\oplus B{S}_{j,k})}{TNB}}\ast 100$$

(5)

The ${\mathrm{HD}}_{IAB}$ values are very close to the ideal value of 50%, with the overall mean value across all bitstring pairing combinations (10,000 × 9999/2 pairings) given as 49.997%. The $3{\sigma }_{IAB}$ values for each group are also depicted in the lower portion of the graph. The expected value is given by the binomial expression in Equation (6). With $NB$ = 256, the expected value is 9.375%. The data plotted in the figure is a very good match to the expected value.

$$3{\sigma }_{IAB}={\displaystyle \frac{3\times \sqrt{NB\times 0.25}}{NB}}\times 100$$

(6)

Alice and Bob’s 256-bit bitstrings are concatenated to form bitstrings of length larger than 50,000 bits and evaluated using the NIST statistical test suite. All applicable NIST tests for bitstrings of this size passed as well as the p-value-of-the-p-value tests. A separate set of experiments is carried out on a set of 120 PUF instances on FPGAs in which KEK regeneration is evaluated across extended industrial range temperatures, from −40 °C to 100 °C. The results obtained indicate that the probability of a bit-flip error is less than $1\times {10}^{-8}$, i.e, one chance in 100 million.

The MAKE enrollment operations take approx. 1.75 s per AT generation. For example, the total amount of time to generate 10,000 AT for both Alice and Bob and for the AT to be transmitted and stored in the ${\mathrm{AuTk}}_{DB}$ on the AS is 4.87 h.

The run times for the MAKE In-Field protocol operations are given in Figure 7, partitioned into a sequence of 7 protocol steps along the x-axis. The ordering of the steps given here is consistent with, but not identical, to the sequence of operations shown in Figure 2. The bar heights give the run times in seconds of 4 experiments, each carrying out different numbers of Alice-Bob authentications as shown along the y-axis.

The run times are nearly constant at ∼1.8 s per authentication for the first three experiments, with the ${\mathrm{AuTk}}_{DB}$ database enrolled with 10 through 1000 AT, respectively. The run time increases to ∼2.2 s for the 10,000 AT experiment. From the bar graph, the increase is attributed to operations carried out in step 4, where AS performs a database search before it can return the ${\mathrm{C}}_A$ and ${\mathrm{C}}_B$ packets to Alice and Bob. With the ${\mathrm{AuTk}}_{DB}$ database populated with 10,000 AT, the search process adds ∼0.4 s to the overall runtime.

Although only one AS device is used in our experiments, the proposed system architecture can support an arbitrary number of authentication servers (AS), which enables the protocol to scale up to millions of customer devices without incurring additional database search time penalties. The ${\mathrm{AuTk}}_{DB}$ database in this type of distributed environment would be populated with local customer device authentication tokens (AT) to enable value-exchange operations to occur with local vendors, in combination with AT from popular global retailers, such as Amazon.

7.2. Communication Complexity

The device-side communication complexity of in-field authentication can be expressed as $1N_{PUF}+1N_H+3N_{ENC}+2N_{DEC}$, which denote PUF, hash, block cipher encryption, and decryption operations, respectively. Note that the storing and retrieving of Chlng and helper data from the NVM, as well as the XOR operation used in session key construction, have only minor computation costs and are therefore not included. Similarly, the computational complexity of the AS per iteration of the protocol can be expressed as: $2N_{DBS}+1N_{DBC}+2N_{ENC}+2N_{DEC}$, where $DBS$ refers to a DB search operation and $DBC$ refers to a DB record creation operation. Encryption and decryption operations are constant time, $O\left(1\right)$, hashing with SHA-3 is a linear operation with a complexity of $O\left(n\right)$. The generation of the PUF response, $N_{PUF}$, is $O\left(n\right)$, where n is the number of response bits generated. The database search operation is characterized as $O(n·log(n\left)\right)$ for a SELECT query applied to a single table containing n records. Note that in terms of absolute time, $N_{PUF}$ is the dominant operation. On the instantiated PUF device, the response regeneration time to a PUF challenge takes 1 s, as shown in the performance analysis section.

The total communication complexity is presented in

Table 1. Comparison of complexity between the state of the art (SOTA) and our proposed approach.

Scheme	Single Node	Server
SOTA [21]	$\begin{array}{c}1N_{PUF}+3N_H+1N_{ECCR}+2N_{ENC}+2N_{MAC}\end{array}$	$\begin{array}{c}2N_{ENC}+2N_{DBS}+1N_{ECCG}\end{array}$
This work	$\begin{array}{c}1N_{PUF}+1N_H+3N_{ENC}+2N_{DEC}\end{array}$	$\begin{array}{c}2N_{DBS}+1N_{DBC}+2N_{ENC}+2N_{DEC}\end{array}$

and compares favorably to a recently proposed scheme. Zheng et al. [21] present the complexity analysis of other, more expensive, peer-to-peer authentication protocols, which are omitted here. Note that the SiRF PUF uses an error avoidance algorithm that runs in linear time, which is included in the $N_{PUF}$ metric, in contrast to the ’Rep’ operation of ECC, which is unspecified but can be on order of O($n^2$) for an n-bit response. The symbol $N_{ECCR}$ in the table refers to the heavier-weight ’Rep’ operation of ECC, while $N_{ECCG}$ refers to the lighter-weight ‘Gen’ operation.

7.3. Resource Utilization

The number of LUTs utilized to implement the SiRF PUF authentication, session key generation, KEK LLK, and TRNG operations on the Xilinx Zynq 7010 system-on-chip (SoC) device is 5842, while the AES encryption and SHA-3 hashing algorithms consume 6937, which is approximately 77% of the 17,600 LUTs available. Additional details regarding programmable logic resource utilization are available in [38].

A C program running on the ARM Cortex A-9 processor co-located on the Xilinx Zynq 7010 SoC device implements all network, database, and bookkeeping operations on customer devices. The size of the binary is approximately 150 KB. The Chlng and HD stored in an NVM by customer devices during enrollment is 4 bytes and 512 bytes, respectively. The Chlngs for the SiRF PUF are represented as a 4 byte seed to an LFSR, which is used to look up challenge vectors from a $Chln{g}_{DB}$, which is approximately 1 megabyte in size [38]. The HD is sufficient to generate a 256-bit KEK LLK. The size of each AT in the ${\mathrm{AuTk}}_{DB}$ database on the server is given as 4 bytes for the ID, 32 bytes for the HK, 4 bytes for the Chlng, and 512 bytes for the HD.

8. Conclusions

Herein, we propose and evaluate a light-weight PUF-based mutual authentication and key exchange (MAKE) protocol designed for high-security applications. The protocol is composed of three distinct phases, namely provisioning, enrollment, and in-field interactive authentication. Evaluation was performed on a set of three FPGAs that incorporate programmable logic instantiations of strong (SHIC) PUF and KEK algorithms and a desktop server. Run times of the interactive in-field authentication operations are upper bound at 2.2 s with an authentication token database containing 20,000 authentication tokens. The computational complexity was analyzed and compared favorably to the state of the art. A detailed security analysis was conducted, in particular channel security for the in-field authentication protocol was formally proven to be cryptographically secure under the Dolev-Yao adversary model, making PUF-MAKE a good candidate for high-security applications such as digital currency transactions for goods and services.