Programmable access-controlled and generic erasable PUF design and its applications

Abstract

Physical unclonable functions (PUFs) have not only been suggested as a new key storage mechanism, but—in the form of so-called strong PUFs—also as cryptographic primitives in advanced schemes, including key exchange, oblivious transfer, or secure multi-party computation. This notably extends their application spectrum, and has led to a sequence of publications at leading venues such as IEEE S&P, CRYPTO, and EUROCRYPT in the past. However, one important unresolved problem is that adversaries can break the security of all these advanced protocols if they gain physical access to the employed strong PUFs after protocol completion. It has been formally proven that this issue cannot be overcome by techniques on the protocol side alone, but requires resolution on the hardware level—the only fully effective known countermeasure being so-called erasable PUFs. Building on this work, this paper is the first to describe a generic method of how any given silicon strong PUF with digital CRP-interface can be turned into an erasable PUF. We describe how the strong PUF can be surrounded with a trusted control logic that allows the blocking (or “erasure”) of single CRP. We implement our approach, which we call “GeniePUF,” on FPGA, reporting detailed performance data and practicality figures. Furthermore, we develop the first comprehensive definitional framework for erasable PUFs. Our work so re-establishes the effective usability of strong PUFs in advanced cryptographic applications, and in the realistic case, adversaries get access to the strong PUF after protocol completion. As an extension to earlier versions of this work, we also introduce a generalization of erasable PUFs in this paper, which we call programmable access-controlled PUFs (PAC PUFs). We detail their definition, and discuss various exemplary applications of theirs.

Appendices

Appendix A: Background on authenticated search trees and red-black trees

Fig. 6

Proof construction in an authenticated search tree. Suppose that one needs to prove that $c_{new}$ does not exist in the authenticated search tree (containing $c_0$ to $c_5$). For example, the dashed node shows the location where $c_{new}$ is supposed to be. The green information is included in the proof of non-existence for $c_{new}$. Note that the hash value stored in the left child of $c_4$ is also needed in the proof, but it is omitted in the diagram, because it is a nil node in the tree (color figure online)

Fig. 7

Insertion of a new node 4

An authenticated search tree was introduced in [45] as an undeniable attester. In the context of our GeniePUF, an untrusted Red-Black Tree (RBT) interface is used, which manages LIST of size n. It takes a challenge as input, and generates a proof of non-existence/existence of this challenge in LIST. Notice that, the length of the proof is only $\mathcal {O}(log(n))$ long. Upon receiving the non-existence/existence proof, the TCB around the PUF can then verify the proof by checking against a constant-sized ($\mathcal {O} (1)$) root hash stored in the TCB. This root hash does not need to be kept secret, i.e., it can be known to adversaries; it must merely be secure against alteration or overwriting by adversaries.

To further improve the performance of an authenticated search tree in the worst-case scenario, where a standard search tree will become extremely unbalanced, we merge a red-black tree (RB tree) [46, 64] with the authenticated search tree in the untrusted memory. In short, a red-black tree is one self-balancing binary search tree structure [46, 64], which checks and balances the depth of the tree after every node insertion and deletion. Hence, a Red-Black tree can guarantee searching in $\mathcal {O}(log(n))$ time in the average and the worst scenario, where n is the total number of nodes in the tree [46].

In the following, we will describe the necessary procedures of our authenticated red-black trees (e.g., we only describe node insertion, not deletion, because in the GeniePUF application, LIST can only grow). In particular, we present the high-level idea of the following basic schemes of our combined tree structure to prepare the readers for understanding this paper.

An authenticated search tree is sorted according to the challenges stored in each node, and it is constructed in such a way that each node consists of a unique challenge $c_i$ in the LIST and a hash value $h_i = F_\mathsf{Hash}(c_i, left(c_i).hash, right(c_i).hash)$, where $left(c_i).hash$ and $right(c_i).hash$ are the hash values stored in the left or right child of node $c_i$, respectively. The hash values of the children of the bottom leaves are considered to be 0 by default. An example tree structure is shown in Fig. 6.

Scheme 3

(Searching for a Challenge $c_i$ in a RBT)

• 1 The RBT interface receives a challenge $c_i$.

• 2 The RBT interface searches for $c_i$, using the RBT as an ordinary binary search tree.

• 3 In the end, it results in two cases:

  • If $c_i$ is found, then a pointer to the node associated with $c_i$ is returned.

  • If the binary search for $c_i$ within RBT reaches a leaf node, where no challenge is stored, then the interface returns a pointer to the parent node of the leaf node. (This parent node is the lowest node in the tree whose child $c_i$ would have supposed to be, if $c_i$ was part of the RBT.) In the example in Fig. 6, the returned pointer will be pointing to the node containing $c_4$.

Scheme 4

(Generating a PROOF of Existence/Non-Existence of a Challenge $c_i$ in a RBT)

