Physical Unclonable Functions (PUFs)

Our world of full of fake goods. Do you know if the components in your device are valid? Well, Physical Unclonable Functions (PUFs) are one…

Photo by Phil Shaw on Unsplash

Physical Unclonable Functions (PUFs)

Our world of full of fake goods. Do you know if the components in your device are valid? Well, Physical Unclonable Functions (PUFs) are one way to create a unique signature pattern based on the inherent delays within the wireless and transistors. With this, we could provide the chips on the device with a range of challenges, and then monitor the response. Every chip would then provide us with a different response, and where we can properly identify a device from one or more chips on the device.

The PUF method works differently from a traditional approach of storing an encryption key on the device, and where it is provided with a series of challenges, and produces a unique response. This matching of the challenge to the response can then be used to match to the specific device.

Arbiter PUF

Figure 1 shows an Arbiter PUF, and uses a MUX. With a MUX, it we have an 0 on the X input, we select the 0 input, and a 1 will select the 1 input. It is basically a controllable switch. For each input, we compute one output value (Y). In this case, there are 128 X inputs (X[0] … X[127]). There are two main paths for the signals. This path will be determined by the X[] inputs, and there will be a race to produce the output for the latch. For the blue box, we have a D-latch, where the value on the D input is latched by the other input. If the upper signal arrives first before the latch, a ‘1’ will be outputted, otherwise a ‘0’ is output. The race will all depend on the delays in the lines and in the MUXes.

Figure 1: Arbiter PUF [1]

There will be 2¹²⁸ different delay paths involved, which will give a fairly unique signature pattern. We can then produce a k-bit response to the circuit k times with a different challenge (X[]), and take a single bit each time. These challenges are typically a random seed value. There are thus k bit vectors for the challenge (X[]) and the result is k bits (Figure 2).

Figure 2: Challenge-response for a PUF [2]

In practice, we further obfuscated the generation of the PUF by XOR’ing multiple outputs [8] (XORArbiterPUF). This is illustrated in Figure 2, and where we now have multiple parallel paths. The outputs of each of the D-gates are then XORed together.

Figure 3: XORArbiterPUF [8]

Oscillator PUFs

An improvement in a PUF circuit is to use N identical oscillators. These oscillators are fabricated with the same design parameters, but, due to tiny differences in their fabrication, they will create a square wave with different frequencies (Figure 4). An input then selects one of the outputs for the top MUX and for the bottom MUX. There is thus a race between the two selected values. Two counters then hold a running value of the two selections, and finally, we output a ‘1’ if the top counter is greater than the bottom counter, else a ‘0’. Due to entropy requirements, we need 35 oscillators to produce 133 bits, and 1,024 oscillators to produce 8,769 bits.

Figure 4: Oscillator PUF [1]

Using a PUF for cryptographic key generation

As we generate randomness in the PUF, we can also use the PUF circuit to generate a cryptographic key (Figure 5). In this, we use an ECC (Error Correcting Code) to always produce the same output — even in there are variations in voltage, temperature, and so on.

Figure 5: Random encryption key generation with a PUF [1]

PUF Simulation

Overall, we can simulate this activity with the PyPuf library. The output uses either a -1 or a 1 for the simulation of the bit values for challenges and responses. To simulate an 8-XOR 64-bit XOR Arbiter PUF, we can use:

from pypuf.simulation import XORArbiterPUF
puf = XORArbiterPUF(n=64, k=8, seed=1)
from pypuf.io import random_inputs
puf.eval(random_inputs(n=64, N=3, seed=2))

In this case, we have a seed value of 1 for the XORAribierPUF, and 2 for the generation of random inputs. Overall, this would be a randomly generated value, but where a fixed seed will produce results that are reproducible.

For example, to evaluate an Arbiter PUF on three randomly chosen challenges. A sample run for a challenge length of 16 (n), with 8 challenges (k), and with seed values of 4 and 9, we get [here]:

Challenge length:  16
Number of challenges: 8
Seed PUF: 4
Seed challenge: 9
PUF challenges
[[-1 1 1 -1 -1 1 1 1 -1 -1 -1 -1 1 1 1 1]
[-1 1 -1 -1 -1 -1 -1 1 1 -1 -1 -1 -1 1 -1 -1]
[ 1 -1 1 -1 1 -1 1 1 -1 -1 1 1 -1 1 1 -1]
[ 1 -1 1 1 -1 1 -1 1 -1 -1 1 1 1 -1 -1 1]
[-1 -1 -1 1 1 -1 -1 1 1 1 -1 -1 1 1 1 -1]
[ 1 -1 1 -1 -1 1 -1 -1 -1 1 1 -1 -1 1 1 1]
[-1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 -1 1 -1 1]
[-1 1 -1 -1 1 1 -1 1 -1 1 -1 -1 -1 -1 1 -1]]

PUF output
[-1 1 -1 -1 1 -1 1 1]

The code used is here:

from pypuf.simulation import XORArbiterPUF
from pypuf.io import random_inputs
import sys

nchal=10
nval=8
seedPUF=1
seedchallenges=2

if (len(sys.argv)>1):
nval=int(sys.argv[1])
if (len(sys.argv)>2):
nchal=int(sys.argv[2])
if (len(sys.argv)>3):
seedPUF=int(sys.argv[3])
if (len(sys.argv)>4):
seedchallenges=int(sys.argv[4])

print("Challenge length:\t",nval)
print("Number of challenges:\t",nchal)
print("Seed PUF:\t\t",seedPUF)
print("Seed challenge:\t\t",seedchallenges)

puf = XORArbiterPUF(n=nval, k=2, seed=seedPUF)

