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 ACES Lab, Rice University *Computation Structures Group, MIT

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 2 Challenge VerifierProver

Physical unclonable functions (PUFs) PUFs based on the inherent, hard to forge, physical disorders Two major types*: – Weak PUF – Strong PUF 3 *Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11

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 4 Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11

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** 5 *Ruhrmair, et al., Book chapter in ‘Intro to Hardware Security and Trust’, Springer’11 **Gassend, et al., CCS’02

Delay-based Strong PUF 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 … c-bit Challenge Rising Edge 1 if top path is faster, else 0 DQ G Response *Suh and Devadas, DAC *Gassend, et al., SAC’03 **Lee, et al., VLSI Symp’04

An arbiter PUF can be modeled easily* Fast modeling  compromised security ** Model building 7 * Majzoobi, Koushanfar, Potkonjak, TRETS’08 **Ruhrmair, et al., CCS’10

Lightweight safeguarding of PUFs Protect against machine learning attacks by Blocking controllability and observability* 1.Transform challenges Input network 2.Block controllability 3.Block observability Output network * Majzoobi, et al., ICCAD ‘08 8

XORed delay-based PUF Block observability by lossy compression Swapping the challenge order to improve statistical properties* 9 *Majzoobi, et al., ICCAD ‘08

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 11 *Ruhrmair, et al., CCS’10

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 12 *Gassend, et al., CCS’02

Desired properties of protocol Robust against model building attacks Robust against PUF errors Ultra low-power – No Hashing – No error correction codes 13

14 Slender PUF Protocol

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 15 Challenge VerifierProver

Xored delay-based PUF model PUF secrets – Set of delays The secret sharing is performed initially Electronic fuse burned to disable access* 16 Probing here for model building *Majzoobi, Koushanfar, Potkonjak, TRETS’08

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 18 Verifier Prover

Slender PUF Protocol 19 Verifier Prover

Slender PUF Protocol 20 Verifier Prover

Slender PUF Protocol 21 Verifier Prover The same seed for both sides Random if only one of them is honest

Slender PUF Protocol 22 Verifier Prover PRNG Generate challenge stream from seed The same challenge for both sides

Slender PUF Protocol 23

Slender PUF Protocol 24

Slender PUF Protocol 25 PUF modeling error

26 The index is not transmitted

27 It reveals minimum informationn about original response sequence

Model building attacks Set L sub = 500, L = % 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 L sub = 500, L = 1024 – /500=1000 rounds of protocol needed – In each one, ind is unknown – /500 = models needed to be built Strict avalanche criteria to avoid correlation attacks

Guessing attack Dishonest Prover Honest Prover – P err : 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%: 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 meta- stability 34 M. Majzoobi, et al., CHES, 2011 PRNG: Need not to be cryptographically secure LFSR is enough

Slender PUF Protocol Previously known protocol*, just SHA-2 Slender PUF Overhead comparison 35 *Gassend, et al., CCS’02

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