1 00:00:00,000 --> 00:00:18,400 *36C3 Intro* ♪ (intro music) ♪ 2 00:00:18,400 --> 00:00:22,590 Herald: Welcome, everybody, to our very first talk on the first day of Congress. 3 00:00:22,590 --> 00:00:27,009 The talk is "Open Source is Insufficient to Solve Trust Problems in Hardware," 4 00:00:27,009 --> 00:00:31,579 and although there is a lot to be said for free and open software, it is 5 00:00:31,579 --> 00:00:37,580 unfortunately not always inherently more secure than proprietary or closed software, 6 00:00:37,580 --> 00:00:41,520 and the same goes for hardware as well. And this talk will take us into 7 00:00:41,520 --> 00:00:46,540 the nitty gritty bits of how to build trustable hardware and how it it has to be 8 00:00:46,540 --> 00:00:51,496 implemented and brought together with the software in order to be secure. 9 00:00:51,496 --> 00:00:54,763 We have one speaker here today. It's bunnie. 10 00:00:54,763 --> 00:00:57,651 He's a hardware and firmware hacker. But actually, 11 00:00:57,651 --> 00:01:01,439 the talk was worked on by three people, so it's not just bunnie, but also 12 00:01:01,439 --> 00:01:04,914 Sean "Xobs" Cross and Tom Marble. But the other two are not present today. 13 00:01:04,914 --> 00:01:07,435 But I would like you to welcome our speaker, bunnie, 14 00:01:07,435 --> 00:01:10,655 with a big, warm, round of applause, and have a lot of fun. 15 00:01:10,655 --> 00:01:16,940 *Applause* 16 00:01:16,940 --> 00:01:20,117 bunnie: Good morning, everybody. Thanks for braving the crowds 17 00:01:20,117 --> 00:01:23,940 and making it in to the Congress. And thank you again to the Congress 18 00:01:23,940 --> 00:01:30,514 for giving me the privilege to address the Congress again this year. 19 00:01:30,514 --> 00:01:34,359 Very exciting being the first talk of the day. Had font problems, 20 00:01:34,359 --> 00:01:39,439 so I'm running from a .pdf backup. So we'll see how this all goes. 21 00:01:39,439 --> 00:01:42,914 Good thing I make backups. So the topic of today's talk is 22 00:01:42,914 --> 00:01:47,226 "Open Source is Insufficient to Solve Trust Problems in Hardware," 23 00:01:47,226 --> 00:01:49,249 and sort of some things we can do about this. 24 00:01:49,249 --> 00:01:53,309 So my background is, I'm a big proponent of open source hardware. I 25 00:01:53,309 --> 00:01:57,939 love it. And I've built a lot of things in open source, using open source hardware 26 00:01:57,939 --> 00:02:01,060 principles. But there's been sort of a nagging question in me about like, you 27 00:02:01,060 --> 00:02:04,299 know, some people would say things like, oh, well, you know, you build open source 28 00:02:04,299 --> 00:02:07,439 hardware because you can trust it more. And there's been sort of this gap in my 29 00:02:07,439 --> 00:02:12,380 head and this talk tries to distill out that gap in my head between trust and open 30 00:02:12,380 --> 00:02:18,610 source and hardware. So I'm sure people have opinions on which browsers you would 31 00:02:18,610 --> 00:02:22,580 think is more secure or trustable than the others. But the question is why might you 32 00:02:22,580 --> 00:02:26,500 think one is more trustable than the other is. You have everything and hear from like 33 00:02:26,500 --> 00:02:31,420 Firefox and Iceweasel down to like the Samsung custom browser or the you know, 34 00:02:31,420 --> 00:02:35,200 xiaomi custom browser. Which one would you rather use for your browsing if you 35 00:02:35,200 --> 00:02:41,300 had to trust something? So I'm sure people have their biases and they might say that 36 00:02:41,300 --> 00:02:45,480 open is more trustable. But why do we say open is more trustable? Is it because we 37 00:02:45,480 --> 00:02:49,270 actually read the source thoroughly and check it every single release for this 38 00:02:49,270 --> 00:02:53,701 browser? Is it because we compile our source, our browsers from source before we 39 00:02:53,701 --> 00:02:57,280 use them? No, actually we don't have the time to do that. So let's take a closer 40 00:02:57,280 --> 00:03:02,480 look as to why we like to think that open source software is more secure. So this is 41 00:03:02,480 --> 00:03:07,720 a kind of a diagram of the lifecycle of, say, a software project. You have a bunch 42 00:03:07,720 --> 00:03:12,920 of developers on the left. They'll commit code into some source management program 43 00:03:12,920 --> 00:03:17,890 like git. It goes to a build. And then ideally, some person who carefully managed 44 00:03:17,890 --> 00:03:22,260 the key signs that build goes into an untrusted cloud, then gets download onto 45 00:03:22,260 --> 00:03:26,080 users disks, pulled into RAM, run by the user at the end of the day. Right? So the 46 00:03:26,080 --> 00:03:31,920 reason why actually we find that we might be able to trust things more is because in 47 00:03:31,920 --> 00:03:35,790 the case of open source, anyone can pull down that source code like someone doing 48 00:03:35,790 --> 00:03:40,350 reproducible builds an audit of some type, build it, confirm that the hashes match 49 00:03:40,350 --> 00:03:44,330 and that the keys are all set up correctly. And then the users also have 50 00:03:44,330 --> 00:03:48,870 the ability to know developers and sort of enforce community norms and standards upon 51 00:03:48,870 --> 00:03:52,640 them to make sure that they're acting in sort of in the favor of the community. So 52 00:03:52,640 --> 00:03:55,630 in the case that we have bad actors who want to go ahead and tamper with builds 53 00:03:55,630 --> 00:03:59,940 and clouds and all the things in the middle, it's much more difficult. So open 54 00:03:59,940 --> 00:04:05,510 is more trustable because we have tools to transfer trust in software, things like 55 00:04:05,510 --> 00:04:10,070 hashing, things like public keys, things like Merkle trees. Right? And also in the 56 00:04:10,070 --> 00:04:14,460 case of open versus closed, we have social networks that we can use to reinforce our 57 00:04:14,460 --> 00:04:20,419 community standards for trust and security. Now, it's worth looking a little 58 00:04:20,419 --> 00:04:25,460 bit more into the hashing mechanism because this is a very important part of 59 00:04:25,460 --> 00:04:29,180 our software trust chain. So I'm sure a lot of people know what hashing is, for 60 00:04:29,180 --> 00:04:33,530 people who don't know. Basically it takes a big pile of bits and turns them into a 61 00:04:33,530 --> 00:04:38,340 short sequence of symbols so that a tiny change in the big pile of bits makes a big 62 00:04:38,340 --> 00:04:42,010 change in the output symbols. And also knowing those symbols doesn't reveal 63 00:04:42,010 --> 00:04:48,090 anything about the original file. So in this case here, the file on the left is 64 00:04:48,090 --> 00:04:54,750 hashed to sort of cat, mouse, panda, bear and the file on the right hashes to, you 65 00:04:54,750 --> 00:05:00,830 know, peach, snake, pizza, cookie. And the thing is, as you may not even have noticed 66 00:05:00,830 --> 00:05:04,790 necessarily that there was that one bit changed up there, but it's very easy to 67 00:05:04,790 --> 00:05:07,350 see that short string of symbols have changed. So you don't actually have to go 68 00:05:07,350 --> 00:05:11,140 through that whole file and look for that needle in the haystack. You have this hash 69 00:05:11,140 --> 00:05:15,550 function that tells you something has changed very quickly. Then once you've 70 00:05:15,550 --> 00:05:19,560 computed the hashes, we have a process called signing, where a secret key is used 71 00:05:19,560 --> 00:05:24,030 to encrypt the hash, users decrypt that using the public key to compare against a 72 00:05:24,030 --> 00:05:27,070 locally computed hash. You know, so we're not trusting the server to compute the 73 00:05:27,070 --> 00:05:31,790 hash. We reproduce it on our site and then we can say that it is now difficult to 74 00:05:31,790 --> 00:05:36,370 modify that file or the signature without detection. Now the problem is, that there 75 00:05:36,370 --> 00:05:41,040 is a time of check, time of use issue with the system, even though we have this 76 00:05:41,040 --> 00:05:44,980 mechanism, if we decouple the point of check from the point of use, it creates a 77 00:05:44,980 --> 00:05:49,790 man in the middle opportunity or a person the middle if you want. The thing is that, 78 00:05:49,790 --> 00:05:55,600 you know, it's a class of attacks that allows someone to tamper with data as it 79 00:05:55,600 --> 00:05:59,620 is in transit. And I'm kind of symbolizing this evil guy, I guess, because hackers 80 00:05:59,620 --> 00:06:05,780 all wear hoodies and, you know, they also keep us warm as well in very cold places. 81 00:06:05,780 --> 00:06:12,280 So now an example of a time of check, time of use issue is that if, say, a user 82 00:06:12,280 --> 00:06:15,730 downloads a copy of the program onto their disk and they just check it after the 83 00:06:15,730 --> 00:06:20,370 download to the disc. And they say, okay, great, that's fine. Later on, an adversary 84 00:06:20,370 --> 00:06:24,319 can then modify the file on a disk as it's cut before it's copied to RAM. And now 85 00:06:24,319 --> 00:06:27,150 actually the user, even though they download the correct version of file, 86 00:06:27,150 --> 00:06:31,560 they're getting the wrong version into the RAM. So the key point is the reason why in 87 00:06:31,560 --> 00:06:37,020 software we feel it's more trustworthy, we have a tool to transfer trust and ideally, 88 00:06:37,020 --> 00:06:41,510 we place that point of check as close to the users as possible. So idea that we're 89 00:06:41,510 --> 00:06:45,960 sort of putting keys into the CPU or some secure enclave that, you know, just before 90 00:06:45,960 --> 00:06:49,550 you run it, you've checked it, that software is perfect and has not been 91 00:06:49,550 --> 00:06:55,380 modified, right? Now, an important clarification is that it's actually more 92 00:06:55,380 --> 00:06:58,750 about the place of check versus the place of use. Whether you checked one second 93 00:06:58,750 --> 00:07:03,010 prior or a minute prior doesn't actually matter. It's more about checking the copy 94 00:07:03,010 --> 00:07:07,520 that's closest to the thing that's running it, right? We don't call it PoCPoU because 95 00:07:07,520 --> 00:07:12,700 it just doesn't have quite the same ring to it. But now this is important. That 96 00:07:12,700 --> 00:07:15,900 reason why I emphasize place of check versus place of use is, this is why 97 00:07:15,900 --> 00:07:20,620 hardware is not the same as software in terms of trust. The place of check is not 98 00:07:20,620 --> 00:07:25,320 the place of use or in other words, trust in hardware is a ToCToU problem all the 99 00:07:25,320 --> 00:07:29,570 way down the supply chain. Right? So the hard problem is how do you trust your 100 00:07:29,570 --> 00:07:33,290 computers? Right? So we have problems where we have firmware, pervasive hidden 101 00:07:33,290 --> 00:07:37,680 bits of code that are inside every single part of your system that can break 102 00:07:37,680 --> 00:07:41,770 abstractions. And there's also the issue of hardware implants. So it's tampering or 103 00:07:41,770 --> 00:07:45,430 adding components that can bypass security in ways that we're not, according to the 104 00:07:45,430 --> 00:07:51,390 specification, that you're building around. So from the firmer standpoint, 105 00:07:51,390 --> 00:07:54,759 it's more here to acknowledge is an issue. The problem is this is actually a software 106 00:07:54,759 --> 00:07:58,680 problem. The good news is we have things like openness and runtime verification, 107 00:07:58,680 --> 00:08:01,970 they go going to frame these questions. If you're, you know, a big enough player or 108 00:08:01,970 --> 00:08:05,180 you have enough influence or something, you can coax out all the firmware blobs 109 00:08:05,180 --> 00:08:10,190 and eventually sort of solve that problem. The bad news is that you're still relying 110 00:08:10,190 --> 00:08:14,770 on the hardware to obediently run the verification. So if your hardware isn't 111 00:08:14,770 --> 00:08:17,160 running the verification correctly, it doesn't matter that you have all the 112 00:08:17,160 --> 00:08:21,600 source code for the firmware. Which brings us to the world of hardware implants. So 113 00:08:21,600 --> 00:08:25,300 very briefly, it's worth thinking about, you know, how bad can this get? What are 114 00:08:25,300 --> 00:08:29,830 we worried about? What is the field? If we really want to be worried about trust and 115 00:08:29,830 --> 00:08:33,870 security, how bad can it be? So I've spent many years trying to deal with supply 116 00:08:33,870 --> 00:08:37,490 chains. They're not friendly territory. There's a lot of reasons people want to 117 00:08:37,490 --> 00:08:43,870 screw with the chips in the supply chain. For example, here this is a small ST 118 00:08:43,870 --> 00:08:47,630 microcontroller, claims to be a secure microcontroller. Someone was like: "Ah, 119 00:08:47,630 --> 00:08:50,830 this is not a secure, you know, it's not behaving correctly." We digest off the top 120 00:08:50,830 --> 00:08:54,770 of it. On the inside, it's an LCX244 buffer. Right. So like, you know, this was 121 00:08:54,770 --> 00:08:59,130 not done because someone wanted to tamper with the secure microcontroller. It's 122 00:08:59,130 --> 00:09:02,490 because someone wants to make a quick buck. Right. But the point is that that 123 00:09:02,490 --> 00:09:05,590 marking on the outside is convincing. Right. You could've been any chip on the 124 00:09:05,590 --> 00:09:11,050 inside in that situation. Another problem that I've had personally as I was building 125 00:09:11,050 --> 00:09:15,690 a robot controller board that had an FPGA on the inside. We manufactured a thousand 126 00:09:15,690 --> 00:09:20,790 of these and about 3% of them weren't passing tests, set them aside. Later on, I 127 00:09:20,790 --> 00:09:23,480 pulled these units that weren't passing tests and looked at them very carefully. 128 00:09:23,480 --> 00:09:28,330 And I noticed that all of the units, the FPGA units that weren't passing test had 129 00:09:28,330 --> 00:09:34,510 that white rectangle on them, which is shown in a big more zoomed in version. It 130 00:09:34,510 --> 00:09:38,080 turned out that underneath that white rectangle where the letters ES for 131 00:09:38,080 --> 00:09:43,480 engineering sample, so someone had gone in and Laser blasted off the letters which 132 00:09:43,480 --> 00:09:46,020 say that's an engineering sample, which means they're not qualified for regular 133 00:09:46,020 --> 00:09:50,240 production, blending them into the supply chain at a 3% rate and managed to 134 00:09:50,240 --> 00:09:53,420 essentially double their profits at the end of the day. The reason why this works 135 00:09:53,420 --> 00:09:56,350 is because distributors make a small amount of money. So even a few percent 136 00:09:56,350 --> 00:09:59,931 actually makes them a lot more profit at the end of day. But the key takeaway is 137 00:09:59,931 --> 00:10:03,980 that this is just because 97% of your hardware is okay. It does not mean that 138 00:10:03,980 --> 00:10:09,860 you're safe. Right? So it doesn't help to take one sample out of your entire set of 139 00:10:09,860 --> 00:10:12,750 hardware and say all this is good. This is constructed correctly right, therefore all 140 00:10:12,750 --> 00:10:17,760 of them should be good. That's a ToCToU problem, right? 100% hardware verification 141 00:10:17,760 --> 00:10:23,140 is mandatory. If if you're worried about trust and verification. So let's go a bit 142 00:10:23,140 --> 00:10:27,220 further down the rabbit hole. This is a diagram, sort of an ontology of supply 143 00:10:27,220 --> 00:10:31,880 chain attacks. And I've kind of divided it into two axis. On the vertical axis, is 144 00:10:31,880 --> 00:10:36,270 how easy is it to detect or how hard. Right? So in the bottom you might need a 145 00:10:36,270 --> 00:10:40,060 SEM, a scanning electron microscope to do it, in the middle is an x-ray, a little 146 00:10:40,060 --> 00:10:43,590 specialized and at the top is just visual or JTAG like anyone can do it at home. 147 00:10:43,590 --> 00:10:47,770 Right? And then from left to right is execution difficulty. Right? Things are 148 00:10:47,770 --> 00:10:51,220 going take millions of dollars and months. Things are going take 10$ and weeks. Or a 149 00:10:51,220 --> 00:10:56,570 dollar in seconds. Right? There's sort of several broad classes I've kind of 150 00:10:56,570 --> 00:10:59,750 outlined here. Adding components is very easy. Substituting components is very 151 00:10:59,750 --> 00:11:03,810 easy. We don't have enough time to really go into those. But instead, we're gona 152 00:11:03,810 --> 00:11:07,990 talk about kind of the two more scary ones, which are sort of adding a chip 153 00:11:07,990 --> 00:11:12,390 inside a package and IC modifications. So let's talk about adding a chip in a 154 00:11:12,390 --> 00:11:16,230 package. This one has sort of grabbed a bunch of headlines, so this sort of these 155 00:11:16,230 --> 00:11:21,250 in the Snowden files, we've found these like NSA implants where they had put chips 156 00:11:21,250 --> 00:11:27,350 literally inside of connectors and other chips to modify the computer's behavior. 157 00:11:27,350 --> 00:11:31,840 Now, it turns out that actually adding a chip in a package is quite easy. It 158 00:11:31,840 --> 00:11:35,490 happens every day. This is a routine thing, right? If you take open any SD 159 00:11:35,490 --> 00:11:39,180 card, micro-SD card that you have, you're going to find that it has two chips on the 160 00:11:39,180 --> 00:11:42,060 inside at the very least. One is a controller chip, one is memory chip. In 161 00:11:42,060 --> 00:11:47,909 fact, they can stick 16, 17 chips inside of these packages today very handily. 162 00:11:47,909 --> 00:11:51,940 Right? And so if you want to go ahead and find these chips, is the solution to go 163 00:11:51,940 --> 00:11:54,760 ahead and X-ray all the things, you just take every single circuit board and throw 164 00:11:54,760 --> 00:11:58,240 inside an x-ray machine. Well, this is what a circuit board looks like, in the 165 00:11:58,240 --> 00:12:02,950 x-ray machine. Some things are very obvious. So on the left, we have our 166 00:12:02,950 --> 00:12:05,780 Ethernet magnetic jacks and there's a bunch of stuff on the inside. Turns out 167 00:12:05,780 --> 00:12:08,980 those are all OK right there. Don't worry about those. And on the right, we have our 168 00:12:08,980 --> 00:12:13,739 chips. And this one here, you may be sort of tempted to look and say, oh, I see this 169 00:12:13,739 --> 00:12:18,290 big sort of square thing on the bottom there. That must be the chip. Actually, 170 00:12:18,290 --> 00:12:22,240 turns out that's not the chip at all. That's the solder pad that holds the chip 171 00:12:22,240 --> 00:12:25,920 in place. You can't actually see the chip as the solder is masking it inside the 172 00:12:25,920 --> 00:12:30,300 x-ray. So when we're looking at a chip inside of an x-ray, I've kind of giving 173 00:12:30,300 --> 00:12:34,750 you a look right here on the left is what it looks like sort of in 3-D. And the 174 00:12:34,750 --> 00:12:37,360 right is what looks like an x-ray, sort of looking from the top down. You're looking 175 00:12:37,360 --> 00:12:41,480 at ghostly outlines with very thin spidery wires coming out of it. So if you were to 176 00:12:41,480 --> 00:12:45,760 look at a chip-on-chip in an x-ray, this is actually an image of a chip. So in the 177 00:12:45,760 --> 00:12:49,790 cross-section, you can see the several pieces of silicon that are stacked on top 178 00:12:49,790 --> 00:12:53,440 of each other. And if you could actually do an edge on x-ray of it, this is what 179 00:12:53,440 --> 00:12:57,000 you would see. Unfortunately, you'd have to take the chip off the board to do the 180 00:12:57,000 --> 00:13:00,500 edge on x-ray. So what you do is you have to look at it from the top down and we 181 00:13:00,500 --> 00:13:03,960 look at it from the top down, all you see are basically some straight wires. Like, I 182 00:13:03,960 --> 00:13:08,510 can't it's not obvious from that top down x-ray, whether you're looking at multiple 183 00:13:08,510 --> 00:13:11,700 chips, eight chips, one chip, how many chips are on the inside? That piece of 184 00:13:11,700 --> 00:13:16,380 wire bonds all stitched perfectly in overlap over the chip. So you know. this 185 00:13:16,380 --> 00:13:20,170 is what the chip-on-chip scenario might look like. You have a chip that's sitting 186 00:13:20,170 --> 00:13:23,959 on top of a chip and wire bonds just sort of going a little bit further on from the 187 00:13:23,959 --> 00:13:28,399 edge. And so in the X-ray, the only kind of difference you see is a slightly longer 188 00:13:28,399 --> 00:13:32,760 wire bond in some cases. So it's actually, it's not not, you can find these, but it's 189 00:13:32,760 --> 00:13:38,450 not like, you know, obvious that you've found an implant or not. So looking for 190 00:13:38,450 --> 00:13:42,880 silicon is hard. Silicon is relatively transparent to X-rays. A lot of things 191 00:13:42,880 --> 00:13:48,279 mask it. Copper traces, Solder masks the presence of silicon. This is like another 192 00:13:48,279 --> 00:13:54,180 example of a, you know, a wire bonded chip under an X-ray. There's some mitigations. 193 00:13:54,180 --> 00:13:57,290 If you have a lot of money, you can do computerized tomography. They'll build a 194 00:13:57,290 --> 00:14:02,839 3D image of the chip. You can do X-ray diffraction spectroscopy, but it's not a 195 00:14:02,839 --> 00:14:07,490 foolproof method. And so basically the threat of wirebonded package is actually 196 00:14:07,490 --> 00:14:11,609 very well understood commodity technology. It's actually quite cheap. This is a I was 197 00:14:11,609 --> 00:14:15,750 actually doing some wire bonding in China the other day. This is the wirebonding 198 00:14:15,750 --> 00:14:20,010 machine. I looked up the price, it's 7000 dollars for a used one. And you 199 00:14:20,010 --> 00:14:23,100 basically just walk into the guy with a picture where you want the bonds to go. He 200 00:14:23,100 --> 00:14:27,100 sort of picks them out, programs the machines motion once and he just plays 201 00:14:27,100 --> 00:14:30,030 back over and over again. So if you want to go ahead and modify a chip and add a 202 00:14:30,030 --> 00:14:34,769 wirebond, it's not as crazy as it sounds. The mitigation is that this is a bit 203 00:14:34,769 --> 00:14:38,770 detectable inside X-rays. So let's go down the rabbit hole a little further. So 204 00:14:38,770 --> 00:14:41,859 there's nother concept of threat use called the Through-Silicon Via. So this 205 00:14:41,859 --> 00:14:46,570 here is a cross-section of a chip. On the bottom is the base chip and the top is a 206 00:14:46,570 --> 00:14:51,350 chip that's only 0.1 to 0.2 millimeters thick, almost the width of a human hair. 207 00:14:51,350 --> 00:14:55,220 And they actually have drilled Vias through the chip. So you have circuits on 208 00:14:55,220 --> 00:14:59,540 the top and circuits on the bottom. So this is kind of used to sort of, you know, 209 00:14:59,540 --> 00:15:03,880 putting interposer in between different chips, also used to stack DRAM and HBM. So 210 00:15:03,880 --> 00:15:07,880 this is a commodity process to be able today. It's not science fiction. And the 211 00:15:07,880 --> 00:15:10,640 second concept I want to throw at you is a thing called a Wafer Level Chip Scale 212 00:15:10,640 --> 00:15:15,340 Package, WLCSP. This is actually a very common method for packaging chips today. 213 00:15:15,340 --> 00:15:19,340 Basically it's solder bolts directly on top of chips. They're everywhere. If you 214 00:15:19,340 --> 00:15:24,129 look inside of like an iPhone, basically almost all the chips are WLCSP package 215 00:15:24,129 --> 00:15:28,380 types. Now, if I were to take that Wafer Level Chip Scale Package and cross-section 216 00:15:28,380 --> 00:15:32,459 and look at it, it looks like a circuit board with some solder-balls and the 217 00:15:32,459 --> 00:15:36,089 silicon itself with some backside passivation. If you go ahead and combine 218 00:15:36,089 --> 00:15:40,709 this with a Through-Silicon Via implant, a man in the middle attack using Through- 219 00:15:40,709 --> 00:15:43,500 Silicon Vias, this is what it looks like at the end of the day, you basically have 220 00:15:43,500 --> 00:15:47,490 a piece of silicon this size, the original silicon, sitting in original pads, in 221 00:15:47,490 --> 00:15:50,350 basically all the right places with the solder-balls masking the presence of that 222 00:15:50,350 --> 00:15:53,690 chip. So it's actually basically a nearly undetectable implant if you want to 223 00:15:53,690 --> 00:15:57,580 execute it, if you go ahead and look at the edge of the chip. They already have 224 00:15:57,580 --> 00:16:00,570 seams on the sides. You can't even just look at the side and say, oh, I see a seam 225 00:16:00,570 --> 00:16:03,851 on my chip. Therefore, it's a problem. The seam on the edge often times is because of 226 00:16:03,851 --> 00:16:08,380 a different coding as the back or passivations, these types of things. So if 227 00:16:08,380 --> 00:16:12,870 you really wanted to sort of say, OK, how well can we hide implant, this is probably 228 00:16:12,870 --> 00:16:16,100 the way I would do it. It's logistically actually easier than to worry about an 229 00:16:16,100 --> 00:16:19,769 implant because you don't have to get the chips in wire-bondable format, you 230 00:16:19,769 --> 00:16:23,250 literally just buy them off the Internet. You can just clean off the solder-balls 231 00:16:23,250 --> 00:16:27,470 with a hot air gun and then the hard part is building it so it can be a template for 232 00:16:27,470 --> 00:16:32,390 doing the attack, which will take some hundreds of thousands of dollars to do and 233 00:16:32,390 --> 00:16:36,870 probably a mid-end fab. But if you have almost no budget constraint and you have a 234 00:16:36,870 --> 00:16:39,950 set of chips that are common and you want to build a template for, this could be a 235 00:16:39,950 --> 00:16:46,459 pretty good way to hide an implant inside of a system. So that's sort of adding 236 00:16:46,459 --> 00:16:52,290 chips inside packages. Let's talk a bit about chip modification itself. So how 237 00:16:52,290 --> 00:16:55,740 hard is it to modify the chip itself? Let's say we've managed to eliminate the 238 00:16:55,740 --> 00:17:00,380 possibility of someone's added chip, but what about the chip itself? So this sort 239 00:17:00,380 --> 00:17:03,300 of goes, a lot of people said, hey, bunnie, why don't you spin an open source, 240 00:17:03,300 --> 00:17:06,459 silicon processor, this will make it trustable, right?. This is not a problem. 241 00:17:06,459 --> 00:17:12,309 Well, let's think about the attack surface of IC fabrication processes. So on the 242 00:17:12,309 --> 00:17:16,140 left hand side here I've got kind of a flowchart of what I see fabrication looks 243 00:17:16,140 --> 00:17:22,630 like. You start with a high level chip design, it's a RTL, like Verilog, or VHDL 244 00:17:22,630 --> 00:17:27,430 these days or Python. You go into some backend and then you have a decision to 245 00:17:27,430 --> 00:17:31,380 make: Do you own your backend tooling or not? And so I will go into this a little 246 00:17:31,380 --> 00:17:34,500 more. If you don't, you trust the fab to compile it and assemble it. If you do, you 247 00:17:34,500 --> 00:17:37,760 assemble the chip with some blanks for what's called "hard IP", we'll get into 248 00:17:37,760 --> 00:17:42,140 this. And then you trust the fab to assemble that, make masks and go to mass 249 00:17:42,140 --> 00:17:46,910 production. So there's three areas that I think are kind of ripe for tampering now, 250 00:17:46,910 --> 00:17:49,510 "Netlist tampering", "hard IP tampering" and "mask tampering". We'll go into each 251 00:17:49,510 --> 00:17:55,140 of those. So "Netlist tampering", a lot of people think that, of course, if you wrote 252 00:17:55,140 --> 00:17:59,360 the RTL, you're going to make the chip. It turns out that's actually kind of a 253 00:17:59,360 --> 00:18:02,910 minority case. We hear about that. That's on the right hand side called customer 254 00:18:02,910 --> 00:18:06,910 owned tooling. That's when the customer does a full flow, down to the mask set. 255 00:18:06,910 --> 00:18:11,520 The problem is it costs several million dollars and a lot of extra headcount of 256 00:18:11,520 --> 00:18:15,169 very talented people to produce these and you usually only do it for flagship 257 00:18:15,169 --> 00:18:20,010 products like CPUs, and GPUs or high-end routers, these sorts of things. I would 258 00:18:20,010 --> 00:18:25,020 say most chips tend to go more towards what's called an ASIC side, "Application 259 00:18:25,020 --> 00:18:28,830 Specific Integrated Circuit". What happens is that the customer will do some RTL and 260 00:18:28,830 --> 00:18:33,270 maybe a high level floorplan and then the silicon foundry or service will go ahead 261 00:18:33,270 --> 00:18:36,500 and do the place/route, the IP integration, the pad ring. This is quite 262 00:18:36,500 --> 00:18:39,640 popular for cheap support chips, like your baseboard management controller inside 263 00:18:39,640 --> 00:18:43,820 your server probably went through this flow, disk controllers probably got this 264 00:18:43,820 --> 00:18:47,860 flow, mid-to-low IO controllers . So all those peripheral chips that we don't like 265 00:18:47,860 --> 00:18:52,210 to think about, that we know that can handle our data probably go through a flow 266 00:18:52,210 --> 00:18:57,880 like this. And, to give you an idea of how common it is, but how little you've heard 267 00:18:57,880 --> 00:19:00,900 of it, there's a company called SOCIONEXT. There are a billion dollar company, 268 00:19:00,900 --> 00:19:04,280 actually, you've probably never heard of them, and they offer services. You 269 00:19:04,280 --> 00:19:07,290 basically just throw a spec over the wall and they'll build a chip to you all the 270 00:19:07,290 --> 00:19:10,160 way to the point where you've done logic, synthesis and physical design and then 271 00:19:10,160 --> 00:19:14,590 they'll go ahead and do the manufacturing and test and sample shipment for it. So 272 00:19:14,590 --> 00:19:18,540 then, OK, fine, now, obviously, if you care about trust, you don't do an ASIC 273 00:19:18,540 --> 00:19:24,260 flow, you pony up the millions of dollars and you do a COT flow, right? Well, there 274 00:19:24,260 --> 00:19:29,140 is a weakness in COT flows. And this is it's called the "Hard IP problem". So this 275 00:19:29,140 --> 00:19:33,000 here on the right hand side is an amoeba plot of the standard cells alongside a 276 00:19:33,000 --> 00:19:39,380 piece of SRAM, a highlight this year. The image wasn't great for presentation, but 277 00:19:39,380 --> 00:19:45,010 this region here is the SRAM-block. And all those little colorful blocks are 278 00:19:45,010 --> 00:19:50,370 standard cells, representing your AND- gates and NAND-gates and that sort of 279 00:19:50,370 --> 00:19:55,040 stuff. What happens is that the foundry will actually ask you, just leave an open 280 00:19:55,040 --> 00:20:00,000 spot on your mask-design and they'll go ahead and merge in the RAM into that spot 281 00:20:00,000 --> 00:20:05,290 just before production. The reason why they do this is because stuff like RAM is 282 00:20:05,290 --> 00:20:08,140 a carefully guarded trade secret. If you can increase the RAM density of your 283 00:20:08,140 --> 00:20:12,970 foundry process, you can get a lot more customers. There's a lot of knowhow in it, 284 00:20:12,970 --> 00:20:16,880 and so foundries tend not to want to share the RAM. You can compile your own RAM, 285 00:20:16,880 --> 00:20:20,110 there are open RAM projects, but their performance or their density is not as 286 00:20:20,110 --> 00:20:24,539 good as the foundry specific ones. So in terms of Hard IP, what are the blocks that 287 00:20:24,539 --> 00:20:29,589 tend to be Hard IP? Stuff like RF and analog, phase-locked-loops, ADCs, DACs, 288 00:20:29,589 --> 00:20:34,230 bandgaps. RAM tends to be Hard IP, ROM tends to be Hard IP, eFuze that stores 289 00:20:34,230 --> 00:20:38,370 your keys is going to be given to you as an opaque block, the pad ring around your 290 00:20:38,370 --> 00:20:41,860 chip, the thing that protects your chip from ESD, that's going to be an opaque 291 00:20:41,860 --> 00:20:46,480 block. Basically all the points you need to backdoor your RTL are going to be 292 00:20:46,480 --> 00:20:52,010 trusted in the foundry in a modern process. So OK, let's say, fine, we're 293 00:20:52,010 --> 00:20:55,650 going ahead and build all of our own IP blocks as well. We're gonna compile our 294 00:20:55,650 --> 00:21:00,180 RAMs, do our own IO, everything, right?. So we're safe, right? Well, turns out that 295 00:21:00,180 --> 00:21:04,080 masks can be tampered with post- processing. So if you're going to do 296 00:21:04,080 --> 00:21:07,820 anything in a modern process, the mask designs change quite dramatically from 297 00:21:07,820 --> 00:21:11,240 what you drew them to what actually ends up in the line: They get fractured into 298 00:21:11,240 --> 00:21:14,940 multiple masks, they have resolution correction techniques applied to them and 299 00:21:14,940 --> 00:21:20,700 then they always go through an editing phase. So masks are not born perfect. Masks 300 00:21:20,700 --> 00:21:24,260 have defects on the inside. And so you can look up papers about how they go and they 301 00:21:24,260 --> 00:21:28,220 inspect the mask, every single line on the inside when they find an error, they'll 302 00:21:28,220 --> 00:21:32,080 patch over it, they'll go ahead and add bits of metal and then take away bits of 303 00:21:32,080 --> 00:21:36,350 glass to go ahead and make that mask perfect or, better in some way, if you 304 00:21:36,350 --> 00:21:40,459 have access to the editing capability. So what can you do with mask-editing? Well, 305 00:21:40,459 --> 00:21:45,080 there's been a lot of papers written on this. You can look up ones on, for 306 00:21:45,080 --> 00:21:48,590 example, "Dopant tampering". This one actually has no morphological change. You 307 00:21:48,590 --> 00:21:52,400 can't look at it under a microscope and detect Dopant tampering. You have to have 308 00:21:52,400 --> 00:21:57,020 something and either you have to do some wet chemistry or some X-ray-spectroscopy 309 00:21:57,020 --> 00:22:03,860 to figure it out. This allows for circuit level change without a gross morphological 310 00:22:03,860 --> 00:22:07,600 change of the circuit. And so this can allow for tampering with things like RNGs 311 00:22:07,600 --> 00:22:15,500 or some logic paths. There are oftentimes spare cells inside of your ASIC, since 312 00:22:15,500 --> 00:22:18,230 everyone makes mistakes, including chip designers and so you want a patch over 313 00:22:18,230 --> 00:22:22,070 that. It can be done at the mask level, by signal bypassing, these types of things. 314 00:22:22,070 --> 00:22:29,320 So some certain attacks can still happen at the mask level. So that's a very quick 315 00:22:29,320 --> 00:22:33,700 sort of idea of how bad can it get. When you talk about the time of check, time of 316 00:22:33,700 --> 00:22:39,720 use trust problem inside the supply chain. The short summary of implants is that 317 00:22:39,720 --> 00:22:43,510 there's a lot of places to hide them. Not all of them are expensive or hard. I 318 00:22:43,510 --> 00:22:48,070 talked about some of the more expensive or hard ones. But remember, wire bonding is 319 00:22:48,070 --> 00:22:52,770 actually a pretty easy process. It's not hard to do and it's hard to detect. And 320 00:22:52,770 --> 00:22:56,350 there's really no actual essential correlation between detection difficulty 321 00:22:56,350 --> 00:23:02,059 and difficulty of the attack, if you're very careful in planning the attack. So, 322 00:23:02,059 --> 00:23:06,240 okay, implants are possible. It's just this. Let's agree on that maybe. So now 323 00:23:06,240 --> 00:23:08,539 the solution is we should just have trustable factories. Let's go ahead and 324 00:23:08,539 --> 00:23:12,440 bring the fabs to the EU. Let's have a fab in my backyard or whatever it is, these 325 00:23:12,440 --> 00:23:17,580 these types of things. Let's make sure all the workers are logged and registered, 326 00:23:17,580 --> 00:23:22,400 that sort of thing. Let's talk about that. So if you think about hardware, there's 327 00:23:22,400 --> 00:23:26,429 you, right?. And then we can talk about evil maids. But let's not actually talk 328 00:23:26,429 --> 00:23:30,270 about those, because that's actually kind of a minority case to worry about. But 329 00:23:30,270 --> 00:23:35,650 let's think about how stuff gets to you. There's a distributor, who goes through a 330 00:23:35,650 --> 00:23:39,330 courier, who gets to you. All right. So we've gone and done all this stuff for the 331 00:23:39,330 --> 00:23:43,679 trustful factory. But it's actually documented that couriers have been 332 00:23:43,679 --> 00:23:50,300 intercepted and implants loaded. You know, by for example, the NSA on Cisco products. 333 00:23:50,300 --> 00:23:55,030 Now, you don't even have to have access to couriers, now. Thanks to the way modern 334 00:23:55,030 --> 00:24:00,730 commerce works, other customers can go ahead and just buy a product, tamper with 335 00:24:00,730 --> 00:24:04,880 it, seal it back in the box, send it back to your distributor. And then maybe you 336 00:24:04,880 --> 00:24:07,880 get one, right? That can be good enough. Particularly, if you know a corporation is 337 00:24:07,880 --> 00:24:10,600 in a particular area. Targeting them, you buy a bunch of hard drives in the area, 338 00:24:10,600 --> 00:24:12,510 seal them up, send them back and eventually one of them ends up in the 339 00:24:12,510 --> 00:24:16,750 right place and you've got your implant, right? So there's a great talk last year 340 00:24:16,750 --> 00:24:20,200 at 35C3. I recommend you check it out. That talks a little bit more about the 341 00:24:20,200 --> 00:24:25,100 scenario, sort of removing tamper stickers and you know, the possibility that some 342 00:24:25,100 --> 00:24:29,412 crypto wallets were sent back in the supply chain then and tampered with. OK, 343 00:24:29,412 --> 00:24:32,480 and then let's let's take that back. We have to now worry about the wonderful 344 00:24:32,480 --> 00:24:36,490 people in customs. We have to worry about the wonderful people in the factory who 345 00:24:36,490 --> 00:24:40,370 have access to your hardware. And so if you cut to the chase, it's a huge attack 346 00:24:40,370 --> 00:24:44,480 surface in terms of the supply chain, right? From you to the courier to the 347 00:24:44,480 --> 00:24:49,120 distributor, customs, box build, the box build factory itself. Oftentimes we'll use 348 00:24:49,120 --> 00:24:53,300 gray market resources to help make themselves more profitable, right? You 349 00:24:53,300 --> 00:24:56,980 have distributors who go to them. You don't even know who those guys are. PCB 350 00:24:56,980 --> 00:25:00,740 assembly, components, boards, chip fab, packaging, the whole thing, right? Every 351 00:25:00,740 --> 00:25:04,270 single point is a place where someone can go ahead and touch a piece of hardware 352 00:25:04,270 --> 00:25:08,970 along the chain. So can open source save us in this scenario? Does open hardware 353 00:25:08,970 --> 00:25:12,140 solve this problem? Right. Let's think about it. Let's go ahead and throw some 354 00:25:12,140 --> 00:25:16,090 developers with git on the left hand side. How far does it get, right? Well, we can 355 00:25:16,090 --> 00:25:18,880 have some continuous integration checks that make sure that you know the hardware 356 00:25:18,880 --> 00:25:23,049 is correct. We can have some open PCB designs. We have some open PDK, but then 357 00:25:23,049 --> 00:25:27,230 from that point, it goes into a rather opaque machine and then, OK, maybe we can 358 00:25:27,230 --> 00:25:31,090 put some test on the very edge before exit the factory to try and catch some 359 00:25:31,090 --> 00:25:36,110 potential issues, right? But you can see all the area, other places, where a time 360 00:25:36,110 --> 00:25:40,750 of check, time of use problem can happen. And this is why, you know, I'm saying that 361 00:25:40,750 --> 00:25:45,700 open hardware on its own is not sufficient to solve this trust problem. Right? And 362 00:25:45,700 --> 00:25:49,500 the big problem at the end of the day is that you can't hash hardware. Right? There 363 00:25:49,500 --> 00:25:53,950 is no hash function for hardware. That's why I want to go through that early today. 364 00:25:53,950 --> 00:25:57,480 There's no convenient, easy way to basically confirming the correctness of 365 00:25:57,480 --> 00:26:00,710 your hardware before you use it. Some people say, well, bunnie, said once, there 366 00:26:00,710 --> 00:26:05,320 is always a bigger microscope, right? You know, I do some, security reverse 367 00:26:05,320 --> 00:26:08,370 engineering stuff. This is true, right? So there's a wonderful technique called 368 00:26:08,370 --> 00:26:12,481 ptychographic X-ray Imaging, there is a great paper in nature about it, where they 369 00:26:12,481 --> 00:26:16,880 take like a modern i7 CPU and they get down to the gate level nondestructively 370 00:26:16,880 --> 00:26:20,600 with it, right? It's great for reverse engineering or for design verification. 371 00:26:20,600 --> 00:26:24,190 The problem number one is it literally needs a building sized microscope. It was 372 00:26:24,190 --> 00:26:28,940 done at the Swiss light source, that donut shaped thing is the size of the light 373 00:26:28,940 --> 00:26:33,000 source for doing that type of verification, right? So you're not going 374 00:26:33,000 --> 00:26:36,591 to have one at your point of use, right? You're going to check it there and then 375 00:26:36,591 --> 00:26:41,279 probably courier it to yourself again. Time of check is not time of use. Problem 376 00:26:41,279 --> 00:26:46,190 number two, it's expensive to do so. Verifying one chip only verifies one chip 377 00:26:46,190 --> 00:26:49,760 and as I said earlier, just because 99.9% of your hardware is OK, doesn't mean 378 00:26:49,760 --> 00:26:54,070 you're safe. Sometimes all it takes is one server out of a thousand, to break some 379 00:26:54,070 --> 00:26:59,110 fundamental assumptions that you have about your cloud. And random sampling just 380 00:26:59,110 --> 00:27:02,030 isn't good enough, right? I mean, would you random sample signature checks on 381 00:27:02,030 --> 00:27:06,240 software that you install? Download? No. You insist 100% check and everything. If 382 00:27:06,240 --> 00:27:08,441 you want that same standard of reliability, you have to do that for 383 00:27:08,441 --> 00:27:12,860 hardware. So then, is there any role for open source and trustful hardware? 384 00:27:12,860 --> 00:27:16,870 Absolutely, yes. Some of you guys may be familiar with that little guy on the 385 00:27:16,870 --> 00:27:22,799 right, the SPECTRE logo. So correctness is very, very hard. Peer review can help fix 386 00:27:22,799 --> 00:27:27,160 correctness bugs. Micro architectural transparency can able the fixes in SPECTRE 387 00:27:27,160 --> 00:27:30,250 like situations. So, you know, for example, you would love to be able to say 388 00:27:30,250 --> 00:27:33,750 we're entering a critical region. Let's turn off all the micro architectural 389 00:27:33,750 --> 00:27:38,340 optimizations, sacrifice performance and then run the code securely and then go 390 00:27:38,340 --> 00:27:41,250 back into, who cares what mode, and just get done fast, right? That would be a 391 00:27:41,250 --> 00:27:44,590 switch I would love to have. But without that sort of transparency or without the 392 00:27:44,590 --> 00:27:48,500 bill to review it, we can't do that. Also, you know, community driven features and 393 00:27:48,500 --> 00:27:51,390 community own designs is very empowering and make sure that we're sort of building 394 00:27:51,390 --> 00:27:56,710 the right hardware for the job and that it's upholding our standards. So there is 395 00:27:56,710 --> 00:28:01,850 a role. It's necessary, but it's not sufficient for trustable hardware. Now the 396 00:28:01,850 --> 00:28:06,220 question is, OK, can we solve the point of use hardware verification problem? Is it 397 00:28:06,220 --> 00:28:09,510 all gloom and doom from here on? Well, I didn't bring us here to tell you it's just 398 00:28:09,510 --> 00:28:14,720 gloom and doom. I've thought about this and I've kind of boiled it into three 399 00:28:14,720 --> 00:28:19,429 principles for building verifiable hardware. The three principles are: 1) 400 00:28:19,429 --> 00:28:23,020 Complexity is the enemy of verification. 2) We should verify entire systems, not 401 00:28:23,020 --> 00:28:26,400 just components. 3) And we need to empower end-users to verify and seal their 402 00:28:26,400 --> 00:28:31,580 hardware. We'll go into this in the remainder of the talk. The first one is 403 00:28:31,580 --> 00:28:37,090 that complexity is complicated. Right? Without a hashing function, verification 404 00:28:37,090 --> 00:28:43,830 rolls back to bit-by-bit or atom-by-atom verification. Modern phones just have so 405 00:28:43,830 --> 00:28:48,690 many components. Even if I gave you the full source code for the SOC inside of a 406 00:28:48,690 --> 00:28:51,960 phone down to the mass level, what are you going to do with it? How are you going to 407 00:28:51,960 --> 00:28:56,560 know that this mass actually matches the chip and those two haven't been modified? 408 00:28:56,560 --> 00:29:01,400 So more complexity, is more difficult. The solution is: Let's go to simplicity, 409 00:29:01,400 --> 00:29:04,250 right? Let's just build things from discrete transistors. Someone's done this. 410 00:29:04,250 --> 00:29:08,250 The Monster 6502 is great. I love the project. Very easy to verify. Runs at 50 411 00:29:08,250 --> 00:29:13,250 kHz. So you're not going to do a lot with that. Well, let's build processors at 412 00:29:13,250 --> 00:29:16,490 a visually inspectable process node. Go to 500 nanometers. You can see that with 413 00:29:16,490 --> 00:29:21,450 light. Well, you know, 100 megahertz clock rate and a very high power consumption and 414 00:29:21,450 --> 00:29:25,419 you know, a couple kilobytes RAM probably is not going to really do it either. 415 00:29:25,419 --> 00:29:30,100 Right? So the point of use verification is a tradeoff between ease of verification 416 00:29:30,100 --> 00:29:34,070 and features and usability. Right? So these two products up here largely do the 417 00:29:34,070 --> 00:29:39,280 same thing. Air pods. Right? And headphones on your head. Right? Air pods 418 00:29:39,280 --> 00:29:43,960 have something on the order of tens of millions of transistors for you to verify. 419 00:29:43,960 --> 00:29:47,570 The headphone that goes on your head. Like I can actually go to Maxwell's equations 420 00:29:47,570 --> 00:29:50,630 and actually tell you how the magnets work from very first principles. And there's 421 00:29:50,630 --> 00:29:54,490 probably one transistor on the inside of the microphone to go ahead and amplify the 422 00:29:54,490 --> 00:29:59,740 membrane. And that's it. Right? So this one, you do sacrifice some features and 423 00:29:59,740 --> 00:30:02,910 usability, when you go to a headset. Like you can't say, hey, Siri, and they will 424 00:30:02,910 --> 00:30:07,510 listen to you and know what you're doing, but it's very easy to verify and know 425 00:30:07,510 --> 00:30:13,250 what's going on. So in order to start a dialog on user verification, we have to 426 00:30:13,250 --> 00:30:17,150 serve a set of context. So I started a project called 'Betrusted' because the 427 00:30:17,150 --> 00:30:22,100 right answer depends on the context. I want to establish what might be a minimum 428 00:30:22,100 --> 00:30:27,119 viable, verifiable product. And it's sort of like meant to be user verifiable by 429 00:30:27,119 --> 00:30:30,230 design. And when we think of it as a hardware software distro. So it's meant to 430 00:30:30,230 --> 00:30:34,291 be modified and changed and customized based upon the right context at the end of 431 00:30:34,291 --> 00:30:39,710 the day. This a picture of what it looks like. I actually have a little prototype 432 00:30:39,710 --> 00:30:43,919 here. Very, very, very early product here at the Congress. If you wanna look at it. 433 00:30:43,919 --> 00:30:48,720 It's a mobile device that is meant for sort of communication, sort of text based 434 00:30:48,720 --> 00:30:52,990 communication and maybe voice authentication. So authenticator tokens 435 00:30:52,990 --> 00:30:56,320 are like a crypto wall if you want. And the people were thinking about who might 436 00:30:56,320 --> 00:31:00,990 be users are either high value targets politically or financially. So you don't 437 00:31:00,990 --> 00:31:04,340 have to have a lot of money to be a high value target. You could also be in a very 438 00:31:04,340 --> 00:31:08,620 politically risky for some people. And also, of course, looking at developers and 439 00:31:08,620 --> 00:31:12,299 enthusiasts and ideally we're thinking about a global demographic, not just 440 00:31:12,299 --> 00:31:15,890 English speaking users, which is sort of a thing when you think about the complexity 441 00:31:15,890 --> 00:31:18,880 standpoint, this is where we really have to sort of champ at the bit and figure out 442 00:31:18,880 --> 00:31:24,250 how to solve a lot of hard problems like getting Unicode and, you know, right to 443 00:31:24,250 --> 00:31:28,210 left rendering and pictographic fonts to work inside a very small tax surface 444 00:31:28,210 --> 00:31:34,419 device. So this leads me to the second point. In which we verify entire systems, 445 00:31:34,419 --> 00:31:37,779 not just components. We all say, well, why not just build a chip? Why not? You know, 446 00:31:37,779 --> 00:31:41,899 why are you thinking about a whole device? Right. The problem is, that private keys 447 00:31:41,899 --> 00:31:45,830 are not your private matters. Screens can be scraped and keyboards can be logged. So 448 00:31:45,830 --> 00:31:50,059 there's some efforts now to build wonderful security enclaves like Keystone 449 00:31:50,059 --> 00:31:54,600 and Open Titan, which will build, you know, wonderful secure chips. The problem 450 00:31:54,600 --> 00:31:58,500 is, that even if you manage to keep your key secret, you still have to get that 451 00:31:58,500 --> 00:32:03,309 information through an insecure CPU from the screen to the keyboard and so forth. 452 00:32:03,309 --> 00:32:06,250 Right? And so, you know, people who have used these, you know, on screen touch 453 00:32:06,250 --> 00:32:09,309 keyboards have probably seen something of a message like this saying that, by the 454 00:32:09,309 --> 00:32:11,940 way, this keyboard can see everything you're typing, clean your passwords. 455 00:32:11,940 --> 00:32:14,680 Right? And people probably clip and say, oh, yeah, sure, whatever. I trust that. 456 00:32:14,680 --> 00:32:18,840 Right? OK, well, this answer, this little enclave on the site here isn't really 457 00:32:18,840 --> 00:32:22,410 doing a lot of good. When you go ahead and you say, sure, I'll run this implant 458 00:32:22,410 --> 00:32:28,890 method, they can go ahead and modify all my data and intercept all my data. So in 459 00:32:28,890 --> 00:32:32,820 terms of making a device variable, let's talk about the concept of practice flow. 460 00:32:32,820 --> 00:32:36,480 How do I take these three principles and turn them into something? So this is you 461 00:32:36,480 --> 00:32:40,320 know, this is the ideal of taking these three requirements and turning it into the 462 00:32:40,320 --> 00:32:44,709 set of five features, a physical keyboard, a black and white LCD, a FPGA-based RISC-V 463 00:32:44,709 --> 00:32:49,310 SoC, users-sealable keys and so on. It's easy to verify and physically protect. So 464 00:32:49,310 --> 00:32:53,250 let's talk about these features one by one. First one is a physical keyboard. Why 465 00:32:53,250 --> 00:32:56,259 am I using a physical keyboard and not a virtual keyboard? People love the virtual 466 00:32:56,259 --> 00:33:00,220 keyboard. The problem is that captouch screens, which is necessary to do a good 467 00:33:00,220 --> 00:33:04,610 virtual keyboard, have a firmware block. They have a microcontroller to do the 468 00:33:04,610 --> 00:33:07,650 touch screens, actually. It's actually really hard to build these things we want. 469 00:33:07,650 --> 00:33:10,630 If you can do a good job with it and build an awesome open source one, that'll be 470 00:33:10,630 --> 00:33:15,020 great, but that's a project in and of itself. So in order to sort of get an easy 471 00:33:15,020 --> 00:33:17,599 win here and we can, let's just go with the physical keyboard. So this is what the 472 00:33:17,599 --> 00:33:21,520 device looks like with this cover off. We have a physical keyboard, PCV with a 473 00:33:21,520 --> 00:33:24,960 little overlay that does, you know, so we can do multilingual inserts and you can go 474 00:33:24,960 --> 00:33:28,580 to change that out. And it's like it's just a two layer daughter card. Right. 475 00:33:28,580 --> 00:33:32,649 Just hold up to like, you know, like, OK, switches, wires. Right? Not a lot of 476 00:33:32,649 --> 00:33:35,500 places to hide things. So I'll take that as an easy win for an input surface, 477 00:33:35,500 --> 00:33:39,540 that's verifiable. Right? The output surface is a little more subtle. So we're 478 00:33:39,540 --> 00:33:44,470 doing a black and white LCD. If you say, OK, why not use a curiosity? If you ever 479 00:33:44,470 --> 00:33:52,279 take apart a liquid crystal display, look for a tiny little thin rectangle sort of 480 00:33:52,279 --> 00:33:57,130 located near the display area. That's actually a silicon chip that's bonded to 481 00:33:57,130 --> 00:34:00,630 the glass. That's what it looks like at the end of the day. That contains a frame 482 00:34:00,630 --> 00:34:05,169 buffer and a command interface. It has millions of transistors on the inside and 483 00:34:05,169 --> 00:34:08,909 you don't know what it does. So if you're ever assuming your adversary may be 484 00:34:08,909 --> 00:34:14,240 tampering with your CPU, this is also a viable place you have to worry about. So I 485 00:34:14,240 --> 00:34:18,991 found a screen. It's called a memory LCD by sharp electronics. It turns out they do 486 00:34:18,991 --> 00:34:22,980 all the drive electrons on glass. So this is a picture of the driver electronics on 487 00:34:22,980 --> 00:34:26,779 the screen through like a 50x microscope with a bright light behind it. Right? You 488 00:34:26,779 --> 00:34:34,369 can actually see the transistors that are used to to drive everything on the display 489 00:34:34,369 --> 00:34:37,980 it's a nondestructive method of verification. But actually more important 490 00:34:37,980 --> 00:34:41,790 to the point is that there's so few places to hide things, you probably don't need to 491 00:34:41,790 --> 00:34:45,359 check it, right? There's not - If you want to add an implant to this, you would need 492 00:34:45,359 --> 00:34:50,469 to grow the glass area substantially or add a silicon chip, which is a thing that 493 00:34:50,469 --> 00:34:55,069 you'll notice, right. So at the end of the day, the less places to hide things is 494 00:34:55,069 --> 00:34:58,510 less need to check things. And so I can feel like this is a screen where I can 495 00:34:58,510 --> 00:35:02,749 write data to, and it'll show what I want to show. The good news is that display has 496 00:35:02,749 --> 00:35:07,119 a 200 ppi pixel density. So it's not - even though it's black and white - it's 497 00:35:07,119 --> 00:35:12,410 kind of closer to E-Paper. EPD in terms of resolution. So now we come to the hard 498 00:35:12,410 --> 00:35:16,869 part, right, the CPU. The silicon problem, right? Any chip built in the last two 499 00:35:16,869 --> 00:35:20,559 decades is not going to be inspectable, fully inspectable with optical microscope, 500 00:35:20,559 --> 00:35:24,469 right? Thorough analysis requires removing layers and layers of metal and dielectric. 501 00:35:24,469 --> 00:35:29,289 This is sort of a cross section of a modernish chip and you can see the sort of 502 00:35:29,289 --> 00:35:34,930 the huge stack of things to look at on this. This process is destructive and you 503 00:35:34,930 --> 00:35:37,569 can think of it as hashing, but it's a little bit too literal, right? We want 504 00:35:37,569 --> 00:35:40,680 something where we can check the thing that we're going to use and then not 505 00:35:40,680 --> 00:35:46,720 destroy it. So I've spent quite a bit of time thinking about options for 506 00:35:46,720 --> 00:35:50,319 nondestructive silicon verification. The best I could come up with maybe was using 507 00:35:50,319 --> 00:35:54,390 optical fauilt induction somehow combined with some chip design techniques to go 508 00:35:54,390 --> 00:35:58,009 ahead and like scan a laser across and look at fault syndromes and figure out, 509 00:35:58,009 --> 00:36:02,019 you know, does the thing... do the gates that we put down correspond to the thing 510 00:36:02,019 --> 00:36:07,349 that I built. The problem is, I couldn't think of a strategy to do it that wouldn't 511 00:36:07,349 --> 00:36:10,459 take years and tens of millions of dollars to develop, which puts it a little bit far 512 00:36:10,459 --> 00:36:13,549 out there and probably in the realm of like sort of venture funded activities, 513 00:36:13,549 --> 00:36:18,250 which is not really going to be very empowering of everyday people. So let's 514 00:36:18,250 --> 00:36:22,380 say I want something a little more short term than that, then that sort of this, 515 00:36:22,380 --> 00:36:27,130 you know, sort of, you know, platonic ideal of verifiability. So the compromise 516 00:36:27,130 --> 00:36:32,300 I sort of arrived at is the FPGA. So field programmable gate arrays, that's what FPGA 517 00:36:32,300 --> 00:36:37,069 stands for, are large arrays of logic and wires that are user configured to 518 00:36:37,069 --> 00:36:42,109 implement hardware designs. So this here is an image inside an FPGA design tool. On 519 00:36:42,109 --> 00:36:47,109 the top right is an example of one sort of logic sub cell. It's got a few flip flops 520 00:36:47,109 --> 00:36:51,920 and lookup tables in it. It's embedded in this huge mass of wires that allow you to 521 00:36:51,920 --> 00:36:56,069 wire it up at runtime to figure out what's going on. And one thing that this diagram 522 00:36:56,069 --> 00:36:59,789 here shows is I'm able to sort of correlate design. I can see "Okay. The 523 00:36:59,789 --> 00:37:04,299 decode_to_execute_INSTRUCTION_reg bit 26 corresponds to this net." So now we're 524 00:37:04,299 --> 00:37:09,260 sort of like bring that Time Of Check a little bit closer to Time Of Use. And so 525 00:37:09,260 --> 00:37:13,099 the idea is to narrow that ToCToU gap by compiling your own CPU. We can basically 526 00:37:13,099 --> 00:37:16,510 give you the CPU from source. You can compile it yourself. You can confirm the 527 00:37:16,510 --> 00:37:20,599 bit stream. So now we're sort of enabling a bit more of that trust transfer like 528 00:37:20,599 --> 00:37:24,989 software, right. But there's a subtlety in that the toolchains are not necessarily 529 00:37:24,989 --> 00:37:30,380 always open. There's some FOSS flows like symbiflow. They have a 100% open flow for 530 00:37:30,380 --> 00:37:35,150 ICE40 and ECP5 and there's like 7-series where they've a coming-soon status, but 531 00:37:35,150 --> 00:37:41,519 they currently require some closed vendor tools. So picking FPGA is a difficult 532 00:37:41,519 --> 00:37:45,230 choice. There's a usability versus verification tradeoff here. The big 533 00:37:45,230 --> 00:37:49,119 usability issue is battery life. If we're going for a mobile device, you want to use 534 00:37:49,119 --> 00:37:54,190 it all day long or you want to be dead by noon. It turns out that the best sort of 535 00:37:54,190 --> 00:37:57,950 chip in terms of battery life is a Spartan7. It gives you 4x, roughly 3 to 536 00:37:57,950 --> 00:38:05,329 4x, in terms of battery life. But the tool flow is still semi-closed. But the, you 537 00:38:05,329 --> 00:38:09,199 know, I am optimistic that symbiflow will get there and we can also fork and make an 538 00:38:09,199 --> 00:38:13,260 ECP5 version if that's a problem at the end of day. So let's talk a little bit 539 00:38:13,260 --> 00:38:18,049 more about sort of FPGA features. So one thing I like to say about FPGA is: they 540 00:38:18,049 --> 00:38:22,420 offer a sort of ASLR, so address-space layout randomization, but for hardware. 541 00:38:22,420 --> 00:38:27,269 Essentially, a design has a kind of pseudo-random mapping to the device. This 542 00:38:27,269 --> 00:38:31,019 is a sort of a screenshot of two compilation runs at the same source code 543 00:38:31,019 --> 00:38:35,379 with a very small modification to it. And basically a version number stored in a 544 00:38:35,379 --> 00:38:41,710 GPR. And then you can see that the actually the locations of a lot of the 545 00:38:41,710 --> 00:38:45,609 registers are basically shifted around. The reason why this is important is 546 00:38:45,609 --> 00:38:50,500 because this hinders a significant class of silicon attacks. All those small mass 547 00:38:50,500 --> 00:38:53,849 level changes I talked about the ones where we just "Okay, we're just gonna head 548 00:38:53,849 --> 00:38:58,459 and change a few wires or run a couple logic cells around", those become more 549 00:38:58,459 --> 00:39:02,329 less likely to capture a critical bit. So if you want to go ahead and backdoor a 550 00:39:02,329 --> 00:39:05,760 full FPGA, you're going to have to change the die size. You have to make it 551 00:39:05,760 --> 00:39:09,969 substantially larger to be able to sort of like swap out the function in those cases. 552 00:39:09,969 --> 00:39:13,480 And so now the verification bar goes from looking for a needle in a haystack to 553 00:39:13,480 --> 00:39:16,959 measuring the size of the haystack, which is a bit easier to do towards the user 554 00:39:16,959 --> 00:39:22,140 side of things. And it turns out, at least in Xilinx-land, it's just a change of a 555 00:39:22,140 --> 00:39:28,819 random parameter does the trick. So some potential attack vectors against FPGA is 556 00:39:28,819 --> 00:39:34,279 like "OK, well, it's closed silicon." What are the backdoors there? Notably inside a 557 00:39:34,279 --> 00:39:38,589 7-series FPGA they actually document introspection features. You can pull out 558 00:39:38,589 --> 00:39:42,869 anything inside the chip by instantiating a certain special block. And then we still 559 00:39:42,869 --> 00:39:46,349 also have to worry about the whole class of like man in the middle. I/O- and JTAG 560 00:39:46,349 --> 00:39:49,990 implants that I talked about earlier. So It's easy, really easy, to mitigate the 561 00:39:49,990 --> 00:39:52,809 known blocks, basically lock them down, tie them down, check them in the bit 562 00:39:52,809 --> 00:39:58,290 stream, right? In terms of the I/O-man-in- the-middle stuff, this is where we're 563 00:39:58,290 --> 00:40:02,750 talking about like someone goes ahead and puts a chip in in the path of your FPGA. 564 00:40:02,750 --> 00:40:06,069 There's a few tricks you can do. We can do sort of bust encryption on the RAM and the 565 00:40:06,069 --> 00:40:11,690 ROM at the design level that frustrates these. At the implementation, basically, 566 00:40:11,690 --> 00:40:15,190 we can use the fact that data pins and address pins can be permuted without 567 00:40:15,190 --> 00:40:19,259 affecting the device's function. So every design can go ahead and permute those data 568 00:40:19,259 --> 00:40:24,670 and address pin mappings sort of uniquely. So any particular implant that goes in 569 00:40:24,670 --> 00:40:28,150 will have to be able to compensate for all those combinations, making the implant a 570 00:40:28,150 --> 00:40:32,339 little more difficult to do. And of course, we can also fall back to sort of 571 00:40:32,339 --> 00:40:37,959 careful inspection of the device. In terms of the closed source silicon, the thing 572 00:40:37,959 --> 00:40:42,160 that I'm really optimistic for there is that so in terms of the closed source 573 00:40:42,160 --> 00:40:46,521 system, the thing that we have to worry about is that, for example, now that 574 00:40:46,521 --> 00:40:49,769 Xilinx knows that we're doing these trustable devices using a tool chain, they 575 00:40:49,769 --> 00:40:54,140 push a patch that compiles back doors into your bit stream. So not even as a silicon 576 00:40:54,140 --> 00:40:57,999 level implant, but like, you know, maybe the tool chain itself has a backdoor that 577 00:40:57,999 --> 00:41:04,940 recognizes that we're doing this. So the cool thing is, this is a cool project: So 578 00:41:04,940 --> 00:41:08,789 there's a project called "Prjxray", project x-ray, it's part of the Symbiflow 579 00:41:08,789 --> 00:41:12,270 effort, and they're actually documenting the full bit stream of the 7-Series 580 00:41:12,270 --> 00:41:15,799 device. It turns out that we don't yet know what all the bit functions are, but 581 00:41:15,799 --> 00:41:19,400 the bit mappings are deterministic. So if someone were to try and activate a 582 00:41:19,400 --> 00:41:22,970 backdoor in the bit stream through compilation, we can see it in a diff. We'd 583 00:41:22,970 --> 00:41:26,220 be like: Wow, we've never seen this bit flip before. What is this? Do we can look 584 00:41:26,220 --> 00:41:29,949 into it and figure out if it's malicious or not, right? So there's actually sort of 585 00:41:29,949 --> 00:41:33,799 a hope that essentially at the end of day we can build sort of a bit stream checker. 586 00:41:33,799 --> 00:41:37,150 We can build a thing that says: Here's a bit stream that came out, does it 587 00:41:37,150 --> 00:41:40,789 correlate to the design source, do all the bits check out, do they make sense? And so 588 00:41:40,789 --> 00:41:44,141 ideally we would come up with like a one click tool. And now we're at the point 589 00:41:44,141 --> 00:41:47,469 where the point of check is very close to the point of use. The users are now 590 00:41:47,469 --> 00:41:50,749 confirming that the CPUs are correctly constructed and mapped to the FPGA 591 00:41:50,749 --> 00:41:56,359 correctly. So the sort of the summary of FPGA vs. custom silicon is sort of like, 592 00:41:56,359 --> 00:42:02,210 the pros of custom silicon is that they have great performance. We can do a true 593 00:42:02,210 --> 00:42:05,479 single chip enclave with hundreds of megahertz speeds and tiny power 594 00:42:05,479 --> 00:42:09,750 consumption. But the cons of silicon is that it's really hard to verify. So, you 595 00:42:09,750 --> 00:42:13,529 know, open source doesn't help that verification and Hard IP blocks are tough 596 00:42:13,529 --> 00:42:17,269 problems we talked about earlier. So FPGAs on the other side, they offer some 597 00:42:17,269 --> 00:42:20,320 immediate mitigation paths. We don't have to wait until we solve this verification 598 00:42:20,320 --> 00:42:25,049 problem. We can inspect the bit streams, we can randomize the logic mapping and we 599 00:42:25,049 --> 00:42:30,029 can do per device unique pin mapping. It's not perfect, but it's better than I think 600 00:42:30,029 --> 00:42:34,529 any other solution I can offer right now. The cons of it is that FPGAs are just 601 00:42:34,529 --> 00:42:37,959 barely good enough to do this today. So you need a little bit of external RAM 602 00:42:37,959 --> 00:42:42,219 which needs to be encrypted, but 100 megahertz speed performance and about five 603 00:42:42,219 --> 00:42:47,529 to 10x the power consumption of a custom silicon solution, which in a mobile device 604 00:42:47,529 --> 00:42:51,849 is a lot. But, you know, actually part of the reason, the main thing that drives the 605 00:42:51,849 --> 00:42:55,799 thickness in this is the battery, right? And most of that battery is for the FPGA. 606 00:42:55,799 --> 00:43:01,490 If we didn't have to go with an FPGA it could be much, much thinner. So now let's 607 00:43:01,490 --> 00:43:05,019 talk a little about the last two points, user-sealable keys, and verification and 608 00:43:05,019 --> 00:43:08,369 protection. And this is that third point, "empowering end users to verify and seal 609 00:43:08,369 --> 00:43:13,349 their hardware". So it's great that we can verify something but can it keep a secret? 610 00:43:13,349 --> 00:43:15,910 No, transparency is good up to a point, but you want to be able to keep secrets so 611 00:43:15,910 --> 00:43:19,569 that people won't come up and say: oh, there's your keys, right? So sealing a key 612 00:43:19,569 --> 00:43:23,969 in the FPGA, ideally we want user generated keys that are hard to extract, 613 00:43:23,969 --> 00:43:28,479 we don't rely on a central keying authority and that any attack to remove 614 00:43:28,479 --> 00:43:32,910 those keys should be noticeable. So any high level apps, I mean, someone with 615 00:43:32,910 --> 00:43:37,220 infinite funding basically should take about a day to extract it and the effort 616 00:43:37,220 --> 00:43:40,499 should be trivially evident. The solution to that is basically self provisioning and 617 00:43:40,499 --> 00:43:45,009 sealing of the cryptographic keys in the bit stream and a bit of epoxy. So let's 618 00:43:45,009 --> 00:43:49,719 talk a little bit about provisioning those keys. If we look at the 7-series FPGA 619 00:43:49,719 --> 00:43:56,131 security, they offer a sort of encrypted HMAC 256-AES, with 256-bit SHA bit 620 00:43:56,131 --> 00:44:02,170 streams. There's a paper which discloses a known weakness in it, so the attack takes 621 00:44:02,170 --> 00:44:06,499 about a day or 1.6 million chosen cipher text traces. The reason why it takes a day 622 00:44:06,499 --> 00:44:09,650 is because that's how long it takes to load in that many chosen ciphertexts 623 00:44:09,650 --> 00:44:13,940 through the interfaces. The good news is there's some easy mitigations to this. You 624 00:44:13,940 --> 00:44:16,910 can just glue shut the JTAG-port or improve your power filtering and that 625 00:44:16,910 --> 00:44:21,599 should significantly complicate the attack. But the point is that it will take 626 00:44:21,599 --> 00:44:24,109 a fixed amount of time to do this and you have to have direct access to the 627 00:44:24,109 --> 00:44:28,750 hardware. It's not the sort of thing that, you know, someone at customs or like an 628 00:44:28,750 --> 00:44:33,369 "evil maid" could easily pull off. And just to put that in perspective, again, 629 00:44:33,369 --> 00:44:37,940 even if we improved dramatically the DPA- resistance of the hardware, if we knew a 630 00:44:37,940 --> 00:44:41,830 region of the chip that we want to inspect, probably with the SEM in it and a 631 00:44:41,830 --> 00:44:45,140 skilled technician, we could probably pull it off in a matter of a day or a couple of 632 00:44:45,140 --> 00:44:49,019 days. Takes only an hour to decap the silicon, you know, an hour for a few 633 00:44:49,019 --> 00:44:52,642 layers, a few hours in the FIB to delayer a chip, and an afternoon in the the SEM 634 00:44:52,642 --> 00:44:57,780 and you can find out the keys, right? But the key point is that, this is kind of the 635 00:44:57,780 --> 00:45:03,709 level that we've agreed is OK for a lot of the silicon enclaves, and this is not 636 00:45:03,709 --> 00:45:07,440 going to happen at a customs checkpoint or by an evil maid. So I think I'm okay with 637 00:45:07,440 --> 00:45:11,150 that for now. We can do better. But I think that's it's a good starting point, 638 00:45:11,150 --> 00:45:14,839 particularly for something that's so cheap and accessible. So then how do we get 639 00:45:14,839 --> 00:45:17,730 those keys in FPGA and how do we keep them from getting out? So those keys should be 640 00:45:17,730 --> 00:45:21,100 user generated, never leave device, not be accessible by the CPU after it's 641 00:45:21,100 --> 00:45:24,299 provisioned, be unique per device. And it should be easy for the user to get it 642 00:45:24,299 --> 00:45:28,170 right. It should be. You don't have to know all the stuff and type a bunch 643 00:45:28,170 --> 00:45:35,339 commands to do it, right. So if you look inside Betrusted there's two rectangles 644 00:45:35,339 --> 00:45:39,319 there, one of them is the ROM that contains a bit stream, the other one is 645 00:45:39,319 --> 00:45:43,399 the FPGA. So we're going to draw those in the schematic form. Inside the ROM, you 646 00:45:43,399 --> 00:45:47,589 start the day with an unencrypted bit stream in ROM, which loads an FPGA. And 647 00:45:47,589 --> 00:45:50,859 then you have this little crypto engine. There's no keys on the inside. There's no 648 00:45:50,859 --> 00:45:53,859 anywhere. You can check everything. You can build your own bitstream, and do what 649 00:45:53,859 --> 00:45:59,309 you want to do. The crypto engine then generates keys from a TRNG that's located 650 00:45:59,309 --> 00:46:02,829 on chip. Probably some help of some off- chip randomness as well, because I don't 651 00:46:02,829 --> 00:46:06,779 necessarily trust everything inside the FPGA. Then that crypto engine can go ahead 652 00:46:06,779 --> 00:46:12,009 and, as it encrypts the external bit stream, inject those keys back into the 653 00:46:12,009 --> 00:46:15,329 bit stream because we know where that block-RAM is. We can go ahead and inject 654 00:46:15,329 --> 00:46:19,789 those keys back into that specific RAM block as we encrypt it. So now we have a 655 00:46:19,789 --> 00:46:26,089 sealed encrypted image on the ROM, which can then load the FPGA if it had the key. 656 00:46:26,089 --> 00:46:28,809 So after you've gone ahead and provisioned the ROM, hopefully at this point you don't 657 00:46:28,809 --> 00:46:35,660 lose power, you go ahead and you burn the key into the FPGA's keying engine which 658 00:46:35,660 --> 00:46:40,609 sets it to only boot from that encrypted bit stream, blow out the readback- 659 00:46:40,609 --> 00:46:45,409 disabled-bit and the AES-only boot is blown. So now at this point in time, 660 00:46:45,409 --> 00:46:48,829 basically there's no way to go ahead and put in a bit stream that says tell me your 661 00:46:48,829 --> 00:46:52,079 keys, whatever it is. You have to go and do one of these hard techniques to pull 662 00:46:52,079 --> 00:46:56,930 out the key. You can maybe enable hardware upgrade path if you want by having the 663 00:46:56,930 --> 00:47:00,959 crypto and just be able to retain a copy of the master key and re-encrypt it, but 664 00:47:00,959 --> 00:47:04,529 that becomes a vulnerability because the user can be coerced to go ahead and load 665 00:47:04,529 --> 00:47:08,240 inside a bit stream that then leaks out the keys. So if you're really paranoid at 666 00:47:08,240 --> 00:47:13,720 some point in time, you seal this thing and it's done. You know, you have to go 667 00:47:13,720 --> 00:47:18,109 ahead and do that full key extraction routine to go ahead and pull stuff out if 668 00:47:18,109 --> 00:47:21,999 you forget your passwords. So that's the sort of user-sealable keys. I think we can 669 00:47:21,999 --> 00:47:27,729 do that with FPGA. Finally, easy to verify and easy to protect. Just very quickly 670 00:47:27,729 --> 00:47:31,119 talking about this. So if you want to make an expectable tamper barrier, a lot of 671 00:47:31,119 --> 00:47:34,619 people have talked about glitter seals. Those are pretty cool, right? The problem 672 00:47:34,619 --> 00:47:39,490 is, I find that glitter seals are too hard to verify. Right. Like, I have tried 673 00:47:39,490 --> 00:47:42,660 glitter-seals before and I stare at the thing and I'm like: Damn, I have no idea 674 00:47:42,660 --> 00:47:45,489 if this is the seal I put down. And so then I say, ok, we'll take a picture or 675 00:47:45,489 --> 00:47:50,079 write an app or something. Now I'm relying on this untrusted device to go ahead and 676 00:47:50,079 --> 00:47:55,700 tell me if the seal is verified or not. So I have a suggestion for a DIY watermark 677 00:47:55,700 --> 00:47:59,629 that relies not on an app to go and verify, but our very, very well tuned 678 00:47:59,629 --> 00:48:03,089 neural networks inside our head to go ahead and verify things. So the idea is 679 00:48:03,089 --> 00:48:08,350 basically, there's this nice epoxy that I found. It comes in this Bi-packs, 2 part 680 00:48:08,350 --> 00:48:12,319 epoxy, you just put on the edge of a table and you go like this and it goes ahead and 681 00:48:12,319 --> 00:48:17,249 mixes the epoxy and you're ready to use. It's very easy for users to apply. And 682 00:48:17,249 --> 00:48:21,039 then you just draw a watermark on a piece of tissue paper. It turns out humans are 683 00:48:21,039 --> 00:48:25,260 really good at identifying our own handwriting, our own signatures, these 684 00:48:25,260 --> 00:48:28,359 types of things. Someone can go ahead and try to forge it. There's people who are 685 00:48:28,359 --> 00:48:32,579 skilled in doing this, but this is way easier than looking at a glitter-seal. You 686 00:48:32,579 --> 00:48:36,539 go ahead and put that down on your device. You swab on the epoxy and at the end of 687 00:48:36,539 --> 00:48:41,119 day, you end up with a sort of tissue paper plus a very easily recognizable 688 00:48:41,119 --> 00:48:44,501 seal. If someone goes ahead and tries to take this off or tamper with it, I can 689 00:48:44,501 --> 00:48:47,980 look at it easy and say, yes, this is a different thing than what I had yesterday, 690 00:48:47,980 --> 00:48:50,749 I don't have to open an app, I don't have to look at glitter patterns, I don't have 691 00:48:50,749 --> 00:48:54,229 to do these sorts of things. And I can go ahead and swab onto all the I/O-ports that 692 00:48:54,229 --> 00:49:01,869 need to do. So it's a bit of a hack, but I think that it's a little closer towards 693 00:49:01,869 --> 00:49:09,900 not having to rely on third party apps to verify a tamper evidence seal. So I've 694 00:49:09,900 --> 00:49:16,249 talked about sort of this implementation and also talked about how it maps to these 695 00:49:16,249 --> 00:49:20,859 three principles for building trustable hardware. So the idea is to try to build a 696 00:49:20,859 --> 00:49:25,729 system that is not too complex so that we can verify most the parts or all of them 697 00:49:25,729 --> 00:49:29,829 at the end-user point, look at the keyboard, look at the display and we can 698 00:49:29,829 --> 00:49:35,930 go ahead and compile the FPGA from source. We're focusing on verifying the entire 699 00:49:35,930 --> 00:49:40,459 system, the keyboard and the display, we're not forgetting the user. They secret 700 00:49:40,459 --> 00:49:43,199 starts with the user and ends with the user, not with the edge of the silicon. 701 00:49:43,199 --> 00:49:47,939 And finally, we're empowering end-users to verify and seal their own hardware. You 702 00:49:47,939 --> 00:49:52,049 don't have to go through a central keying authority to go ahead and make sure 703 00:49:52,049 --> 00:49:56,730 secrets are are inside your hardware. So at the end of the day, the idea behind 704 00:49:56,730 --> 00:50:01,460 Betrusted is to close that hardware time of check/time of use gap by moving the 705 00:50:01,460 --> 00:50:07,690 verification point closer to the point of use. So in this huge, complicated 706 00:50:07,690 --> 00:50:12,329 landscape of problems that we can have, the idea is that we want to, as much as 707 00:50:12,329 --> 00:50:19,279 possible, teach users to verify their own stuff. So by design, it's meant to be a 708 00:50:19,279 --> 00:50:23,249 thing that hopefully anyone can be taught to sort of verify and use, and we can 709 00:50:23,249 --> 00:50:27,520 provide tools that enable them to do that. But if that ends up being too high of a 710 00:50:27,520 --> 00:50:31,920 bar, I would like it to be within like one or two nodes in your immediate social 711 00:50:31,920 --> 00:50:35,550 network, so anyone in the world can find someone who can do this. And the reason 712 00:50:35,550 --> 00:50:41,240 why I kind of set this bar is, I want to sort of define the maximum level of 713 00:50:41,240 --> 00:50:45,330 technical competence required to do this, because it's really easy, particularly 714 00:50:45,330 --> 00:50:48,999 when sitting in an audience of these really brilliant technical people to say, 715 00:50:48,999 --> 00:50:52,210 yeah, of course everyone can just hash things and compile things and look at 716 00:50:52,210 --> 00:50:55,499 things in microscopes and solder and then you get into life and reality and then be 717 00:50:55,499 --> 00:51:01,019 like: oh, wait, I had completely forgotten what real people are like. So this tries 718 00:51:01,019 --> 00:51:06,770 to get me grounded and make sure that I'm not sort of drinking my own Kool-Aid in 719 00:51:06,770 --> 00:51:11,719 terms of how useful open hardware is as a mechanism to verify anything. Because I 720 00:51:11,719 --> 00:51:14,459 hand a bunch of people schematics and say, check this and they'll be like: I have no 721 00:51:14,459 --> 00:51:22,459 idea. So the current development status is that: The hardware is kind of an initial 722 00:51:22,459 --> 00:51:27,969 EVT stage for types subject to significant change, particularly part of the reason 723 00:51:27,969 --> 00:51:31,589 we're here is talking about this is to collect more ideas and feedback on this, 724 00:51:31,589 --> 00:51:35,869 to make sure we're doing it right. The software is just starting. We're writing 725 00:51:35,869 --> 00:51:40,809 our own OS called Xous, being done by Sean Cross, and we're exploring the UX and 726 00:51:40,809 --> 00:51:44,180 applications being done by Tom Marble shown here. And I actually want to give a 727 00:51:44,180 --> 00:51:48,891 big shout out to NLnet for funding us partially. We have a grant, a couple of 728 00:51:48,891 --> 00:51:52,559 grants for under privacy and trust enhancing technologies. This is really 729 00:51:52,559 --> 00:51:57,309 significant because now we can actually think about the hard problems, and not 730 00:51:57,309 --> 00:52:00,260 have to be like, oh, when do we go crowdfunded, when do we go fundraising. 731 00:52:00,260 --> 00:52:04,030 Like a lot of time, people are like: This looks like a product, can we sell this 732 00:52:04,030 --> 00:52:10,849 now? It's not ready yet. And I want to be able to take the time to talk about it, 733 00:52:10,849 --> 00:52:15,780 listen to people, incorporate changes and make sure we're doing the right thing. So 734 00:52:15,780 --> 00:52:18,900 with that, I'd like to open up the floor for Q&A. Thanks to everyone, for coming to 735 00:52:18,900 --> 00:52:20,400 my talk. 736 00:52:20,400 --> 00:52:29,299 *Applause* 737 00:52:29,299 --> 00:52:32,239 Herald: Thank you so much, bunnie, for the great talk. We have about five minutes 738 00:52:32,239 --> 00:52:36,130 left for Q&A. For those who are leaving earlier, you're only supposed to use the 739 00:52:36,130 --> 00:52:40,480 two doors on the left, not the one, not the tunnel you came in through, but only 740 00:52:40,480 --> 00:52:44,769 the doors on the left back, the very left door and the door in the middle. Now, Q&A, 741 00:52:44,769 --> 00:52:49,310 you can pile up at the microphones. Do we have a question from the Internet? No, not 742 00:52:49,310 --> 00:52:54,170 yet. If someone wants to ask a question but is not present but in the stream, or 743 00:52:54,170 --> 00:52:57,790 maybe a person in the room who wants to ask a question, you can use the hashtag 744 00:52:57,790 --> 00:53:01,849 #Clark and Twitter. Mastodon and IRC are being monitored. So let's start with 745 00:53:01,849 --> 00:53:04,489 microphone number one. Your question, please. 746 00:53:04,489 --> 00:53:10,169 Q: Hey, bunnie. So you mentioned that with the foundry process that the Hard IP- 747 00:53:10,169 --> 00:53:16,569 blocks, the prototyped IP-blocks are a place where attacks could be made. Do you 748 00:53:16,569 --> 00:53:22,469 have the same concern about the Hard IP blocks in the FPGA, either the embedded 749 00:53:22,469 --> 00:53:27,559 block RAM or any of the other special features that you might be using? 750 00:53:27,559 --> 00:53:34,059 bunnie: Yeah, I think that we do have to be concerned about implants that have 751 00:53:34,059 --> 00:53:40,630 existed inside the FPGA prior to this project. And I think there is a risk, for 752 00:53:40,630 --> 00:53:44,930 example, that there's a JTAG-path that we didn't know about. But I guess the 753 00:53:44,930 --> 00:53:49,229 compensating side is that the military, U.S. military does use a lot of these in 754 00:53:49,229 --> 00:53:52,869 their devices. So they have a self- interest in not having backdoors inside of 755 00:53:52,869 --> 00:54:01,280 these things as well. So we'll see. I think that the answer is it's possible. I 756 00:54:01,280 --> 00:54:07,549 think the upside is that because the FPGA is actually a very regular structure, 757 00:54:07,549 --> 00:54:11,099 doing like sort of a SEM-level analysis, of the initial construction of it at 758 00:54:11,099 --> 00:54:15,220 least, is not insane. We can identify these blocks and look at them and make 759 00:54:15,220 --> 00:54:18,880 sure the right number of bits. That doesn't mean the one you have today is the 760 00:54:18,880 --> 00:54:22,759 same one. But if they were to go ahead and modify that block to do sort of the 761 00:54:22,759 --> 00:54:26,920 implant, my argument is that because of the randomness of the wiring and the 762 00:54:26,920 --> 00:54:29,839 number of factors they have to consider, they would have to actually grow the 763 00:54:29,839 --> 00:54:34,779 silicon area substantially. And that's a thing that is a proxy for detection of 764 00:54:34,779 --> 00:54:38,459 these types of problems. So that would be my kind of half answer to that problem. 765 00:54:38,459 --> 00:54:41,269 It's a good question, though. Thank you. Herald: Thanks for the question. The next 766 00:54:41,269 --> 00:54:46,069 one from microphone number three, please. Yeah. Move close to the microphone. 767 00:54:46,069 --> 00:54:50,969 Thanks. Q: Hello. My question is, in your proposed 768 00:54:50,969 --> 00:54:56,459 solution, how do you get around the fact that the attacker, whether it's an implant 769 00:54:56,459 --> 00:55:01,609 or something else, will just attack it before they user self provisioning so 770 00:55:01,609 --> 00:55:04,769 it'll compromise a self provisioning process itself? 771 00:55:04,769 --> 00:55:13,009 bunnie: Right. So the idea of the self provisioning process is that we send the 772 00:55:13,009 --> 00:55:18,509 device to you, you can look at the circuit boards and devices and then you compile 773 00:55:18,509 --> 00:55:23,630 your own FPGA, which includes a self provisioning code from source and you can 774 00:55:23,630 --> 00:55:26,339 confirm, or if you don't want to compile, you can confirm that the signatures match 775 00:55:26,339 --> 00:55:30,049 with what's on the Internet. And so someone wanting to go ahead and compromise 776 00:55:30,049 --> 00:55:34,390 that process and so stash away some keys in some other place, that modification 777 00:55:34,390 --> 00:55:40,400 would either be evident in the bit stream or that would be evident as a modification 778 00:55:40,400 --> 00:55:44,230 of the hash of the code that's running on it at that point in time. So someone would 779 00:55:44,230 --> 00:55:49,710 have to then add a hardware implant, for example, to the ROM, but that doesn't help 780 00:55:49,710 --> 00:55:52,229 because it's already encrypted by the time it hits the ROM. So it'd really have to be 781 00:55:52,229 --> 00:55:55,539 an implant that's inside the FPGA and then trammel's question just sort of talked 782 00:55:55,539 --> 00:56:01,609 about that situation itself. So I think the attack surface is limited at least for 783 00:56:01,609 --> 00:56:05,549 that. Q: So you talked about how the courier 784 00:56:05,549 --> 00:56:11,809 might be a hacker, right? So in this case, you know, the courier would put a 785 00:56:11,809 --> 00:56:17,719 hardware implant, not in the Hard IP, but just in the piece of hardware inside the 786 00:56:17,719 --> 00:56:21,519 FPGA that provisions the bit stream. bunnie: Right. So the idea is that you 787 00:56:21,519 --> 00:56:26,529 would get that FPGA and you would blow your own FPGA bitstream yourself. You 788 00:56:26,529 --> 00:56:30,339 don't trust my factory to give you a bit stream. You get the device. 789 00:56:30,339 --> 00:56:34,209 Q: How do you trust that the bitstream is being blown. You just get indicate your 790 00:56:34,209 --> 00:56:36,609 computer's saying this bitstream is being blown. 791 00:56:36,609 --> 00:56:40,109 bunnie: I see, I see, I see. So how do you trust that the ROM actually doesn't have a 792 00:56:40,109 --> 00:56:43,499 backdoor in itself that's pulling in the secret bit stream that's not related to 793 00:56:43,499 --> 00:56:52,839 him. I mean, possible, I guess. I think there are things you can do to defeat 794 00:56:52,839 --> 00:56:58,640 that. So the way that we do the semi randomness in the compilation is that 795 00:56:58,640 --> 00:57:02,599 there's a random 64-Bit random number we compile into the bit stream. So we're 796 00:57:02,599 --> 00:57:07,099 compiling our own bitstream. You can read out that number and see if it matches. At 797 00:57:07,099 --> 00:57:13,039 that point, if someone had pre burned a bit stream onto it that is actually loaded 798 00:57:13,039 --> 00:57:16,499 instead of your own bit stream, it's not going to be able to have that random 799 00:57:16,499 --> 00:57:21,309 number, for example, on the inside. So I think there's ways to tell if, for 800 00:57:21,309 --> 00:57:24,539 example, the ROM has been backdoored and it has two copies of the ROM, one of the 801 00:57:24,539 --> 00:57:27,399 evil one and one of yours, and then they're going to use the evil one during 802 00:57:27,399 --> 00:57:31,169 provisioning, right? I think that's a thing that can be mitigated. 803 00:57:31,169 --> 00:57:33,779 Herald: All right. Thank you very much. We take the very last question from 804 00:57:33,779 --> 00:57:39,309 microphone number five. Q: Hi, bunnie. So one of the options you 805 00:57:39,309 --> 00:57:44,569 sort of touched on in the talk but then didn't pursue was this idea of doing some 806 00:57:44,569 --> 00:57:49,769 custom silicon in a sort of very low-res process that could be optically inspected 807 00:57:49,769 --> 00:57:51,769 directly. bunnie: Yes. 808 00:57:51,769 --> 00:57:55,950 Q: Is that completely out of the question in terms of being a usable route in the 809 00:57:55,950 --> 00:58:00,099 future or, you know, did you look into that and go to detail at all? 810 00:58:00,099 --> 00:58:05,069 bunnie: So I thought about that when there's a couple of issues: 1) Is that if 811 00:58:05,069 --> 00:58:10,109 we rely on optical verification now, users need optical verification prior to do it. 812 00:58:10,109 --> 00:58:14,209 So we have to somehow move those optical verification tools to the edge towards 813 00:58:14,209 --> 00:58:17,559 that time of use. Right. So nice thing about the FPGA is everything I talked 814 00:58:17,559 --> 00:58:20,869 about building your own midstream, inspecting the bit stream, checking the 815 00:58:20,869 --> 00:58:27,279 hashes. Those are things that don't require particular sort of user equipment. 816 00:58:27,279 --> 00:58:32,219 But yes, if we if we were to go ahead and build like an enclave out of 500 817 00:58:32,219 --> 00:58:36,369 nanometers, silicon like it probably run around 100 megahertz, you'd have a few 818 00:58:36,369 --> 00:58:40,960 kilobytes of RAM on the inside. Not a lot. Right. So you have a limitation in how 819 00:58:40,960 --> 00:58:47,499 much capability you have on it and would consume a lot of power. But then every 820 00:58:47,499 --> 00:58:52,710 single one of those chips. Right. We put them in a black piece of epoxy. How do you 821 00:58:52,710 --> 00:58:55,420 like, you know, what keeps someone from swapping that out with another chip? 822 00:58:55,420 --> 00:58:58,009 Q: Yeah. I mean, I was I was thinking of like old school, transparent top, like on 823 00:58:58,009 --> 00:59:00,109 a lark. bunnie: So, yeah, you can go ahead and 824 00:59:00,109 --> 00:59:03,599 wire bond on the board, put some clear epoxy on and then now people have to take 825 00:59:03,599 --> 00:59:11,009 a microscope to look at that. That's a possibility. I think that that's the sort 826 00:59:11,009 --> 00:59:15,049 of thing that I think I am trying to imagine. Like, for example, my mom using 827 00:59:15,049 --> 00:59:19,640 this and asking her do this sort of stuff. I just don't envision her knowing anyone 828 00:59:19,640 --> 00:59:22,719 who would have an optical microscope who could do this for except for me. Right. 829 00:59:22,719 --> 00:59:29,089 And I don't think that's a fair assessment of what is verifiable by the end user. At 830 00:59:29,089 --> 00:59:33,599 the end of the day. So maybe for some scenarios it's OK. But I think that the 831 00:59:33,599 --> 00:59:37,599 full optical verification of a chip and making that sort of the only thing between 832 00:59:37,599 --> 00:59:42,589 you and implant, worries me. That's the problem with the hard chip is that 833 00:59:42,589 --> 00:59:46,589 basically if someone even if it's full, you know, it's just to get a clear thing 834 00:59:46,589 --> 00:59:51,699 and someone just swapped out the chip with another chip. Right. You still need to 835 00:59:51,699 --> 00:59:55,699 know, a piece of equipment to check that. Right. Whereas like when I talked about 836 00:59:55,699 --> 00:59:58,652 the display and the fact that you can look at that, actually the argument for that is 837 00:59:58,652 --> 01:00:01,660 not that you have to check the display. It's that you don't it's actually because 838 01:00:01,660 --> 01:00:04,700 it's so simple. You don't need to check the display. Right. You don't need the 839 01:00:04,700 --> 01:00:07,809 microscope to check it, because there is no place to hide anything. 840 01:00:07,809 --> 01:00:11,169 Herald: All right, folks, we ran out of time. Thank you very much to everyone who 841 01:00:11,169 --> 01:00:14,319 asked a question. And please give another big round of applause to our great 842 01:00:14,319 --> 01:00:17,319 speaker, bunnie. Thank you so much for the great talk. Thanks. 843 01:00:17,319 --> 01:00:18,319 *Applause* 844 01:00:18,319 --> 01:00:20,869 bunnie: Thanks everyone! 845 01:00:20,869 --> 01:00:23,796 *Outro* 846 01:00:23,796 --> 01:00:46,000 Subtitles created by c3subtitles.de in the year 2020. Join, and help us!