Open Source is Insufficient to Solve Trust Problems in Hardware
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
bunnie
Cross, Sean "xobs"
Marble, Tom
While open source is necessary for trustable hardware, it is far from sufficient. This is because “hashing” hardware – verifying its construction down to the transistor level – is typically a destructive process, so trust in hardware is a massive time-of-check/time-of-use (TOCTOU) problem. This talk helps us understand the nature of the TOCTOU problem by providing a brief overview of the supply chain security problem and various classes of hardware implants. We then shift gears to talk about ways to potentially close the TOCTOU gap, concluding with a curated set of verifiable components that we are sharing as an open source mobile communications platform – a kind of combination hardware and software distribution – that we hope can be useful for developing and deploying all manner of open platforms that require a higher level of trust and security. The inconvenient truth is that open source hardware is precisely as trustworthy as closed source hardware. The availability of design source only enables us to agree that the designer’s intent can be trusted and is likely correct, but there is no essential link between the hardware design source and the piece of hardware on your desk. Thus while open source is necessary for trustable hardware, it is far from sufficient. This is quite opposite from the case of open source software thanks to projects like Reproducible Builds, where binaries can be loaded in-memory and cryptographically verified and independently reproduced to ensure a match to the complete and corresponding source of a particular build prior to execution, thus establishing a robust link between the executable and the source. Unfortunately, “hashing” hardware – verifying its construction down to the transistor level – is typically a destructive process, so trust in hardware is a massive time-of-check/time-of-use (TOCTOU) problem. Even if you thoroughly inspect the design source, the factory could modify the design. Even if you audit the factory, the courier delivering the hardware to your desk could insert an implant. Even if you carried the hardware from the factory to your desk, an “evil maid” could modify your machine. This creates an existential crisis for trust – how can we know our secrets are safe if the very hardware we use to compute them could be readily tainted? This talk addresses the elephant in the room by helping us understand the nature of the TOCTOU problem by providing a brief overview of the supply chain security problem and various classes of hardware implants. We then shift gears to talk about ways to potentially close the TOCTOU gap. When thinking about hardening a system against supply chain attacks, every component – from the CPU to the keyboard to the LCD – must be considered in order to defend against implanted screen grabbers and key loggers. At every level, a trade-off exists between complexity and the feasibility of non-destructive end-user verification with minimal tooling: a system simple enough to be readily verified will not have the equivalent compute power or features of a smartphone. However, we believe that a verifiable system should have adequate performance for a select range of tasks that include text chats, cryptocurrency wallets, and voice calls. Certain high-risk individuals such as politicians, journalists, executives, whistleblowers, and activists may be willing to use a device that forgoes bells and whistles in exchange for privacy and security. With this in mind, the <>Betrusted project brings together a curated set of verifiable components as an open source mobile communications platform - a combination open source hardware and software distribution. We are sharing Betrusted with the community in the hopes that others may adopt it as a reference design for developing and deploying all manner of open platforms that require a higher level of trust and security.
 Welcome everybody for our very first talk on the first day of Congress. The talk is open source is insufficient to solve trust problems and hardware. Although there is a lot to be said for free and open software, it is unfortunately not always inherently more secure than proprietary or close software. The same goes for hardware as well. This talk will take us into the nitty gritty bits of how to build trustable hardware and how it has to be implemented and brought together with the software in order to be secure. We have one speaker here today. It's Bunny. He is a hardware and film hacker. But actually the talk was worked on by three people. So it's not just Bunny but also Sean Zobbs Cross and Tom Marble. The other two are not present today. But I would like you to welcome our speaker Bunny with a big warm round of applause and have a lot of fun. Good morning everybody. Thanks for braving the crowds and making it into the Congress. And thank you again to the Congress for giving me the privilege to address the Congress again this year. Very exciting being the first talk of the day. Had front problems. I'm running from a PDF backup. So we'll see how this all goes. Good thing I make backups. So the topic of today's talk is open source is insufficient to solve trust problems and hardware and sort of some things we can do about this. So my background is I'm a big proponent of open source hardware. I love it. And I've built a lot of things in open source using open source hardware principles. But there's been sort of a nagging question to me about like some people would say things like oh well you know you build open source hardware because you can trust it more. And there's been sort of this gap in my head and this talk tries to distill out that gap in my head between trust and open source and hardware. So I'm sure people have opinions on which browsers you would think is more secure or trustable than the others. But the question is why might you think one is more trustable than the others. You have everything from Firefox and Iced Weasel down to the Samsung custom browser or the Xiaomi custom browser. Which one would you rather use for your browsing if you had to trust something. So I'm sure people have their biases and they might say that open is more trustable. But why do we say open is more trustable. Is it because we actually read the source thoroughly and check it every single release for this browser. Is it because we compile our source our browsers from source before we use them. No actually we don't have the time to do that. So let's take a closer look as to why we like to think that open source software is more secure. So this is a kind of a diagram of a life cycle of say a software project. You have a bunch of developers on the left. They'll commit code into some source management program like Git. It goes to a build and then ideally some person who carefully manages a key signs that build goes into an untrusted cloud. Then gets done load on users disks pulled into RAM run by the user at the end of the day. Right. So the reason why actually we find that we might be able to trust things more is because in the case of open source anyone can pull down that source code like someone doing reproducible builds or an audit of some type build it confirm that the hashes match and that the keys are all set up correctly. And then the users also have the ability to know developers and sort of enforce community norms and standards upon them to make sure that they're acting in sort of in the favor of the community. So in the case that we have bad actors who want to go ahead and tamper with builds and clouds and all the things in the middle it's much more difficult. So open is more trustable because we have tools to transfer trust in software. Things like hashing things like public keys things like Merkel trees right and also in the case of open versus closed we have social networks that we can use to reinforce our community standards for trust and security. Now it's worth looking a little bit more into the hashing mechanism because this is a very important part about the software trust chain. So I'm sure a lot of people know what hashing is for people who don't know. It basically takes a big pile of bits and turns them into a short sequence of symbols so that a tiny change in the big pile of bits makes a big change in the output symbols and also knowing those symbols doesn't reveal anything about the original file. So in this case here the file on the left is hashed to sort of cat mouse panda bear and the file on the right hashes to peach snake pizza cookie. And the thing is as you may not even have noticed necessarily that there was that one bit changed up there but it's very easy to see that short string of symbols had changed so you don't actually have to go through that whole file and look for that needle in the haystack you have this hash function that tells you something has changed very quickly. Then once you've computed the hashes we have a process called signing where a secret key is used to encrypt the hash uses decrypt that using the public key to compare against a locally computed hash. We're not trusting the server to compute the hash we reproduce it on our side and then we can say that it's now difficult to modify that file or the signature without detection. Now the problem is that there's a time of check, time of use issue with the system even though we have this mechanism if we decouple the point of check from the point of use it creates a man in the middle opportunity or person in the middle if you want. The thing is that it's a class of attacks that allows someone to tamper with data as it is in transit. I'm kind of symbolizing this evil guy because hackers all wear hoodies and they also keep us warm as well in very cold places. So now an example of a time of check, time of use issue is that if say a user downloads a copy of the program onto their disk and they just check it after they download it to the disk and they say okay great that's fine later on an adversary can then modify the file on the disk as before it's copied to RAM and now actually the user even though they download the correct version of file they're getting the wrong version into the RAM. So the key point is the reason why in software we feel it's more trustable is we have a tool to transfer trust and ideally we place that point of check as close to the user as possible. So ideally we're sort of putting keys into the CPU or some secure enclave that just before you run it you've checked that that software is perfect and has not been modified. Now an important clarification is that it's actually more about the place of check versus the place of use whether you checked one second prior or a minute prior doesn't actually matter. It's more about checking the copy that's closest to the thing that's running it. We don't call it Pockpoo because it just doesn't have quite the same ring to it. But now this is important. The reason why I emphasize place of check versus place of use is this is why hardware is not the same as software in terms of trust. The place of check is not the place of use or in other words trust and hardware is a talk to problem all the way down the supply chain. So the hard problem is how do you trust your computers? So we have problems where we have firmware, pervasive hidden bits of code that are inside every single part of your system that can break abstractions and there's also the issue of hardware implants so it's tampering or adding components that can bypass security in ways that we're not according to the specification that you're building around. So from the firmware standpoint, it's more here to acknowledge as an issue. The problem is this is actually a software problem. The good news is we have things like openness and runtime verification that go away to remedy these questions. If you're a big enough player or you have enough influence or something, you can coax out all the firmware blobs and eventually sort of solve that problem. The bad news is that you're still relying on the hardware to obediently run the verification. So if your hardware isn't running the verification correctly, it doesn't matter that you have all the source code for the firmware, which brings us to the world of hardware implants. So very briefly, it's worth thinking about how bad can this get? What are we worried about? What is the field if we really want to be worried about trust and security? How bad can it be? So I've spent many years trying to deal with supply chains. They're not friendly territory. There's a lot of reasons people want to screw with the chips in the supply chain. For example, here, this is a small ST microcontroller. It claims to be a secure microcontroller. Someone was like, ah, this is not secure. It's not behaving correctly. We digest off the top of it. On the inside, it's an LCX244 buffer. This was not done because someone wanted to tamper with the secure microcontroller. It's because someone wanted to make a quick buck. But the point is that that marking on the outside is convincing. You could have been any chip on the inside in that situation. Another problem that I've had personally is I was building a robot controller board that had an FPGA on the inside. We manufactured a thousand of these. And about 3% of them weren't passing tests. Set them aside. Later on, I pulled these units that weren't passing tests and looked them very carefully. And I noticed that all of the units, the FPGA units that weren't passing tests, had that white rectangle on them, which is shown in a more zoomed-in version. It turned out that underneath that white rectangle were the letters ES for engineering sample. So someone had gone in and laser blasted off the letters, which say that's an engineering sample, which means they're not qualified for regular production, blended them into the supply chain at a 3% rate, and managed to essentially double their profit at the other day. The reason why this works is because distributors make a small amount of money. So even a few percent actually makes them a lot more profit at the end of the day. But the key takeaway of this is just because 97% of your hardware is OK, it does not mean that you're safe. So it doesn't help to take one sample out of your entire set of hardware and say, oh, this is good. This is constructed correctly. Therefore, all of them should be good. That's a talk-to problem. 100% hardware verification is mandatory if you're worried about trust and verification. So let's go a bit further down the rabbit hole. This is a diagram, sort of an ontology of supply chain attacks. And I've kind of divided it into two axes. On the vertical axis is how easy is it to detect or how hard. So on the bottom, you might need a SEM, a scanning electron microscope, to do it. In the middle is an X-ray, a little specialized. And on the top is just visual or JTAG, like anyone can do it at home. And then from left to right is execution difficulty. Things are going to take millions of dollars in months. Things are going to take 10,000 weeks or a dollar in seconds. There's sort of several broad classes I've kind of outlined here. Adding components is very easy. Substitute components is very easy. We don't have enough time to really go into those. But instead, we're going to talk about kind of the two more scary ones, which are sort of adding a chip inside a package and IC modification. So let's talk about adding a chip in a package. This one has sort of grabbed a bunch of headlines. So there's sort of these in the Snowden files. We found these like NSA implants where they had put chips literally inside of connectors and other chips to modify the computer's behavior. Now it turns out that actually adding a chip in a package is quite easy. It happens every day. This is a routine thing. If you take open any SD card, micro SD card that you have, you're going to find that has two chips on the inside at the very least. One is a controller chip. One is a memory chip. In fact, they can stick 16, 17 chips inside of these packages today very handily. And so if you want to go ahead and find these chips, is the solution to go ahead and X-ray all the things? You just take every single circuit board and throw inside of an X-ray machine. Well this is what a circuit board looks like in the X-ray machine. Some things are very obvious. So on the left we have our ethernet magnetic jacks. And there's a bunch of stuff on the inside. Turns out those are all OK. Don't worry about those. And on the right we have our chips. And this one here, you may be sort of tempted to look and say, oh, I see this big sort of square thing on the bottom there. That must be the chip. It actually turns out that's not the chip at all. That's the solder pad that holds the chip in place. You can't actually see the chip because the solder is massing it inside the X-ray. So when we're looking at a chip inside of an X-ray, I've kind of given you a little key guide here. And the left is what it looks like, sort of in 3D. And the right is what it looks like in X-ray. Sort of looking from the top down, you're looking at ghostly outlines with very thin spirey wires coming out of it. So if you were to look at a chip and chip on an X-ray, this is actually an image of a chip. So the cross section, you can see there's several pieces of silicon that are stacked in top of each other. And if you could actually do an edge on X-ray of it, this is what you would see, unfortunately you'd have to take the chip off the board to do the edge on X-ray. So what you do is you have to look at it from the top down. And when you look at it from the top down, all you see are basically some straight wires. Like, I can't, it's not obvious from that top down X-ray whether you're looking at multiple chips, eight chips, one chip, how many chips are on the inside of that because the wire bonds all stitch perfectly and overlap over the chip. So this is what the chip and chip scenario might look like. You have a chip that's sitting on top of a chip and wire bonds just sort of going a little bit further on from the edge. And so in the X-ray, the only kind of difference you see is a slightly longer wire bond in some cases. So it's actually, it's not, you can find these, but it's not like obvious that you've found it implant or not. So looking for silicon's heart, silicon is relatively transparent to X-rays. A lot of things, masquot, copper traces, solder, mass the presence of silicon. This is like another example of a wire bonded chip under an X-ray. There's some mitigations. If you have a lot of money, you can do computerized tomography. It'll build up the 3D image of the chip. You can do X-ray diffraction spectroscopy, but it's not a foolproof method. And so basically the threat of wire bond package is actually a very well understood commodity technology. It's actually quite cheap. I was actually doing some wire bonding in China the other day. This is a wire bonding machine. I looked up the price of $7,000 for a used one. And you basically just walk into the guy with a picture of where you want the bonds to go. He sort of picks them out, programs the machine's motion once, and he just plays it back over and over again. So if you want to go ahead and modify a chip and add a wire bond, it's not as crazy as it sounds. The mitigation is that this is a bit detectable inside X-rays. So let's go down the rabbit hole a little further. So there's another concept I want to throw at you, it's called the through silicon via. So this here is a cross section of a chip. On the bottom is the base chip. And the top is a chip that's only 0.1 to 0.2 millimeters thick, almost the width of a human hair. And they actually have drilled via through the chip so you have circuits on the top and circuits on the bottom. So this is kind of used as sort of putting an interposer in between different chips. Also used to stack DRAM and HBM. So this is a commodity process. It's available today. It's not science fiction. And the second concept I want to throw you is a thing called a wafer level chip scale package, WLCSP. This is actually a very common method for packaging chips today. Basically it's solder balls directly on top of chips. They're everywhere. If you look inside of like an iPhone, basically almost all the chips are WLCSP package types. Now if we were to take the wafer level chip scale package and cross section and look at it, it looks like a circuit board with some solder balls and the silicon itself with some backside passivation. If you go ahead and combine this with a through silicon via implant, a man in the middle attack using through silicon via, this is what it looks like at the other day. You basically have a piece of silicon that's the size of the original silicon sitting on the original pads in basically all the right places with the solder balls masking the presence of that chip. So it's actually basically a nearly undetectable implant if you want to execute it. If you go ahead and look at the edge of the chip, they already have seams on the side. So you can't even just look at the side and say, oh, I see a seam on a chip. Therefore it's a problem. The seam on the edge, a lot of times it's because they have different coatings on the back or passivations, these types of things. So if you really want to sort of say, OK, how well can we hide an implant? This is probably the way I would do it. It's logistically actually easier than a wire bond implant because you don't have to get the chips in wire bondable format. You literally just buy them off the internet. You can just clean off the solder balls with a hot air gun. And then the hard part is building that through silicon via template for doing the attack, which will take some hundreds of thousands of dollars to do and probably a mid-end fab. But if you have almost no budget constraint and you have a set of chips that are common and you want to build a template for, this could be a pretty good way to hide an implant inside of a system. So that's sort of adding chips inside packages. Let's talk a bit about chip modification itself. So how hard is it to modify the chip itself? Let's say we've managed to eliminate the possibility someone's added chip, but what about the chip itself? And this sort of goes out. A lot of people have said, hey, buddy, why don't you spin like an open source silicon processor? This will make it trustable, right? This is not a problem. Well, let's think about the attack surface of IC fabrication processes. So on the left-hand side here, I've got kind of a flow chart of what IC fabrication looks like. You start with a high-level chip design. It's an RTL, like Verilog, DHDL, these days now Python. You go into some back-end. You have a decision to make. Do you own your back-end tooling or not? And so we'll go into this a little bit more. If you don't, you trust the fab to compile it and assemble it. If you do, you assemble the chip with some blanks for what's called hard IP. We'll get into this. And then you trust the fab to assemble that, make masks, and go to mass production. So there's three areas that I think are kind of ripe for tampering. Netlist tampering, hard IP tampering, and mass tampering. We'll go into each of those. So netlist tampering, you might, a lot of people think that, of course, if you wrote the RTL, you're going to make the chip. It turns out that's actually kind of a minority case. We hear about that. That's on the right-hand side, called customer-owned tooling. That's when the customer does the full flow down to the mass set. The problem is it costs $7 million and a lot of extra head count of very talented people to produce these. And we usually only do it for flagship products, like CPUs and GPUs, high-end routers, these sorts of things. Most, I would say, most chips tend to go more towards what's called an ASIC side, application-specific integrated circuit. What happens is that the customer will do some RTL, maybe a high-level floor plan. And then the silicon foundry or service will go ahead and do the place and route, the IP integration, the paddling. This is quite popular for cheap support chips, like your baseband management controller inside your server. Probably went to this flow. Disk controllers will probably go through this flow. Mid to Ion, Ion controllers. All those peripheral chips that we don't like to think about, that can handle our data, probably go through a flow like this. And to give you an idea of how common it is, but how little you've heard of it, there's a company called Sock Ion Next. They're a billion-dollar company, actually. You've probably never heard of them. And they offer services where basically you can just throw a spec over the wall and they'll build a chip to you, all the way to the point where you've done logic synthesis and physical design. And then they'll go ahead and do the manufacturing and test and sample shipment for it. So then, OK, fine. Obviously, if you care about trust, you don't do an ASIC flow. You're pawning up the millions of dollars and you do a cop flow, right? Well, there is a weakness in cop flows, and this is called the hard IP problem. So this here on the right-hand side is an amoeba plot of the standard cells alongside a piece of SRAM. I'll highlight this here. The image wasn't great for presentation, but this region here is the SRAM block. And all those little colorful blocks are standard cells representing your AND gates and AND gates and that sort of stuff, right? What happens is that the Foundry will actually ask you just to leave an open spot on your mass design and they'll go ahead and merge in the RAM into that spot just before production. The reason why they do this is because stuff like RAM is a carefully guarded trade secret. If you can increase the RAM density of your Foundry process, you can get a lot more customers. There's a lot of know-how in it. And so Foundry's tend not to want to share the RAM. You can compile your own RAM. There are open RAM projects, but their performance and their density is not as good as the Foundry specific ones. So in terms of hard IP, what are the blocks that tend to be hard IP? Stuff like RF and analog. So your phase lock loops, your ADCs, your DAX, your band gaps. RAM tends to be hard IP. ROM tends to hard IP. EFUSE that stores your keys is going to give into you as an opaque block. The pad ring around your chip, the thing that protects your chip from ESD, that's going to be an opaque block. Basically, all the points you need to backdoor your RTL are going to be trusted to the Foundry in a modern process. So, OK, let's say, fine, we're going to go ahead and build all of our own IP blocks as well. We're going to compile our RAMs, do our own I.O. Everything, right? So we're safe, right? Well, it turns out that masks can be tampered with post-processing. So if you're going to do anything in a modern process, the mask designs change quite dramatically from what you drew them to what actually ends up in the line. They get fractured into multiple masks. They have resolution correction techniques applied to them. And then they always go through an editing phase, right? So masks are not born perfect, right? Masks have defects on the inside. And so you can look up papers about how they go, and they inspect the mask every single line on the inside. When they find an error, they'll go ahead and patch over it. They'll go ahead and add bits of metal, and then take away bits of glass to go ahead and make that mask perfect, or better in some way, if you have access to the editing capability, right? So what can you do with mask editing? Well, there's a lot of papers that have been written on this. You can look up ones on, for example, dopant tampering. This one actually has no morphological change. You can't look at it under a microscope and detect dopant tampering. You have to have something and do some, either you have to do some wet chemistry or some extra spectroscopy to figure it out. And this allows for circuit level change without a gross morphological change to the circuit. And so this can allow for tampering with things like RNGs, some logic paths. There are oftentimes spare cells inside of your ASIC, because everyone makes mistakes, including chip designers. And so you want to patch over that. That can be done at the mask level, signal bypassing these types of things. So there are some attacks that can still happen at the mask level. So that's a very quick sort of idea of how bad can it get when you talk about the time of check time to use trust problem inside the supply chain. So a short summary of implants is that there's a lot of places to hide them. Not all of them are expensive or hard. I talked about some of the more expensive or hard one. But remember, wire bonding is actually a pretty easy process. It's not hard to do. And it's hard to detect. And there's really no actual essential correlation between detection difficulty and difficulty in attack if you're very careful in planning the attack. So implants are possible. Let's agree on that, maybe. So now the solution is we should just have trustable factories. Let's go ahead and bring the fabs to the EU. Let's have a fab in my backyard or whatever it is, these types of things. Let's make sure all the workers are logged and registered, that sort of thing. Well, let's talk about that. So if you think about hardware, there's you, right? And then we can talk about evil maids. But let's not actually talk about those, because that's actually kind of a minority case to worry about. But let's think about how stuff gets to you. There's a distributor who goes to a courier who gets to you. All right, so we've gone and done all this stuff for the trustable factory. But it's actually documented that couriers have been intercepted and implants loaded, by for example, the NSA on Cisco products. Now you don't even have to have access to couriers now, thanks to the way modern commerce works. Other customers can go ahead and just buy a product, tamper with it, seal it back in the box, send it back to your distributor, and then maybe you get one, right? That can be good enough, particularly if you know a corporation is a particular area you're targeting them, you buy a bunch of hard drives from the area, seal them up, send them back, and eventually when them ends up in the right place, then you've got your implant, right? So there's a great talk last year at 35C3. I recommend you check it out. That talks a little bit more about the scenario, sort of removing tamper stickers and the possibility that some crypto wallets were sent back into supply chain that they've been tampered with. And then let's take that back. We have to now worry about the wonderful people in customs. We have to worry about the people in the factory who have access to your hardware. And so if you cut to the chase, it's a huge attack surface in terms of the supply chain, right? From you to the courier to the distributor, customs, box build, the box build factory itself oftentimes will use gray market resources to help make themselves a little more profitable, right? You have distributors who go to them who you don't even know who those guys are, PCB assembly, components, boards, chip fad, packaging, the whole thing, right? Every single point is a place where someone can go ahead and touch a piece of hardware along the chain. So can open source save us in this scenario? Does open hardware solve this problem, right? Let's think about it. Let's go ahead and throw some developers with Git on the left-hand side. How far does it get, right? Well, we can have some continuous integration checks that make sure that the hardware is correct. We can have some open PCB designs. We can have some open PDK. But then from that point, it goes into a rather opaque machine. And then, okay, maybe we can put some tests on the very edge before exit the factory to try and catch some potential issues, right? But you can see all the area of other places where sort of a time of check to time of use problem can happen. And this is why I'm saying that open hardware on its own is not sufficient to solve this trust problem, right? And the big problem at the other day is that you can't hash hardware, right? There is no hash function for hardware. This is why I wanted to go through that earlier today. There's no convening easy way to basically confirm the correctness of your hardware before you use it. Some people say, well, Bonnie said once, oh, it's a bigger microscope, right? This is a, you know, I do some security reverse engineering stuff. This is true, right? So there's a wonderful technique called tachographic X-ray imaging. There's a great paper and nature about it where they take like a modern I7 CPU and they get down to the gate level non-destructively with it, right? It's great for reverse engineering and for design verification. The problem number one is it literally needs a building size microscope. It was done at the Swiss light source. That donut-shaped thing is the size of the light source for doing that type of verification, right? So you're not going to have one at your point of use, right? You're going to check it there and then probably query it to yourself. Again, time of check is not time of use. Problem number two, it's expensive to do, so verifying one chip only verifies one chip. And as I said earlier, just because 99.9% of your hardware is okay, doesn't mean you're safe. Sometimes all it takes is one server of 1,000 to break some fundamental assumptions that you have about your cloud. And random sampling just isn't good enough, right? I mean, would you random sample signature checks on software that you install? Download? No, you insist 100% check on everything. If you want that same standard of reliability, you have to do that for hardware. So then is there any role for open source and trustable hardware? Absolutely yes. Some of you guys may be familiar with it. A little guy on the right, the Spectre logo. So correctness is very, very hard. Your review can help fix correctness bugs, microarchitectural transparency can aid with the fixes and specter-like situations. So for example, we would love to be able to say we're entering a critical region, let's turn off all the microarchitectural optimizations, sacrifice performance, and then run the code securely and then go back into who cares what mode and just get done fast, right? That would be a switch I would love to have, but without that sort of transparency or without the ability to review it, we can't do that. Also community-driven features and community-owned designs is very empowering and make sure that we're sort of building the right hardware for the job and that it's upholding our standards. So there is a role. It's necessary, but it's not sufficient for trustable hardware. So now the question is, okay, can we solve the point of use hardware verification problem? Is it all gloom and doom from here on? Well, I didn't bring you guys here to tell you it's just gloom and doom. I've thought about this and I've kind of boiled it into three principles for building verifiable hardware. Three principles are that complexity is the enemy of verification. We should verify entire systems, not just components, and we need to empower end users to verify and seal their hardware. We'll go into this in the remainder of the talk. So the first one is that complexity is complicated, right? So without a hashing function, verification rolls back to bit by bit or atom by atom verification. So those modern phones just have so many components, even if I gave you the full source code for the sock inside of a phone down to the mass level, what are you going to do with it, right? How are you going to know that this mass actually matches the chip and those two haven't been modified, right? So more complexity, it's more difficult. So okay, the solution is let's go to simplicity, right? Let's just build things from discrete transistors. Someone's done this, the Monster 6502 is great. I love the project. Very easy to verify, runs at 50 kilohertz, right? So you're not going to do a lot with that. Okay, well, let's build processes that are visually inspectable processes. So let's go to 500 nanometers, you can see that with light. Okay, well, you know, 100 megahertz clock rate and a very high power consumption and you know, a couple of kilobytes of RAM probably is not going to really do it either, right? So the point of use verification is a trade off between ease of verification and features and usability, right? So these two products up here largely do the same thing, AirPods, right? And headphones on your head, right? AirPods have something on the order of tens of millions of transistors for you to verify. The headphone that goes on your head, like I can actually go to Maxwell's Equations and actually tell you how the magnets work from very first principles and there's probably one transistor on the inside of the microphone to go ahead and amplify the membrane and that's it, right? So this one, you do sacrifice some features and usability when you go to a headset, like you can't say, hey Siri and they'll listen to you and know what you're doing, but it's very easy to verify and know what's going on. So in order to start a dialogue on user verification, we have to sort of set a context. So I started a project called Be Trusted because the right answer depends on the context. I want to establish what might be a minimum viable, verifiable product and it's sort of like meant to be used verifiable by design and we think of it as a hardware software distro. So it's meant to be modified and changed and customized based upon the right context at the end of the day. This is a picture of what it looks like, I actually have a little prototype here, very, very, very early prototype here at the Congress if you want to look at it. It's a mobile device that is meant for sort of communication, sort of text-based communication and maybe voice. Authentication, so authenticated tokens or like a crypto wallet if you want. And the people we're thinking about who might be users are either high value targets politically or financially, so you don't have to have a lot of money to be a high value target, you could also be very politically risky for some people. And also of course looking at developers and enthusiasts and ideally we're thinking about a global demographic, not just English speaking users which is sort of a thing, when you think about the complexity standpoint this is where we really have to sort of champ at the bit and figure out how to solve a lot of hard problems like getting Unicode and right to left rendering and pictographic fonts to work inside a very small tax surface device. So this leads me to the second point which we need to verify entire systems is not just components. You'll say well why don't you just build a chip? Why not, you know, why are you thinking about a whole device? The problem is that private keys are not your private matters. Screens can be scraped and keyboards can be logged. So there's some efforts now to build wonderful security enclaves like Keystone and OpenTitan which will build wonderful secure chips. The problem is that even if you manage to keep your keys secret you still have to get that information through an insecure CPU from the screen to the keyboard and so forth. And so people who have used these on screen touch keyboards have probably seen a message like this saying that by the way this keyboard can see everything you're typing including your passwords and people probably clip and say oh yeah sure whatever I trust that. Well this little enclave on the site here isn't really doing a lot of good when you go ahead and you say sure I'll run this input method that can go ahead and modify all my data or intercept all my data. So in terms of making a device variable let's talk about the concept of practice flow. How do I take these three principles and turn them into something? So this is the ideal of taking these three requirements and turning it into the set of five features, a physical keyboard, a black and white LCD, an FPGA based RISC-5 SOC, user-seable keys and something that's easy to verify and physically protect. So let's talk about these features one by one. First one is a physical keyboard. Why am I using a physical keyboard and not a virtual keyboard? People love the virtual keyboards. The problem is that cap touch screens which is necessary to do a good virtual keyboard have a firmware block. They have a microcontroller to do the touch screen. It's actually really hard to build these things. If you can do a good Java and build an open source one that'd be great but that's a project in and of itself. So in order to sort of get an easy one here and we can let's just go with a physical keyboard. So this is what the device looks like with this cover off. We have a physical keyboard PCB with a little overlay that does you know so you can do multi-lingual inserts and you just can go ahead and change that out. And it's just a two-layer daughter card. Just hold up to the light and you're like okay, switches, wires, right? Not a lot of places to hide things. So I'll take that as an easy win for an input surface that's verifiable, right? The output surface is a little more subtle so we're doing a black and white LCD. If you say okay, why not use a color LCD? If you ever take apart a liquid crystal display, look for a tiny little thin rectangle sort of located near the display area. That's actually a silicon chip that's bonded to the glass. That's what it looks like at the other day. That contains a frame buffer and a command interface. It has millions of transitions on the inside and you don't know what it does. So if you're already assuming your adversary may be tamping with your CPU, this is also a viable place you have to worry about. So I found a screen. It's called a memory LCD by Sharp Electronics. It turns out they do all the drive electronics on glass. So this is a picture of the drive electronics on the screen through like a 50X microscope with a bright light behind it. You can actually see the transistors that are used to drive everything on the display. It's a non-destructive method of verification. But actually more important to the point is that there are so few places to hide things you probably don't need to check it. If you wanted to add an implant to this, you would need to grow the glass area substantially or add a silicon chip, which is a thing that you'll notice. So at the end of the day, the less places to hide things is less need to check things. So I can feel like this is a screen where I can write data to and it will show what I want to show. The good news is that the display has a 200-pPI pixel density. So even though it's black and white, it's closer to e-paper, e-PD, in terms of resolution. So now we come to the hard part, the CPU, the silicon problem. Any chip built in the last two decades is not going to be fully inspectable with an optical microscope. Right? Thorough analysis requires removing layers and layers of metal and dielectric. This is sort of a cross-section of a modern-ish chip. You can see the huge stack of things to look at on this. This process is destructive and you can think of it as hashing, but it's a little bit too literal. We want something where we can check the thing that we're going to use and then not destroy it. So I spent quite a bit of time thinking about options for non-destructive silicon verification to best come up with maybe using optical felt induction somehow, combined with some chip design techniques to go ahead and scan a laser across and look at fault syndromes and figure out, you know, does the thing do the gates that we put down correspond to the thing that I built. The problem is I couldn't think of a strategy to do it that wouldn't take years and tens of millions of dollars to develop, which puts it a little bit far out there and probably in the realm of venture-funded activities, which is not really going to be very empowering of everyday people. So I want something a little more short-term than that, than this sort of platonic ideal of verifiability. So the compromise that arrived at is the FPGA. So field-programmed gate arrays, that's what FPGA stands for, are large arrays of logic and wires that are user-configured to implement hardware designs. So this here is an image inside an FPGA design tool. On the top right is an example of one sort of logic subcell. It's got a few flip-flops and lookup tables in it, and it's embedded in this huge mass of wires that allow you to wire it up at runtime to figure out what's going on. And one thing that this diagram here shows is I'm able to sort of correlate design. I can see, okay, decode to XU instruction register bit 26 corresponds to this net. So now we're sort of like bringing that time of check a little bit closer to the time of use. And so the idea is to narrow that talk to gap by compiling your own CPU. We can basically give you the CPU from source, you can compile it yourself, you can confirm the bit stream. So now we're sort of enabling a bit more of that trust transfer-like software, right? But there's a subtlety in that the tool chains are not necessarily always open. There's some FOSS flows, like Simba flow. They have a 100% open flow for Iced 40 and ECP5. And there's like seven series where they have a coming soon status, but they currently require some close vendor tools. So picking an FPGA is a difficult choice. There's a usability versus verification trade off here. The big usability issue is battery life. If we're going for a mobile device, you want to use it all day long or you want to be dead by noon, it turns out that the best sort of chip in terms of battery life is a Spartan 7. It gives you 4X, roughly 3 to 4X in terms of battery life. But the tool flow is still semi-closed. But I am optimistic that Simba flow will get there. And we can also fork and make an ECP5 version if that's a problem at the end of the day. So let's talk a little bit more about sort of FPGA features. So one thing I like to say about FPGAs is they offer sort of ASLR, sort of address-based layout randomization, but for hardware. Essentially a design has a kind of pseudo random mapping to the device. This is a sort of a screenshot of two compilation runs of the same source code with a very small modification to it and basically a version number stored in a GPR. And then you can see that actually the locations of a lot of the registers have basically shifted around. The reason why this is important is because this hinders a significant class of silicon attacks. All those small mass level changes. I talked about the ones where we just say, okay, we're just going to change a few wires or run a couple logic cells around, those become more less likely to capture a critical bit. So if you want to go ahead and backdoor a full FPGA, you're going to have to change the die size. You have to make it substantially larger to be able to sort of like swap out the function in those cases. And so now the verification bar goes from looking for a needle in a haystack to measuring the size of the haystack, which is a bit easier to do towards the user side of things. And it turns out at least in Xilinx land, it's just a change in random parameter does a trick. So some potential attack vectors against FPGAs is like, okay, well, it's closed silicon. What are the backdoors there? Notably inside a seven series FPGAs, they actually document introspection features you can pull out anything inside the chip by instantiating a certain special block. And then we still also have to worry about the whole class of like man in the middle IO and JTAG implants that I talked about earlier. So this easy, really easy to mitigate the known blocks, basically lock them down, tie them down, check them in the bit stream, right? In terms of the IO man in the middle stuff, this is where we're talking about like someone goes ahead and puts a chip in the path of your FPGA. There's a few tricks we can do. We can do sort of bus encryption on the RAM and the ROM at the design level that frustrates these. At the implementation, basically we can use the fact that data pins and address pins can be permuted without affecting the devices function. So every design can go ahead and permute those data and address pin mappings sort of uniquely. So any particular implant that goes in will have to be able to compensate for all those combinations making the implant a little more difficult to do. And of course, we all can always fall back to sort of careful inspection of the device. In terms of the closed source silicon, the thing that I'm really optimistic for there is that so in terms of closed source system, the thing we have to worry about is that for example, now that Xilinx knows that we're doing these trustable devices using a tool chain, they push a patch that compiles backdoors into your bit stream. So not even a silicon level implant, but maybe the tool chain itself has a backdoor that recognizes that we're doing this. So the cool thing is in a very, this is a cool project, so there's a project called PRJ, actually Project Xray. It's part of the Symbolful effort. And they're actually documenting the full bit stream of the seven series device. It turns out that we don't yet know all the bit functions are, but the bit mappings are deterministic. So someone were to try and activate a backdoor in the bit stream through compilation. We can see it in a diff. We'd be like, well, we've never seen this bit flip before. What does this do? We can look into it and figure out if it's malicious or not. So there's actually sort of a hope that essentially at the end of the day, we can build sort of a bit stream checker. We can build a thing that says, here's a bit stream that came out. Does it correlate to the design source? Do all the bits check out? Do they make sense? And so ideally, we would come up with like a one click tool. And now we're at the point where the point of check is very close to the point of use. The users are now confirming that the CPUs are correctly constructed and mapped to the FPGA correctly. So the summary of FPGA versus custom silicon is sort of like the pros of custom silicon is that they have great performance. We can do a true single chip enclave with hundreds of megahertz speeds and tiny power consumption, but the con of silicon is that it's really hard to verify. So open source doesn't help that verification and hard IP blocks are tough problems we talked about earlier. So FPGAs on the other side, they offer some immediate mitigation paths. We don't have to wait until we solve this verification problem. We can inspect a bit streams. We can randomize the logic mapping. And we can do per device unique pin mapping. It's not perfect, but it's better than, I think, anything other solution I can offer right now. The cons of it is that the FPGAs are just barely good enough to do this today. So you need a little bit of external RAM, which needs to be encrypted, about 100 megahertz speed performance, and about 5 to 10 X the power consumption of a custom silicon solution, which in a mobile device is a lot, but we actually, part of the reason, the main thing that drives the thickness in this is the battery, right? And most of that battery is for the FPGA. If we didn't have to go with an FPGA, it could be much, much thinner. So now let's talk a little about the last two points, user feeble keys and verification and protection. And this is that third point, empowering end users to verify and seal their hardware. So it's great that we can verify something, but can it keep a secret? Transparency is good up to a point, but you want to be able to keep secrets so that people just welcome and say, oh, there's your keys, right? So sealing a key in the FPGA, ideally we want user generated keys that are hard to extract. We don't rely on a central key authority, and that any attack to remove those keys should be noticeable, right? So any high level apps, I mean, someone like infinite funding basically, should take about a day to extract it, and that effort should be trivially evident. The solution to that is basically self provisioning and sealing of the cryptographic keys in the bit stream and a bit of epoxy. So let's talk a little bit about, you know, sort of provisioning those keys. If we look at the seven series FPGA security, they offer sort of encrypted HMAC 256AS with 256 SHA bit streams. There's a paper which discloses a known weakness as it, so it's about, it takes, the, the attack takes about a day, 1.6 million chosen Cypher text traces. The reason why it takes a day is because that's how long it takes to load in that many chosen Cypher text through the, through the interfaces. The good news is there's some easy mitigations to this. You can just glue shut the JTAG port or improve your power filtering, and that should significantly complicate the attack. But the point is that it will take a fixed amount of time to do this, and you have to have direct access to the hardware. It's not the sort of thing that, you know, someone that customs or like an evil maid could easily pull off. And just to put that in perspective again, if, even if we improved dramatically the DPA resistance of the hardware, if we knew a region of the chip that we want to inspect, probably with a SEM and a, and a skill technician, we could probably pull it off in a matter of a day or a couple of days, takes only an hour to decap the silicon, you know, an hour or a few layers, a few hours in a fib to delay our chip in an afternoon in the SEM, and you can find out the keys, right? So, so, but the key point is that this is kind of the level that we've agreed is, is okay for, for, for a lot of the, the silicon enclaves, and this is not going to happen at a customs checkpoint or by an evil maid, so I think I'm, I'm okay with that for now. We can do better, but I think that's a, it's a good starting point, particularly for something that's so cheap and accessible. So then how do we get those keys in FPGA and how do you keep them from getting out? So those keys should be user generated, never leave the device, not accessible by the CPU after it's provisioned, unique per device, and it should be easy for the user to get it right. So you don't have to know all the stuff and type a bunch of commands to do it right, right? So if you look inside, be trusted. We have, there's two rectangles there. One of them is the ROM that contains the bitstream, and the other one's the FPGA. So I'm going to draw those in a schematic form. Inside the ROM, you start the day with an unencrypted bitstream in ROM, which loads in the FPGA, and then you have this little crypto engine that has no keys on the inside, there's no, there's no keys anywhere. So you can check everything, you can build your own bitstream, you can do what you want to do. The crypto engine then generates keys from a TRNG that's located on chip, probably some help with some off-chip randomness as well, because I don't necessarily trust everything inside the FPGA. Then that crypto engine can go ahead and as it encrypts the external bitstream, inject those keys back into the bitstream, because we know where that block RAM is. We can go ahead and inject those keys back into that specific RAM block as we encrypt it. So we have a sealed encrypted image on the ROM, which can then load, literally load in the FPGA if it had the key. So after you've gone ahead and provisioned the ROM, hopefully at this point you don't lose power, you go ahead and you burn the key into the FPGA's key engine, which sets it to only boot from that encrypted bitstream, blow out the, re-back the disabled bit and AS-only bit is blown. So now at this point in time, basically there's no way to go ahead and put in a bitstream that says, tell me your keys, whatever it is. You have to go do one of these hard techniques to pull out the key. You can maybe enable Hardware Upgrade Path if you want by having the crypto engines be able to retain a copy of the master key and re-encrypt it, but that becomes a vulnerability because the user can be coerced to go ahead and load inside a bitstream that then leaks out the keys. So if you're really paranoid at some point in time, you seal this thing and it's like done. You have to go ahead and do that full key extraction routine to go ahead and pull stuff out. If you forget your passwords. So that's the sort of user-sealable keys. I think we can do that with an FPGA. Finally easy to verify and easy to protect. Just very quickly talking about this. So if you want to make an inspectable tamper barrier, a lot of people have talked about glitter seals. Those are pretty cool, right? The problem is I find that glitter seals are too hard to verify, right? Like I have tried glitter seals before and I stared the thing and I'm like, damn it, I have no idea if this is the seal I put down. And so then say, okay, we'll take a picture or write an app or something. Now I'm relying on this untrusted device to go ahead and tell me if the seal is verified or not. So I have a suggestion for a DIY watermark that relies not on an app to go ahead and verify, but our very, very well-tuned neural networks inside our head to go ahead and verify things. So the idea is basically there's this nice epoxy that I found. It comes in this by-pack. It's a two-party epoxy. You just put it on the edge of the table and you go like this and it goes ahead and mixes the epoxy and you're ready to use. So it's very easy for users to apply. And then you just draw a watermark on a piece of tissue paper. It turns out humans are really good at identifying our own handwriting, right? Our own signatures, these types of things. Someone can go ahead and try to forge it. There's people who are skilled in doing this, but this is way easier than looking at a glitter seal. You go ahead and put that down on your device. You swab on the epoxy and at the end of the day you end up with a sort of tissue paper plus a very easily recognizable seal. Someone goes ahead and tries to take this off or tamper with it. I can look at it easy and say, yes, this is a different thing than what I had yesterday. I don't have to open an app. I don't have to look at glitter patterns. I don't have to do these sorts of things. And I can go ahead and swab on to all the IO ports they need to do. So it's a bit of a hack, but I think that it's a little closer towards not having to rely on third-party apps to verify a tamper evidence seal. So I've talked about sort of this implementation and also talked about how it maps to these three principles for building trustable hardware. So the idea is trying to build a system that is not too complex so that we can verify most of the parts or all of them at the end user point, look at the keyboard, look at the display, and we can go ahead and compile the FPGA from source. We're focusing on verifying the entire system end to end, so the keyboard and the display. We're not forgetting the user. The secrets start with the user and end with the user, not at the edge of the silicon. And finally, we're impiring end users to verify and seal their own hardware so you don't have to go to a central keying authority to go ahead and make sure your secrets are inside your hardware. So at the end of the day, the idea behind BeTrusted is to close that hardware time of check time of use gap by moving the verification point closer to the point of use. So in this huge complicated landscape of problems that we can have, the idea is that we want to as much as possible teach users to verify their own stuff. So by design, it's meant to be a thing that hopefully anyone can be taught to sort of verify and use and we can provide tools that enable them to do that. But if that ends up being too hard of a bar, I would like it to within one or two nodes in your immediate social network, anyone in the world can find someone who can do this. And the reason why I set this bar is I want to define the maximum level of technical competence required to do this. Because it's really easy, particularly sitting in an audience of this of really brilliant technical people, say, of course, everyone can just hash things and compile things and look at things on microscopes and solder it. And then you get into life and reality and like, oh, wait, I have completely forgotten what real people are like. So this tries to get me grounded and make sure that I'm not sort of drinking my own Kool-Aid in terms of how useful open hardware is as a mechanism to verify anything. Because a bunch of people schematic and say, check this, but you're like, I have no idea. So the current development status is that the hardware is kind of an initial EVT stage for a type subject to significant change, particularly part of the reason we're here talking about this is to collect more ideas and feedback on this, make sure we're doing it right. The software is just starting. We're writing our own OS called Zeus being done by Sean Cross. And we're exploring the UX and applications being done by Tom Marble shown here. And I actually want to give a big shout out to Enelnet for funding us partially. We have a couple of grants for underprivacy and trust enhancing technologies. And this is really significant because now we can actually think about the hard problems and not have to be like, oh, when do we go crowdfunded? When do we go fundraise? Like a lot of people are just like, oh, this looks like a product, right? Can we sell this now? It's not ready yet, right? And I want to be able to take the time to talk about it, listen to people, incorporate changes, and make sure we're doing the right thing. So with that, I'd like to open up the floor for Q&A. Thanks everyone for coming to my talk. Thank you so much, Bani, for the great talk. We have about five minutes left for Q&A. For those who are leaving earlier, you're only supposed to use the two doors on the left, not the one, not the tunnel you came in through, but only the doors on the left, like the very left door and the door in the middle. Now Q&A, you can pile up at the microphones. Do we have a question from the internet? No, not yet. If someone wants to ask a question but is not present, but in the stream or maybe a person in the room who wants to ask a question, you can use the hashtag Clark and Twitter, Masterland, and IRC are being monitored. So let's start with microphone number one. Your question, please. Hey, Bani. Hey. So you mentioned that with the Foundry process that the hard IP blocks, the proprietary IP blocks were a place where attacks could be made. Do you have the same concern about the hard IP blocks in the FPGA, either the embedded block RAM or any of the other special features that you might be using? Yeah, I think that we do have to be concerned about implants that have existed inside the FPGA prior to this project, right? I think there is a risk, for example, that there's a JTAG path we didn't know about. But the other, I guess the compensating side is that the military, US military does use a lot of these in their devices. So they have a self-interest in not having backdoors inside of these things as well, is sort of, we'll see. I think that the answer is it's possible. I think the upside is that because the FPGA is actually a very regular structure, it's doing sort of a sem level analysis of the initial construction of it at least is not insane. We can identify these blocks and look at them and make sure they're the right number of bits. That doesn't mean the one you have today is the same one. But if they were to go ahead and modify that block to do sort of the implant, my argument is that because of the randomness of the wiring and the number of factors they have to consider, they would have to actually grow the silicon area substantially and that's a thing that is a proxy for detection of these types of problems. So that would be my kind of half answer to that problem. It's a good question though. Thank you. Yeah, thanks for the question. Next one for microphone number three, please. Hi. Yeah, move close to the microphone. Thanks. Hello. My question is in your proposed solution, how do you get around the fact that the attacker, whether it's an implant or something else, will just attack it before the user's self-provisioning? So it'll compromise the self-provisioning process itself. Right. So the idea of the self-provisioning process is that is that... So we send the device to you, you can look at the circuit boards and devices and then you compile your own FPGA, which includes the self-provisioning code from source and you can confirm... Or if you don't want to compile, you can confirm that the signatures match with what's on the internet. Right. And so if someone wanted to go ahead and compromise that process and sort of stash away some keys in some other place, that modification would either be evident in the bit stream or that it would be evident as a modification of the hash of the code that's running on it at that point in time. So someone would have to then add a harder implant, for example, to the ROM, but that doesn't help because it's already encrypted by the time it hits the ROM, so it really has to be an implant that's inside the FPGA and then Traml's question just sort of talked about that situation itself. So I think the attack surface is limited at least for that. So you talked about how the courier might be the hacker, right? So in this case, the courier would put a hard-core implant not in the hard IP, but just in the piece of hardware inside the FPGA that provisions the bit stream. So the idea is that you would get that FPGA and you would blow your own FPGA bit stream yourself. You don't trust my factory to give you a bit stream. You get the device... You trust that the bit stream is being blown. You just get indicated on your computer saying this bit stream is being blown, right? I see. I see. So how do you trust that the ROM actually doesn't have a backdoor in itself that's putting another secret bit stream that's not related to... A problem for a courier or evil maid. Yeah, I mean, possible, I guess. I think there are things you can do, for example, to defeat that. So the way that we do the semi-randomness in the compilation is there's a 64-bit random number we compile into the bit stream. So if you're compiling your own bit stream, you can read out that number and see if it matches. At that point, if someone had pre-burned a bit stream onto it that they're sort of using to actually load it instead of your own bit stream, it's not going to be able to have that random number, for example, on the inside. So I think there's ways to tell if, for example, the ROM has been backdoored and it has two copies of the ROM, one of the evil one and one of yours, and then they're going to use the evil one during provisioning, right? I think that's a thing that can be mitigated. All right, thank you very much. We take the very last question from microphone number five. Hi, Bunny. Hi. So one of the options you sort of touched on in the talk but then didn't pursue was this idea of doing some custom silicon in a sort of very low-res process that could be optically inspected directly. Is that completely out of the question in terms of being a usable root in the future or did you look into that in great detail at all? So I thought about that one. There's a couple of issues. One is that if we rely on optical verification, now users need optical verification prior to do it. So we have to somehow move those optical verification tools to the edge towards the time of use, right? So nice thing about the FPGA is everything I talked about, building your own bit stream, inspecting the bit stream, checking the hashes, those are things that don't require particular sort of user equipment. But yes, if we were to go ahead and build like an enclave out of 500 nanometer silicon, like it probably run around 100 megahertz, you'd have a few kilobytes of RAM on the inside, not a lot, right? So you have a limitation in how much capability you have on it and would consume a lot of power. But then every single one of those chips, right, we put them in a black piece of epoxy. How do you, like, you know, what keeps someone from swapping that out with another chip? Yeah, I mean, I was thinking of like old school transparent top like on a little... Oh, okay. So yeah, you can go ahead and wire bond on the board, put some clear epoxy on, and then now people have to take a microscope to look at that. That's a possibility. I think that that's the sort of thing that I think I'm trying to imagine, like for example, my mom using this and asking her to do this sort of stuff. I just don't envision her knowing anyone who would have an optical microscope who could do this except for me, right? And I don't think that's a fair, you know, assessment of what is verifiable by the end user at the end of the day. So maybe for some scenarios it's okay, but I think that the full optical verification of a chip and making that sort of the only thing between you and an implant worries me. And that's the problem with the hard chip is that basically if someone, even if it's full, you know, it's just a clear thing and someone just swapped out the chip with another chip, right, you still need to know, you know, a piece of equipment to check that, right? Whereas like when I talked about the display and the fact that you can look at that, actually the argument for that is not that you have to check the display. It's that you don't, it's actually because it's so simple, you don't need to check the display, right? You don't need the microscope to check it because there's no place to hide anything. All right, folks, we ran out of time. Thank you very much to everyone who asked the question. And please give another big round of applause for our great speaker, Bunny. Thank you so much for the great talk. Thanks, everyone. Thanks, everyone.
 Welcome everybody for our very first talk on the first day of Congress.  The talk is open source is insufficient to solve trust problems and hardware.  Although there is a lot to be said for free and open software, it is unfortunately not  always inherently more secure than proprietary or close software.  The same goes for hardware as well.  This talk will take us into the nitty gritty bits of how to build trustable hardware and  how it has to be implemented and brought together with the software in order to be secure.  We have one speaker here today.  It's Bunny.  He is a hardware and film hacker.  But actually the talk was worked on by three people.  So it's not just Bunny but also Sean Zobbs Cross and Tom Marble.  The other two are not present today.  But I would like you to welcome our speaker Bunny with a big warm round of applause and  have a lot of fun.  Good morning everybody.  Thanks for braving the crowds and making it into the Congress.  And thank you again to the Congress for giving me the privilege to address the Congress again  this year.  Very exciting being the first talk of the day.  Had front problems.  I'm running from a PDF backup.  So we'll see how this all goes.  Good thing I make backups.  So the topic of today's talk is open source is insufficient to solve trust problems and  hardware and sort of some things we can do about this.  So my background is I'm a big proponent of open source hardware.  I love it.  And I've built a lot of things in open source using open source hardware principles.  But there's been sort of a nagging question to me about like some people would say things  like oh well you know you build open source hardware because you can trust it more.  And there's been sort of this gap in my head and this talk tries to distill out that gap  in my head between trust and open source and hardware.  So I'm sure people have opinions on which browsers you would think is more secure or  trustable than the others.  But the question is why might you think one is more trustable than the others.  You have everything from Firefox and Iced Weasel down to the Samsung custom browser or the  Xiaomi custom browser.  Which one would you rather use for your browsing if you had to trust something.  So I'm sure people have their biases and they might say that open is more trustable.  But why do we say open is more trustable.  Is it because we actually read the source thoroughly and check it every single release  for this browser.  Is it because we compile our source our browsers from source before we use them.  No actually we don't have the time to do that.  So let's take a closer look as to why we like to think that open source software is more  secure.  So this is a kind of a diagram of a life cycle of say a software project.  You have a bunch of developers on the left.  They'll commit code into some source management program like Git.  It goes to a build and then ideally some person who carefully manages a key signs that build  goes into an untrusted cloud.  Then gets done load on users disks pulled into RAM run by the user at the end of the  day.  Right.  So the reason why actually we find that we might be able to trust things more is because  in the case of open source anyone can pull down that source code like someone doing reproducible  builds or an audit of some type build it confirm that the hashes match and that the keys are  all set up correctly.  And then the users also have the ability to know developers and sort of enforce community  norms and standards upon them to make sure that they're acting in sort of in the favor  of the community.  So in the case that we have bad actors who want to go ahead and tamper with builds and  clouds and all the things in the middle it's much more difficult.  So open is more trustable because we have tools to transfer trust in software.  Things like hashing things like public keys things like Merkel trees right and also in  the case of open versus closed we have social networks that we can use to reinforce our  community standards for trust and security.  Now it's worth looking a little bit more into the hashing mechanism because this is a very  important part about the software trust chain.  So I'm sure a lot of people know what hashing is for people who don't know.  It basically takes a big pile of bits and turns them into a short sequence of symbols  so that a tiny change in the big pile of bits makes a big change in the output symbols and  also knowing those symbols doesn't reveal anything about the original file.  So in this case here the file on the left is hashed to sort of cat mouse panda bear and  the file on the right hashes to peach snake pizza cookie.  And the thing is as you may not even have noticed necessarily that there was that one  bit changed up there but it's very easy to see that short string of symbols had changed  so you don't actually have to go through that whole file and look for that needle in the  haystack you have this hash function that tells you something has changed very quickly.  Then once you've computed the hashes we have a process called signing where a secret key  is used to encrypt the hash uses decrypt that using the public key to compare against a  locally computed hash.  We're not trusting the server to compute the hash we reproduce it on our side and then  we can say that it's now difficult to modify that file or the signature without detection.  Now the problem is that there's a time of check, time of use issue with the system even  though we have this mechanism if we decouple the point of check from the point of use it  creates a man in the middle opportunity or person in the middle if you want.  The thing is that it's a class of attacks that allows someone to tamper with data as  it is in transit.  I'm kind of symbolizing this evil guy because hackers all wear hoodies and they also keep  us warm as well in very cold places.  So now an example of a time of check, time of use issue is that if say a user downloads  a copy of the program onto their disk and they just check it after they download it  to the disk and they say okay great that's fine later on an adversary can then modify  the file on the disk as before it's copied to RAM and now actually the user even though  they download the correct version of file they're getting the wrong version into the  RAM.  So the key point is the reason why in software we feel it's more trustable is we have a tool  to transfer trust and ideally we place that point of check as close to the user as possible.  So ideally we're sort of putting keys into the CPU or some secure enclave that just before  you run it you've checked that that software is perfect and has not been modified.  Now an important clarification is that it's actually more about the place of check versus  the place of use whether you checked one second prior or a minute prior doesn't actually  matter.  It's more about checking the copy that's closest to the thing that's running it.  We don't call it Pockpoo because it just doesn't have quite the same ring to it.  But now this is important.  The reason why I emphasize place of check versus place of use is this is why hardware  is not the same as software in terms of trust.  The place of check is not the place of use or in other words trust and hardware is a  talk to problem all the way down the supply chain.  So the hard problem is how do you trust your computers?  So we have problems where we have firmware, pervasive hidden bits of code that are inside  every single part of your system that can break abstractions and there's also the issue  of hardware implants so it's tampering or adding components that can bypass security  in ways that we're not according to the specification that you're building around.  So from the firmware standpoint, it's more here to acknowledge as an issue.  The problem is this is actually a software problem.  The good news is we have things like openness and runtime verification that go away to  remedy these questions.  If you're a big enough player or you have enough influence or something, you can coax  out all the firmware blobs and eventually sort of solve that problem.  The bad news is that you're still relying on the hardware to obediently run the verification.  So if your hardware isn't running the verification correctly, it doesn't matter that you have  all the source code for the firmware, which brings us to the world of hardware implants.  So very briefly, it's worth thinking about how bad can this get?  What are we worried about?  What is the field if we really want to be worried about trust and security?  How bad can it be?  So I've spent many years trying to deal with supply chains.  They're not friendly territory.  There's a lot of reasons people want to screw with the chips in the supply chain.  For example, here, this is a small ST microcontroller.  It claims to be a secure microcontroller.  Someone was like, ah, this is not secure.  It's not behaving correctly.  We digest off the top of it.  On the inside, it's an LCX244 buffer.  This was not done because someone wanted to tamper with the secure microcontroller.  It's because someone wanted to make a quick buck.  But the point is that that marking on the outside is convincing.  You could have been any chip on the inside in that situation.  Another problem that I've had personally is I was building a robot controller board that  had an FPGA on the inside.  We manufactured a thousand of these.  And about 3% of them weren't passing tests.  Set them aside.  Later on, I pulled these units that weren't passing tests and looked them very carefully.  And I noticed that all of the units, the FPGA units that weren't passing tests, had that  white rectangle on them, which is shown in a more zoomed-in version.  It turned out that underneath that white rectangle were the letters ES for engineering sample.  So someone had gone in and laser blasted off the letters, which say that's an engineering  sample, which means they're not qualified for regular production, blended them into  the supply chain at a 3% rate, and managed to essentially double their profit at the  other day.  The reason why this works is because distributors make a small amount of money.  So even a few percent actually makes them a lot more profit at the end of the day.  But the key takeaway of this is just because 97% of your hardware is OK, it does not mean  that you're safe.  So it doesn't help to take one sample out of your entire set of hardware and say, oh,  this is good.  This is constructed correctly.  Therefore, all of them should be good.  That's a talk-to problem.  100% hardware verification is mandatory if you're worried about trust and verification.  So let's go a bit further down the rabbit hole.  This is a diagram, sort of an ontology of supply chain attacks.  And I've kind of divided it into two axes.  On the vertical axis is how easy is it to detect or how hard.  So on the bottom, you might need a SEM, a scanning electron microscope, to do it.  In the middle is an X-ray, a little specialized.  And on the top is just visual or JTAG, like anyone can do it at home.  And then from left to right is execution difficulty.  Things are going to take millions of dollars in months.  Things are going to take 10,000 weeks or a dollar in seconds.  There's sort of several broad classes I've kind of outlined here.  Adding components is very easy.  Substitute components is very easy.  We don't have enough time to really go into those.  But instead, we're going to talk about kind of the two more scary ones, which are sort  of adding a chip inside a package and IC modification.  So let's talk about adding a chip in a package.  This one has sort of grabbed a bunch of headlines.  So there's sort of these in the Snowden files.  We found these like NSA implants where they had put chips literally inside of connectors  and other chips to modify the computer's behavior.  Now it turns out that actually adding a chip in a package is quite easy.  It happens every day.  This is a routine thing.  If you take open any SD card, micro SD card that you have, you're going to find that has  two chips on the inside at the very least.  One is a controller chip.  One is a memory chip.  In fact, they can stick 16, 17 chips inside of these packages today very handily.  And so if you want to go ahead and find these chips, is the solution to go ahead and X-ray  all the things?  You just take every single circuit board and throw inside of an X-ray machine.  Well this is what a circuit board looks like in the X-ray machine.  Some things are very obvious.  So on the left we have our ethernet magnetic jacks.  And there's a bunch of stuff on the inside.  Turns out those are all OK.  Don't worry about those.  And on the right we have our chips.  And this one here, you may be sort of tempted to look and say, oh, I see this big sort of  square thing on the bottom there.  That must be the chip.  It actually turns out that's not the chip at all.  That's the solder pad that holds the chip in place.  You can't actually see the chip because the solder is massing it inside the X-ray.  So when we're looking at a chip inside of an X-ray, I've kind of given you a little  key guide here.  And the left is what it looks like, sort of in 3D.  And the right is what it looks like in X-ray.  Sort of looking from the top down, you're looking at ghostly outlines with very thin  spirey wires coming out of it.  So if you were to look at a chip and chip on an X-ray, this is actually an image of a  chip.  So the cross section, you can see there's several pieces of silicon that are stacked  in top of each other.  And if you could actually do an edge on X-ray of it, this is what you would see, unfortunately  you'd have to take the chip off the board to do the edge on X-ray.  So what you do is you have to look at it from the top down.  And when you look at it from the top down, all you see are basically some straight wires.  Like, I can't, it's not obvious from that top down X-ray whether you're looking at multiple  chips, eight chips, one chip, how many chips are on the inside of that because the wire  bonds all stitch perfectly and overlap over the chip.  So this is what the chip and chip scenario might look like.  You have a chip that's sitting on top of a chip and wire bonds just sort of going a little  bit further on from the edge.  And so in the X-ray, the only kind of difference you see is a slightly longer wire bond in  some cases.  So it's actually, it's not, you can find these, but it's not like obvious that you've  found it implant or not.  So looking for silicon's heart, silicon is relatively transparent to X-rays.  A lot of things, masquot, copper traces, solder, mass the presence of silicon.  This is like another example of a wire bonded chip under an X-ray.  There's some mitigations.  If you have a lot of money, you can do computerized tomography.  It'll build up the 3D image of the chip.  You can do X-ray diffraction spectroscopy, but it's not a foolproof method.  And so basically the threat of wire bond package is actually a very well understood commodity  technology.  It's actually quite cheap.  I was actually doing some wire bonding in China the other day.  This is a wire bonding machine.  I looked up the price of $7,000 for a used one.  And you basically just walk into the guy with a picture of where you want the bonds to go.  He sort of picks them out, programs the machine's motion once, and he just plays it back over  and over again.  So if you want to go ahead and modify a chip and add a wire bond, it's not as crazy as  it sounds.  The mitigation is that this is a bit detectable inside X-rays.  So let's go down the rabbit hole a little further.  So there's another concept I want to throw at you, it's called the through silicon via.  So this here is a cross section of a chip.  On the bottom is the base chip.  And the top is a chip that's only 0.1 to 0.2 millimeters thick, almost the width of a  human hair.  And they actually have drilled via through the chip so you have circuits on the top  and circuits on the bottom.  So this is kind of used as sort of putting an interposer in between different chips.  Also used to stack DRAM and HBM.  So this is a commodity process.  It's available today.  It's not science fiction.  And the second concept I want to throw you is a thing called a wafer level chip scale  package, WLCSP.  This is actually a very common method for packaging chips today.  Basically it's solder balls directly on top of chips.  They're everywhere.  If you look inside of like an iPhone, basically almost all the chips are WLCSP package types.  Now if we were to take the wafer level chip scale package and cross section and look at  it, it looks like a circuit board with some solder balls and the silicon itself with some  backside passivation.  If you go ahead and combine this with a through silicon via implant, a man in the middle attack  using through silicon via, this is what it looks like at the other day.  You basically have a piece of silicon that's the size of the original silicon sitting on  the original pads in basically all the right places with the solder balls masking the presence  of that chip.  So it's actually basically a nearly undetectable implant if you want to execute it.  If you go ahead and look at the edge of the chip, they already have seams on the side.  So you can't even just look at the side and say, oh, I see a seam on a chip.  Therefore it's a problem.  The seam on the edge, a lot of times it's because they have different coatings on the  back or passivations, these types of things.  So if you really want to sort of say, OK, how well can we hide an implant?  This is probably the way I would do it.  It's logistically actually easier than a wire bond implant because you don't have to get  the chips in wire bondable format.  You literally just buy them off the internet.  You can just clean off the solder balls with a hot air gun.  And then the hard part is building that through silicon via template for doing the attack,  which will take some hundreds of thousands of dollars to do and probably a mid-end fab.  But if you have almost no budget constraint and you have a set of chips that are common  and you want to build a template for, this could be a pretty good way to hide an implant  inside of a system.  So that's sort of adding chips inside packages.  Let's talk a bit about chip modification itself.  So how hard is it to modify the chip itself?  Let's say we've managed to eliminate the possibility someone's added chip, but what about the chip  itself?  And this sort of goes out.  A lot of people have said, hey, buddy, why don't you spin like an open source silicon  processor?  This will make it trustable, right?  This is not a problem.  Well, let's think about the attack surface of IC fabrication processes.  So on the left-hand side here, I've got kind of a flow chart of what IC fabrication looks  like.  You start with a high-level chip design.  It's an RTL, like Verilog, DHDL, these days now Python.  You go into some back-end.  You have a decision to make.  Do you own your back-end tooling or not?  And so we'll go into this a little bit more.  If you don't, you trust the fab to compile it and assemble it.  If you do, you assemble the chip with some blanks for what's called hard IP.  We'll get into this.  And then you trust the fab to assemble that, make masks, and go to mass production.  So there's three areas that I think are kind of ripe for tampering.  Netlist tampering, hard IP tampering, and mass tampering.  We'll go into each of those.  So netlist tampering, you might, a lot of people think that, of course, if you wrote  the RTL, you're going to make the chip.  It turns out that's actually kind of a minority case.  We hear about that.  That's on the right-hand side, called customer-owned tooling.  That's when the customer does the full flow down to the mass set.  The problem is it costs $7 million and a lot of extra head count of very talented  people to produce these.  And we usually only do it for flagship products, like CPUs and GPUs, high-end  routers, these sorts of things.  Most, I would say, most chips tend to go more towards what's called an ASIC side,  application-specific integrated circuit.  What happens is that the customer will do some RTL, maybe a high-level floor plan.  And then the silicon foundry or service will go ahead and do the place and route,  the IP integration, the paddling.  This is quite popular for cheap support chips, like your baseband management  controller inside your server.  Probably went to this flow.  Disk controllers will probably go through this flow.  Mid to Ion, Ion controllers.  All those peripheral chips that we don't like to think about, that can handle  our data, probably go through a flow like this.  And to give you an idea of how common it is, but how little you've heard of it,  there's a company called Sock Ion Next.  They're a billion-dollar company, actually.  You've probably never heard of them.  And they offer services where basically you can just throw a spec over the wall  and they'll build a chip to you, all the way to the point where you've done  logic synthesis and physical design.  And then they'll go ahead and do the manufacturing and test and sample  shipment for it.  So then, OK, fine.  Obviously, if you care about trust, you don't do an ASIC flow.  You're pawning up the millions of dollars and you do a cop flow, right?  Well, there is a weakness in cop flows, and this is called the hard IP problem.  So this here on the right-hand side is an amoeba plot of the standard cells  alongside a piece of SRAM.  I'll highlight this here.  The image wasn't great for presentation, but this region here is the SRAM block.  And all those little colorful blocks are standard cells representing your  AND gates and AND gates and that sort of stuff, right?  What happens is that the Foundry will actually ask you just to leave an open  spot on your mass design and they'll go ahead and merge in the RAM into that  spot just before production.  The reason why they do this is because stuff like RAM is a carefully  guarded trade secret.  If you can increase the RAM density of your Foundry process,  you can get a lot more customers.  There's a lot of know-how in it.  And so Foundry's tend not to want to share the RAM.  You can compile your own RAM.  There are open RAM projects, but their performance and their density is not as  good as the Foundry specific ones.  So in terms of hard IP, what are the blocks that tend to be hard IP?  Stuff like RF and analog.  So your phase lock loops, your ADCs, your DAX, your band gaps.  RAM tends to be hard IP.  ROM tends to hard IP.  EFUSE that stores your keys is going to give into you as an opaque block.  The pad ring around your chip, the thing that protects your chip from  ESD, that's going to be an opaque block.  Basically, all the points you need to backdoor your RTL are going to be trusted  to the Foundry in a modern process.  So, OK, let's say, fine, we're going to go ahead and build all of our own IP blocks  as well.  We're going to compile our RAMs, do our own I.O.  Everything, right?  So we're safe, right?  Well, it turns out that masks can be tampered with post-processing.  So if you're going to do anything in a modern process,  the mask designs change quite dramatically from what you drew them to what  actually ends up in the line.  They get fractured into multiple masks.  They have resolution correction techniques applied to them.  And then they always go through an editing phase, right?  So masks are not born perfect, right?  Masks have defects on the inside.  And so you can look up papers about how they go,  and they inspect the mask every single line on the inside.  When they find an error, they'll go ahead and patch over it.  They'll go ahead and add bits of metal, and then take away bits of glass  to go ahead and make that mask perfect, or better in some way,  if you have access to the editing capability, right?  So what can you do with mask editing?  Well, there's a lot of papers that have been written on this.  You can look up ones on, for example, dopant tampering.  This one actually has no morphological change.  You can't look at it under a microscope and detect dopant tampering.  You have to have something and do some, either you have to do some wet chemistry  or some extra spectroscopy to figure it out.  And this allows for circuit level change without a gross morphological change  to the circuit.  And so this can allow for tampering with things like RNGs, some logic paths.  There are oftentimes spare cells inside of your ASIC,  because everyone makes mistakes, including chip designers.  And so you want to patch over that.  That can be done at the mask level, signal bypassing these types of things.  So there are some attacks that can still happen at the mask level.  So that's a very quick sort of idea of how bad can it get when you talk  about the time of check time to use trust problem inside the supply chain.  So a short summary of implants is that there's a lot of places to hide them.  Not all of them are expensive or hard.  I talked about some of the more expensive or hard one.  But remember, wire bonding is actually a pretty easy process.  It's not hard to do.  And it's hard to detect.  And there's really no actual essential correlation between detection difficulty  and difficulty in attack if you're very careful in planning the attack.  So implants are possible.  Let's agree on that, maybe.  So now the solution is we should just have trustable factories.  Let's go ahead and bring the fabs to the EU.  Let's have a fab in my backyard or whatever it is, these types of things.  Let's make sure all the workers are logged and registered, that sort of thing.  Well, let's talk about that.  So if you think about hardware, there's you, right?  And then we can talk about evil maids.  But let's not actually talk about those, because that's actually kind of a minority case  to worry about.  But let's think about how stuff gets to you.  There's a distributor who goes to a courier who gets to you.  All right, so we've gone and done all this stuff for the trustable factory.  But it's actually documented that couriers have been intercepted and implants loaded,  by for example, the NSA on Cisco products.  Now you don't even have to have access to couriers now, thanks to the way modern commerce  works.  Other customers can go ahead and just buy a product, tamper with it, seal it back in  the box, send it back to your distributor, and then maybe you get one, right?  That can be good enough, particularly if you know a corporation is a particular area  you're targeting them, you buy a bunch of hard drives from the area, seal them up, send  them back, and eventually when them ends up in the right place, then you've got your  implant, right?  So there's a great talk last year at 35C3.  I recommend you check it out.  That talks a little bit more about the scenario, sort of removing tamper stickers and the possibility  that some crypto wallets were sent back into supply chain that they've been tampered with.  And then let's take that back.  We have to now worry about the wonderful people in customs.  We have to worry about the people in the factory who have access to your hardware.  And so if you cut to the chase, it's a huge attack surface in terms of the supply chain,  right?  From you to the courier to the distributor, customs, box build, the box build factory  itself oftentimes will use gray market resources to help make themselves a little more profitable,  right?  You have distributors who go to them who you don't even know who those guys are, PCB  assembly, components, boards, chip fad, packaging, the whole thing, right?  Every single point is a place where someone can go ahead and touch a piece of hardware  along the chain.  So can open source save us in this scenario?  Does open hardware solve this problem, right?  Let's think about it.  Let's go ahead and throw some developers with Git on the left-hand side.  How far does it get, right?  Well, we can have some continuous integration checks that make sure that the hardware is  correct.  We can have some open PCB designs.  We can have some open PDK.  But then from that point, it goes into a rather opaque machine.  And then, okay, maybe we can put some tests on the very edge before exit the factory to  try and catch some potential issues, right?  But you can see all the area of other places where sort of a time of check to time of use  problem can happen.  And this is why I'm saying that open hardware on its own is not sufficient to solve this  trust problem, right?  And the big problem at the other day is that you can't hash hardware, right?  There is no hash function for hardware.  This is why I wanted to go through that earlier today.  There's no convening easy way to basically confirm the correctness of your hardware before  you use it.  Some people say, well, Bonnie said once, oh, it's a bigger microscope, right?  This is a, you know, I do some security reverse engineering stuff.  This is true, right?  So there's a wonderful technique called tachographic X-ray imaging.  There's a great paper and nature about it where they take like a modern I7 CPU and they  get down to the gate level non-destructively with it, right?  It's great for reverse engineering and for design verification.  The problem number one is it literally needs a building size microscope.  It was done at the Swiss light source.  That donut-shaped thing is the size of the light source for doing that type of verification,  right?  So you're not going to have one at your point of use, right?  You're going to check it there and then probably query it to yourself.  Again, time of check is not time of use.  Problem number two, it's expensive to do, so verifying one chip only verifies one chip.  And as I said earlier, just because 99.9% of your hardware is okay, doesn't mean you're  safe.  Sometimes all it takes is one server of 1,000 to break some fundamental assumptions that  you have about your cloud.  And random sampling just isn't good enough, right?  I mean, would you random sample signature checks on software that you install?  Download?  No, you insist 100% check on everything.  If you want that same standard of reliability, you have to do that for hardware.  So then is there any role for open source and trustable hardware?  Absolutely yes.  Some of you guys may be familiar with it.  A little guy on the right, the Spectre logo.  So correctness is very, very hard.  Your review can help fix correctness bugs, microarchitectural transparency can aid with  the fixes and specter-like situations.  So for example, we would love to be able to say we're entering a critical region, let's  turn off all the microarchitectural optimizations, sacrifice performance, and then run the code  securely and then go back into who cares what mode and just get done fast, right?  That would be a switch I would love to have, but without that sort of transparency or without  the ability to review it, we can't do that.  Also community-driven features and community-owned designs is very empowering and make sure that  we're sort of building the right hardware for the job and that it's upholding our standards.  So there is a role.  It's necessary, but it's not sufficient for trustable hardware.  So now the question is, okay, can we solve the point of use hardware verification problem?  Is it all gloom and doom from here on?  Well, I didn't bring you guys here to tell you it's just gloom and doom.  I've thought about this and I've kind of boiled it into three principles for building verifiable  hardware.  Three principles are that complexity is the enemy of verification.  We should verify entire systems, not just components, and we need to empower end users  to verify and seal their hardware.  We'll go into this in the remainder of the talk.  So the first one is that complexity is complicated, right?  So without a hashing function, verification rolls back to bit by bit or atom by atom verification.  So those modern phones just have so many components, even if I gave you the full source code for  the sock inside of a phone down to the mass level, what are you going to do with it, right?  How are you going to know that this mass actually matches the chip and those two haven't been  modified, right?  So more complexity, it's more difficult.  So okay, the solution is let's go to simplicity, right?  Let's just build things from discrete transistors.  Someone's done this, the Monster 6502 is great.  I love the project.  Very easy to verify, runs at 50 kilohertz, right?  So you're not going to do a lot with that.  Okay, well, let's build processes that are visually inspectable processes.  So let's go to 500 nanometers, you can see that with light.  Okay, well, you know, 100 megahertz clock rate and a very high power consumption and  you know, a couple of kilobytes of RAM probably is not going to really do it either, right?  So the point of use verification is a trade off between ease of verification and features  and usability, right?  So these two products up here largely do the same thing, AirPods, right?  And headphones on your head, right?  AirPods have something on the order of tens of millions of transistors for you to verify.  The headphone that goes on your head, like I can actually go to Maxwell's Equations and  actually tell you how the magnets work from very first principles and there's probably  one transistor on the inside of the microphone to go ahead and amplify the membrane and that's  it, right?  So this one, you do sacrifice some features and usability when you go to a headset, like  you can't say, hey Siri and they'll listen to you and know what you're doing, but it's  very easy to verify and know what's going on.  So in order to start a dialogue on user verification, we have to sort of set a context.  So I started a project called Be Trusted because the right answer depends on the context.  I want to establish what might be a minimum viable, verifiable product and it's sort of  like meant to be used verifiable by design and we think of it as a hardware software  distro.  So it's meant to be modified and changed and customized based upon the right context  at the end of the day.  This is a picture of what it looks like, I actually have a little prototype here, very,  very, very early prototype here at the Congress if you want to look at it.  It's a mobile device that is meant for sort of communication, sort of text-based communication  and maybe voice.  Authentication, so authenticated tokens or like a crypto wallet if you want.  And the people we're thinking about who might be users are either high value targets politically  or financially, so you don't have to have a lot of money to be a high value target, you  could also be very politically risky for some people.  And also of course looking at developers and enthusiasts and ideally we're thinking about  a global demographic, not just English speaking users which is sort of a thing, when you think  about the complexity standpoint this is where we really have to sort of champ at the bit  and figure out how to solve a lot of hard problems like getting Unicode and right to left rendering  and pictographic fonts to work inside a very small tax surface device.  So this leads me to the second point which we need to verify entire systems is not just  components.  You'll say well why don't you just build a chip?  Why not, you know, why are you thinking about a whole device?  The problem is that private keys are not your private matters.  Screens can be scraped and keyboards can be logged.  So there's some efforts now to build wonderful security enclaves like Keystone and OpenTitan  which will build wonderful secure chips.  The problem is that even if you manage to keep your keys secret you still have to get  that information through an insecure CPU from the screen to the keyboard and so forth.  And so people who have used these on screen touch keyboards have probably seen a message  like this saying that by the way this keyboard can see everything you're typing including  your passwords and people probably clip and say oh yeah sure whatever I trust that.  Well this little enclave on the site here isn't really doing a lot of good when you  go ahead and you say sure I'll run this input method that can go ahead and modify all my  data or intercept all my data.  So in terms of making a device variable let's talk about the concept of practice flow.  How do I take these three principles and turn them into something?  So this is the ideal of taking these three requirements and turning it into the set of  five features, a physical keyboard, a black and white LCD, an FPGA based RISC-5 SOC,  user-seable keys and something that's easy to verify and physically protect.  So let's talk about these features one by one.  First one is a physical keyboard.  Why am I using a physical keyboard and not a virtual keyboard?  People love the virtual keyboards.  The problem is that cap touch screens which is necessary to do a good virtual keyboard  have a firmware block.  They have a microcontroller to do the touch screen.  It's actually really hard to build these things.  If you can do a good Java and build an open source one that'd be great but that's a project  in and of itself.  So in order to sort of get an easy one here and we can let's just go with a physical keyboard.  So this is what the device looks like with this cover off.  We have a physical keyboard PCB with a little overlay that does you know so you can do multi-lingual  inserts and you just can go ahead and change that out.  And it's just a two-layer daughter card.  Just hold up to the light and you're like okay, switches, wires, right?  Not a lot of places to hide things.  So I'll take that as an easy win for an input surface that's verifiable, right?  The output surface is a little more subtle so we're doing a black and white LCD.  If you say okay, why not use a color LCD?  If you ever take apart a liquid crystal display, look for a tiny little thin rectangle sort  of located near the display area.  That's actually a silicon chip that's bonded to the glass.  That's what it looks like at the other day.  That contains a frame buffer and a command interface.  It has millions of transitions on the inside and you don't know what it does.  So if you're already assuming your adversary may be tamping with your CPU, this is also  a viable place you have to worry about.  So I found a screen.  It's called a memory LCD by Sharp Electronics.  It turns out they do all the drive electronics on glass.  So this is a picture of the drive electronics on the screen through like a 50X microscope  with a bright light behind it.  You can actually see the transistors that are used to drive everything on the display.  It's a non-destructive method of verification.  But actually more important to the point is that there are so few places to hide things  you probably don't need to check it.  If you wanted to add an implant to this, you would need to grow the glass area substantially  or add a silicon chip, which is a thing that you'll notice.  So at the end of the day, the less places to hide things is less need to check things.  So I can feel like this is a screen where I can write data to and it will show what  I want to show.  The good news is that the display has a 200-pPI pixel density.  So even though it's black and white, it's closer to e-paper, e-PD, in terms of resolution.  So now we come to the hard part, the CPU, the silicon problem.  Any chip built in the last two decades is not going to be fully inspectable with an  optical microscope.  Right?  Thorough analysis requires removing layers and layers of metal and dielectric.  This is sort of a cross-section of a modern-ish chip.  You can see the huge stack of things to look at on this.  This process is destructive and you can think of it as hashing, but it's a little bit too  literal.  We want something where we can check the thing that we're going to use and then not destroy  it.  So I spent quite a bit of time thinking about options for non-destructive silicon verification  to best come up with maybe using optical felt induction somehow, combined with some chip  design techniques to go ahead and scan a laser across and look at fault syndromes and figure  out, you know, does the thing do the gates that we put down correspond to the thing that  I built.  The problem is I couldn't think of a strategy to do it that wouldn't take years and tens  of millions of dollars to develop, which puts it a little bit far out there and probably  in the realm of venture-funded activities, which is not really going to be very empowering  of everyday people.  So I want something a little more short-term than that, than this sort of platonic ideal  of verifiability.  So the compromise that arrived at is the FPGA.  So field-programmed gate arrays, that's what FPGA stands for, are large arrays of logic  and wires that are user-configured to implement hardware designs.  So this here is an image inside an FPGA design tool.  On the top right is an example of one sort of logic subcell.  It's got a few flip-flops and lookup tables in it, and it's embedded in this huge mass  of wires that allow you to wire it up at runtime to figure out what's going on.  And one thing that this diagram here shows is I'm able to sort of correlate design.  I can see, okay, decode to XU instruction register bit 26 corresponds to this net.  So now we're sort of like bringing that time of check a little bit closer to the time of  use.  And so the idea is to narrow that talk to gap by compiling your own CPU.  We can basically give you the CPU from source, you can compile it yourself, you can confirm  the bit stream.  So now we're sort of enabling a bit more of that trust transfer-like software, right?  But there's a subtlety in that the tool chains are not necessarily always open.  There's some FOSS flows, like Simba flow.  They have a 100% open flow for Iced 40 and ECP5.  And there's like seven series where they have a coming soon status, but they currently  require some close vendor tools.  So picking an FPGA is a difficult choice.  There's a usability versus verification trade off here.  The big usability issue is battery life.  If we're going for a mobile device, you want to use it all day long or you want to be dead  by noon, it turns out that the best sort of chip in terms of battery life is a Spartan  7.  It gives you 4X, roughly 3 to 4X in terms of battery life.  But the tool flow is still semi-closed.  But I am optimistic that Simba flow will get there.  And we can also fork and make an ECP5 version if that's a problem at the end of the day.  So let's talk a little bit more about sort of FPGA features.  So one thing I like to say about FPGAs is they offer sort of ASLR, sort of address-based  layout randomization, but for hardware.  Essentially a design has a kind of pseudo random mapping to the device.  This is a sort of a screenshot of two compilation runs of the same source code with a very small  modification to it and basically a version number stored in a GPR.  And then you can see that actually the locations of a lot of the registers have basically shifted  around.  The reason why this is important is because this hinders a significant class of silicon  attacks.  All those small mass level changes.  I talked about the ones where we just say, okay, we're just going to change a few wires  or run a couple logic cells around, those become more less likely to capture a critical  bit.  So if you want to go ahead and backdoor a full FPGA, you're going to have to change  the die size.  You have to make it substantially larger to be able to sort of like swap out the function  in those cases.  And so now the verification bar goes from looking for a needle in a haystack to measuring  the size of the haystack, which is a bit easier to do towards the user side of things.  And it turns out at least in Xilinx land, it's just a change in random parameter does  a trick.  So some potential attack vectors against FPGAs is like, okay, well, it's closed silicon.  What are the backdoors there?  Notably inside a seven series FPGAs, they actually document introspection features  you can pull out anything inside the chip by instantiating a certain special block.  And then we still also have to worry about the whole class of like man in the middle  IO and JTAG implants that I talked about earlier.  So this easy, really easy to mitigate the known blocks, basically lock them down, tie  them down, check them in the bit stream, right?  In terms of the IO man in the middle stuff, this is where we're talking about like someone  goes ahead and puts a chip in the path of your FPGA.  There's a few tricks we can do.  We can do sort of bus encryption on the RAM and the ROM at the design level that frustrates  these.  At the implementation, basically we can use the fact that data pins and address pins can  be permuted without affecting the devices function.  So every design can go ahead and permute those data and address pin mappings sort of uniquely.  So any particular implant that goes in will have to be able to compensate for all those  combinations making the implant a little more difficult to do.  And of course, we all can always fall back to sort of careful inspection of the device.  In terms of the closed source silicon, the thing that I'm really optimistic for there  is that so in terms of closed source system, the thing we have to worry about is that for  example, now that Xilinx knows that we're doing these trustable devices using a tool  chain, they push a patch that compiles backdoors into your bit stream.  So not even a silicon level implant, but maybe the tool chain itself has a backdoor that  recognizes that we're doing this.  So the cool thing is in a very, this is a cool project, so there's a project called  PRJ, actually Project Xray.  It's part of the Symbolful effort.  And they're actually documenting the full bit stream of the seven series device.  It turns out that we don't yet know all the bit functions are, but the bit mappings are  deterministic.  So someone were to try and activate a backdoor in the bit stream through compilation.  We can see it in a diff.  We'd be like, well, we've never seen this bit flip before.  What does this do?  We can look into it and figure out if it's malicious or not.  So there's actually sort of a hope that essentially at the end of the day, we can build sort of  a bit stream checker.  We can build a thing that says, here's a bit stream that came out.  Does it correlate to the design source?  Do all the bits check out?  Do they make sense?  And so ideally, we would come up with like a one click tool.  And now we're at the point where the point of check is very close to the point of use.  The users are now confirming that the CPUs are correctly constructed and mapped to the  FPGA correctly.  So the summary of FPGA versus custom silicon is sort of like the pros of custom silicon  is that they have great performance.  We can do a true single chip enclave with hundreds of megahertz speeds and tiny power  consumption, but the con of silicon is that it's really hard to verify.  So open source doesn't help that verification and hard IP blocks are tough problems we talked  about earlier.  So FPGAs on the other side, they offer some immediate mitigation paths.  We don't have to wait until we solve this verification problem.  We can inspect a bit streams.  We can randomize the logic mapping.  And we can do per device unique pin mapping.  It's not perfect, but it's better than, I think, anything other solution I can offer  right now.  The cons of it is that the FPGAs are just barely good enough to do this today.  So you need a little bit of external RAM, which needs to be encrypted, about 100 megahertz  speed performance, and about 5 to 10 X the power consumption of a custom silicon solution,  which in a mobile device is a lot, but we actually, part of the reason, the main thing  that drives the thickness in this is the battery, right?  And most of that battery is for the FPGA.  If we didn't have to go with an FPGA, it could be much, much thinner.  So now let's talk a little about the last two points, user feeble keys and verification  and protection.  And this is that third point, empowering end users to verify and seal their hardware.  So it's great that we can verify something, but can it keep a secret?  Transparency is good up to a point, but you want to be able to keep secrets so that people  just welcome and say, oh, there's your keys, right?  So sealing a key in the FPGA, ideally we want user generated keys that are hard to extract.  We don't rely on a central key authority, and that any attack to remove those keys should  be noticeable, right?  So any high level apps, I mean, someone like infinite funding basically, should take about  a day to extract it, and that effort should be trivially evident.  The solution to that is basically self provisioning and sealing of the cryptographic keys in the  bit stream and a bit of epoxy.  So let's talk a little bit about, you know, sort of provisioning those keys.  If we look at the seven series FPGA security, they offer sort of encrypted HMAC 256AS with  256 SHA bit streams.  There's a paper which discloses a known weakness as it, so it's about, it takes, the, the attack  takes about a day, 1.6 million chosen Cypher text traces.  The reason why it takes a day is because that's how long it takes to load in that many chosen  Cypher text through the, through the interfaces.  The good news is there's some easy mitigations to this.  You can just glue shut the JTAG port or improve your power filtering, and that should significantly  complicate the attack.  But the point is that it will take a fixed amount of time to do this, and you have to  have direct access to the hardware.  It's not the sort of thing that, you know, someone that customs or like an evil maid  could easily pull off.  And just to put that in perspective again, if, even if we improved dramatically the DPA  resistance of the hardware, if we knew a region of the chip that we want to inspect,  probably with a SEM and a, and a skill technician, we could probably pull it off in a matter  of a day or a couple of days, takes only an hour to decap the silicon, you know, an hour  or a few layers, a few hours in a fib to delay our chip in an afternoon in the SEM, and you  can find out the keys, right?  So, so, but the key point is that this is kind of the level that we've agreed is, is  okay for, for, for a lot of the, the silicon enclaves, and this is not going to happen  at a customs checkpoint or by an evil maid, so I think I'm, I'm okay with that for now.  We can do better, but I think that's a, it's a good starting point, particularly for something  that's so cheap and accessible.  So then how do we get those keys in FPGA and how do you keep them from getting out?  So those keys should be user generated, never leave the device, not accessible by the CPU  after it's provisioned, unique per device, and it should be easy for the user to get  it right.  So you don't have to know all the stuff and type a bunch of commands to do it right, right?  So if you look inside, be trusted.  We have, there's two rectangles there.  One of them is the ROM that contains the bitstream, and the other one's the FPGA.  So I'm going to draw those in a schematic form.  Inside the ROM, you start the day with an unencrypted bitstream in ROM, which loads in  the FPGA, and then you have this little crypto engine that has no keys on the inside, there's  no, there's no keys anywhere.  So you can check everything, you can build your own bitstream, you can do what you want  to do.  The crypto engine then generates keys from a TRNG that's located on chip, probably some  help with some off-chip randomness as well, because I don't necessarily trust everything  inside the FPGA.  Then that crypto engine can go ahead and as it encrypts the external bitstream, inject  those keys back into the bitstream, because we know where that block RAM is.  We can go ahead and inject those keys back into that specific RAM block as we encrypt  it.  So we have a sealed encrypted image on the ROM, which can then load, literally load in  the FPGA if it had the key.  So after you've gone ahead and provisioned the ROM, hopefully at this point you don't  lose power, you go ahead and you burn the key into the FPGA's key engine, which sets it  to only boot from that encrypted bitstream, blow out the, re-back the disabled bit and  AS-only bit is blown.  So now at this point in time, basically there's no way to go ahead and put in a bitstream  that says, tell me your keys, whatever it is.  You have to go do one of these hard techniques to pull out the key.  You can maybe enable Hardware Upgrade Path if you want by having the crypto engines be  able to retain a copy of the master key and re-encrypt it, but that becomes a vulnerability  because the user can be coerced to go ahead and load inside a bitstream that then leaks  out the keys.  So if you're really paranoid at some point in time, you seal this thing and it's like  done.  You have to go ahead and do that full key extraction routine to go ahead and pull stuff out.  If you forget your passwords.  So that's the sort of user-sealable keys.  I think we can do that with an FPGA.  Finally easy to verify and easy to protect.  Just very quickly talking about this.  So if you want to make an inspectable tamper barrier, a lot of people have talked about  glitter seals.  Those are pretty cool, right?  The problem is I find that glitter seals are too hard to verify, right?  Like I have tried glitter seals before and I stared the thing and I'm like, damn it,  I have no idea if this is the seal I put down.  And so then say, okay, we'll take a picture or write an app or something.  Now I'm relying on this untrusted device to go ahead and tell me if the seal is verified  or not.  So I have a suggestion for a DIY watermark that relies not on an app to go ahead and verify,  but our very, very well-tuned neural networks inside our head to go ahead and verify things.  So the idea is basically there's this nice epoxy that I found.  It comes in this by-pack.  It's a two-party epoxy.  You just put it on the edge of the table and you go like this and it goes ahead and mixes  the epoxy and you're ready to use.  So it's very easy for users to apply.  And then you just draw a watermark on a piece of tissue paper.  It turns out humans are really good at identifying our own handwriting, right?  Our own signatures, these types of things.  Someone can go ahead and try to forge it.  There's people who are skilled in doing this, but this is way easier than looking at a glitter  seal.  You go ahead and put that down on your device.  You swab on the epoxy and at the end of the day you end up with a sort of tissue paper  plus a very easily recognizable seal.  Someone goes ahead and tries to take this off or tamper with it.  I can look at it easy and say, yes, this is a different thing than what I had yesterday.  I don't have to open an app.  I don't have to look at glitter patterns.  I don't have to do these sorts of things.  And I can go ahead and swab on to all the IO ports they need to do.  So it's a bit of a hack, but I think that it's a little closer towards not having to rely  on third-party apps to verify a tamper evidence seal.  So I've talked about sort of this implementation and also talked about how it maps to these  three principles for building trustable hardware.  So the idea is trying to build a system that is not too complex so that we can verify most  of the parts or all of them at the end user point, look at the keyboard, look at the display,  and we can go ahead and compile the FPGA from source.  We're focusing on verifying the entire system end to end, so the keyboard and the display.  We're not forgetting the user.  The secrets start with the user and end with the user, not at the edge of the silicon.  And finally, we're impiring end users to verify and seal their own hardware so you don't have  to go to a central keying authority to go ahead and make sure your secrets are inside  your hardware.  So at the end of the day, the idea behind BeTrusted is to close that hardware time of  check time of use gap by moving the verification point closer to the point of use.  So in this huge complicated landscape of problems that we can have, the idea is that we want  to as much as possible teach users to verify their own stuff.  So by design, it's meant to be a thing that hopefully anyone can be taught to sort of  verify and use and we can provide tools that enable them to do that.  But if that ends up being too hard of a bar, I would like it to within one or two nodes  in your immediate social network, anyone in the world can find someone who can do this.  And the reason why I set this bar is I want to define the maximum level of technical competence  required to do this.  Because it's really easy, particularly sitting in an audience of this of really brilliant  technical people, say, of course, everyone can just hash things and compile things and  look at things on microscopes and solder it.  And then you get into life and reality and like, oh, wait, I have completely forgotten  what real people are like.  So this tries to get me grounded and make sure that I'm not sort of drinking my own  Kool-Aid in terms of how useful open hardware is as a mechanism to verify anything.  Because a bunch of people schematic and say, check this, but you're like, I have no idea.  So the current development status is that the hardware is kind of an initial EVT stage  for a type subject to significant change, particularly part of the reason we're here  talking about this is to collect more ideas and feedback on this, make sure we're doing  it right.  The software is just starting.  We're writing our own OS called Zeus being done by Sean Cross.  And we're exploring the UX and applications being done by Tom Marble shown here.  And I actually want to give a big shout out to Enelnet for funding us partially.  We have a couple of grants for underprivacy and trust enhancing technologies.  And this is really significant because now we can actually think about the hard problems  and not have to be like, oh, when do we go crowdfunded?  When do we go fundraise?  Like a lot of people are just like, oh, this looks like a product, right?  Can we sell this now?  It's not ready yet, right?  And I want to be able to take the time to talk about it, listen to people, incorporate  changes, and make sure we're doing the right thing.  So with that, I'd like to open up the floor for Q&A.  Thanks everyone for coming to my talk.  Thank you so much, Bani, for the great talk.  We have about five minutes left for Q&A.  For those who are leaving earlier, you're only supposed to use the two doors on the  left, not the one, not the tunnel you came in through, but only the doors on the left,  like the very left door and the door in the middle.  Now Q&A, you can pile up at the microphones.  Do we have a question from the internet?  No, not yet.  If someone wants to ask a question but is not present, but in the stream or maybe a person  in the room who wants to ask a question, you can use the hashtag Clark and Twitter,  Masterland, and IRC are being monitored.  So let's start with microphone number one.  Your question, please.  Hey, Bani.  Hey.  So you mentioned that with the Foundry process that the hard IP blocks, the proprietary IP  blocks were a place where attacks could be made.  Do you have the same concern about the hard IP blocks in the FPGA, either the embedded  block RAM or any of the other special features that you might be using?  Yeah, I think that we do have to be concerned about implants that have existed inside the  FPGA prior to this project, right?  I think there is a risk, for example, that there's a JTAG path we didn't know about.  But the other, I guess the compensating side is that the military, US military does use  a lot of these in their devices.  So they have a self-interest in not having backdoors inside of these things as well,  is sort of, we'll see.  I think that the answer is it's possible.  I think the upside is that because the FPGA is actually a very regular structure, it's  doing sort of a sem level analysis of the initial construction of it at least is not  insane.  We can identify these blocks and look at them and make sure they're the right number of  bits.  That doesn't mean the one you have today is the same one.  But if they were to go ahead and modify that block to do sort of the implant, my argument  is that because of the randomness of the wiring and the number of factors they have to consider,  they would have to actually grow the silicon area substantially and that's a thing that  is a proxy for detection of these types of problems.  So that would be my kind of half answer to that problem.  It's a good question though.  Thank you.  Yeah, thanks for the question.  Next one for microphone number three, please.  Hi.  Yeah, move close to the microphone.  Thanks.  Hello.  My question is in your proposed solution, how do you get around the fact that the attacker,  whether it's an implant or something else, will just attack it before the user's self-provisioning?  So it'll compromise the self-provisioning process itself.  Right.  So the idea of the self-provisioning process is that is that...  So we send the device to you, you can look at the circuit boards and devices and then  you compile your own FPGA, which includes the self-provisioning code from source and  you can confirm...  Or if you don't want to compile, you can confirm that the signatures match with what's  on the internet.  Right.  And so if someone wanted to go ahead and compromise that process and sort of stash away some keys  in some other place, that modification would either be evident in the bit stream or that  it would be evident as a modification of the hash of the code that's running on it at that  point in time.  So someone would have to then add a harder implant, for example, to the ROM, but that  doesn't help because it's already encrypted by the time it hits the ROM, so it really  has to be an implant that's inside the FPGA and then Traml's question just sort of talked  about that situation itself.  So I think the attack surface is limited at least for that.  So you talked about how the courier might be the hacker, right?  So in this case, the courier would put a hard-core implant not in the hard IP, but just in the  piece of hardware inside the FPGA that provisions the bit stream.  So the idea is that you would get that FPGA and you would blow your own FPGA bit stream  yourself.  You don't trust my factory to give you a bit stream.  You get the device...  You trust that the bit stream is being blown.  You just get indicated on your computer saying this bit stream is being blown, right?  I see.  I see.  So how do you trust that the ROM actually doesn't have a backdoor in itself that's putting  another secret bit stream that's not related to...  A problem for a courier or evil maid.  Yeah, I mean, possible, I guess.  I think there are things you can do, for example, to defeat that.  So the way that we do the semi-randomness in the compilation is there's a 64-bit random  number we compile into the bit stream.  So if you're compiling your own bit stream, you can read out that number and see if it  matches.  At that point, if someone had pre-burned a bit stream onto it that they're sort of using  to actually load it instead of your own bit stream, it's not going to be able to have  that random number, for example, on the inside.  So I think there's ways to tell if, for example, the ROM has been backdoored and it has two  copies of the ROM, one of the evil one and one of yours, and then they're going to use  the evil one during provisioning, right?  I think that's a thing that can be mitigated.  All right, thank you very much.  We take the very last question from microphone number five.  Hi, Bunny.  Hi.  So one of the options you sort of touched on in the talk but then didn't pursue was this  idea of doing some custom silicon in a sort of very low-res process that could be optically  inspected directly.  Is that completely out of the question in terms of being a usable root in the future  or did you look into that in great detail at all?  So I thought about that one.  There's a couple of issues.  One is that if we rely on optical verification, now users need optical verification prior  to do it.  So we have to somehow move those optical verification tools to the edge towards the time of use,  right?  So nice thing about the FPGA is everything I talked about, building your own bit stream,  inspecting the bit stream, checking the hashes, those are things that don't require particular  sort of user equipment.  But yes, if we were to go ahead and build like an enclave out of 500 nanometer silicon,  like it probably run around 100 megahertz, you'd have a few kilobytes of RAM on the inside,  not a lot, right?  So you have a limitation in how much capability you have on it and would consume a lot of power.  But then every single one of those chips, right, we put them in a black piece of epoxy.  How do you, like, you know, what keeps someone from swapping that out with another chip?  Yeah, I mean, I was thinking of like old school transparent top like on a little...  Oh, okay.  So yeah, you can go ahead and wire bond on the board, put some clear epoxy on, and then  now people have to take a microscope to look at that.  That's a possibility.  I think that that's the sort of thing that I think I'm trying to imagine, like for example,  my mom using this and asking her to do this sort of stuff.  I just don't envision her knowing anyone who would have an optical microscope who could  do this except for me, right?  And I don't think that's a fair, you know, assessment of what is verifiable by the end  user at the end of the day.  So maybe for some scenarios it's okay, but I think that the full optical verification  of a chip and making that sort of the only thing between you and an implant worries me.  And that's the problem with the hard chip is that basically if someone, even if it's  full, you know, it's just a clear thing and someone just swapped out the chip with another  chip, right, you still need to know, you know, a piece of equipment to check that, right?  Whereas like when I talked about the display and the fact that you can look at that, actually  the argument for that is not that you have to check the display.  It's that you don't, it's actually because it's so simple, you don't need to check the  display, right?  You don't need the microscope to check it because there's no place to hide anything.  All right, folks, we ran out of time.  Thank you very much to everyone who asked the question.  And please give another big round of applause for our great speaker, Bunny.  Thank you so much for the great talk.  Thanks, everyone.  Thanks, everyone.
