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

based authentication
•
Keys stored in non

volatile memory
–
V
erifier
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
Verifier
Prover
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
D
Q
1
1
0
0
1
1
0
0
1
1
0
0
1
0
1
0
0
1
0
1
G
Response
*
Suh
and Devadas, DAC 2007
6
*
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*
PUF
PUF
Input
Net
. (
G
)
PUF
Input
Net
. (
G
)
Input
Net
. (
G
)
...
...
Output Network
(
Z
)
...
Interconnect Network
Input
Output
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
Verifier
Prover
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
Nonce
v
(
1
)
Verifier
Prover
Slender PUF Protocol
19
Verifier
Prover
Verifier
Prover
Nonce
p
(
2
)
Nonce
v
(
1
)
Slender PUF Protocol
20
Verifier
Prover
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
(
3
)
(
2
)
Nonce
v
(
1
)
Slender PUF Protocol
21
Verifier
Prover
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
(
3
)
(
2
)
Nonce
v
(
1
)
The same
seed for both sides
Random if only one of them is honest
Slender PUF Protocol
22
Verifier
Prover
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
(
3
)
(
4
)
(
2
)
Nonce
v
(
1
)
PRNG
PRNG
Generate challenge stream from seed
The same challenge for both sides
Slender PUF Protocol
23
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
R
’
=
PUF
_
model
(
C
)
R
=
PUF
(
C
)
(
3
)
(
4
)
(
2
)
(
5
)
Nonce
v
(
1
)
Slender PUF Protocol
24
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
:
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
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
R
’
=
PUF
_
model
(
C
)
R
=
PUF
(
C
)
(
3
)
(
4
)
(
2
)
(
5
)
Nonce
v
(
1
)
Slender PUF Protocol
25
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
:
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
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
R
’
=
PUF
_
model
(
C
)
R
=
PUF
(
C
)
(
3
)
(
4
)
(
2
)
(
5
)
Nonce
v
(
1
)
PUF modeling error
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
R
’
=
PUF
_
model
(
C
)
R
=
PUF
(
C
)
W
=
sub

seq
(
ind
,
L
sub
,
R
)
(
3
)
(
4
)
(
2
)
(
6
)
(
5
)
Nonce
v
(
1
)
26
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
L
sub
=
11
ind
=
10
R
:
1
0
1
1
0
0
0
1
1
1
0
0
W
:
The index is not transmitted
27
Verifier
Prover
Nonce
p
Seed
=
{
Nonce
v
,
Nonce
p
}
Seed
=
{
Nonce
v
,
Nonce
p
}
C
=
G
(
Seed
)
C
=
G
(
Seed
)
R
’
=
PUF
_
model
(
C
)
R
=
PUF
(
C
)
W
=
sub

seq
(
ind
,
L
sub
,
R
)
(
3
)
(
4
)
(
2
)
(
6
)
(
5
)
Nonce
v
(
1
)
T
=
match
(
R’
,
W
,
e
)
Auth
.
pass
:
T
=
true
?
(
7
)
1
0
1
1
0
0
0
1
1
1
0
0
W
:
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
1
0
errors
:
It reveals minimum information
n
about original response sequence
Model building attacks
•
Set
L
sub
= 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
L
sub
= 500,
L
= 1024
–
500000/500=
1000
rounds of protocol needed
–
In each one,
ind
is unknown
–
1024
500000/500
=
1024
1000
models needed to be built
•
Strict avalanche criteria to avoid correlation attacks
29
2
10000
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%: 2
127
•
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
Control
Monitor
D
C
Q
PDL
Binary Sequence
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
Comments 0
Log in to post a comment