challenges = random_inputs(n=nval, N=nchal, seed=seedchallenges)

print("PUF challenges")
print(challenges)

print("\nPUF output")
print(puf.eval(challenges))

We can also add noise into one of the parameters to ArbiterPUF or XORArbiterPUF, and which can simulate a noisy environment, such as noisiness=0.1. In a noisy environment, the output of the PUF will change depending on the amount of noise in the circuit. The simulator, though, will make sure the outputs are dependable on the same parameters applied.

Overall, the library also supports Feed-Forward (XOR) Arbiter [6], LightweightSecurePUF [5], PermutationPUF [4], and InterposePUF [3].

Linking a device to an NFT

One of the greatest challenges within IoT is to properly identify devices. With can identify malicious or fake devices. Along with this, we can use the identity of the device to provide a timeline of its usage — from its creation until it is destroyed.

And so, one way to do this is to match the IoT device to an NFT (Non-fungible Token), and where we can create a cryptographically signed artefact that relates to each device. A recent paper defines a mechanism for achieving this in a secure and trustworthy way [7]:

In a tokenized world, we can transfer ownership of the crypto asset through the digital signing process, where the previous owner of a car uses their private key to assess the car to me. I prove to everyone that I now own it using my public key. That all works well for physical assets, but what about software and digital artefacts? Well for this we have the concept of the NFT, and where we can protect the ownership and also the creator of a digital asset. This might relate to photographs, music, or movies. The creator of the asset can thus provide digital evidence that the asset was registered at a certain time, and then can transfer this to others to own. In fact, we can get a complete timeline of its ownership.

Within the paper [7], each device has its own BCA (Blockchain Account) and where an IoT device can sign for its own transactions. The researchers use an ERC-721 NFT, and which can identify the manufacturer, users, and managers (owners and approvers). The each device within the blockchain can then verify both the identity of the device and can validate the data it generates.

To create the NFT, an initial seed is generated and which is not stored on the device. Instead the researchers use a PUF (Physical Unclonable Function) in the device along with other parameters from memory in order to generate the private and public keys associated with the BCA. This differs from many other methods which store the private key on the device (and where the private key could be leaked).

The device then actively becomes part of the blockchain, and generates a public key and a BCA_SD. These can then be used with a smart contract to create the NFT (along with the owner), which will return back a Token ID, and which is stored in the firmware of the device.

Figure 6: Device registration

On a transfer of ownership of a device, the smart contract receives a request with the identity of the owner (BCA_owner), the identity of the new owner (BCA_user) and the BCA_SD (the value that binds the device to the NFT). The device then goes into a blocked state and activates a firmware reset with a new nonce and the public key of the new owner. The device then regenerates the new SD Public Key and Token ID and requests a token transfer, and then the transfer completes for the new owner:

Figure 7: Change of ownership

Once created the device goes back into an operative state. Within ERC-721, we only have an ownership name defined (BCA_owner), and where BCA_SD and BCA _user are additional entities that would be stored within the smart contract.

The authors have implemented their method using an embedded system (wipy) and used a Solidity-based smart contract on the Kovan Ethereum test network. It was then proven through Etherscan:

Figure 8

Conclusions

PUFs are cool, and provide a way to fingerprint devices.

References

[1] Suh, G. E. & Devadas, S. Physical Unclonable Functions for Device Authentication and Secret Key Generation. in Proceedings of the 44th Annual Design Automation Conference 9–14 (ACM, 2007). doi:10.1145/1278480.1278484.

[2] Suh, G. E., & Devadas, S. (2007, June). Physical unclonable functions for device authentication and secret key generation. In Proceedings of the 44th annual design automation conference (pp. 9–14).

[3] Nguyen, P. H. et al. The Interpose PUF: Secure PUF Design against State-of-the-art Machine Learning Attacks. IACR Transactions on Cryptographic Hardware and Embedded Systems 243–290 (2019) doi:10.13154/tches.v2019.i4.243–290.

[4] Wisiol, N. et al. Breaking the Lightweight Secure PUF: Understanding the Relation of Input Transformations and Machine Learning Resistance. in Smart Card Research and Advanced Applications (eds. Belaïd, S. & Güneysu, T.) 40–54 (Springer International Publishing, 2020). doi:10.1007/978–3–030–42068–0_3

[5] Majzoobi, M., Koushanfar, F. & Potkonjak, M. Lightweight Secure PUFs. in Proceedings of the 2008 IEEE/ACM International Conference on Computer-Aided Design 670–673 (IEEE Press, 2008).

[6] Gassend, B., Lim, D., Clarke, D., Dijk, M. van & Devadas, S. Identification and authentication of integrated circuits. Concurrency and Computation: Practice and Experience 16, 1077–1098 (2004).

[7] Arcenegui, J., Arjona, R., & Baturone, I. (2020, October). Secure management of IoT devices based on blockchain non-fungible tokens and physical unclonable functions. In International Conference on Applied Cryptography and Network Security (pp. 24–40). Springer, Cham [link].

[8] Alamro, M. A., Mursi, K. T., Zhuang, Y., Aseeri, A. O., & Alkatheiri, M. S. (2020). Robustness and unpredictability for double arbiter pufs on silicon data: Performance evaluation and modeling accuracy. Electronics, 9(5), 870.

[9] Chatterjee, D., Mukhopadhyay, D., & Hazra, A. (2020). Formal Representation Language for PUF Constructions and Compositions. Online code repository, SEAL.

Appendix

Figure 9: Feed-forward Arbiter PUF [9]
Figure 10: InterposePUF [9]
Figure 11: LIghtweight secure PUF [9]