1
00:00:00,000 --> 00:00:16,050
33C3 preroll music
2
00:00:16,050 --> 00:00:22,529
Herald: Ok, please welcome Pol van Aubel,
PhD student at Radboud University in
3
00:00:22,529 --> 00:00:29,540
Nijmegen, and he's going to give a talk
of physically uncloneable functions.
4
00:00:29,540 --> 00:00:31,729
A warm round of applause, please.
5
00:00:31,729 --> 00:00:38,809
applause
Thank you.
6
00:00:38,809 --> 00:00:42,250
Pol: Thank you, thank you for having me,
thank you for having me on prime time,
7
00:00:42,250 --> 00:00:45,329
when everybody is finally awake,
but not yet drunk.
8
00:00:45,329 --> 00:00:46,329
mild laughter
9
00:00:46,329 --> 00:00:52,680
And, thank you for letting me compete with
the space track. So, well, my Herald just
10
00:00:52,680 --> 00:01:00,350
explained who I am, but the work in this
talk is actually mostly not from me. It's
11
00:01:00,350 --> 00:01:06,300
by many many authors, and there will be
citations on almost every slide. Don't pay
12
00:01:06,300 --> 00:01:10,680
attention to those. It was simply too hard
for me to make two different sets of
13
00:01:10,680 --> 00:01:17,040
slides. Download the slides afterwards, if
something interests you. The entire intent
14
00:01:17,040 --> 00:01:20,720
of this talk is to get you interested in
this material, get you reading the papers,
15
00:01:20,720 --> 00:01:25,220
and get you implementing this stuff
yourself. So, without further ado, and
16
00:01:25,220 --> 00:01:30,790
without any further egocentric blathering,
let's look at the problem we're trying to
17
00:01:30,790 --> 00:01:40,330
solve. In computer security, since the
1980's, we've noticed that we might want
18
00:01:40,330 --> 00:01:46,040
unique identification and authentication
of devices. And then, specifically, integrated
19
00:01:46,040 --> 00:01:52,420
circuits. So, we want to distinguish
chips, uniquely, from the same
20
00:01:52,420 --> 00:02:00,230
manufacturing masks, even, and with high
accuracy, unforgeably. Eh, simple task,
21
00:02:00,230 --> 00:02:07,290
right? So, in order to explain how we get
to physically uncloneable functions, I'm
22
00:02:07,290 --> 00:02:11,260
first going to explain some history in
anti-counterfeiting. And
23
00:02:11,260 --> 00:02:15,630
anti-counterfeiting, you can think of
money, you can think of magstripe cards,
24
00:02:15,630 --> 00:02:22,420
you can think of identity documents, and
nuke counters, or as they are commonly
25
00:02:22,420 --> 00:02:28,960
called in literature, "Treaty Limited
Item" identifiers. So let's start with
26
00:02:28,960 --> 00:02:35,910
money. Historically, money has been
protected with highly intricate imagery.
27
00:02:35,910 --> 00:02:41,981
This is an example from right after the US
Revolution, and I personally really like
28
00:02:41,981 --> 00:02:47,011
the, let's see, the "To Counterfeit is
Death". Because, you know, while it was a
29
00:02:47,011 --> 00:02:52,600
crime against the state, you were drawn
and quartered when you did it. Then we
30
00:02:52,600 --> 00:02:56,340
fast forward a few centuries, and I would
like to know from the audience, who has
31
00:02:56,340 --> 00:03:02,260
ever seen this? ... Quite a lot. Can
anybody tell me what it is?
32
00:03:02,260 --> 00:03:04,870
audience comment (inaudible)
33
00:03:04,870 --> 00:03:12,610
The EURion constellation. It's
intended to prevent photocopiers from
34
00:03:12,610 --> 00:03:17,220
copying your money. So basically, when the
photocopier detects this thing, it'll just
35
00:03:17,220 --> 00:03:22,290
not... it'll just say, "I don't want to
copy." You can actually use this on your
36
00:03:22,290 --> 00:03:29,480
own stuff if you want. But, we see a
common theme in those entire few
37
00:03:29,480 --> 00:03:35,060
centuries, namely, you mark all valid
bills the same, and then you make sure
38
00:03:35,060 --> 00:03:41,770
that you can check the marks in order to
identify that it is legitimate. An
39
00:03:41,770 --> 00:03:47,980
alternative to this would be to have
different marks for each bill, and sign
40
00:03:47,980 --> 00:03:54,620
that marking. But, you get into a whole
bunch of questions, like, how do I then
41
00:03:54,620 --> 00:04:01,250
prevent somebody from copying that
bill-specific valid mark a hundred
42
00:04:01,250 --> 00:04:04,750
thousand times, and just, you know,
copying the signature as well. It's not as
43
00:04:04,750 --> 00:04:17,190
though anybody is checking paper money
online. So, back in 1983, Bader proposed
44
00:04:17,190 --> 00:04:23,540
an anti-counterfeiting measure, which
basically meant you sprinkle random-length
45
00:04:23,540 --> 00:04:30,570
cuts of optical fibers into your paper,
before it becomes paper, the... mull. (?)
46
00:04:30,570 --> 00:04:38,650
And then, you make the money, and you use
basically a light bar scanner, so whatever
47
00:04:38,650 --> 00:04:43,010
a photocopier does as well. And then there
will be a dot pattern that appears around
48
00:04:43,010 --> 00:04:47,810
the light bar. And you extract that dot
pattern, you make that into a series of
49
00:04:47,810 --> 00:04:54,190
bits, and you sign that dot pattern. And then
you print the signature onto the bill. Now
50
00:04:54,190 --> 00:04:57,241
there's several problems with this, which
are all explained in those papers, I don't
51
00:04:57,241 --> 00:05:04,980
have time to go into that, but in
principle, this works. Then, next, cards.
52
00:05:04,980 --> 00:05:09,130
You know magnetic stripes and PIN, the way
we used to use them in Europe, I think you
53
00:05:09,130 --> 00:05:16,110
still use them in the US, I'm not sure...
But because nobody knows how to copy
54
00:05:16,110 --> 00:05:24,770
magstripes, right? So, you add stuff to
the card, so that it becomes detectable
55
00:05:24,770 --> 00:05:30,299
when somebody has copied the card onto a
forgery. So, you use holograms. So far as
56
00:05:30,299 --> 00:05:35,800
I know, holograms are also copyable, now,
I don't have a literature reference there,
57
00:05:35,800 --> 00:05:47,320
but... stuff can be done. Now somebody in
1980 already proposed this: You randomly
58
00:05:47,320 --> 00:05:57,400
disperse magnetic fibers in a coating, you
scan those fibers with a, well,
59
00:05:57,400 --> 00:06:03,500
electromagnetic sensing device, and turn
them into pulses and AND the pulses with clock
60
00:06:03,500 --> 00:06:08,530
etc., turn them into bits again, sign
that pattern etc. Then there's also
61
00:06:08,530 --> 00:06:12,341
this nice proposal where you randomly
disperse conductive particles in an
62
00:06:12,341 --> 00:06:17,780
insulating material, scan it with microwave,
it's basically the same principle from
63
00:06:17,780 --> 00:06:25,710
also the 1980s. Next, identity documents,
somebody proposed using the translucency
64
00:06:25,710 --> 00:06:34,340
of a paper strip in an identity document,
scan that strip, turn the translucency
65
00:06:34,340 --> 00:06:40,570
pattern into a bitmask, sign the bitmask,
etc. Now, Simmons already said that
66
00:06:40,570 --> 00:06:44,270
this was too easily cloneable, because,
you know, you can just take a photograph
67
00:06:44,270 --> 00:06:51,229
of this and reproduce it through
photographic techniques. So translucency
68
00:06:51,229 --> 00:06:57,120
isn't really nice. Now you could also
potentially use the exact
69
00:06:57,120 --> 00:07:03,980
three-dimensional cotton fiber pattern of
the paper. But that proposal was also in
70
00:07:03,980 --> 00:07:14,470
1991, and Simmons also said, this is
infeasible to do. However, in 1999,
71
00:07:14,470 --> 00:07:18,600
somebody came up with something similar,
they take the texture hash of a postal
72
00:07:18,600 --> 00:07:23,949
envelope, so you just print a square on
the envelope, take a high resolution
73
00:07:23,949 --> 00:07:30,910
picture of that, and then hash that with a
certain hashing code that ensures that all
74
00:07:30,910 --> 00:07:40,620
these things collapse into the same bit
pattern every time. This works. Then
75
00:07:40,620 --> 00:07:46,990
finally, those Treaty Limited Items, the
reflective particle tags, you basically
76
00:07:46,990 --> 00:07:52,560
affix such a tag to the surface of a
treaty-limited item, then you cure them
77
00:07:52,560 --> 00:07:57,610
with ultraviolet light, so that you turn
it into a glass-like substance, which
78
00:07:57,610 --> 00:08:03,500
makes a tamper evident, if I try to take
it off, the glass breaks, and it also
79
00:08:03,500 --> 00:08:08,350
preserves the particle orientation, and
then you put a laser onto it, you look at the
80
00:08:08,350 --> 00:08:13,760
reflective pattern, and you have your
identifier. So, if you ever have a bunch
81
00:08:13,760 --> 00:08:19,750
of nukes to count, that might be
interesting. The common theme here is that
82
00:08:19,750 --> 00:08:27,220
we are using an intrinsic aspect of an
item that's infeasible to copy, but easily
83
00:08:27,220 --> 00:08:35,938
readable. It's unpredictable, and it
should ideally be unchanging. Which brings
84
00:08:35,938 --> 00:08:46,420
us to a proposal in 2001 of physical
one-way-functions. Basically the idea was,
85
00:08:46,420 --> 00:08:55,279
you have an epoxy with miniscule glass
spheres, you cure the epoxy, you make it
86
00:08:55,279 --> 00:08:58,119
into a ten by ten by two and a half
millimeters, don't know the exact
87
00:08:58,119 --> 00:09:06,350
dimensions anymore, ... I say "sphere", I
mean, what's it called, cube... cuboids,
88
00:09:06,350 --> 00:09:10,959
something like that... And then you illuminate
it by a laser, and then you get a speckle
89
00:09:10,959 --> 00:09:14,769
pattern out of that, because the laser
will disperse in a really unpredictable
90
00:09:14,769 --> 00:09:22,660
pattern, and you capture that at 320 by
240 pixels, you turn that into a 2400 bit
91
00:09:22,660 --> 00:09:27,249
key with a so called Gabor transform. I have
no idea how the math behind that works because
92
00:09:27,249 --> 00:09:34,309
that's not my field of expertise. And you
get interesting properties like drilling a
93
00:09:34,309 --> 00:09:39,420
hole here causes half the bits to flip, so
it’s tamper resistant, and it mirrors the
94
00:09:39,420 --> 00:09:45,480
way one-way functions work, like SHA-1 and
SHA-256: ideally, if you flip one bit in
95
00:09:45,480 --> 00:09:51,310
your input, half your output bits are
flipped. So this paper is really the first
96
00:09:51,310 --> 00:10:00,740
paper that proposed this as a connection
with cryptography. So here, reading the
97
00:10:00,740 --> 00:10:06,239
structure is feasible, because, you know,
you have this glass pattern, you can just
98
00:10:06,239 --> 00:10:10,269
– I say just, but you can use
microscopic techniques to read it out
99
00:10:10,269 --> 00:10:18,129
exactly, but good luck with having this
sub-micron accuracy for all those glass
100
00:10:18,129 --> 00:10:31,059
spheres in the epoxy. So, you can, in
theory, if you know the structure, emulate
101
00:10:31,059 --> 00:10:37,779
or simulate how a laser passes through
this. But it requires a lot of
102
00:10:37,779 --> 00:10:44,740
computational power, and in order to...
you also can't build a database of responses
103
00:10:44,740 --> 00:10:52,799
to challenges, because imagine that the
challenge to the structure is a laser at
104
00:10:52,799 --> 00:10:57,529
different orientations, like, I can say a
laser under an angle of 5 degrees, or 10
105
00:10:57,529 --> 00:11:02,760
degrees or 20 degrees, and at different
locations, and all those responses will be
106
00:11:02,760 --> 00:11:10,250
different. So this challenge-response space
is infeasibly huge. So the protocol here
107
00:11:10,250 --> 00:11:17,279
would be, first, you read this thing on a
trusted terminal, and you create a random
108
00:11:17,279 --> 00:11:21,969
collection of challenge-response pairs.
Your challenges have to be kept secret
109
00:11:21,969 --> 00:11:27,369
because, next, you get an authentication
request from an untrusted terminal, and
110
00:11:27,369 --> 00:11:34,699
you challenge that terminal. And the idea
would be that it is infeasible to send the
111
00:11:34,699 --> 00:11:42,769
correct response key if you don't have the
device containing this PUF, er, this
112
00:11:42,769 --> 00:11:46,920
physical one-way function. So you then
receive the response key, and you reject
113
00:11:46,920 --> 00:11:55,950
this if the key differs by too many bits.
Because it won't be a perfect match. There
114
00:11:55,950 --> 00:12:01,259
might be scratches, there might be slight
micron differences in the orientations, it
115
00:12:01,259 --> 00:12:08,619
might be a bad camera, you get some
differences, and the way you then do this
116
00:12:08,619 --> 00:12:18,999
is you calculate the least probable
acceptance rate of a counterfeit device
117
00:12:18,999 --> 00:12:23,769
that you want, and then you get to this
amount of bits. And then you can get a
118
00:12:23,769 --> 00:12:28,620
better match rate if you repeat steps
(4) - (6) a few times, and if you run
119
00:12:28,620 --> 00:12:36,509
out of challenge pairs you can just go
back to (1). That's the general idea. So
120
00:12:36,509 --> 00:12:39,490
this is the first paper that made this
connection with cryptography, it has a
121
00:12:39,490 --> 00:12:44,939
defined protocol, but there are several
not-so-nice things, like, you have special
122
00:12:44,939 --> 00:12:50,649
equipment required, and we would really
like to have the same possibility in
123
00:12:50,649 --> 00:12:55,929
silicon and silicon only. Now in this
paper already, the proposal was that you
124
00:12:55,929 --> 00:13:03,309
might be able to have a similar approach,
if you scatter electrons... uhhh... I
125
00:13:03,309 --> 00:13:07,279
don't understand what this says, but I
know that it is not what we're going to
126
00:13:07,279 --> 00:13:14,529
see next. As an aside, if you do this kind
of thing, then you get to read very old
127
00:13:14,529 --> 00:13:21,910
papers. So, wasn't it nice, back when you
could say this: "In the fuel rod placement
128
00:13:21,910 --> 00:13:26,509
monitor … high radiation levels in the "hot"
cell provided the general tamper resistance."
129
00:13:26,509 --> 00:13:30,100
Or: "The seismic sensors … would detect any
attempt to gain physical access to the
130
00:13:30,100 --> 00:13:33,459
package long before the information
security is in jeopardy." Now I wouldn't
131
00:13:33,459 --> 00:13:39,550
actually take that one as a bet because
I know you guys, but, uhhm, the first one
132
00:13:39,550 --> 00:13:45,489
is pretty good. And you get to see things
like this. This is how RSA was done in
133
00:13:45,489 --> 00:13:53,729
1984. This is a – I think – that's an
ISA, maybe pre-ISA bus, I dont know... So
134
00:13:53,729 --> 00:13:59,959
this is how that was done. And the text is
really beautiful: they scanned an old,
135
00:13:59,959 --> 00:14:05,569
basically typed on a typing machine paper.
This is available online, by the
136
00:14:05,569 --> 00:14:11,769
way, if you have university access...
sorry... Then, there are other solutions
137
00:14:11,769 --> 00:14:13,930
to this problem, of course. You have
hardware security modules, you have
138
00:14:13,930 --> 00:14:18,920
smartcards, you have trusted platform
modules... actually, I found out we only
139
00:14:18,920 --> 00:14:23,500
have those since 2006, I felt [like] they
were older?... But you still have the
140
00:14:23,500 --> 00:14:26,819
problem of key management, right? Because
the key isn't tied to the platform. If I
141
00:14:26,819 --> 00:14:31,759
can extract the key, and put it into
another trusted platform module, or
142
00:14:31,759 --> 00:14:37,879
another hardware security module, then
we're still dead in the water. So the aspects of
143
00:14:37,879 --> 00:14:42,699
these things is the key never leaves the
device – ideally – but then how does
144
00:14:42,699 --> 00:14:46,769
the key enter the device? You can enter
new keys, you can enter key-encrypting
145
00:14:46,769 --> 00:14:52,129
keys to decrypt keys that you never see,
that another hardware security module exports,
146
00:14:52,129 --> 00:14:58,850
it's all interesting crypto, but you also
get the problem of what can the key do,
147
00:14:58,850 --> 00:15:04,720
are you limited to 1024 bits RSA, and is
it possible to emulate all this once you
148
00:15:04,720 --> 00:15:13,480
have the key, right? We really want to
have other aspects to our function. Now,
149
00:15:13,480 --> 00:15:21,371
this is the first name for PUFs, "silicon
physical random functions", but they
150
00:15:21,371 --> 00:15:28,449
already knew that "PRF" might have some
three letter acronym that clashes with
151
00:15:28,449 --> 00:15:31,280
"pseudo-random function", so they decided
to go for "physical uncloneable
152
00:15:31,280 --> 00:15:34,519
functions". There's an interesting
discussion going on whether it should be
153
00:15:34,519 --> 00:15:41,149
"physical" or "physically"... not going
into that. The idea is, tamper resistance
154
00:15:41,149 --> 00:15:46,689
in general is expensive, is difficult,
it's just... let's look at a different
155
00:15:46,689 --> 00:15:51,679
approach. There is enough process
variation across identical integrated
156
00:15:51,679 --> 00:15:55,509
circuits, where... yeah, so, they're not
identical because of those process
157
00:15:55,509 --> 00:16:02,730
variations. And already in 2000 somebody
made a... Lofstrom, Daasch and Taylor had
158
00:16:02,730 --> 00:16:14,230
a small paper on specific special device
identification circuits. But, if you want
159
00:16:14,230 --> 00:16:17,400
to use those for secure device
identification and authentication, then
160
00:16:17,400 --> 00:16:23,809
just a single such circuit is not enough.
You need more. So, what do you do? You
161
00:16:23,809 --> 00:16:28,889
build this. And I don't think it's
really feasible, ... basically, this is
162
00:16:28,889 --> 00:16:33,120
the entire circuit, you have a delay
circuit here, ...this is a ring oscillator
163
00:16:33,120 --> 00:16:40,529
PUF. So you have a delay circuit here,
this is a self-oscillating loop,
164
00:16:40,529 --> 00:16:46,109
basically, this feeds back into this. And
the challenge here is a bit for each of
165
00:16:46,109 --> 00:16:54,110
these blocks. And what the bit says: if
it's one then you pass through, if it's
166
00:16:54,110 --> 00:16:58,310
zero you pass over. So if you have a
different challenge, you have a different
167
00:16:58,310 --> 00:17:03,509
path through this PUF. So ideally, for
each challenge, it should be unpredictable
168
00:17:03,509 --> 00:17:12,030
whether this final arbiter block here...
uhh, somewhere over there... gives a one
169
00:17:12,030 --> 00:17:19,509
or a zero, and then you count the pulses,
and you identify your circuits. Now
170
00:17:19,509 --> 00:17:24,930
attacks on this were also quite well
studied in this paper... possible attacks.
171
00:17:24,930 --> 00:17:28,720
So, you have the duplication attack, which
is basically cloning, which should be
172
00:17:28,720 --> 00:17:32,990
impossible. Right, that's the general
idea: Cloning should be impossible. There
173
00:17:32,990 --> 00:17:40,640
is emulation from measuring, so, you build
a model from this by measuring the exact
174
00:17:40,640 --> 00:17:46,890
distances between logical units inside the
PUF, or the length of the wires inside the
175
00:17:46,890 --> 00:17:52,240
PUF, also deemed infeasible because how
are you going to measure this without
176
00:17:52,240 --> 00:17:58,640
destroying the PUF. This is back in 2001. Then
there was emulation from modeling, so basically, if
177
00:17:58,640 --> 00:18:02,480
you get these challenge-response pairs, if
you get enough of them, you can apply some
178
00:18:02,480 --> 00:18:07,950
nice maching-learning algorithms to that,
and then you get prediction of responses.
179
00:18:07,950 --> 00:18:10,910
And, finally, you have the control
algorithm attack, which is
180
00:18:10,910 --> 00:18:16,180
attacking the PUF's control algorithm
without ever getting into the PUF. If you
181
00:18:16,180 --> 00:18:24,040
can do that, then your PUF is useless. So,
they also proposed controlled physically
182
00:18:24,040 --> 00:18:30,090
uncloneable functions, which is the same
but with bells on. So you have an access
183
00:18:30,090 --> 00:18:37,960
function for the PUF, which is part of the
PUF. This is to prevent against that final
184
00:18:37,960 --> 00:18:44,770
attack. So basically you overlay the logic
of the access function with the PUF, so
185
00:18:44,770 --> 00:18:49,650
that to access the logic of the access
function, you have to break the PUF. And
186
00:18:49,650 --> 00:18:56,290
if you break the PUF, everything breaks,
no longer works. So this gives additional
187
00:18:56,290 --> 00:19:01,720
properties. An uncontrolled PUF can only
be used for device authentication. This
188
00:19:01,720 --> 00:19:10,030
can be used to have nice things like proof
of execution on a specific device.
189
00:19:10,030 --> 00:19:14,480
Potentially [for] things that I don't have an
opinion on: on code that only runs on specific
190
00:19:14,480 --> 00:19:20,380
devices, but basically whatever you need a
secure cryptographic key for, you should
191
00:19:20,380 --> 00:19:23,750
really be using a controlled PUF. Is
the idea. But you can still do device
192
00:19:23,750 --> 00:19:28,991
identification. So, how does a controlled
PUF look? You have a random hash here, you
193
00:19:28,991 --> 00:19:34,701
have a potential ID here, you have the PUF
here, Challenge, ID, Personality into the
194
00:19:34,701 --> 00:19:38,770
random hash, you run that through the PUF,
do some error correction, because PUFs are
195
00:19:38,770 --> 00:19:42,640
not ideal, and then the random hash again,
and then the response. This is to prevent
196
00:19:42,640 --> 00:19:50,090
all these attacks. If you're interested in
this, read the paper. Then, in 2011, a
197
00:19:50,090 --> 00:19:54,570
formal model was proposed, what do we
really need from PUFs? First, we need
198
00:19:54,570 --> 00:20:00,500
robustness. Across evaluations, we need
the same response. We need physical
199
00:20:00,500 --> 00:20:04,340
uncloneability, it really shouldn't be
possible to clone these things, and we
200
00:20:04,340 --> 00:20:12,010
need unpredictability. Now, these two are
potentially a lot, so we'll get into that
201
00:20:12,010 --> 00:20:18,320
on the final slide, I think... And since then,
since 2001 there have been a lot of proposals
202
00:20:18,320 --> 00:20:23,560
and attacks on PUFs. So, first, there are
the Arbiter PUFs, which are all delay
203
00:20:23,560 --> 00:20:31,140
based. So, the general idea here is that
if you run a signal through a chip, it is
204
00:20:31,140 --> 00:20:36,500
delayed by a certain amount. But the
amount is unique per chip. But it turns
205
00:20:36,500 --> 00:20:43,250
out that you can pretty easily model this.
And even the Bistable Ring PUF, which is
206
00:20:43,250 --> 00:20:50,870
fairly recent, I think, you can do some
fancy machine learning... I highly
207
00:20:50,870 --> 00:20:54,920
recommend this paper, "Pac learning of
arbiter PUFs". Basically, the idea is, you
208
00:20:54,920 --> 00:21:00,450
have 30000 challenge-response pairs, and
that is enough to give you 100% accuracy
209
00:21:00,450 --> 00:21:07,440
on a 256-bit challenge PUF. That's not
good. This doesn't really work, if you can
210
00:21:07,440 --> 00:21:16,670
model it that way. And you can also use
optical measuring of signals through
211
00:21:16,670 --> 00:21:21,700
devices at six pico-second accuracy. So
these things might not be around for much
212
00:21:21,700 --> 00:21:28,430
longer. Then there are memory-based PUFs.
They are based on bistable memory, which
213
00:21:28,430 --> 00:21:35,540
basically looks like this, and it's also
delay-based, but here it's unique to this
214
00:21:35,540 --> 00:21:40,690
cell. You have a block of these cells,
they are all independent, so you get a
215
00:21:40,690 --> 00:21:48,260
pattern out of this. These cells go to one
or zero, and they are pretty fairly stable
216
00:21:48,260 --> 00:21:54,480
in doing it. I'll show you a picture later of
what happens if you have a nice PUF of
217
00:21:54,480 --> 00:22:00,030
this type and if you don't have a nice PUF
of this type. However, if you have a SRAM
218
00:22:00,030 --> 00:22:06,511
PUF, for instance, you have fairly limited
SRAM. So you can just, in principle, read
219
00:22:06,511 --> 00:22:11,990
all this out and store all the bits in a
database. And then you can, er, clone the
220
00:22:11,990 --> 00:22:20,830
PUF. Because you can use focused ion beams
to trim the SRAM of another chip into the
221
00:22:20,830 --> 00:22:26,360
correct orientation. And, well, emulation,
if you have this database, you can just
222
00:22:26,360 --> 00:22:32,020
respond from your database. So, this is,
in some literature, termed a "weak PUF",
223
00:22:32,020 --> 00:22:37,590
but it's probably still the most useful
one we have right now. This is usually
224
00:22:37,590 --> 00:22:41,890
also what's in your devices if it's
claimed to have a physical uncloneable
225
00:22:41,890 --> 00:22:47,940
function. But they are of the control
variety most of the time. Then finally,
226
00:22:47,940 --> 00:22:53,770
recently somebody proposed, I think that
was, yeah, Schaller, Xiong, and
227
00:22:53,770 --> 00:23:00,460
Anagnosto... can not pronounce it. But the
decay-based PUFs, the idea is, you have
228
00:23:00,460 --> 00:23:07,290
DRAM, take the power off, put the power
back on, look how it decayed. No attacks
229
00:23:07,290 --> 00:23:16,100
on that that I have seen yet. So, the
final few minutes of this talk will be
230
00:23:16,100 --> 00:23:26,810
about your very own memory PUFs. Which is
trivial. Right? ...No. It's not, actually.
231
00:23:26,810 --> 00:23:31,711
And all this time before, you might think,
why would we even bother with this? It
232
00:23:31,711 --> 00:23:37,630
seems to be hopeless for PUFs, there is
not enough randomness in the silicon, but
233
00:23:37,630 --> 00:23:42,180
I disagree. Because for one, some
protection is better than none, which is
234
00:23:42,180 --> 00:23:49,360
what most system-on-chip devices have. And
two, I do not believe in silver bullets.
235
00:23:49,360 --> 00:23:55,970
This should be part of a greater security
mechanism. So if nothing else, if all you
236
00:23:55,970 --> 00:24:03,100
want from this talk is some interesting
paper to read, just one, read this one.
237
00:24:03,100 --> 00:24:06,660
That's on slide 39, it's called
"Lightweight anti-counterfeiting solution
238
00:24:06,660 --> 00:24:12,220
for low and commodity hardware using
inherent PUFs." And, preferably, you also
239
00:24:12,220 --> 00:24:17,300
read this related one, "PUF based software
protection for low end embedded devices."
240
00:24:17,300 --> 00:24:22,400
Don't be fooled by the terms "IP
protection" and "license model". This is a
241
00:24:22,400 --> 00:24:26,480
Secure Boot environment. You want it, in
your Raspberry Pi, for instance. I don't
242
00:24:26,480 --> 00:24:30,930
know whether Raspberry Pis have it, that's
for you to find out. So what you'll need
243
00:24:30,930 --> 00:24:39,380
is a device with a masked ROM to hold the
boot loader, like the first stage of code
244
00:24:39,380 --> 00:24:45,160
needs to be under your control. You need
to have that modifiable startup code, you
245
00:24:45,160 --> 00:24:50,690
need to be able to modify it, obviously.
And you need on-board SRAM, to build the
246
00:24:50,690 --> 00:24:56,860
PUF from. And then you need some
non-volatile memory for encrypted firmware
247
00:24:56,860 --> 00:25:05,840
and helper data. So, in the puffin
project, which that earlier pic was a result
248
00:25:05,840 --> 00:25:16,950
of... So, there are several results here.
This is an STM32F100B microcontroller,
249
00:25:16,950 --> 00:25:21,590
this is PandaBoard, which is pretty much like a
mobile phone actually, so what you want to
250
00:25:21,590 --> 00:25:27,160
see is this. White noise. This part is a
PUF-like memory range, this part is
251
00:25:27,160 --> 00:25:32,110
probably spoiled by the bootloader or
something like that or the wrong code, but
252
00:25:32,110 --> 00:25:39,860
this you can use. This looks good. So,
once you have such a white-noise area, you
253
00:25:39,860 --> 00:25:46,110
start measuring a lot of times, and then
you compute the Hamming distance between
254
00:25:46,110 --> 00:25:49,830
lots of measurements from lots of
different devices. And you want it to look
255
00:25:49,830 --> 00:25:54,940
like this, you want it be around half.
Because that means that every device will
256
00:25:54,940 --> 00:26:02,950
look different. By about 50%. You also measure
the inner class Hamming distance, which is same
257
00:26:02,950 --> 00:26:08,900
measurements from the same PUF, and you
want that to be below 0.1. You don't want
258
00:26:08,900 --> 00:26:13,940
that to be too inaccurate, because then
your error correction becomes too complex
259
00:26:13,940 --> 00:26:18,680
and starts leaking information, and you
will need error correction, using for
260
00:26:18,680 --> 00:26:28,930
example Golay codes. So this first paper I
mentioned, the... this one... the
261
00:26:28,930 --> 00:26:33,130
lightweight anti-counterfeiting one, this
is also from that paper. Read it, it also
262
00:26:33,130 --> 00:26:36,430
explains how this fuzzy extraction works.
If you're interested in this, there's lots
263
00:26:36,430 --> 00:26:42,560
of scientific literature out there. And
then finally, you build this fuzzy
264
00:26:42,560 --> 00:26:49,450
extractor, and then you enrol your chip.
And you generate some helper data for
265
00:26:49,450 --> 00:26:53,870
this error correction, and then once you
challenge the chip you send this
266
00:26:53,870 --> 00:26:58,710
error-correcting data with the challenge.
And in the end the idea would be that you
267
00:26:58,710 --> 00:27:04,690
get a secret S' from every chip. Now how
can you use this? You have the bootloader
268
00:27:04,690 --> 00:27:08,700
in the masked ROM, this is the first-stage
bootloader, it challenges the PUF, and
269
00:27:08,700 --> 00:27:13,800
decrypts the second-stage bootloader,
which comes from external memory. And then
270
00:27:13,800 --> 00:27:18,500
you boot the embedded operating system.
So, this should look familiar to a lot of
271
00:27:18,500 --> 00:27:23,900
you, because this is basically also how
device attestation on x86 works if you're
272
00:27:23,900 --> 00:27:34,960
using trusted platform modules. So, in a
bit more detail, same procedure, query the
273
00:27:34,960 --> 00:27:38,680
PUF, decrypt and call, here the key also
ends up, and you decrypt and call the
274
00:27:38,680 --> 00:27:45,970
kernel, and then finally, this is how it
really looks in real detail. And even if
275
00:27:45,970 --> 00:27:51,970
you don't want to build this, you'll still
have this: So, remember when I showed you
276
00:27:51,970 --> 00:27:58,500
the inner class Hamming distance, the 10% of
differences between meausurements? That's
277
00:27:58,500 --> 00:28:03,250
caused by the red dots. Those are the
unstable SRAM cells. You can use those as
278
00:28:03,250 --> 00:28:07,500
seeds for a random function. And
hopefully, you won't have this. This looks
279
00:28:07,500 --> 00:28:11,640
wrong, this is not a PUF, this is too
predictable. Unfortunately, all this won't
280
00:28:11,640 --> 00:28:16,350
be possible on x86, because we looked for
the PUFs in the CPUs, but Intel and AMD
281
00:28:16,350 --> 00:28:22,970
both explicitly zero everything. Finally,
a word on privacy. I don't have too much
282
00:28:22,970 --> 00:28:28,121
time for this, but I really liked the fact
they mentioned they feel that users... users
283
00:28:28,121 --> 00:28:32,020
feel that they can be tracked if you have
a unique identifier. As though, its not a
284
00:28:32,020 --> 00:28:39,059
valid concern. Damn the users, being paranoid.
Now, back to the controlled PUF. You can
285
00:28:39,059 --> 00:28:43,490
add personality IDs as a user. If they
challenge it, you add a personality, so
286
00:28:43,490 --> 00:28:47,020
one application reading the PUF gets a
different ID from another application,
287
00:28:47,020 --> 00:28:50,940
which changes the entire output of the
hash function, no paranoia required
288
00:28:50,940 --> 00:28:59,910
anymore. Hopefully. Finally, the references.
Google Scholar is your friend. The rest of
289
00:28:59,910 --> 00:29:05,600
the slides are... all kinds of
references... Read it! You've already seen
290
00:29:05,600 --> 00:29:08,940
all of those, read it,
thank you for your attention.
291
00:29:08,940 --> 00:29:17,790
applause
292
00:29:17,790 --> 00:29:22,150
Herald: Thank you, Pol. We have
time for maybe two questions.
293
00:29:22,150 --> 00:29:26,000
Please come up to the mics... Mic 3!
294
00:29:26,000 --> 00:29:32,460
Mic 3: What do you think about MEMS-based
physically uncloneable functions, where
295
00:29:32,460 --> 00:29:36,970
they basically use the accelerometer
sensors, and the deviations in these
296
00:29:36,970 --> 00:29:40,770
sensors by inducing challenges
as controlled vibration?
297
00:29:40,770 --> 00:29:44,140
Pol: Sorry, I missed the
first word of your question.
298
00:29:44,140 --> 00:29:48,360
Mik 3: The MEMS-based… basically the
technology that is being used to build
299
00:29:48,360 --> 00:29:55,230
accelerometers in silicon. So Bosch has
some PUF chips based on that, where they
300
00:29:55,230 --> 00:29:59,290
have arrays of these MEMS-chips, and then
a controlled vibrator to induce the
301
00:29:59,290 --> 00:30:00,290
challenge into that.
302
00:30:00,290 --> 00:30:05,240
Pol: I think they're probably more secure
than silicon-based PUFs, because they are
303
00:30:05,240 --> 00:30:09,810
built for randomness, whereas we're here
trying to extract randomness from an
304
00:30:09,810 --> 00:30:15,010
existing circuit. Yeah, they're
interesting. Use them if you can, but most
305
00:30:15,010 --> 00:30:19,890
people don't have the option.
306
00:30:19,890 --> 00:30:20,930
Mik 3: Thank you.
307
00:30:20,930 --> 00:30:24,620
Herald: More questions?
Pol: Up there!
308
00:30:24,620 --> 00:30:27,760
Herald: Ok, Mic 7!
309
00:30:27,760 --> 00:30:32,370
Mic 7: Hi, thanks for your talk, I'd never
heard of PUFs. I recently went on a
310
00:30:32,370 --> 00:30:36,980
quest to find a usable smartcard that met
all the things I wanted to do, like open
311
00:30:36,980 --> 00:30:45,630
source, et cetera. Can you expand a bit on
how PUFs could be used with an OpenPGP
312
00:30:45,630 --> 00:30:49,550
smartcard or similar?
313
00:30:49,550 --> 00:30:54,350
Pol: Short answer: no. I have no idea
whether OpenPGP will ever support anything
314
00:30:54,350 --> 00:31:01,290
like this. You have the PKCS protocols,
I know that in theory this is possible.
315
00:31:01,290 --> 00:31:04,710
I don't know whether anything has
implemented it. There are PUFs on
316
00:31:04,710 --> 00:31:10,310
smartcards, but whether.. We haven't looked
into this, I don't know of anyone who has.
317
00:31:10,310 --> 00:31:11,030
Mic 7: Thank you.
318
00:31:11,030 --> 00:31:13,750
Pol: But that doesn't mean
it doesn't exist.
319
00:31:13,750 --> 00:31:16,610
Herald: That would be all.
Please give it up for Pol, one more time.
320
00:31:16,610 --> 00:31:20,237
Pol: Thanks!
applause
321
00:31:20,237 --> 00:31:25,413
postroll music
322
00:31:25,413 --> 00:31:44,000
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!