# In what sense are silicon PUFs unclonable?

I see quite a few publications on Physically Unclonable Functions implemented using regular silicon IC techniques; for example A 0.19pJ/b PVT-variation-tolerant hybrid physically unclonable function circuit for 100% stable secure key generation in 22nm CMOS (10 authors at Intel), at 2014 IEEE International Solid-State Circuits Conference, with free preview there. The device is summarized as

..creating a golden key at first array power-up during tester-time operation and thereafter recreating this golden value from the inherently noisy raw PUF value during regular field operation. The golden key is used to compute an Error Correction Code signature, which is stored on-die as fuses. During regular operation, error correction circuits mix raw PUF bits with ECC fuse values to regenerate the golden key with 100% accuracy.

A reference for that principle is given as: FPGA Intrinsic PUFs and Their Use for IP Protection (4 authors at Philips), in proceedings of CHES 2007.

I wonder in what sense these things are unclonable.

In particular, I fail to understand why it would not be possible to replace the noisy PUF array and its sensors by ROM with content the (probed) raw PUF value, replace the ECC data/signature by ROM too, letting the error-correction circuitry do its thing; or replace the whole thing by a small ROM or wires defining the golden key.

• I was at that conference. If you find me in the ether, I can send you a scan of what I was given. Jan 5 '17 at 14:36

The answer lies in "complexity", but I do not believe they are unclonable in the explicit sense, but I can think of ways to get data out depending on how they are made. It is easy for me to see "ROM" type gates under a SEM, and what PUFs buy you is that the structure is uniform but then you do not know the electrical characteristics.

In a PUF array, you give it some electrical input and you get a seemingly random, but repeatable output due to [PVT] (Process Voltage Temperature) of the devices 1. You could actually consider this just a huge lookup table of complexity of bit-width and clock depth. A 32-bit number gives you a 32-bit number out at some clock of X. The input is generally easily to get to, but the output is buried in the layout. The output could completely be probed, but you would get an answer for a single input. (on the reverse engineering side, I could make things current mode so I could not probe them because probing them would cause errors). Now assume that you have a PUF array that takes a single clock and has a 32-bit output due to a single 32-bit input, that means you'd need a single 32-bit value in your ROM to emulate the PUF. Otherwise, you need an entry for each clock and input vector. If you have 32-bits of possible input, for one clock, you'll need $2^{32}$ entries in your rom, and it gets huge from there.

So, (1) If you a voltage mode circuit on the output, (2) have a single entry to map, and (3) have a semiconductor lab, there's no reason you could not get a single output and replace it with the ROM.

At least in the Intel ISSCC 2014 paper, including with access to the 7 figures, I do not see that the PUF block has any kind of variable input. The aim of the PUF and accompanying circuitry seems to be: generate a small random value that

• is mostly rooted in imbalances of the silicon manufacturing process, rather than injected by a test procedure;
• remains constant in the life of the IC.

Nothing is told about how the generated value is protected against disclosure by probing or other side channels, or how a modification of the circuitry would make it impossible to make a different circuit where that value can be chosen.

I conclude that the silicon PUF described in this paper is unclonable by adversaries that

1. are unable to find the generated value (by probing or either side channel)
2. OR are bound to blindly reproduce the circuitry less its manufacturing-induced imbalances (rather than modify or simulate it)

The fact that there is a double line of defense is a good feature. Point 1 suggests that the generated value is best used as the secret key of a cryptographic primitive, like a block cipher or MAC, close to where it is generated.

• You are correct that they did not use an input vector. I didn't dive into the actual paper. The work that I was part of (some the semiconductor side) worked how I described. I probably should have pulled the paper before answering. also, #2 is a the hard one. I see +-100mV thresholds on a 800mV process, so that makes a real mess form the standpoint of the current equations. Jan 9 '17 at 14:35