Slender PUF Protocol
Authentication by Substring Matching
M. Majzoobi, M. Rostami,
F. Koushanfar, D. Wallach, and S. Devadas*
International Workshop on Trustworthy Embedded Devices,
San Francisco, May 2012
ACES Lab, Rice University
*Computation Structures Group, MIT
1
Traditional digital
key-based authentication
• Keys stored in non-volatile memory
– Verifier sends random number (challenge)
– Prover signs the number by it’s secret key and sends a
response
• Limitation
– Extra cost of non-volatile memory
– Physical and side channel attacks
– Intensive cryptographic algorithms
Challenge
Verifier
Prover
2
Physical unclonable functions
(PUFs)
• PUFs based on the inherent, hard to forge,
physical disorders
• Two major types*:
– Weak PUF
– Strong PUF
*Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11
3
Security based on PUFs:
Weak PUFs
• Also called Physically Obfuscated Keys (POKs)
• Limited Challenge-Response Pairs
– Based on ring-oscillators
• Generate standard digital key for security apps
• When challenged by one (or very few) fixed
challenge(s) generates Response(s) depending on
its physical disorder
• Response(s) is used to generate secret key
• Intensive cryptographic algorithm is still needed
Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11
4
Strong PUFs*
• Directly used for challenge response
authentication
• Provide large Challenge-Response Pairs (CRPs)
• Often exponential w.r.t. system elements
• Neither an adversary nor manufacturer should
correctly predict the response to a randomly
chosen challenge with a high probability**
*Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11
**Gassend, et al., CCS’02
5
Delay-based Strong PUF
1
0
c-bit
Challenge
Rising
Edge
0
1
*Suh and Devadas, DAC 2007
1
1
0
0
0
0
0
1
1
1
1
0
1
…
0
D Q
G
1 if top
path is
faster,
else 0
Response
• Compare two paths with an identical delay in design*, **
• Each challenge selects a unique pair of delay paths
– Random process variation determines which path is faster
– An arbiter outputs 1-bit digital response
– Multiple bits can be obtained by either duplicate the circuit or
use different challenges
*Gassend, et al. , SAC’03
**Lee, et al., VLSI Symp’04
6
Model building
• An arbiter PUF can be modeled easily*
• Fast modeling  compromised security **
*Majzoobi, Koushanfar, Potkonjak, TRETS’08
**Ruhrmair, et al., CCS’10
7
Lightweight safeguarding of PUFs
• Protect against machine learning attacks by
• Blocking controllability and observability*
PUF
Input
Net. (G)
PUF
PUF
...
...
Input
Net. (G)
Output Network (Z)
Input
Net. (G)
...
1. Transform challenges
• Input network
Input
2. Block controllability
3. Block observability
• Output network
Output
Interconnect Network
* Majzoobi,
et al., ICCAD ‘08
8
XORed delay-based PUF
• Block observability by lossy compression
• Swapping the challenge order to improve
statistical properties*
*Majzoobi, et al., ICCAD ‘08
9
XORed delay-based PUFs
• Improvement in randomness of responses
• Strict Avalanche Criterion
– Any transition in the input causes a transition in
the output with a probability of 0.5
• Balances the impact of challenge on output
10
Model building attack on Xored-PUF
• Use XORed PUFs to guard against modeling
• Harder, but still breakable *
– Logistic regression, evolutionary strategies
– Two order of magnitude more CRPs needed
*Ruhrmair, et al., CCS’10
11
Problem with just Xoring
• Still breakable
• Cannot increase XOR layers indefinitely
• Accumulates error
– 5%  20% for 4 XOR
• A solution* to guard against modeling while
robust against errors
– Using error correction codes (ECC) and hashing
– Computationally intensive!
– Not suitable for low-power embedded devices
*Gassend, et al., CCS’02
12
Desired properties of protocol
• Robust against model building attacks
• Robust against PUF errors
• Ultra low-power
– No Hashing
– No error correction codes
13
Slender PUF
Protocol
14
Communicating parties
• Prover
– Has PUF
– Will be authenticated
• Verifier
– Has a compact soft model of the PUF
• Compute challenge/response pairs
– Will authenticate the prover
Challenge
Verifier
Prover
15
Xored delay-based PUF model
• PUF secrets
– Set of delays
• The secret sharing is performed initially
• Electronic fuse burned to disable access*
Probing here for
model building
*Majzoobi, Koushanfar, Potkonjak, TRETS’08
16
Malicious parties
• Dishonest prover
– Does not have access to the PUF
– Wants to pass the authentication
• Eavesdropper
– Taps the communication between prover and verifier
– Tries to learn the secret
• Dishonest verifier
– Does not have access to the PUF soft model
– Tries to actively trick the prover to leak information
17
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
Verifier
Prover
18
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
(2)
Verifier
Noncep
Prover
19
Slender PUF Protocol
Verifier
(1)
Noncev
(2)
(3)
Prover
Noncep
Seed ={Noncev,Noncep}
Verifier
Seed = {Noncev,Noncep}
Prover
20
Slender PUF Protocol
Verifier
(1)
Noncev
(2)
(3)
Prover
Noncep
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
The same seed for both sides
Random if only one of them is honest
Verifier
Prover
21
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
(4)
C = G(Seed)
PRNG
Seed = {Noncev,Noncep}
C = G(Seed)
PRNG
Generate challenge stream from seed
The same challenge for both sides
Verifier
Prover
22
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
(4)
C = G(Seed)
C = G(Seed)
(5)
R’ = PUF_model(C)
R = PUF(C)
23
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
(4)
C = G(Seed)
C = G(Seed)
(5)
R’ = PUF_model(C)
R = PUF(C)
R:
1
0
0
1
1
1
0
0
1
1
0
1
1
0
0
0
1
1
1
0
0
1
0
0
1
1
R’:
1
0
0
1
1
1
0
0
1
1
0
1
1
1
0
0
0
1
1
0
0
1
0
0
1
1
24
Slender PUF Protocol
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
(4)
C = G(Seed)
C = G(Seed)
(5)
R’ = PUF_model(C)
R = PUF(C)
R:
1
0
0
1
1
1
0
0
1
1
0
1
1
0
0
0
1
1
1
0
0
1
0
0
1
1
R’:
1
0
0
1
1
1
0
0
1
1
0
1
1
1
0
0
0
1
1
0
0
1
0
0
1
1
PUF modeling error
25
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
(4)
C = G(Seed)
C = G(Seed)
(5)
R’ = PUF_model(C)
R = PUF(C)
(6)
W = sub-seq (ind,Lsub,R)
ind = 10
R:
1
0
0
1
1
1
0
0
1
1
0
1
1
0
0
0
1
1
1
0
0
1
0
0
1
1
Lsub = 11
W:
1
0
1
1
0
0
0
1
1
1
0
0
The index is not transmitted
26
Verifier
(1)
Prover
Noncev
(2)
Noncep
(3)
Seed ={Noncev,Noncep}
Seed = {Noncev,Noncep}
(4)
C = G(Seed)
C = G(Seed)
(5)
R’ = PUF_model(C)
R = PUF(C)
(6)
(7)
W = sub-seq (ind,Lsub,R)
T =match(R’,W,e)
W:
Auth. pass: T = true?
R’:
1
0
0
1
1
1
0
0
1
1
0
1
1
0
errors:
0
1
1
0
1
1
0
0
1
1
1
0
0
1
1
0
0
1
0
0
0
1
0
0
1
1
It reveals minimum informationn about original response sequence
27
Model building attacks
• Set Lsub = 500, L = 1024
• 99% threshold for authentication 
– 99% accuracy in modeling
• XORed PUF attack: 500,000 CRPs needed
• 500,000 /500=1000 rounds needed
• He doesn’t have ind  …
28
Brute-force modeling attack
• Set Lsub = 500, L = 1024
– 500000/500=1000 rounds of protocol needed
– In each one, ind is unknown
– 1024500000/500 = 10241000 models needed to be built
210000
• Strict avalanche criteria to avoid correlation attacks
29
Guessing attack
• Dishonest Prover
• Honest Prover
– Perr : PUF error rate
30
Replay attack
• Eavesdropping and replying the responses
• Nonce scheme prevents it
• If prover and verifier nonces are 128-bit:
– Size of database for 50%: 2127
• Very low probability!
31
Implementation
• Same challenge streams should not be used
• We need :
– PRNG (pseudo random number generator)
• Challenge stream generation
– TRNG (true random number generator)
• Nonce
• Index of substring (ind)
• ind is generated first 
– PUF is only challenged when necessary
32
Slender PUF protocol:
System overview
33
TRNG and PRNG
• TRNG:
– PUF based
– Based on flip-flop metastability
• PRNG:
• Need not to be
cryptographically
secure
• LFSR is enough
Binary Sequence
PDL
D Q
Monitor
C
Control
M. Majzoobi, et al., CHES, 2011
34
Slender PUF
Overhead comparison
• Slender PUF Protocol
• Previously known protocol*, just SHA-2
*Gassend, et al., CCS’02
35
Conclusions
– Authentication protocol based on PUFs
– Protect against model building
– Revealing a partial section of the PUF responses
• Based on string matching
– Resilient against PUF error, without:
– Error correction
– Hashing
– Exponentiation
36