• 1 After a search for $c_i$, as described in Scheme 3, is completed in the LIST (either found or not found), the RBT interface gets a node in the tree from the search procedure. It sets this node as the starting node of the PROOF.

• 2 The interface adds the challenge of the starting node and the hash values stored in the children nodes of the starting node into the PROOF. Again, taking the example of Fig. 6, the information added is $c_4$ and the hash values of its two children (two nil nodes).

• 3 Then, the RBT interface fetches the challenge of the node and the hash value in the sibling node of each node along the path in the tree from the starting node to the root of the tree to generate the completed PROOF of non-existence/existence of $c_i$, e.g., adding $(c_1, h_3)$ and $(c_0, h_2)$ into the PROOF, as shown in Fig. 6.

• 4 It returns the completed PROOF.

The proof construction process is also illustrated in Fig. 6.

Scheme 5

(Verifying a PROOF of Existence/Non-Existence)

• 1 All the proofs generated by the RBT interface have to be verified by the trusted control logic CL. After a proof is received, the CL checks the starting node first. If it is a proof of non-existence, the CL checks whether the left/ right child of the starting node is a leave node based on whether c is smaller/ greater than the challenge in the starting node. In the case of an existence proof, the CL verifies the order of the two children and the starting node. If any of the above check failed, return “$\bot$”.

• 2 Then, the CL hashes every node from the starting node of the proof all the way to the root, using the challenge value of each node and their sibling hash values provided in the proof. The order of left and right child is determined by comparing two consecutive challenges in the PROOF. The final result is RootHash’.

• 3 Check if RootHash’ = RootHash stored in the TCB:

  • If yes, we conclude that the PROOF is a valid proof. Based on whether it’s an existence proof or a non-existence proof, we conclude whether $c_i$ is in the LIST or not.

  • If no, the PROOF is considered as invalid, and we conclude that either the LIST or the RBT Interface has been tampered with by an attacker.

Scheme 6

(Adding a New Challenge $c_i$ to the RBT)

• 1 In the case that a new challenge $c_i$ needs to be added to the LIST, the RBT interface first proves that $c_i$ is not in the LIST using the above schemes.

• 2 If the non-existence of $c_i$ gets accepted by the verifier, then $c_i$ is added as a child of the node returned by the search procedure.

• 3 After insertion, a red-black tree fixup is triggered. It may rotate the structure of the tree to re-balance it. More details about the red-black tree fixup can be found in the example in Appendix B and [46].

• 4 After fixup, a new RootHash will be generated by the trusted control logic CL according to the fixup information of the tree and the proof of non-existence used in Scheme 3.

Note that, based on the way the authenticated search tree is constructed and verified, its security solely relies on the collision resistance of the underlying hash function.

Appendix B: Example rotation of an authenticated RB tree

Figure 7 depicts an example of consecutive operations in Red-Black Tree Insert-Fixup, see [46]. (a) A new node 4 is inserted. The dashed path in (a) is PROOF. All of the information in nodes 5, 7, 2, and 11 are included in PROOF, together with the hash values of nodes 8, 1, and 14, called the sibling’s hash values. In order to verify non-existence, we need to reconstruct the root hash using PROOF and compare with the trusted root hash stored in the TCB. In addition, we need to check whether new node 4 is added at the correct location, which means $2< 4 <5$, and node 5 has no left child. Here, case 1 in [46] applies, so nodes 5 and 7 are recolored but the structure remains the same.

There are six possible cases in a RB tree fixup, in which only case 2, 3, 5, and 6 in [46] will rotate the structure of the tree; this example shows three cases (the other three cases are similar in that they are mirrored versions of the three in the example). In (b), (c), and (d), the nodes in dashed blocks are the nodes which hash values need to be updated; the transition from (b) to (c) is a rotation and the transition from (c) to (d) is a rotation. Note that, PROOF already provides all the information needed for updating these hash values. In this example, in order to compute the hash of nodes 2, 7, and 11 in (d), we need the hash value of node 5, which was updated in case 1 during the transition from (a) to (b), and the hash values of nodes 1, 8, and 14, which are exactly the sibling’s hash values that are contained in PROOF.

Appendix C: Proofs of theorems

In the following proofs, we assume that ignoring operations or communication does not increase the original execution time $t_\mathsf{att}$ of an adversary.

1.1 C.1 Proof of Theorem 1

Proof

We will show the contraposition of the above statement, assuming that P is not an $(k, t_\mathsf{att}, \epsilon )$-secure strong PUF with respect to some adversary $\mathcal {A}$. By Definition 2, this implies that there exists an adversary $\mathcal {A}$ who is capable of winning the security game $\mathbf {SecGameStrong} \, (P, \mathcal {A}, k, t_\mathsf{att})$ of Definition 2 with probability greater than $\epsilon$. This, in turn, means that $\mathcal {A}$ can predict the correct response to one out of k uniformly randomly chosen challenges $c^j \in C_P$ with probability greater than $\epsilon$, whereby the time that $\mathcal {A}$ requires for his physical actions and numeric computations does not exceed $t_\mathsf{att}$.