36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_0_107.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_108_1079.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_1080_1259.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_1260_1859.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_1860_2015.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_2016_8075.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_8076_11687.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_11688_13763.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_13764_16799.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_16800_17147.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_17148_17699.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_17700_17891.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_17892_18155.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_18156_18215.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_18216_18275.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_18276_19859.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_19860_20147.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_20148_20399.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_20400_21035.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_21036_24167.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_24168_24875.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_24876_25451.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_25452_25895.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_25896_26099.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_26100_28367.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_28368_28955.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_28956_29687.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_29688_30587.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_30588_31919.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_31920_32555.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_32556_33887.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_33888_36335.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_36336_36683.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_36684_39071.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_39072_40019.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_40020_42491.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_42492_42719.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_42720_45851.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_45852_45995.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_45996_46103.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_46104_46343.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_46344_46991.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_46992_47039.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_47040_47339.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_47340_47843.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_47844_48779.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_48780_49283.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_49284_51815.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_51816_52499.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_52500_52751.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_52752_52835.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_52836_56459.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_56460_58079.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_58080_62363.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_62364_64907.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_64908_65591.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_65592_66047.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_66048_67439.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_67440_73775.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_73776_74315.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_74316_74639.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_74640_75011.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_75012_76787.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_76788_76967.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_76968_78479.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_78480_78695.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_78696_79691.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_79692_79895.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_79896_80543.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_80544_80615.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_80616_80759.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_80760_81971.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_81972_82691.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_82692_82811.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_82812_87587.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_87588_88307.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_88308_89339.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_89340_89891.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_89892_90431.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_90432_90539.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_90540_90587.png 36c3-10690-eng-deu-Open_Source_is_Insufficient_to_Solve_Trust_Problems_in_Hardware_hd_90588_91122.png