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!