We notice that the very same adversary $\mathcal {A}$ will also win the security game $\mathbf {SecGameErasable} \, (P, \mathcal {A}, k, t_\mathsf{att})$ with probability greater than $\epsilon$. The reason for this is that the execution of the security game $\mathbf {SecGameErasable} \, (P, \mathcal {A}, k, t_\mathsf{att})$ with $c^j=c^j_\mathsf{erase}$ is identical to the execution of the security game $\mathbf {SecGameStrong} \, (P, \mathcal {A}, k, t_\mathsf{att})$ because adversary $\mathcal {A}$ in $\mathbf {SecGameErasable} \, (P, \mathcal {A}, k, t_\mathsf{att})$ never attempts to query an erased challenge $c^j=c^j_\mathsf{erase}$. This implies that P is not a $(k, t_\mathsf{att}, \epsilon )$-secure erasable PUF, completing our contraposition argument. $\square$

1.2 C.2 Proof Sketch of Theorem 2

Proof Sketch. Let $\mathcal {A}$ be any adversary that is modeled by Definition 5. We define a series of games that reduce

$$\begin{aligned} \mathbf {SecGameErasable} \, (P, \mathcal {A}, k, t_\mathsf{att}), \end{aligned}$$

with probability of winning denoted by $\epsilon _\mathsf{erase}$, to

$$\begin{aligned} \mathbf {SecGameStrong} \, (P, \mathcal {A}', k, t_\mathsf{att}), \end{aligned}$$

where $\epsilon$ is the probability of winning as stated in the theorem.

We first modify $\mathbf {SecGameErasable}$ by assuming an adversary $\mathcal {A}^0$ who is like $\mathcal {A}$ but who cannot produce a valid PROOF for an invalid claim that a challenge was not erased in its interactions with GeniePUF(P). We call this new game $\mathbf {SecGameErasable}^0$ and denote the probability of winning this game by $\epsilon _0$. By the implicit assumptions on the capabilities of the adversary in Definition 5, we know that the control logic CL and PUF P cannot be modified. Therefore, the only way to produce a valid PROOF for an (erased) challenge c in RBT is to find a collision for the hash function. By Theorem 1 in Section 6.2 of [45], the probability of finding a valid PROOF is at most $\rho$. This shows that

$$\begin{aligned} \epsilon _\mathsf{erase} \le \epsilon _0 + \rho . \end{aligned}$$

Not being able to provide a valid PROOF for an invalid claim in $\mathbf {SecGameErasable}^0$ means that the GeniePUF(P) does not produce responses for erased challenges. This is similar to the same game $\mathbf {SecGameErasable}^0$ where in Step 4a only a challenge $c^j_\mathsf{erase}$ is chosen at random but not erased, and with the restriction that the adversary is not allowed to query $c_\mathsf{erase}^{j}$ after $c_\mathsf{erase}^{j}$ is given to the adversary in Step 4b. We call this game $\mathbf {SecGameErasable}^1$. We now define $\mathcal {A}^1$ as adversary $\mathcal {A}^0$ by discarding any erasure operations which $\mathcal {A}^0$ asks for in Step 2 or Step 4c (these operations cannot lead to feedback from GeniePUF(P) which contains predictive information that can be used in Step 5). For $\mathcal {A}^1$, we can now conclude that game $\mathbf {SecGameErasable}^1$ has winning probability $\epsilon _1$ for which

$$\begin{aligned} \epsilon _0= \epsilon _1. \end{aligned}$$

Notice that $\mathbf {SecGameErasable}^1$ does not implement any erasure operations. Because $\mathbf {SecGameErasable}^1$ disallows querying any of the $c_\mathsf{erase}^j$ after being selected in Step 4a and communicated to $\mathcal {A}^1$ in Step 4b of game $\mathbf {SecGameErasable}^1$, we know that the control logic CL of GeniePUF(P) simply provides direct access to P for the queries by $\mathcal {A}^1$. Therefore, the control logic of GeniePUF(P) provides direct access to P in $\mathbf {SecGameErasable}^1$ and provides no other functionality. This means $\mathbf {SecGameErasable}^1$ results directly in a game for PUF P where we have conceptually stripped away the control logic of GeniePUF(P).

Unrolling all the steps in $\mathbf {SecGameErasable}^1$ for P shows its equivalence with $\mathbf {SecGameStrong}$. We now define $\mathcal {A}'$ as $\mathcal {A}^1$ where any attempt by $\mathcal {A}^1$ to read state in RBT or control logic CL is replaced by dummy observations. For $\mathcal {A}'$, we may now conclude that $\mathbf {SecGameStrong}$ has winning probability

$$\begin{aligned} \epsilon _1=\epsilon . \end{aligned}$$

By combining all inequalities and equations we have

$$\begin{aligned} \epsilon _\mathsf{erase}\le \epsilon +\rho . \end{aligned}$$