0:00:00.000,0:00:16.050
33C3 preroll music
0:00:16.050,0:00:22.529
Herald: Ok, please welcome Pol van Aubel,[br]PhD student at Radboud University in
0:00:22.529,0:00:29.540
Nijmegen, and he's going to give a talk[br]of physically uncloneable functions.
0:00:29.540,0:00:31.729
A warm round of applause, please.
0:00:31.729,0:00:38.809
applause[br]Thank you.
0:00:38.809,0:00:42.250
Pol: Thank you, thank you for having me,[br]thank you for having me on prime time,
0:00:42.250,0:00:45.329
when everybody is finally awake,[br]but not yet drunk.
0:00:45.329,0:00:46.329
mild laughter
0:00:46.329,0:00:52.680
And, thank you for letting me compete with[br]the space track. So, well, my Herald just
0:00:52.680,0:01:00.350
explained who I am, but the work in this[br]talk is actually mostly not from me. It's
0:01:00.350,0:01:06.300
by many many authors, and there will be[br]citations on almost every slide. Don't pay
0:01:06.300,0:01:10.680
attention to those. It was simply too hard[br]for me to make two different sets of
0:01:10.680,0:01:17.040
slides. Download the slides afterwards, if[br]something interests you. The entire intent
0:01:17.040,0:01:20.720
of this talk is to get you interested in[br]this material, get you reading the papers,
0:01:20.720,0:01:25.220
and get you implementing this stuff[br]yourself. So, without further ado, and
0:01:25.220,0:01:30.790
without any further egocentric blathering,[br]let's look at the problem we're trying to
0:01:30.790,0:01:40.330
solve. In computer security, since the[br]1980's, we've noticed that we might want
0:01:40.330,0:01:46.040
unique identification and authentication[br]of devices. And then, specifically, integrated
0:01:46.040,0:01:52.420
circuits. So, we want to distinguish[br]chips, uniquely, from the same
0:01:52.420,0:02:00.230
manufacturing masks, even, and with high[br]accuracy, unforgeably. Eh, simple task,
0:02:00.230,0:02:07.290
right? So, in order to explain how we get[br]to physically uncloneable functions, I'm
0:02:07.290,0:02:11.260
first going to explain some history in[br]anti-counterfeiting. And
0:02:11.260,0:02:15.630
anti-counterfeiting, you can think of[br]money, you can think of magstripe cards,
0:02:15.630,0:02:22.420
you can think of identity documents, and[br]nuke counters, or as they are commonly
0:02:22.420,0:02:28.960
called in literature, "Treaty Limited[br]Item" identifiers. So let's start with
0:02:28.960,0:02:35.910
money. Historically, money has been[br]protected with highly intricate imagery.
0:02:35.910,0:02:41.981
This is an example from right after the US[br]Revolution, and I personally really like
0:02:41.981,0:02:47.011
the, let's see, the "To Counterfeit is[br]Death". Because, you know, while it was a
0:02:47.011,0:02:52.600
crime against the state, you were drawn[br]and quartered when you did it. Then we
0:02:52.600,0:02:56.340
fast forward a few centuries, and I would[br]like to know from the audience, who has
0:02:56.340,0:03:02.260
ever seen this? ... Quite a lot. Can[br]anybody tell me what it is?
0:03:02.260,0:03:04.870
audience comment (inaudible)
0:03:04.870,0:03:12.610
The EURion constellation. It's[br]intended to prevent photocopiers from
0:03:12.610,0:03:17.220
copying your money. So basically, when the[br]photocopier detects this thing, it'll just
0:03:17.220,0:03:22.290
not... it'll just say, "I don't want to[br]copy." You can actually use this on your
0:03:22.290,0:03:29.480
own stuff if you want. But, we see a[br]common theme in those entire few
0:03:29.480,0:03:35.060
centuries, namely, you mark all valid[br]bills the same, and then you make sure
0:03:35.060,0:03:41.770
that you can check the marks in order to[br]identify that it is legitimate. An
0:03:41.770,0:03:47.980
alternative to this would be to have[br]different marks for each bill, and sign
0:03:47.980,0:03:54.620
that marking. But, you get into a whole[br]bunch of questions, like, how do I then
0:03:54.620,0:04:01.250
prevent somebody from copying that[br]bill-specific valid mark a hundred
0:04:01.250,0:04:04.750
thousand times, and just, you know,[br]copying the signature as well. It's not as
0:04:04.750,0:04:17.190
though anybody is checking paper money[br]online. So, back in 1983, Bader proposed
0:04:17.190,0:04:23.540
an anti-counterfeiting measure, which[br]basically meant you sprinkle random-length
0:04:23.540,0:04:30.570
cuts of optical fibers into your paper,[br]before it becomes paper, the... mull. (?)
0:04:30.570,0:04:38.650
And then, you make the money, and you use[br]basically a light bar scanner, so whatever
0:04:38.650,0:04:43.010
a photocopier does as well. And then there[br]will be a dot pattern that appears around
0:04:43.010,0:04:47.810
the light bar. And you extract that dot[br]pattern, you make that into a series of
0:04:47.810,0:04:54.190
bits, and you sign that dot pattern. And then[br]you print the signature onto the bill. Now
0:04:54.190,0:04:57.241
there's several problems with this, which[br]are all explained in those papers, I don't
0:04:57.241,0:05:04.980
have time to go into that, but in[br]principle, this works. Then, next, cards.
0:05:04.980,0:05:09.130
You know magnetic stripes and PIN, the way[br]we used to use them in Europe, I think you
0:05:09.130,0:05:16.110
still use them in the US, I'm not sure...[br]But because nobody knows how to copy
0:05:16.110,0:05:24.770
magstripes, right? So, you add stuff to[br]the card, so that it becomes detectable
0:05:24.770,0:05:30.299
when somebody has copied the card onto a[br]forgery. So, you use holograms. So far as
0:05:30.299,0:05:35.800
I know, holograms are also copyable, now,[br]I don't have a literature reference there,
0:05:35.800,0:05:47.320
but... stuff can be done. Now somebody in[br]1980 already proposed this: You randomly
0:05:47.320,0:05:57.400
disperse magnetic fibers in a coating, you[br]scan those fibers with a, well,
0:05:57.400,0:06:03.500
electromagnetic sensing device, and turn[br]them into pulses and AND the pulses with clock
0:06:03.500,0:06:08.530
etc., turn them into bits again, sign[br]that pattern etc. Then there's also
0:06:08.530,0:06:12.341
this nice proposal where you randomly[br]disperse conductive particles in an
0:06:12.341,0:06:17.780
insulating material, scan it with microwave,[br]it's basically the same principle from
0:06:17.780,0:06:25.710
also the 1980s. Next, identity documents,[br]somebody proposed using the translucency
0:06:25.710,0:06:34.340
of a paper strip in an identity document,[br]scan that strip, turn the translucency
0:06:34.340,0:06:40.570
pattern into a bitmask, sign the bitmask,[br]etc. Now, Simmons already said that
0:06:40.570,0:06:44.270
this was too easily cloneable, because,[br]you know, you can just take a photograph
0:06:44.270,0:06:51.229
of this and reproduce it through[br]photographic techniques. So translucency
0:06:51.229,0:06:57.120
isn't really nice. Now you could also[br]potentially use the exact
0:06:57.120,0:07:03.980
three-dimensional cotton fiber pattern of[br]the paper. But that proposal was also in
0:07:03.980,0:07:14.470
1991, and Simmons also said, this is[br]infeasible to do. However, in 1999,
0:07:14.470,0:07:18.600
somebody came up with something similar,[br]they take the texture hash of a postal
0:07:18.600,0:07:23.949
envelope, so you just print a square on[br]the envelope, take a high resolution
0:07:23.949,0:07:30.910
picture of that, and then hash that with a[br]certain hashing code that ensures that all
0:07:30.910,0:07:40.620
these things collapse into the same bit[br]pattern every time. This works. Then
0:07:40.620,0:07:46.990
finally, those Treaty Limited Items, the[br]reflective particle tags, you basically
0:07:46.990,0:07:52.560
affix such a tag to the surface of a[br]treaty-limited item, then you cure them
0:07:52.560,0:07:57.610
with ultraviolet light, so that you turn[br]it into a glass-like substance, which
0:07:57.610,0:08:03.500
makes a tamper evident, if I try to take[br]it off, the glass breaks, and it also
0:08:03.500,0:08:08.350
preserves the particle orientation, and[br]then you put a laser onto it, you look at the
0:08:08.350,0:08:13.760
reflective pattern, and you have your[br]identifier. So, if you ever have a bunch
0:08:13.760,0:08:19.750
of nukes to count, that might be[br]interesting. The common theme here is that
0:08:19.750,0:08:27.220
we are using an intrinsic aspect of an[br]item that's infeasible to copy, but easily
0:08:27.220,0:08:35.938
readable. It's unpredictable, and it[br]should ideally be unchanging. Which brings
0:08:35.938,0:08:46.420
us to a proposal in 2001 of physical[br]one-way-functions. Basically the idea was,
0:08:46.420,0:08:55.279
you have an epoxy with miniscule glass[br]spheres, you cure the epoxy, you make it
0:08:55.279,0:08:58.119
into a ten by ten by two and a half[br]millimeters, don't know the exact
0:08:58.119,0:09:06.350
dimensions anymore, ... I say "sphere", I[br]mean, what's it called, cube... cuboids,
0:09:06.350,0:09:10.959
something like that... And then you illuminate[br]it by a laser, and then you get a speckle
0:09:10.959,0:09:14.769
pattern out of that, because the laser[br]will disperse in a really unpredictable
0:09:14.769,0:09:22.660
pattern, and you capture that at 320 by[br]240 pixels, you turn that into a 2400 bit
0:09:22.660,0:09:27.249
key with a so called Gabor transform. I have[br]no idea how the math behind that works because
0:09:27.249,0:09:34.309
that's not my field of expertise. And you[br]get interesting properties like drilling a
0:09:34.309,0:09:39.420
hole here causes half the bits to flip, so[br]it’s tamper resistant, and it mirrors the
0:09:39.420,0:09:45.480
way one-way functions work, like SHA-1 and[br]SHA-256: ideally, if you flip one bit in
0:09:45.480,0:09:51.310
your input, half your output bits are[br]flipped. So this paper is really the first
0:09:51.310,0:10:00.740
paper that proposed this as a connection[br]with cryptography. So here, reading the
0:10:00.740,0:10:06.239
structure is feasible, because, you know,[br]you have this glass pattern, you can just
0:10:06.239,0:10:10.269
– I say just, but you can use[br]microscopic techniques to read it out
0:10:10.269,0:10:18.129
exactly, but good luck with having this[br]sub-micron accuracy for all those glass
0:10:18.129,0:10:31.059
spheres in the epoxy. So, you can, in[br]theory, if you know the structure, emulate
0:10:31.059,0:10:37.779
or simulate how a laser passes through[br]this. But it requires a lot of
0:10:37.779,0:10:44.740
computational power, and in order to...[br]you also can't build a database of responses
0:10:44.740,0:10:52.799
to challenges, because imagine that the[br]challenge to the structure is a laser at
0:10:52.799,0:10:57.529
different orientations, like, I can say a[br]laser under an angle of 5 degrees, or 10
0:10:57.529,0:11:02.760
degrees or 20 degrees, and at different[br]locations, and all those responses will be
0:11:02.760,0:11:10.250
different. So this challenge-response space[br]is infeasibly huge. So the protocol here
0:11:10.250,0:11:17.279
would be, first, you read this thing on a[br]trusted terminal, and you create a random
0:11:17.279,0:11:21.969
collection of challenge-response pairs.[br]Your challenges have to be kept secret
0:11:21.969,0:11:27.369
because, next, you get an authentication[br]request from an untrusted terminal, and
0:11:27.369,0:11:34.699
you challenge that terminal. And the idea[br]would be that it is infeasible to send the
0:11:34.699,0:11:42.769
correct response key if you don't have the[br]device containing this PUF, er, this
0:11:42.769,0:11:46.920
physical one-way function. So you then[br]receive the response key, and you reject
0:11:46.920,0:11:55.950
this if the key differs by too many bits.[br]Because it won't be a perfect match. There
0:11:55.950,0:12:01.259
might be scratches, there might be slight[br]micron differences in the orientations, it
0:12:01.259,0:12:08.619
might be a bad camera, you get some[br]differences, and the way you then do this
0:12:08.619,0:12:18.999
is you calculate the least probable[br]acceptance rate of a counterfeit device
0:12:18.999,0:12:23.769
that you want, and then you get to this[br]amount of bits. And then you can get a
0:12:23.769,0:12:28.620
better match rate if you repeat steps[br](4) - (6) a few times, and if you run
0:12:28.620,0:12:36.509
out of challenge pairs you can just go[br]back to (1). That's the general idea. So
0:12:36.509,0:12:39.490
this is the first paper that made this[br]connection with cryptography, it has a
0:12:39.490,0:12:44.939
defined protocol, but there are several[br]not-so-nice things, like, you have special
0:12:44.939,0:12:50.649
equipment required, and we would really[br]like to have the same possibility in
0:12:50.649,0:12:55.929
silicon and silicon only. Now in this[br]paper already, the proposal was that you
0:12:55.929,0:13:03.309
might be able to have a similar approach,[br]if you scatter electrons... uhhh... I
0:13:03.309,0:13:07.279
don't understand what this says, but I[br]know that it is not what we're going to
0:13:07.279,0:13:14.529
see next. As an aside, if you do this kind[br]of thing, then you get to read very old
0:13:14.529,0:13:21.910
papers. So, wasn't it nice, back when you[br]could say this: "In the fuel rod placement
0:13:21.910,0:13:26.509
monitor … high radiation levels in the "hot"[br]cell provided the general tamper resistance."
0:13:26.509,0:13:30.100
Or: "The seismic sensors … would detect any[br]attempt to gain physical access to the
0:13:30.100,0:13:33.459
package long before the information[br]security is in jeopardy." Now I wouldn't
0:13:33.459,0:13:39.550
actually take that one as a bet because[br]I know you guys, but, uhhm, the first one
0:13:39.550,0:13:45.489
is pretty good. And you get to see things[br]like this. This is how RSA was done in
0:13:45.489,0:13:53.729
1984. This is a – I think – that's an[br]ISA, maybe pre-ISA bus, I dont know... So
0:13:53.729,0:13:59.959
this is how that was done. And the text is[br]really beautiful: they scanned an old,
0:13:59.959,0:14:05.569
basically typed on a typing machine paper.[br]This is available online, by the
0:14:05.569,0:14:11.769
way, if you have university access...[br]sorry... Then, there are other solutions
0:14:11.769,0:14:13.930
to this problem, of course. You have[br]hardware security modules, you have
0:14:13.930,0:14:18.920
smartcards, you have trusted platform[br]modules... actually, I found out we only
0:14:18.920,0:14:23.500
have those since 2006, I felt [like] they[br]were older?... But you still have the
0:14:23.500,0:14:26.819
problem of key management, right? Because[br]the key isn't tied to the platform. If I
0:14:26.819,0:14:31.759
can extract the key, and put it into[br]another trusted platform module, or
0:14:31.759,0:14:37.879
another hardware security module, then[br]we're still dead in the water. So the aspects of
0:14:37.879,0:14:42.699
these things is the key never leaves the[br]device – ideally – but then how does
0:14:42.699,0:14:46.769
the key enter the device? You can enter[br]new keys, you can enter key-encrypting
0:14:46.769,0:14:52.129
keys to decrypt keys that you never see,[br]that another hardware security module exports,
0:14:52.129,0:14:58.850
it's all interesting crypto, but you also[br]get the problem of what can the key do,
0:14:58.850,0:15:04.720
are you limited to 1024 bits RSA, and is[br]it possible to emulate all this once you
0:15:04.720,0:15:13.480
have the key, right? We really want to[br]have other aspects to our function. Now,
0:15:13.480,0:15:21.371
this is the first name for PUFs, "silicon[br]physical random functions", but they
0:15:21.371,0:15:28.449
already knew that "PRF" might have some[br]three letter acronym that clashes with
0:15:28.449,0:15:31.280
"pseudo-random function", so they decided[br]to go for "physical uncloneable
0:15:31.280,0:15:34.519
functions". There's an interesting[br]discussion going on whether it should be
0:15:34.519,0:15:41.149
"physical" or "physically"... not going[br]into that. The idea is, tamper resistance
0:15:41.149,0:15:46.689
in general is expensive, is difficult,[br]it's just... let's look at a different
0:15:46.689,0:15:51.679
approach. There is enough process[br]variation across identical integrated
0:15:51.679,0:15:55.509
circuits, where... yeah, so, they're not[br]identical because of those process
0:15:55.509,0:16:02.730
variations. And already in 2000 somebody[br]made a... Lofstrom, Daasch and Taylor had
0:16:02.730,0:16:14.230
a small paper on specific special device[br]identification circuits. But, if you want
0:16:14.230,0:16:17.400
to use those for secure device[br]identification and authentication, then
0:16:17.400,0:16:23.809
just a single such circuit is not enough.[br]You need more. So, what do you do? You
0:16:23.809,0:16:28.889
build this. And I don't think it's[br]really feasible, ... basically, this is
0:16:28.889,0:16:33.120
the entire circuit, you have a delay[br]circuit here, ...this is a ring oscillator
0:16:33.120,0:16:40.529
PUF. So you have a delay circuit here,[br]this is a self-oscillating loop,
0:16:40.529,0:16:46.109
basically, this feeds back into this. And[br]the challenge here is a bit for each of
0:16:46.109,0:16:54.110
these blocks. And what the bit says: if[br]it's one then you pass through, if it's
0:16:54.110,0:16:58.310
zero you pass over. So if you have a[br]different challenge, you have a different
0:16:58.310,0:17:03.509
path through this PUF. So ideally, for[br]each challenge, it should be unpredictable
0:17:03.509,0:17:12.030
whether this final arbiter block here...[br]uhh, somewhere over there... gives a one
0:17:12.030,0:17:19.509
or a zero, and then you count the pulses,[br]and you identify your circuits. Now
0:17:19.509,0:17:24.930
attacks on this were also quite well[br]studied in this paper... possible attacks.
0:17:24.930,0:17:28.720
So, you have the duplication attack, which[br]is basically cloning, which should be
0:17:28.720,0:17:32.990
impossible. Right, that's the general[br]idea: Cloning should be impossible. There
0:17:32.990,0:17:40.640
is emulation from measuring, so, you build[br]a model from this by measuring the exact
0:17:40.640,0:17:46.890
distances between logical units inside the[br]PUF, or the length of the wires inside the
0:17:46.890,0:17:52.240
PUF, also deemed infeasible because how[br]are you going to measure this without
0:17:52.240,0:17:58.640
destroying the PUF. This is back in 2001. Then[br]there was emulation from modeling, so basically, if
0:17:58.640,0:18:02.480
you get these challenge-response pairs, if[br]you get enough of them, you can apply some
0:18:02.480,0:18:07.950
nice maching-learning algorithms to that,[br]and then you get prediction of responses.
0:18:07.950,0:18:10.910
And, finally, you have the control[br]algorithm attack, which is
0:18:10.910,0:18:16.180
attacking the PUF's control algorithm[br]without ever getting into the PUF. If you
0:18:16.180,0:18:24.040
can do that, then your PUF is useless. So,[br]they also proposed controlled physically
0:18:24.040,0:18:30.090
uncloneable functions, which is the same[br]but with bells on. So you have an access
0:18:30.090,0:18:37.960
function for the PUF, which is part of the[br]PUF. This is to prevent against that final
0:18:37.960,0:18:44.770
attack. So basically you overlay the logic[br]of the access function with the PUF, so
0:18:44.770,0:18:49.650
that to access the logic of the access[br]function, you have to break the PUF. And
0:18:49.650,0:18:56.290
if you break the PUF, everything breaks,[br]no longer works. So this gives additional
0:18:56.290,0:19:01.720
properties. An uncontrolled PUF can only[br]be used for device authentication. This
0:19:01.720,0:19:10.030
can be used to have nice things like proof[br]of execution on a specific device.
0:19:10.030,0:19:14.480
Potentially [for] things that I don't have an[br]opinion on: on code that only runs on specific
0:19:14.480,0:19:20.380
devices, but basically whatever you need a[br]secure cryptographic key for, you should
0:19:20.380,0:19:23.750
really be using a controlled PUF. Is[br]the idea. But you can still do device
0:19:23.750,0:19:28.991
identification. So, how does a controlled[br]PUF look? You have a random hash here, you
0:19:28.991,0:19:34.701
have a potential ID here, you have the PUF[br]here, Challenge, ID, Personality into the
0:19:34.701,0:19:38.770
random hash, you run that through the PUF,[br]do some error correction, because PUFs are
0:19:38.770,0:19:42.640
not ideal, and then the random hash again,[br]and then the response. This is to prevent
0:19:42.640,0:19:50.090
all these attacks. If you're interested in[br]this, read the paper. Then, in 2011, a
0:19:50.090,0:19:54.570
formal model was proposed, what do we[br]really need from PUFs? First, we need
0:19:54.570,0:20:00.500
robustness. Across evaluations, we need[br]the same response. We need physical
0:20:00.500,0:20:04.340
uncloneability, it really shouldn't be[br]possible to clone these things, and we
0:20:04.340,0:20:12.010
need unpredictability. Now, these two are[br]potentially a lot, so we'll get into that
0:20:12.010,0:20:18.320
on the final slide, I think... And since then,[br]since 2001 there have been a lot of proposals
0:20:18.320,0:20:23.560
and attacks on PUFs. So, first, there are[br]the Arbiter PUFs, which are all delay
0:20:23.560,0:20:31.140
based. So, the general idea here is that[br]if you run a signal through a chip, it is
0:20:31.140,0:20:36.500
delayed by a certain amount. But the[br]amount is unique per chip. But it turns
0:20:36.500,0:20:43.250
out that you can pretty easily model this.[br]And even the Bistable Ring PUF, which is
0:20:43.250,0:20:50.870
fairly recent, I think, you can do some[br]fancy machine learning... I highly
0:20:50.870,0:20:54.920
recommend this paper, "Pac learning of[br]arbiter PUFs". Basically, the idea is, you
0:20:54.920,0:21:00.450
have 30000 challenge-response pairs, and[br]that is enough to give you 100% accuracy
0:21:00.450,0:21:07.440
on a 256-bit challenge PUF. That's not[br]good. This doesn't really work, if you can
0:21:07.440,0:21:16.670
model it that way. And you can also use[br]optical measuring of signals through
0:21:16.670,0:21:21.700
devices at six pico-second accuracy. So[br]these things might not be around for much
0:21:21.700,0:21:28.430
longer. Then there are memory-based PUFs.[br]They are based on bistable memory, which
0:21:28.430,0:21:35.540
basically looks like this, and it's also[br]delay-based, but here it's unique to this
0:21:35.540,0:21:40.690
cell. You have a block of these cells,[br]they are all independent, so you get a
0:21:40.690,0:21:48.260
pattern out of this. These cells go to one[br]or zero, and they are pretty fairly stable
0:21:48.260,0:21:54.480
in doing it. I'll show you a picture later of[br]what happens if you have a nice PUF of
0:21:54.480,0:22:00.030
this type and if you don't have a nice PUF[br]of this type. However, if you have a SRAM
0:22:00.030,0:22:06.511
PUF, for instance, you have fairly limited[br]SRAM. So you can just, in principle, read
0:22:06.511,0:22:11.990
all this out and store all the bits in a[br]database. And then you can, er, clone the
0:22:11.990,0:22:20.830
PUF. Because you can use focused ion beams[br]to trim the SRAM of another chip into the
0:22:20.830,0:22:26.360
correct orientation. And, well, emulation,[br]if you have this database, you can just
0:22:26.360,0:22:32.020
respond from your database. So, this is,[br]in some literature, termed a "weak PUF",
0:22:32.020,0:22:37.590
but it's probably still the most useful[br]one we have right now. This is usually
0:22:37.590,0:22:41.890
also what's in your devices if it's[br]claimed to have a physical uncloneable
0:22:41.890,0:22:47.940
function. But they are of the control[br]variety most of the time. Then finally,
0:22:47.940,0:22:53.770
recently somebody proposed, I think that[br]was, yeah, Schaller, Xiong, and
0:22:53.770,0:23:00.460
Anagnosto... can not pronounce it. But the[br]decay-based PUFs, the idea is, you have
0:23:00.460,0:23:07.290
DRAM, take the power off, put the power[br]back on, look how it decayed. No attacks
0:23:07.290,0:23:16.100
on that that I have seen yet. So, the[br]final few minutes of this talk will be
0:23:16.100,0:23:26.810
about your very own memory PUFs. Which is[br]trivial. Right? ...No. It's not, actually.
0:23:26.810,0:23:31.711
And all this time before, you might think,[br]why would we even bother with this? It
0:23:31.711,0:23:37.630
seems to be hopeless for PUFs, there is[br]not enough randomness in the silicon, but
0:23:37.630,0:23:42.180
I disagree. Because for one, some[br]protection is better than none, which is
0:23:42.180,0:23:49.360
what most system-on-chip devices have. And[br]two, I do not believe in silver bullets.
0:23:49.360,0:23:55.970
This should be part of a greater security[br]mechanism. So if nothing else, if all you
0:23:55.970,0:24:03.100
want from this talk is some interesting[br]paper to read, just one, read this one.
0:24:03.100,0:24:06.660
That's on slide 39, it's called[br]"Lightweight anti-counterfeiting solution
0:24:06.660,0:24:12.220
for low and commodity hardware using[br]inherent PUFs." And, preferably, you also
0:24:12.220,0:24:17.300
read this related one, "PUF based software[br]protection for low end embedded devices."
0:24:17.300,0:24:22.400
Don't be fooled by the terms "IP[br]protection" and "license model". This is a
0:24:22.400,0:24:26.480
Secure Boot environment. You want it, in[br]your Raspberry Pi, for instance. I don't
0:24:26.480,0:24:30.930
know whether Raspberry Pis have it, that's[br]for you to find out. So what you'll need
0:24:30.930,0:24:39.380
is a device with a masked ROM to hold the[br]boot loader, like the first stage of code
0:24:39.380,0:24:45.160
needs to be under your control. You need[br]to have that modifiable startup code, you
0:24:45.160,0:24:50.690
need to be able to modify it, obviously.[br]And you need on-board SRAM, to build the
0:24:50.690,0:24:56.860
PUF from. And then you need some[br]non-volatile memory for encrypted firmware
0:24:56.860,0:25:05.840
and helper data. So, in the puffin[br]project, which that earlier pic was a result
0:25:05.840,0:25:16.950
of... So, there are several results here.[br]This is an STM32F100B microcontroller,
0:25:16.950,0:25:21.590
this is PandaBoard, which is pretty much like a[br]mobile phone actually, so what you want to
0:25:21.590,0:25:27.160
see is this. White noise. This part is a[br]PUF-like memory range, this part is
0:25:27.160,0:25:32.110
probably spoiled by the bootloader or[br]something like that or the wrong code, but
0:25:32.110,0:25:39.860
this you can use. This looks good. So,[br]once you have such a white-noise area, you
0:25:39.860,0:25:46.110
start measuring a lot of times, and then[br]you compute the Hamming distance between
0:25:46.110,0:25:49.830
lots of measurements from lots of[br]different devices. And you want it to look
0:25:49.830,0:25:54.940
like this, you want it be around half.[br]Because that means that every device will
0:25:54.940,0:26:02.950
look different. By about 50%. You also measure[br]the inner class Hamming distance, which is same
0:26:02.950,0:26:08.900
measurements from the same PUF, and you[br]want that to be below 0.1. You don't want
0:26:08.900,0:26:13.940
that to be too inaccurate, because then[br]your error correction becomes too complex
0:26:13.940,0:26:18.680
and starts leaking information, and you[br]will need error correction, using for
0:26:18.680,0:26:28.930
example Golay codes. So this first paper I[br]mentioned, the... this one... the
0:26:28.930,0:26:33.130
lightweight anti-counterfeiting one, this[br]is also from that paper. Read it, it also
0:26:33.130,0:26:36.430
explains how this fuzzy extraction works.[br]If you're interested in this, there's lots
0:26:36.430,0:26:42.560
of scientific literature out there. And[br]then finally, you build this fuzzy
0:26:42.560,0:26:49.450
extractor, and then you enrol your chip.[br]And you generate some helper data for
0:26:49.450,0:26:53.870
this error correction, and then once you[br]challenge the chip you send this
0:26:53.870,0:26:58.710
error-correcting data with the challenge.[br]And in the end the idea would be that you
0:26:58.710,0:27:04.690
get a secret S' from every chip. Now how[br]can you use this? You have the bootloader
0:27:04.690,0:27:08.700
in the masked ROM, this is the first-stage[br]bootloader, it challenges the PUF, and
0:27:08.700,0:27:13.800
decrypts the second-stage bootloader,[br]which comes from external memory. And then
0:27:13.800,0:27:18.500
you boot the embedded operating system.[br]So, this should look familiar to a lot of
0:27:18.500,0:27:23.900
you, because this is basically also how[br]device attestation on x86 works if you're
0:27:23.900,0:27:34.960
using trusted platform modules. So, in a[br]bit more detail, same procedure, query the
0:27:34.960,0:27:38.680
PUF, decrypt and call, here the key also[br]ends up, and you decrypt and call the
0:27:38.680,0:27:45.970
kernel, and then finally, this is how it[br]really looks in real detail. And even if
0:27:45.970,0:27:51.970
you don't want to build this, you'll still[br]have this: So, remember when I showed you
0:27:51.970,0:27:58.500
the inner class Hamming distance, the 10% of[br]differences between meausurements? That's
0:27:58.500,0:28:03.250
caused by the red dots. Those are the[br]unstable SRAM cells. You can use those as
0:28:03.250,0:28:07.500
seeds for a random function. And[br]hopefully, you won't have this. This looks
0:28:07.500,0:28:11.640
wrong, this is not a PUF, this is too[br]predictable. Unfortunately, all this won't
0:28:11.640,0:28:16.350
be possible on x86, because we looked for[br]the PUFs in the CPUs, but Intel and AMD
0:28:16.350,0:28:22.970
both explicitly zero everything. Finally,[br]a word on privacy. I don't have too much
0:28:22.970,0:28:28.121
time for this, but I really liked the fact[br]they mentioned they feel that users... users
0:28:28.121,0:28:32.020
feel that they can be tracked if you have[br]a unique identifier. As though, its not a
0:28:32.020,0:28:39.059
valid concern. Damn the users, being paranoid.[br]Now, back to the controlled PUF. You can
0:28:39.059,0:28:43.490
add personality IDs as a user. If they[br]challenge it, you add a personality, so
0:28:43.490,0:28:47.020
one application reading the PUF gets a[br]different ID from another application,
0:28:47.020,0:28:50.940
which changes the entire output of the[br]hash function, no paranoia required
0:28:50.940,0:28:59.910
anymore. Hopefully. Finally, the references.[br]Google Scholar is your friend. The rest of
0:28:59.910,0:29:05.600
the slides are... all kinds of[br]references... Read it! You've already seen
0:29:05.600,0:29:08.940
all of those, read it,[br]thank you for your attention.
0:29:08.940,0:29:17.790
applause
0:29:17.790,0:29:22.150
Herald: Thank you, Pol. We have[br]time for maybe two questions.
0:29:22.150,0:29:26.000
Please come up to the mics... Mic 3!
0:29:26.000,0:29:32.460
Mic 3: What do you think about MEMS-based[br]physically uncloneable functions, where
0:29:32.460,0:29:36.970
they basically use the accelerometer[br]sensors, and the deviations in these
0:29:36.970,0:29:40.770
sensors by inducing challenges[br]as controlled vibration?
0:29:40.770,0:29:44.140
Pol: Sorry, I missed the[br]first word of your question.
0:29:44.140,0:29:48.360
Mik 3: The MEMS-based… basically the[br]technology that is being used to build
0:29:48.360,0:29:55.230
accelerometers in silicon. So Bosch has[br]some PUF chips based on that, where they
0:29:55.230,0:29:59.290
have arrays of these MEMS-chips, and then[br]a controlled vibrator to induce the
0:29:59.290,0:30:00.290
challenge into that.
0:30:00.290,0:30:05.240
Pol: I think they're probably more secure[br]than silicon-based PUFs, because they are
0:30:05.240,0:30:09.810
built for randomness, whereas we're here[br]trying to extract randomness from an
0:30:09.810,0:30:15.010
existing circuit. Yeah, they're[br]interesting. Use them if you can, but most
0:30:15.010,0:30:19.890
people don't have the option.
0:30:19.890,0:30:20.930
Mik 3: Thank you.
0:30:20.930,0:30:24.620
Herald: More questions?[br]Pol: Up there!
0:30:24.620,0:30:27.760
Herald: Ok, Mic 7!
0:30:27.760,0:30:32.370
Mic 7: Hi, thanks for your talk, I'd never[br]heard of PUFs. I recently went on a
0:30:32.370,0:30:36.980
quest to find a usable smartcard that met[br]all the things I wanted to do, like open
0:30:36.980,0:30:45.630
source, et cetera. Can you expand a bit on[br]how PUFs could be used with an OpenPGP
0:30:45.630,0:30:49.550
smartcard or similar?
0:30:49.550,0:30:54.350
Pol: Short answer: no. I have no idea[br]whether OpenPGP will ever support anything
0:30:54.350,0:31:01.290
like this. You have the PKCS protocols,[br]I know that in theory this is possible.
0:31:01.290,0:31:04.710
I don't know whether anything has[br]implemented it. There are PUFs on
0:31:04.710,0:31:10.310
smartcards, but whether.. We haven't looked[br]into this, I don't know of anyone who has.
0:31:10.310,0:31:11.030
Mic 7: Thank you.
0:31:11.030,0:31:13.750
Pol: But that doesn't mean[br]it doesn't exist.
0:31:13.750,0:31:16.610
Herald: That would be all.[br]Please give it up for Pol, one more time.
0:31:16.610,0:31:20.237
Pol: Thanks![br]applause
0:31:20.237,0:31:25.413
postroll music
0:31:25.413,0:31:44.000
subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!