[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:18.40,Default,,0000,0000,0000,,{\i1}36C3 Intro{\i0}\N♪ (intro music) ♪
Dialogue: 0,0:00:18.40,0:00:22.59,Default,,0000,0000,0000,,Herald: Welcome, everybody, to our very\Nfirst talk on the first day of Congress.
Dialogue: 0,0:00:22.59,0:00:27.01,Default,,0000,0000,0000,,The talk is "Open Source is Insufficient\Nto Solve Trust Problems in Hardware,"
Dialogue: 0,0:00:27.01,0:00:31.58,Default,,0000,0000,0000,,and although there is a lot to be said\Nfor free and open software, it is
Dialogue: 0,0:00:31.58,0:00:37.58,Default,,0000,0000,0000,,unfortunately not always inherently more\Nsecure than proprietary or closed software,
Dialogue: 0,0:00:37.58,0:00:41.52,Default,,0000,0000,0000,,and the same goes for hardware as well.\NAnd this talk will take us into
Dialogue: 0,0:00:41.52,0:00:46.54,Default,,0000,0000,0000,,the nitty gritty bits of how to build\Ntrustable hardware and how it it has to be
Dialogue: 0,0:00:46.54,0:00:51.50,Default,,0000,0000,0000,,implemented and brought together\Nwith the software in order to be secure.
Dialogue: 0,0:00:51.50,0:00:54.76,Default,,0000,0000,0000,,We have one speaker here today.\NIt's bunnie.
Dialogue: 0,0:00:54.76,0:00:57.65,Default,,0000,0000,0000,,He's a hardware and firmware hacker.\NBut actually,
Dialogue: 0,0:00:57.65,0:01:01.44,Default,,0000,0000,0000,,the talk was worked on by three people,\Nso it's not just bunnie, but also
Dialogue: 0,0:01:01.44,0:01:04.91,Default,,0000,0000,0000,,Sean "Xobs" Cross and Tom Marble.\NBut the other two are not present today.
Dialogue: 0,0:01:04.91,0:01:07.44,Default,,0000,0000,0000,,But I would like you to welcome\Nour speaker, bunnie,
Dialogue: 0,0:01:07.44,0:01:10.66,Default,,0000,0000,0000,,with a big, warm, round of applause,\Nand have a lot of fun.
Dialogue: 0,0:01:10.66,0:01:16.94,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:01:16.94,0:01:20.12,Default,,0000,0000,0000,,bunnie: Good morning, everybody.\NThanks for braving the crowds
Dialogue: 0,0:01:20.12,0:01:23.94,Default,,0000,0000,0000,,and making it in to the Congress.\NAnd thank you again to the Congress
Dialogue: 0,0:01:23.94,0:01:30.51,Default,,0000,0000,0000,,for giving me the privilege\Nto address the Congress again this year.
Dialogue: 0,0:01:30.51,0:01:34.36,Default,,0000,0000,0000,,Very exciting being the first talk\Nof the day. Had font problems,
Dialogue: 0,0:01:34.36,0:01:39.44,Default,,0000,0000,0000,,so I'm running from a .pdf backup.\NSo we'll see how this all goes.
Dialogue: 0,0:01:39.44,0:01:42.91,Default,,0000,0000,0000,,Good thing I make backups. So the\Ntopic of today's talk is
Dialogue: 0,0:01:42.91,0:01:47.23,Default,,0000,0000,0000,,"Open Source is Insufficient\Nto Solve Trust Problems in Hardware,"
Dialogue: 0,0:01:47.23,0:01:49.25,Default,,0000,0000,0000,,and sort of some things\Nwe can do about this.
Dialogue: 0,0:01:49.25,0:01:53.31,Default,,0000,0000,0000,,So my background is, I'm\Na big proponent of open source hardware. I
Dialogue: 0,0:01:53.31,0:01:57.94,Default,,0000,0000,0000,,love it. And I've built a lot of things in\Nopen source, using open source hardware
Dialogue: 0,0:01:57.94,0:02:01.06,Default,,0000,0000,0000,,principles. But there's been sort of a\Nnagging question in me about like, you
Dialogue: 0,0:02:01.06,0:02:04.30,Default,,0000,0000,0000,,know, some people would say things like,\Noh, well, you know, you build open source
Dialogue: 0,0:02:04.30,0:02:07.44,Default,,0000,0000,0000,,hardware because you can trust it more.\NAnd there's been sort of this gap in my
Dialogue: 0,0:02:07.44,0:02:12.38,Default,,0000,0000,0000,,head and this talk tries to distill out\Nthat gap in my head between trust and open
Dialogue: 0,0:02:12.38,0:02:18.61,Default,,0000,0000,0000,,source and hardware. So I'm sure people\Nhave opinions on which browsers you would
Dialogue: 0,0:02:18.61,0:02:22.58,Default,,0000,0000,0000,,think is more secure or trustable than the\Nothers. But the question is why might you
Dialogue: 0,0:02:22.58,0:02:26.50,Default,,0000,0000,0000,,think one is more trustable than the other\Nis. You have everything and hear from like
Dialogue: 0,0:02:26.50,0:02:31.42,Default,,0000,0000,0000,,Firefox and Iceweasel down to like the\NSamsung custom browser or the you know,
Dialogue: 0,0:02:31.42,0:02:35.20,Default,,0000,0000,0000,,xiaomi custom browser. Which one would\Nyou rather use for your browsing if you
Dialogue: 0,0:02:35.20,0:02:41.30,Default,,0000,0000,0000,,had to trust something? So I'm sure people\Nhave their biases and they might say that
Dialogue: 0,0:02:41.30,0:02:45.48,Default,,0000,0000,0000,,open is more trustable. But why do we say\Nopen is more trustable? Is it because we
Dialogue: 0,0:02:45.48,0:02:49.27,Default,,0000,0000,0000,,actually read the source thoroughly and\Ncheck it every single release for this
Dialogue: 0,0:02:49.27,0:02:53.70,Default,,0000,0000,0000,,browser? Is it because we compile our\Nsource, our browsers from source before we
Dialogue: 0,0:02:53.70,0:02:57.28,Default,,0000,0000,0000,,use them? No, actually we don't have the\Ntime to do that. So let's take a closer
Dialogue: 0,0:02:57.28,0:03:02.48,Default,,0000,0000,0000,,look as to why we like to think that open\Nsource software is more secure. So this is
Dialogue: 0,0:03:02.48,0:03:07.72,Default,,0000,0000,0000,,a kind of a diagram of the lifecycle of,\Nsay, a software project. You have a bunch
Dialogue: 0,0:03:07.72,0:03:12.92,Default,,0000,0000,0000,,of developers on the left. They'll commit\Ncode into some source management program
Dialogue: 0,0:03:12.92,0:03:17.89,Default,,0000,0000,0000,,like git. It goes to a build. And then\Nideally, some person who carefully managed
Dialogue: 0,0:03:17.89,0:03:22.26,Default,,0000,0000,0000,,the key signs that build goes into an\Nuntrusted cloud, then gets download onto
Dialogue: 0,0:03:22.26,0:03:26.08,Default,,0000,0000,0000,,users disks, pulled into RAM, run by the\Nuser at the end of the day. Right? So the
Dialogue: 0,0:03:26.08,0:03:31.92,Default,,0000,0000,0000,,reason why actually we find that we might\Nbe able to trust things more is because in
Dialogue: 0,0:03:31.92,0:03:35.79,Default,,0000,0000,0000,,the case of open source, anyone can pull\Ndown that source code like someone doing
Dialogue: 0,0:03:35.79,0:03:40.35,Default,,0000,0000,0000,,reproducible builds an audit of some type,\Nbuild it, confirm that the hashes match
Dialogue: 0,0:03:40.35,0:03:44.33,Default,,0000,0000,0000,,and that the keys are all set up\Ncorrectly. And then the users also have
Dialogue: 0,0:03:44.33,0:03:48.87,Default,,0000,0000,0000,,the ability to know developers and sort of\Nenforce community norms and standards upon
Dialogue: 0,0:03:48.87,0:03:52.64,Default,,0000,0000,0000,,them to make sure that they're acting in\Nsort of in the favor of the community. So
Dialogue: 0,0:03:52.64,0:03:55.63,Default,,0000,0000,0000,,in the case that we have bad actors who\Nwant to go ahead and tamper with builds
Dialogue: 0,0:03:55.63,0:03:59.94,Default,,0000,0000,0000,,and clouds and all the things in the\Nmiddle, it's much more difficult. So open
Dialogue: 0,0:03:59.94,0:04:05.51,Default,,0000,0000,0000,,is more trustable because we have tools to\Ntransfer trust in software, things like
Dialogue: 0,0:04:05.51,0:04:10.07,Default,,0000,0000,0000,,hashing, things like public keys, things\Nlike Merkle trees. Right? And also in the
Dialogue: 0,0:04:10.07,0:04:14.46,Default,,0000,0000,0000,,case of open versus closed, we have social\Nnetworks that we can use to reinforce our
Dialogue: 0,0:04:14.46,0:04:20.42,Default,,0000,0000,0000,,community standards for trust and\Nsecurity. Now, it's worth looking a little
Dialogue: 0,0:04:20.42,0:04:25.46,Default,,0000,0000,0000,,bit more into the hashing mechanism\Nbecause this is a very important part of
Dialogue: 0,0:04:25.46,0:04:29.18,Default,,0000,0000,0000,,our software trust chain. So I'm sure a\Nlot of people know what hashing is, for
Dialogue: 0,0:04:29.18,0:04:33.53,Default,,0000,0000,0000,,people who don't know. Basically it takes\Na big pile of bits and turns them into a
Dialogue: 0,0:04:33.53,0:04:38.34,Default,,0000,0000,0000,,short sequence of symbols so that a tiny\Nchange in the big pile of bits makes a big
Dialogue: 0,0:04:38.34,0:04:42.01,Default,,0000,0000,0000,,change in the output symbols. And also\Nknowing those symbols doesn't reveal
Dialogue: 0,0:04:42.01,0:04:48.09,Default,,0000,0000,0000,,anything about the original file. So in\Nthis case here, the file on the left is
Dialogue: 0,0:04:48.09,0:04:54.75,Default,,0000,0000,0000,,hashed to sort of cat, mouse, panda, bear\Nand the file on the right hashes to, you
Dialogue: 0,0:04:54.75,0:05:00.83,Default,,0000,0000,0000,,know, peach, snake, pizza, cookie. And the\Nthing is, as you may not even have noticed
Dialogue: 0,0:05:00.83,0:05:04.79,Default,,0000,0000,0000,,necessarily that there was that one bit\Nchanged up there, but it's very easy to
Dialogue: 0,0:05:04.79,0:05:07.35,Default,,0000,0000,0000,,see that short string of symbols have\Nchanged. So you don't actually have to go
Dialogue: 0,0:05:07.35,0:05:11.14,Default,,0000,0000,0000,,through that whole file and look for that\Nneedle in the haystack. You have this hash
Dialogue: 0,0:05:11.14,0:05:15.55,Default,,0000,0000,0000,,function that tells you something has\Nchanged very quickly. Then once you've
Dialogue: 0,0:05:15.55,0:05:19.56,Default,,0000,0000,0000,,computed the hashes, we have a process\Ncalled signing, where a secret key is used
Dialogue: 0,0:05:19.56,0:05:24.03,Default,,0000,0000,0000,,to encrypt the hash, users decrypt that\Nusing the public key to compare against a
Dialogue: 0,0:05:24.03,0:05:27.07,Default,,0000,0000,0000,,locally computed hash. You know, so we're\Nnot trusting the server to compute the
Dialogue: 0,0:05:27.07,0:05:31.79,Default,,0000,0000,0000,,hash. We reproduce it on our site and then\Nwe can say that it is now difficult to
Dialogue: 0,0:05:31.79,0:05:36.37,Default,,0000,0000,0000,,modify that file or the signature without\Ndetection. Now the problem is, that there
Dialogue: 0,0:05:36.37,0:05:41.04,Default,,0000,0000,0000,,is a time of check, time of use issue with\Nthe system, even though we have this
Dialogue: 0,0:05:41.04,0:05:44.98,Default,,0000,0000,0000,,mechanism, if we decouple the point of\Ncheck from the point of use, it creates a
Dialogue: 0,0:05:44.98,0:05:49.79,Default,,0000,0000,0000,,man in the middle opportunity or a person\Nthe middle if you want. The thing is that,
Dialogue: 0,0:05:49.79,0:05:55.60,Default,,0000,0000,0000,,you know, it's a class of attacks that\Nallows someone to tamper with data as it
Dialogue: 0,0:05:55.60,0:05:59.62,Default,,0000,0000,0000,,is in transit. And I'm kind of symbolizing\Nthis evil guy, I guess, because hackers
Dialogue: 0,0:05:59.62,0:06:05.78,Default,,0000,0000,0000,,all wear hoodies and, you know, they also\Nkeep us warm as well in very cold places.
Dialogue: 0,0:06:05.78,0:06:12.28,Default,,0000,0000,0000,,So now an example of a time of check, time\Nof use issue is that if, say, a user
Dialogue: 0,0:06:12.28,0:06:15.73,Default,,0000,0000,0000,,downloads a copy of the program onto their\Ndisk and they just check it after the
Dialogue: 0,0:06:15.73,0:06:20.37,Default,,0000,0000,0000,,download to the disc. And they say, okay,\Ngreat, that's fine. Later on, an adversary
Dialogue: 0,0:06:20.37,0:06:24.32,Default,,0000,0000,0000,,can then modify the file on a disk as it's\Ncut before it's copied to RAM. And now
Dialogue: 0,0:06:24.32,0:06:27.15,Default,,0000,0000,0000,,actually the user, even though they\Ndownload the correct version of file,
Dialogue: 0,0:06:27.15,0:06:31.56,Default,,0000,0000,0000,,they're getting the wrong version into the\NRAM. So the key point is the reason why in
Dialogue: 0,0:06:31.56,0:06:37.02,Default,,0000,0000,0000,,software we feel it's more trustworthy, we\Nhave a tool to transfer trust and ideally,
Dialogue: 0,0:06:37.02,0:06:41.51,Default,,0000,0000,0000,,we place that point of check as close to\Nthe users as possible. So idea that we're
Dialogue: 0,0:06:41.51,0:06:45.96,Default,,0000,0000,0000,,sort of putting keys into the CPU or some\Nsecure enclave that, you know, just before
Dialogue: 0,0:06:45.96,0:06:49.55,Default,,0000,0000,0000,,you run it, you've checked it, that\Nsoftware is perfect and has not been
Dialogue: 0,0:06:49.55,0:06:55.38,Default,,0000,0000,0000,,modified, right? Now, an important\Nclarification is that it's actually more
Dialogue: 0,0:06:55.38,0:06:58.75,Default,,0000,0000,0000,,about the place of check versus the place\Nof use. Whether you checked one second
Dialogue: 0,0:06:58.75,0:07:03.01,Default,,0000,0000,0000,,prior or a minute prior doesn't actually\Nmatter. It's more about checking the copy
Dialogue: 0,0:07:03.01,0:07:07.52,Default,,0000,0000,0000,,that's closest to the thing that's running\Nit, right? We don't call it PoCPoU because
Dialogue: 0,0:07:07.52,0:07:12.70,Default,,0000,0000,0000,,it just doesn't have quite the same ring\Nto it. But now this is important. That
Dialogue: 0,0:07:12.70,0:07:15.90,Default,,0000,0000,0000,,reason why I emphasize place of check\Nversus place of use is, this is why
Dialogue: 0,0:07:15.90,0:07:20.62,Default,,0000,0000,0000,,hardware is not the same as software in\Nterms of trust. The place of check is not
Dialogue: 0,0:07:20.62,0:07:25.32,Default,,0000,0000,0000,,the place of use or in other words, trust\Nin hardware is a ToCToU problem all the
Dialogue: 0,0:07:25.32,0:07:29.57,Default,,0000,0000,0000,,way down the supply chain. Right? So the\Nhard problem is how do you trust your
Dialogue: 0,0:07:29.57,0:07:33.29,Default,,0000,0000,0000,,computers? Right? So we have problems\Nwhere we have firmware, pervasive hidden
Dialogue: 0,0:07:33.29,0:07:37.68,Default,,0000,0000,0000,,bits of code that are inside every single\Npart of your system that can break
Dialogue: 0,0:07:37.68,0:07:41.77,Default,,0000,0000,0000,,abstractions. And there's also the issue\Nof hardware implants. So it's tampering or
Dialogue: 0,0:07:41.77,0:07:45.43,Default,,0000,0000,0000,,adding components that can bypass security\Nin ways that we're not, according to the
Dialogue: 0,0:07:45.43,0:07:51.39,Default,,0000,0000,0000,,specification, that you're building\Naround. So from the firmer standpoint,
Dialogue: 0,0:07:51.39,0:07:54.76,Default,,0000,0000,0000,,it's more here to acknowledge is an issue.\NThe problem is this is actually a software
Dialogue: 0,0:07:54.76,0:07:58.68,Default,,0000,0000,0000,,problem. The good news is we have things\Nlike openness and runtime verification,
Dialogue: 0,0:07:58.68,0:08:01.97,Default,,0000,0000,0000,,they go going to frame these questions. If\Nyou're, you know, a big enough player or
Dialogue: 0,0:08:01.97,0:08:05.18,Default,,0000,0000,0000,,you have enough influence or something,\Nyou can coax out all the firmware blobs
Dialogue: 0,0:08:05.18,0:08:10.19,Default,,0000,0000,0000,,and eventually sort of solve that problem.\NThe bad news is that you're still relying
Dialogue: 0,0:08:10.19,0:08:14.77,Default,,0000,0000,0000,,on the hardware to obediently run the\Nverification. So if your hardware isn't
Dialogue: 0,0:08:14.77,0:08:17.16,Default,,0000,0000,0000,,running the verification correctly, it\Ndoesn't matter that you have all the
Dialogue: 0,0:08:17.16,0:08:21.60,Default,,0000,0000,0000,,source code for the firmware. Which brings\Nus to the world of hardware implants. So
Dialogue: 0,0:08:21.60,0:08:25.30,Default,,0000,0000,0000,,very briefly, it's worth thinking about,\Nyou know, how bad can this get? What are
Dialogue: 0,0:08:25.30,0:08:29.83,Default,,0000,0000,0000,,we worried about? What is the field? If we\Nreally want to be worried about trust and
Dialogue: 0,0:08:29.83,0:08:33.87,Default,,0000,0000,0000,,security, how bad can it be? So I've spent\Nmany years trying to deal with supply
Dialogue: 0,0:08:33.87,0:08:37.49,Default,,0000,0000,0000,,chains. They're not friendly territory.\NThere's a lot of reasons people want to
Dialogue: 0,0:08:37.49,0:08:43.87,Default,,0000,0000,0000,,screw with the chips in the supply chain.\NFor example, here this is a small ST
Dialogue: 0,0:08:43.87,0:08:47.63,Default,,0000,0000,0000,,microcontroller, claims to be a secure\Nmicrocontroller. Someone was like: "Ah,
Dialogue: 0,0:08:47.63,0:08:50.83,Default,,0000,0000,0000,,this is not a secure, you know, it's not\Nbehaving correctly." We digest off the top
Dialogue: 0,0:08:50.83,0:08:54.77,Default,,0000,0000,0000,,of it. On the inside, it's an LCX244\Nbuffer. Right. So like, you know, this was
Dialogue: 0,0:08:54.77,0:08:59.13,Default,,0000,0000,0000,,not done because someone wanted to tamper\Nwith the secure microcontroller. It's
Dialogue: 0,0:08:59.13,0:09:02.49,Default,,0000,0000,0000,,because someone wants to make a quick\Nbuck. Right. But the point is that that
Dialogue: 0,0:09:02.49,0:09:05.59,Default,,0000,0000,0000,,marking on the outside is convincing.\NRight. You could've been any chip on the
Dialogue: 0,0:09:05.59,0:09:11.05,Default,,0000,0000,0000,,inside in that situation. Another problem\Nthat I've had personally as I was building
Dialogue: 0,0:09:11.05,0:09:15.69,Default,,0000,0000,0000,,a robot controller board that had an FPGA\Non the inside. We manufactured a thousand
Dialogue: 0,0:09:15.69,0:09:20.79,Default,,0000,0000,0000,,of these and about 3% of them weren't\Npassing tests, set them aside. Later on, I
Dialogue: 0,0:09:20.79,0:09:23.48,Default,,0000,0000,0000,,pulled these units that weren't passing\Ntests and looked at them very carefully.
Dialogue: 0,0:09:23.48,0:09:28.33,Default,,0000,0000,0000,,And I noticed that all of the units, the\NFPGA units that weren't passing test had
Dialogue: 0,0:09:28.33,0:09:34.51,Default,,0000,0000,0000,,that white rectangle on them, which is\Nshown in a big more zoomed in version. It
Dialogue: 0,0:09:34.51,0:09:38.08,Default,,0000,0000,0000,,turned out that underneath that white\Nrectangle where the letters ES for
Dialogue: 0,0:09:38.08,0:09:43.48,Default,,0000,0000,0000,,engineering sample, so someone had gone in\Nand Laser blasted off the letters which
Dialogue: 0,0:09:43.48,0:09:46.02,Default,,0000,0000,0000,,say that's an engineering sample, which\Nmeans they're not qualified for regular
Dialogue: 0,0:09:46.02,0:09:50.24,Default,,0000,0000,0000,,production, blending them into the supply\Nchain at a 3% rate and managed to
Dialogue: 0,0:09:50.24,0:09:53.42,Default,,0000,0000,0000,,essentially double their profits at the\Nend of the day. The reason why this works
Dialogue: 0,0:09:53.42,0:09:56.35,Default,,0000,0000,0000,,is because distributors make a small\Namount of money. So even a few percent
Dialogue: 0,0:09:56.35,0:09:59.93,Default,,0000,0000,0000,,actually makes them a lot more profit at\Nthe end of day. But the key takeaway is
Dialogue: 0,0:09:59.93,0:10:03.98,Default,,0000,0000,0000,,that this is just because 97% of your\Nhardware is okay. It does not mean that
Dialogue: 0,0:10:03.98,0:10:09.86,Default,,0000,0000,0000,,you're safe. Right? So it doesn't help to\Ntake one sample out of your entire set of
Dialogue: 0,0:10:09.86,0:10:12.75,Default,,0000,0000,0000,,hardware and say all this is good. This is\Nconstructed correctly right, therefore all
Dialogue: 0,0:10:12.75,0:10:17.76,Default,,0000,0000,0000,,of them should be good. That's a ToCToU\Nproblem, right? 100% hardware verification
Dialogue: 0,0:10:17.76,0:10:23.14,Default,,0000,0000,0000,,is mandatory. If if you're worried about\Ntrust and verification. So let's go a bit
Dialogue: 0,0:10:23.14,0:10:27.22,Default,,0000,0000,0000,,further down the rabbit hole. This is a\Ndiagram, sort of an ontology of supply
Dialogue: 0,0:10:27.22,0:10:31.88,Default,,0000,0000,0000,,chain attacks. And I've kind of divided it\Ninto two axis. On the vertical axis, is
Dialogue: 0,0:10:31.88,0:10:36.27,Default,,0000,0000,0000,,how easy is it to detect or how hard.\NRight? So in the bottom you might need a
Dialogue: 0,0:10:36.27,0:10:40.06,Default,,0000,0000,0000,,SEM, a scanning electron microscope to do\Nit, in the middle is an x-ray, a little
Dialogue: 0,0:10:40.06,0:10:43.59,Default,,0000,0000,0000,,specialized and at the top is just visual\Nor JTAG like anyone can do it at home.
Dialogue: 0,0:10:43.59,0:10:47.77,Default,,0000,0000,0000,,Right? And then from left to right is\Nexecution difficulty. Right? Things are
Dialogue: 0,0:10:47.77,0:10:51.22,Default,,0000,0000,0000,,going take millions of dollars and months.\NThings are going take 10$ and weeks. Or a
Dialogue: 0,0:10:51.22,0:10:56.57,Default,,0000,0000,0000,,dollar in seconds. Right? There's sort of\Nseveral broad classes I've kind of
Dialogue: 0,0:10:56.57,0:10:59.75,Default,,0000,0000,0000,,outlined here. Adding components is very\Neasy. Substituting components is very
Dialogue: 0,0:10:59.75,0:11:03.81,Default,,0000,0000,0000,,easy. We don't have enough time to really\Ngo into those. But instead, we're gona
Dialogue: 0,0:11:03.81,0:11:07.99,Default,,0000,0000,0000,,talk about kind of the two more scary\Nones, which are sort of adding a chip
Dialogue: 0,0:11:07.99,0:11:12.39,Default,,0000,0000,0000,,inside a package and IC modifications. So\Nlet's talk about adding a chip in a
Dialogue: 0,0:11:12.39,0:11:16.23,Default,,0000,0000,0000,,package. This one has sort of grabbed a\Nbunch of headlines, so this sort of these
Dialogue: 0,0:11:16.23,0:11:21.25,Default,,0000,0000,0000,,in the Snowden files, we've found these\Nlike NSA implants where they had put chips
Dialogue: 0,0:11:21.25,0:11:27.35,Default,,0000,0000,0000,,literally inside of connectors and other\Nchips to modify the computer's behavior.
Dialogue: 0,0:11:27.35,0:11:31.84,Default,,0000,0000,0000,,Now, it turns out that actually adding a\Nchip in a package is quite easy. It
Dialogue: 0,0:11:31.84,0:11:35.49,Default,,0000,0000,0000,,happens every day. This is a routine\Nthing, right? If you take open any SD
Dialogue: 0,0:11:35.49,0:11:39.18,Default,,0000,0000,0000,,card, micro-SD card that you have, you're\Ngoing to find that it has two chips on the
Dialogue: 0,0:11:39.18,0:11:42.06,Default,,0000,0000,0000,,inside at the very least. One is a\Ncontroller chip, one is memory chip. In
Dialogue: 0,0:11:42.06,0:11:47.91,Default,,0000,0000,0000,,fact, they can stick 16, 17 chips inside\Nof these packages today very handily.
Dialogue: 0,0:11:47.91,0:11:51.94,Default,,0000,0000,0000,,Right? And so if you want to go ahead and\Nfind these chips, is the solution to go
Dialogue: 0,0:11:51.94,0:11:54.76,Default,,0000,0000,0000,,ahead and X-ray all the things, you just\Ntake every single circuit board and throw
Dialogue: 0,0:11:54.76,0:11:58.24,Default,,0000,0000,0000,,inside an x-ray machine. Well, this is\Nwhat a circuit board looks like, in the
Dialogue: 0,0:11:58.24,0:12:02.95,Default,,0000,0000,0000,,x-ray machine. Some things are very\Nobvious. So on the left, we have our
Dialogue: 0,0:12:02.95,0:12:05.78,Default,,0000,0000,0000,,Ethernet magnetic jacks and there's a\Nbunch of stuff on the inside. Turns out
Dialogue: 0,0:12:05.78,0:12:08.98,Default,,0000,0000,0000,,those are all OK right there. Don't worry\Nabout those. And on the right, we have our
Dialogue: 0,0:12:08.98,0:12:13.74,Default,,0000,0000,0000,,chips. And this one here, you may be sort\Nof tempted to look and say, oh, I see this
Dialogue: 0,0:12:13.74,0:12:18.29,Default,,0000,0000,0000,,big sort of square thing on the bottom\Nthere. That must be the chip. Actually,
Dialogue: 0,0:12:18.29,0:12:22.24,Default,,0000,0000,0000,,turns out that's not the chip at all.\NThat's the solder pad that holds the chip
Dialogue: 0,0:12:22.24,0:12:25.92,Default,,0000,0000,0000,,in place. You can't actually see the chip\Nas the solder is masking it inside the
Dialogue: 0,0:12:25.92,0:12:30.30,Default,,0000,0000,0000,,x-ray. So when we're looking at a chip\Ninside of an x-ray, I've kind of giving
Dialogue: 0,0:12:30.30,0:12:34.75,Default,,0000,0000,0000,,you a look right here on the left is what\Nit looks like sort of in 3-D. And the
Dialogue: 0,0:12:34.75,0:12:37.36,Default,,0000,0000,0000,,right is what looks like an x-ray, sort of\Nlooking from the top down. You're looking
Dialogue: 0,0:12:37.36,0:12:41.48,Default,,0000,0000,0000,,at ghostly outlines with very thin spidery\Nwires coming out of it. So if you were to
Dialogue: 0,0:12:41.48,0:12:45.76,Default,,0000,0000,0000,,look at a chip-on-chip in an x-ray, this\Nis actually an image of a chip. So in the
Dialogue: 0,0:12:45.76,0:12:49.79,Default,,0000,0000,0000,,cross-section, you can see the several\Npieces of silicon that are stacked on top
Dialogue: 0,0:12:49.79,0:12:53.44,Default,,0000,0000,0000,,of each other. And if you could actually\Ndo an edge on x-ray of it, this is what
Dialogue: 0,0:12:53.44,0:12:57.00,Default,,0000,0000,0000,,you would see. Unfortunately, you'd have\Nto take the chip off the board to do the
Dialogue: 0,0:12:57.00,0:13:00.50,Default,,0000,0000,0000,,edge on x-ray. So what you do is you have\Nto look at it from the top down and we
Dialogue: 0,0:13:00.50,0:13:03.96,Default,,0000,0000,0000,,look at it from the top down, all you see\Nare basically some straight wires. Like, I
Dialogue: 0,0:13:03.96,0:13:08.51,Default,,0000,0000,0000,,can't it's not obvious from that top down\Nx-ray, whether you're looking at multiple
Dialogue: 0,0:13:08.51,0:13:11.70,Default,,0000,0000,0000,,chips, eight chips, one chip, how many\Nchips are on the inside? That piece of
Dialogue: 0,0:13:11.70,0:13:16.38,Default,,0000,0000,0000,,wire bonds all stitched perfectly in\Noverlap over the chip. So you know. this
Dialogue: 0,0:13:16.38,0:13:20.17,Default,,0000,0000,0000,,is what the chip-on-chip scenario might\Nlook like. You have a chip that's sitting
Dialogue: 0,0:13:20.17,0:13:23.96,Default,,0000,0000,0000,,on top of a chip and wire bonds just sort\Nof going a little bit further on from the
Dialogue: 0,0:13:23.96,0:13:28.40,Default,,0000,0000,0000,,edge. And so in the X-ray, the only kind\Nof difference you see is a slightly longer
Dialogue: 0,0:13:28.40,0:13:32.76,Default,,0000,0000,0000,,wire bond in some cases. So it's actually,\Nit's not not, you can find these, but it's
Dialogue: 0,0:13:32.76,0:13:38.45,Default,,0000,0000,0000,,not like, you know, obvious that you've\Nfound an implant or not. So looking for
Dialogue: 0,0:13:38.45,0:13:42.88,Default,,0000,0000,0000,,silicon is hard. Silicon is relatively\Ntransparent to X-rays. A lot of things
Dialogue: 0,0:13:42.88,0:13:48.28,Default,,0000,0000,0000,,mask it. Copper traces, Solder masks the\Npresence of silicon. This is like another
Dialogue: 0,0:13:48.28,0:13:54.18,Default,,0000,0000,0000,,example of a, you know, a wire bonded chip\Nunder an X-ray. There's some mitigations.
Dialogue: 0,0:13:54.18,0:13:57.29,Default,,0000,0000,0000,,If you have a lot of money, you can do\Ncomputerized tomography. They'll build a
Dialogue: 0,0:13:57.29,0:14:02.84,Default,,0000,0000,0000,,3D image of the chip. You can do X-ray\Ndiffraction spectroscopy, but it's not a
Dialogue: 0,0:14:02.84,0:14:07.49,Default,,0000,0000,0000,,foolproof method. And so basically the\Nthreat of wirebonded package is actually
Dialogue: 0,0:14:07.49,0:14:11.61,Default,,0000,0000,0000,,very well understood commodity technology.\NIt's actually quite cheap. This is a I was
Dialogue: 0,0:14:11.61,0:14:15.75,Default,,0000,0000,0000,,actually doing some wire bonding in China\Nthe other day. This is the wirebonding
Dialogue: 0,0:14:15.75,0:14:20.01,Default,,0000,0000,0000,,machine. I looked up the price, it's 7000 \Ndollars for a used one. And you
Dialogue: 0,0:14:20.01,0:14:23.10,Default,,0000,0000,0000,,basically just walk into the guy with a\Npicture where you want the bonds to go. He
Dialogue: 0,0:14:23.10,0:14:27.10,Default,,0000,0000,0000,,sort of picks them out, programs the\Nmachines motion once and he just plays
Dialogue: 0,0:14:27.10,0:14:30.03,Default,,0000,0000,0000,,back over and over again. So if you want\Nto go ahead and modify a chip and add a
Dialogue: 0,0:14:30.03,0:14:34.77,Default,,0000,0000,0000,,wirebond, it's not as crazy as it sounds.\NThe mitigation is that this is a bit
Dialogue: 0,0:14:34.77,0:14:38.77,Default,,0000,0000,0000,,detectable inside X-rays. So let's go down\Nthe rabbit hole a little further. So
Dialogue: 0,0:14:38.77,0:14:41.86,Default,,0000,0000,0000,,there's nother concept of threat use\Ncalled the Through-Silicon Via. So this
Dialogue: 0,0:14:41.86,0:14:46.57,Default,,0000,0000,0000,,here is a cross-section of a chip. On the\Nbottom is the base chip and the top is a
Dialogue: 0,0:14:46.57,0:14:51.35,Default,,0000,0000,0000,,chip that's only 0.1 to 0.2 millimeters\Nthick, almost the width of a human hair.
Dialogue: 0,0:14:51.35,0:14:55.22,Default,,0000,0000,0000,,And they actually have drilled Vias\Nthrough the chip. So you have circuits on
Dialogue: 0,0:14:55.22,0:14:59.54,Default,,0000,0000,0000,,the top and circuits on the bottom. So\Nthis is kind of used to sort of, you know,
Dialogue: 0,0:14:59.54,0:15:03.88,Default,,0000,0000,0000,,putting interposer in between different\Nchips, also used to stack DRAM and HBM. So
Dialogue: 0,0:15:03.88,0:15:07.88,Default,,0000,0000,0000,,this is a commodity process to be able\Ntoday. It's not science fiction. And the
Dialogue: 0,0:15:07.88,0:15:10.64,Default,,0000,0000,0000,,second concept I want to throw at you is a\Nthing called a Wafer Level Chip Scale
Dialogue: 0,0:15:10.64,0:15:15.34,Default,,0000,0000,0000,,Package, WLCSP. This is actually a very\Ncommon method for packaging chips today.
Dialogue: 0,0:15:15.34,0:15:19.34,Default,,0000,0000,0000,,Basically it's solder bolts directly on\Ntop of chips. They're everywhere. If you
Dialogue: 0,0:15:19.34,0:15:24.13,Default,,0000,0000,0000,,look inside of like an iPhone, basically\Nalmost all the chips are WLCSP package
Dialogue: 0,0:15:24.13,0:15:28.38,Default,,0000,0000,0000,,types. Now, if I were to take that Wafer\NLevel Chip Scale Package and cross-section
Dialogue: 0,0:15:28.38,0:15:32.46,Default,,0000,0000,0000,,and look at it, it looks like a circuit\Nboard with some solder-balls and the
Dialogue: 0,0:15:32.46,0:15:36.09,Default,,0000,0000,0000,,silicon itself with some backside\Npassivation. If you go ahead and combine
Dialogue: 0,0:15:36.09,0:15:40.71,Default,,0000,0000,0000,,this with a Through-Silicon Via implant, a\Nman in the middle attack using Through-
Dialogue: 0,0:15:40.71,0:15:43.50,Default,,0000,0000,0000,,Silicon Vias, this is what it looks like\Nat the end of the day, you basically have
Dialogue: 0,0:15:43.50,0:15:47.49,Default,,0000,0000,0000,,a piece of silicon this size, the original\Nsilicon, sitting in original pads, in
Dialogue: 0,0:15:47.49,0:15:50.35,Default,,0000,0000,0000,,basically all the right places with the\Nsolder-balls masking the presence of that
Dialogue: 0,0:15:50.35,0:15:53.69,Default,,0000,0000,0000,,chip. So it's actually basically a nearly\Nundetectable implant if you want to
Dialogue: 0,0:15:53.69,0:15:57.58,Default,,0000,0000,0000,,execute it, if you go ahead and look at\Nthe edge of the chip. They already have
Dialogue: 0,0:15:57.58,0:16:00.57,Default,,0000,0000,0000,,seams on the sides. You can't even just\Nlook at the side and say, oh, I see a seam
Dialogue: 0,0:16:00.57,0:16:03.85,Default,,0000,0000,0000,,on my chip. Therefore, it's a problem. The\Nseam on the edge often times is because of
Dialogue: 0,0:16:03.85,0:16:08.38,Default,,0000,0000,0000,,a different coding as the back or\Npassivations, these types of things. So if
Dialogue: 0,0:16:08.38,0:16:12.87,Default,,0000,0000,0000,,you really wanted to sort of say, OK, how\Nwell can we hide implant, this is probably
Dialogue: 0,0:16:12.87,0:16:16.10,Default,,0000,0000,0000,,the way I would do it. It's logistically\Nactually easier than to worry about an
Dialogue: 0,0:16:16.10,0:16:19.77,Default,,0000,0000,0000,,implant because you don't have to get the\Nchips in wire-bondable format, you
Dialogue: 0,0:16:19.77,0:16:23.25,Default,,0000,0000,0000,,literally just buy them off the Internet.\NYou can just clean off the solder-balls
Dialogue: 0,0:16:23.25,0:16:27.47,Default,,0000,0000,0000,,with a hot air gun and then the hard part\Nis building it so it can be a template for
Dialogue: 0,0:16:27.47,0:16:32.39,Default,,0000,0000,0000,,doing the attack, which will take some\Nhundreds of thousands of dollars to do and
Dialogue: 0,0:16:32.39,0:16:36.87,Default,,0000,0000,0000,,probably a mid-end fab. But if you have\Nalmost no budget constraint and you have a
Dialogue: 0,0:16:36.87,0:16:39.95,Default,,0000,0000,0000,,set of chips that are common and you want\Nto build a template for, this could be a
Dialogue: 0,0:16:39.95,0:16:46.46,Default,,0000,0000,0000,,pretty good way to hide an implant inside\Nof a system. So that's sort of adding
Dialogue: 0,0:16:46.46,0:16:52.29,Default,,0000,0000,0000,,chips inside packages. Let's talk a bit\Nabout chip modification itself. So how
Dialogue: 0,0:16:52.29,0:16:55.74,Default,,0000,0000,0000,,hard is it to modify the chip itself?\NLet's say we've managed to eliminate the
Dialogue: 0,0:16:55.74,0:17:00.38,Default,,0000,0000,0000,,possibility of someone's added chip, but\Nwhat about the chip itself? So this sort
Dialogue: 0,0:17:00.38,0:17:03.30,Default,,0000,0000,0000,,of goes, a lot of people said, hey,\Nbunnie, why don't you spin an open source,
Dialogue: 0,0:17:03.30,0:17:06.46,Default,,0000,0000,0000,,silicon processor, this will make it\Ntrustable, right?. This is not a problem.
Dialogue: 0,0:17:06.46,0:17:12.31,Default,,0000,0000,0000,,Well, let's think about the attack surface\Nof IC fabrication processes. So on the
Dialogue: 0,0:17:12.31,0:17:16.14,Default,,0000,0000,0000,,left hand side here I've got kind of a\Nflowchart of what I see fabrication looks
Dialogue: 0,0:17:16.14,0:17:22.63,Default,,0000,0000,0000,,like. You start with a high level chip\Ndesign, it's a RTL, like Verilog, or VHDL
Dialogue: 0,0:17:22.63,0:17:27.43,Default,,0000,0000,0000,,these days or Python. You go into some\Nbackend and then you have a decision to
Dialogue: 0,0:17:27.43,0:17:31.38,Default,,0000,0000,0000,,make: Do you own your backend tooling or\Nnot? And so I will go into this a little
Dialogue: 0,0:17:31.38,0:17:34.50,Default,,0000,0000,0000,,more. If you don't, you trust the fab to\Ncompile it and assemble it. If you do, you
Dialogue: 0,0:17:34.50,0:17:37.76,Default,,0000,0000,0000,,assemble the chip with some blanks for\Nwhat's called "hard IP", we'll get into
Dialogue: 0,0:17:37.76,0:17:42.14,Default,,0000,0000,0000,,this. And then you trust the fab to\Nassemble that, make masks and go to mass
Dialogue: 0,0:17:42.14,0:17:46.91,Default,,0000,0000,0000,,production. So there's three areas that I\Nthink are kind of ripe for tampering now,
Dialogue: 0,0:17:46.91,0:17:49.51,Default,,0000,0000,0000,,"Netlist tampering", "hard IP tampering"\Nand "mask tampering". We'll go into each
Dialogue: 0,0:17:49.51,0:17:55.14,Default,,0000,0000,0000,,of those. So "Netlist tampering", a lot of\Npeople think that, of course, if you wrote
Dialogue: 0,0:17:55.14,0:17:59.36,Default,,0000,0000,0000,,the RTL, you're going to make the chip. It\Nturns out that's actually kind of a
Dialogue: 0,0:17:59.36,0:18:02.91,Default,,0000,0000,0000,,minority case. We hear about that. That's\Non the right hand side called customer
Dialogue: 0,0:18:02.91,0:18:06.91,Default,,0000,0000,0000,,owned tooling. That's when the customer\Ndoes a full flow, down to the mask set.
Dialogue: 0,0:18:06.91,0:18:11.52,Default,,0000,0000,0000,,The problem is it costs several million\Ndollars and a lot of extra headcount of
Dialogue: 0,0:18:11.52,0:18:15.17,Default,,0000,0000,0000,,very talented people to produce these and\Nyou usually only do it for flagship
Dialogue: 0,0:18:15.17,0:18:20.01,Default,,0000,0000,0000,,products like CPUs, and GPUs or high-end\Nrouters, these sorts of things. I would
Dialogue: 0,0:18:20.01,0:18:25.02,Default,,0000,0000,0000,,say most chips tend to go more towards\Nwhat's called an ASIC side, "Application
Dialogue: 0,0:18:25.02,0:18:28.83,Default,,0000,0000,0000,,Specific Integrated Circuit". What happens\Nis that the customer will do some RTL and
Dialogue: 0,0:18:28.83,0:18:33.27,Default,,0000,0000,0000,,maybe a high level floorplan and then the\Nsilicon foundry or service will go ahead
Dialogue: 0,0:18:33.27,0:18:36.50,Default,,0000,0000,0000,,and do the place/route, the IP\Nintegration, the pad ring. This is quite
Dialogue: 0,0:18:36.50,0:18:39.64,Default,,0000,0000,0000,,popular for cheap support chips, like your\Nbaseboard management controller inside
Dialogue: 0,0:18:39.64,0:18:43.82,Default,,0000,0000,0000,,your server probably went through this\Nflow, disk controllers probably got this
Dialogue: 0,0:18:43.82,0:18:47.86,Default,,0000,0000,0000,,flow, mid-to-low IO controllers . So all\Nthose peripheral chips that we don't like
Dialogue: 0,0:18:47.86,0:18:52.21,Default,,0000,0000,0000,,to think about, that we know that can\Nhandle our data probably go through a flow
Dialogue: 0,0:18:52.21,0:18:57.88,Default,,0000,0000,0000,,like this. And, to give you an idea of how\Ncommon it is, but how little you've heard
Dialogue: 0,0:18:57.88,0:19:00.90,Default,,0000,0000,0000,,of it, there's a company called SOCIONEXT.\NThere are a billion dollar company,
Dialogue: 0,0:19:00.90,0:19:04.28,Default,,0000,0000,0000,,actually, you've probably never heard of\Nthem, and they offer services. You
Dialogue: 0,0:19:04.28,0:19:07.29,Default,,0000,0000,0000,,basically just throw a spec over the wall\Nand they'll build a chip to you all the
Dialogue: 0,0:19:07.29,0:19:10.16,Default,,0000,0000,0000,,way to the point where you've done logic,\Nsynthesis and physical design and then
Dialogue: 0,0:19:10.16,0:19:14.59,Default,,0000,0000,0000,,they'll go ahead and do the manufacturing\Nand test and sample shipment for it. So
Dialogue: 0,0:19:14.59,0:19:18.54,Default,,0000,0000,0000,,then, OK, fine, now, obviously, if you\Ncare about trust, you don't do an ASIC
Dialogue: 0,0:19:18.54,0:19:24.26,Default,,0000,0000,0000,,flow, you pony up the millions of dollars\Nand you do a COT flow, right? Well, there
Dialogue: 0,0:19:24.26,0:19:29.14,Default,,0000,0000,0000,,is a weakness in COT flows. And this is\Nit's called the "Hard IP problem". So this
Dialogue: 0,0:19:29.14,0:19:33.00,Default,,0000,0000,0000,,here on the right hand side is an amoeba\Nplot of the standard cells alongside a
Dialogue: 0,0:19:33.00,0:19:39.38,Default,,0000,0000,0000,,piece of SRAM, a highlight this year. The\Nimage wasn't great for presentation, but
Dialogue: 0,0:19:39.38,0:19:45.01,Default,,0000,0000,0000,,this region here is the SRAM-block. And\Nall those little colorful blocks are
Dialogue: 0,0:19:45.01,0:19:50.37,Default,,0000,0000,0000,,standard cells, representing your AND-\Ngates and NAND-gates and that sort of
Dialogue: 0,0:19:50.37,0:19:55.04,Default,,0000,0000,0000,,stuff. What happens is that the foundry\Nwill actually ask you, just leave an open
Dialogue: 0,0:19:55.04,0:20:00.00,Default,,0000,0000,0000,,spot on your mask-design and they'll go\Nahead and merge in the RAM into that spot
Dialogue: 0,0:20:00.00,0:20:05.29,Default,,0000,0000,0000,,just before production. The reason why\Nthey do this is because stuff like RAM is
Dialogue: 0,0:20:05.29,0:20:08.14,Default,,0000,0000,0000,,a carefully guarded trade secret. If you\Ncan increase the RAM density of your
Dialogue: 0,0:20:08.14,0:20:12.97,Default,,0000,0000,0000,,foundry process, you can get a lot more\Ncustomers. There's a lot of knowhow in it,
Dialogue: 0,0:20:12.97,0:20:16.88,Default,,0000,0000,0000,,and so foundries tend not to want to share\Nthe RAM. You can compile your own RAM,
Dialogue: 0,0:20:16.88,0:20:20.11,Default,,0000,0000,0000,,there are open RAM projects, but their\Nperformance or their density is not as
Dialogue: 0,0:20:20.11,0:20:24.54,Default,,0000,0000,0000,,good as the foundry specific ones. So in\Nterms of Hard IP, what are the blocks that
Dialogue: 0,0:20:24.54,0:20:29.59,Default,,0000,0000,0000,,tend to be Hard IP? Stuff like RF and\Nanalog, phase-locked-loops, ADCs, DACs,
Dialogue: 0,0:20:29.59,0:20:34.23,Default,,0000,0000,0000,,bandgaps. RAM tends to be Hard IP, ROM\Ntends to be Hard IP, eFuze that stores
Dialogue: 0,0:20:34.23,0:20:38.37,Default,,0000,0000,0000,,your keys is going to be given to you as\Nan opaque block, the pad ring around your
Dialogue: 0,0:20:38.37,0:20:41.86,Default,,0000,0000,0000,,chip, the thing that protects your chip\Nfrom ESD, that's going to be an opaque
Dialogue: 0,0:20:41.86,0:20:46.48,Default,,0000,0000,0000,,block. Basically all the points you need\Nto backdoor your RTL are going to be
Dialogue: 0,0:20:46.48,0:20:52.01,Default,,0000,0000,0000,,trusted in the foundry in a modern\Nprocess. So OK, let's say, fine, we're
Dialogue: 0,0:20:52.01,0:20:55.65,Default,,0000,0000,0000,,going ahead and build all of our own IP\Nblocks as well. We're gonna compile our
Dialogue: 0,0:20:55.65,0:21:00.18,Default,,0000,0000,0000,,RAMs, do our own IO, everything, right?.\NSo we're safe, right? Well, turns out that
Dialogue: 0,0:21:00.18,0:21:04.08,Default,,0000,0000,0000,,masks can be tampered with post-\Nprocessing. So if you're going to do
Dialogue: 0,0:21:04.08,0:21:07.82,Default,,0000,0000,0000,,anything in a modern process, the mask\Ndesigns change quite dramatically from
Dialogue: 0,0:21:07.82,0:21:11.24,Default,,0000,0000,0000,,what you drew them to what actually ends\Nup in the line: They get fractured into
Dialogue: 0,0:21:11.24,0:21:14.94,Default,,0000,0000,0000,,multiple masks, they have resolution\Ncorrection techniques applied to them and
Dialogue: 0,0:21:14.94,0:21:20.70,Default,,0000,0000,0000,,then they always go through an editing\Nphase. So masks are not born perfect. Masks
Dialogue: 0,0:21:20.70,0:21:24.26,Default,,0000,0000,0000,,have defects on the inside. And so you can\Nlook up papers about how they go and they
Dialogue: 0,0:21:24.26,0:21:28.22,Default,,0000,0000,0000,,inspect the mask, every single line on the\Ninside when they find an error, they'll
Dialogue: 0,0:21:28.22,0:21:32.08,Default,,0000,0000,0000,,patch over it, they'll go ahead and add\Nbits of metal and then take away bits of
Dialogue: 0,0:21:32.08,0:21:36.35,Default,,0000,0000,0000,,glass to go ahead and make that mask\Nperfect or, better in some way, if you
Dialogue: 0,0:21:36.35,0:21:40.46,Default,,0000,0000,0000,,have access to the editing capability. So\Nwhat can you do with mask-editing? Well,
Dialogue: 0,0:21:40.46,0:21:45.08,Default,,0000,0000,0000,,there's been a lot of papers written on\Nthis. You can look up ones on, for
Dialogue: 0,0:21:45.08,0:21:48.59,Default,,0000,0000,0000,,example, "Dopant tampering". This one\Nactually has no morphological change. You
Dialogue: 0,0:21:48.59,0:21:52.40,Default,,0000,0000,0000,,can't look at it under a microscope and\Ndetect Dopant tampering. You have to have
Dialogue: 0,0:21:52.40,0:21:57.02,Default,,0000,0000,0000,,something and either you have to do some\Nwet chemistry or some X-ray-spectroscopy
Dialogue: 0,0:21:57.02,0:22:03.86,Default,,0000,0000,0000,,to figure it out. This allows for circuit\Nlevel change without a gross morphological
Dialogue: 0,0:22:03.86,0:22:07.60,Default,,0000,0000,0000,,change of the circuit. And so this can\Nallow for tampering with things like RNGs
Dialogue: 0,0:22:07.60,0:22:15.50,Default,,0000,0000,0000,,or some logic paths. There are oftentimes\Nspare cells inside of your ASIC, since
Dialogue: 0,0:22:15.50,0:22:18.23,Default,,0000,0000,0000,,everyone makes mistakes, including chip\Ndesigners and so you want a patch over
Dialogue: 0,0:22:18.23,0:22:22.07,Default,,0000,0000,0000,,that. It can be done at the mask level, by\Nsignal bypassing, these types of things.
Dialogue: 0,0:22:22.07,0:22:29.32,Default,,0000,0000,0000,,So some certain attacks can still happen\Nat the mask level. So that's a very quick
Dialogue: 0,0:22:29.32,0:22:33.70,Default,,0000,0000,0000,,sort of idea of how bad can it get. When\Nyou talk about the time of check, time of
Dialogue: 0,0:22:33.70,0:22:39.72,Default,,0000,0000,0000,,use trust problem inside the supply chain.\NThe short summary of implants is that
Dialogue: 0,0:22:39.72,0:22:43.51,Default,,0000,0000,0000,,there's a lot of places to hide them. Not\Nall of them are expensive or hard. I
Dialogue: 0,0:22:43.51,0:22:48.07,Default,,0000,0000,0000,,talked about some of the more expensive or\Nhard ones. But remember, wire bonding is
Dialogue: 0,0:22:48.07,0:22:52.77,Default,,0000,0000,0000,,actually a pretty easy process. It's not\Nhard to do and it's hard to detect. And
Dialogue: 0,0:22:52.77,0:22:56.35,Default,,0000,0000,0000,,there's really no actual essential\Ncorrelation between detection difficulty
Dialogue: 0,0:22:56.35,0:23:02.06,Default,,0000,0000,0000,,and difficulty of the attack, if you're\Nvery careful in planning the attack. So,
Dialogue: 0,0:23:02.06,0:23:06.24,Default,,0000,0000,0000,,okay, implants are possible. It's just\Nthis. Let's agree on that maybe. So now
Dialogue: 0,0:23:06.24,0:23:08.54,Default,,0000,0000,0000,,the solution is we should just have\Ntrustable factories. Let's go ahead and
Dialogue: 0,0:23:08.54,0:23:12.44,Default,,0000,0000,0000,,bring the fabs to the EU. Let's have a fab\Nin my backyard or whatever it is, these
Dialogue: 0,0:23:12.44,0:23:17.58,Default,,0000,0000,0000,,these types of things. Let's make sure all\Nthe workers are logged and registered,
Dialogue: 0,0:23:17.58,0:23:22.40,Default,,0000,0000,0000,,that sort of thing. Let's talk about that.\NSo if you think about hardware, there's
Dialogue: 0,0:23:22.40,0:23:26.43,Default,,0000,0000,0000,,you, right?. And then we can talk about\Nevil maids. But let's not actually talk
Dialogue: 0,0:23:26.43,0:23:30.27,Default,,0000,0000,0000,,about those, because that's actually kind\Nof a minority case to worry about. But
Dialogue: 0,0:23:30.27,0:23:35.65,Default,,0000,0000,0000,,let's think about how stuff gets to you.\NThere's a distributor, who goes through a
Dialogue: 0,0:23:35.65,0:23:39.33,Default,,0000,0000,0000,,courier, who gets to you. All right. So\Nwe've gone and done all this stuff for the
Dialogue: 0,0:23:39.33,0:23:43.68,Default,,0000,0000,0000,,trustful factory. But it's actually\Ndocumented that couriers have been
Dialogue: 0,0:23:43.68,0:23:50.30,Default,,0000,0000,0000,,intercepted and implants loaded. You know,\Nby for example, the NSA on Cisco products.
Dialogue: 0,0:23:50.30,0:23:55.03,Default,,0000,0000,0000,,Now, you don't even have to have access to\Ncouriers, now. Thanks to the way modern
Dialogue: 0,0:23:55.03,0:24:00.73,Default,,0000,0000,0000,,commerce works, other customers can go\Nahead and just buy a product, tamper with
Dialogue: 0,0:24:00.73,0:24:04.88,Default,,0000,0000,0000,,it, seal it back in the box, send it back\Nto your distributor. And then maybe you
Dialogue: 0,0:24:04.88,0:24:07.88,Default,,0000,0000,0000,,get one, right? That can be good enough.\NParticularly, if you know a corporation is
Dialogue: 0,0:24:07.88,0:24:10.60,Default,,0000,0000,0000,,in a particular area. Targeting them, you\Nbuy a bunch of hard drives in the area,
Dialogue: 0,0:24:10.60,0:24:12.51,Default,,0000,0000,0000,,seal them up, send them back and\Neventually one of them ends up in the
Dialogue: 0,0:24:12.51,0:24:16.75,Default,,0000,0000,0000,,right place and you've got your implant,\Nright? So there's a great talk last year
Dialogue: 0,0:24:16.75,0:24:20.20,Default,,0000,0000,0000,,at 35C3. I recommend you check it out.\NThat talks a little bit more about the
Dialogue: 0,0:24:20.20,0:24:25.10,Default,,0000,0000,0000,,scenario, sort of removing tamper stickers\Nand you know, the possibility that some
Dialogue: 0,0:24:25.10,0:24:29.41,Default,,0000,0000,0000,,crypto wallets were sent back in the\Nsupply chain then and tampered with. OK,
Dialogue: 0,0:24:29.41,0:24:32.48,Default,,0000,0000,0000,,and then let's let's take that back. We\Nhave to now worry about the wonderful
Dialogue: 0,0:24:32.48,0:24:36.49,Default,,0000,0000,0000,,people in customs. We have to worry about\Nthe wonderful people in the factory who
Dialogue: 0,0:24:36.49,0:24:40.37,Default,,0000,0000,0000,,have access to your hardware. And so if\Nyou cut to the chase, it's a huge attack
Dialogue: 0,0:24:40.37,0:24:44.48,Default,,0000,0000,0000,,surface in terms of the supply chain,\Nright? From you to the courier to the
Dialogue: 0,0:24:44.48,0:24:49.12,Default,,0000,0000,0000,,distributor, customs, box build, the box\Nbuild factory itself. Oftentimes we'll use
Dialogue: 0,0:24:49.12,0:24:53.30,Default,,0000,0000,0000,,gray market resources to help make\Nthemselves more profitable, right? You
Dialogue: 0,0:24:53.30,0:24:56.98,Default,,0000,0000,0000,,have distributors who go to them. You\Ndon't even know who those guys are. PCB
Dialogue: 0,0:24:56.98,0:25:00.74,Default,,0000,0000,0000,,assembly, components, boards, chip fab,\Npackaging, the whole thing, right? Every
Dialogue: 0,0:25:00.74,0:25:04.27,Default,,0000,0000,0000,,single point is a place where someone can\Ngo ahead and touch a piece of hardware
Dialogue: 0,0:25:04.27,0:25:08.97,Default,,0000,0000,0000,,along the chain. So can open source save\Nus in this scenario? Does open hardware
Dialogue: 0,0:25:08.97,0:25:12.14,Default,,0000,0000,0000,,solve this problem? Right. Let's think\Nabout it. Let's go ahead and throw some
Dialogue: 0,0:25:12.14,0:25:16.09,Default,,0000,0000,0000,,developers with git on the left hand side.\NHow far does it get, right? Well, we can
Dialogue: 0,0:25:16.09,0:25:18.88,Default,,0000,0000,0000,,have some continuous integration checks\Nthat make sure that you know the hardware
Dialogue: 0,0:25:18.88,0:25:23.05,Default,,0000,0000,0000,,is correct. We can have some open PCB\Ndesigns. We have some open PDK, but then
Dialogue: 0,0:25:23.05,0:25:27.23,Default,,0000,0000,0000,,from that point, it goes into a rather\Nopaque machine and then, OK, maybe we can
Dialogue: 0,0:25:27.23,0:25:31.09,Default,,0000,0000,0000,,put some test on the very edge before exit\Nthe factory to try and catch some
Dialogue: 0,0:25:31.09,0:25:36.11,Default,,0000,0000,0000,,potential issues, right? But you can see\Nall the area, other places, where a time
Dialogue: 0,0:25:36.11,0:25:40.75,Default,,0000,0000,0000,,of check, time of use problem can happen.\NAnd this is why, you know, I'm saying that
Dialogue: 0,0:25:40.75,0:25:45.70,Default,,0000,0000,0000,,open hardware on its own is not sufficient\Nto solve this trust problem. Right? And
Dialogue: 0,0:25:45.70,0:25:49.50,Default,,0000,0000,0000,,the big problem at the end of the day is\Nthat you can't hash hardware. Right? There
Dialogue: 0,0:25:49.50,0:25:53.95,Default,,0000,0000,0000,,is no hash function for hardware. That's\Nwhy I want to go through that early today.
Dialogue: 0,0:25:53.95,0:25:57.48,Default,,0000,0000,0000,,There's no convenient, easy way to\Nbasically confirming the correctness of
Dialogue: 0,0:25:57.48,0:26:00.71,Default,,0000,0000,0000,,your hardware before you use it. Some\Npeople say, well, bunnie, said once, there
Dialogue: 0,0:26:00.71,0:26:05.32,Default,,0000,0000,0000,,is always a bigger microscope, right? You\Nknow, I do some, security reverse
Dialogue: 0,0:26:05.32,0:26:08.37,Default,,0000,0000,0000,,engineering stuff. This is true, right? So\Nthere's a wonderful technique called
Dialogue: 0,0:26:08.37,0:26:12.48,Default,,0000,0000,0000,,ptychographic X-ray Imaging, there is a\Ngreat paper in nature about it, where they
Dialogue: 0,0:26:12.48,0:26:16.88,Default,,0000,0000,0000,,take like a modern i7 CPU and they get\Ndown to the gate level nondestructively
Dialogue: 0,0:26:16.88,0:26:20.60,Default,,0000,0000,0000,,with it, right? It's great for reverse\Nengineering or for design verification.
Dialogue: 0,0:26:20.60,0:26:24.19,Default,,0000,0000,0000,,The problem number one is it literally\Nneeds a building sized microscope. It was
Dialogue: 0,0:26:24.19,0:26:28.94,Default,,0000,0000,0000,,done at the Swiss light source, that donut\Nshaped thing is the size of the light
Dialogue: 0,0:26:28.94,0:26:33.00,Default,,0000,0000,0000,,source for doing that type of\Nverification, right? So you're not going
Dialogue: 0,0:26:33.00,0:26:36.59,Default,,0000,0000,0000,,to have one at your point of use, right?\NYou're going to check it there and then
Dialogue: 0,0:26:36.59,0:26:41.28,Default,,0000,0000,0000,,probably courier it to yourself again.\NTime of check is not time of use. Problem
Dialogue: 0,0:26:41.28,0:26:46.19,Default,,0000,0000,0000,,number two, it's expensive to do so.\NVerifying one chip only verifies one chip
Dialogue: 0,0:26:46.19,0:26:49.76,Default,,0000,0000,0000,,and as I said earlier, just because 99.9%\Nof your hardware is OK, doesn't mean
Dialogue: 0,0:26:49.76,0:26:54.07,Default,,0000,0000,0000,,you're safe. Sometimes all it takes is one\Nserver out of a thousand, to break some
Dialogue: 0,0:26:54.07,0:26:59.11,Default,,0000,0000,0000,,fundamental assumptions that you have\Nabout your cloud. And random sampling just
Dialogue: 0,0:26:59.11,0:27:02.03,Default,,0000,0000,0000,,isn't good enough, right? I mean, would\Nyou random sample signature checks on
Dialogue: 0,0:27:02.03,0:27:06.24,Default,,0000,0000,0000,,software that you install? Download? No.\NYou insist 100% check and everything. If
Dialogue: 0,0:27:06.24,0:27:08.44,Default,,0000,0000,0000,,you want that same standard of\Nreliability, you have to do that for
Dialogue: 0,0:27:08.44,0:27:12.86,Default,,0000,0000,0000,,hardware. So then, is there any role for\Nopen source and trustful hardware?
Dialogue: 0,0:27:12.86,0:27:16.87,Default,,0000,0000,0000,,Absolutely, yes. Some of you guys may be\Nfamiliar with that little guy on the
Dialogue: 0,0:27:16.87,0:27:22.80,Default,,0000,0000,0000,,right, the SPECTRE logo. So correctness is\Nvery, very hard. Peer review can help fix
Dialogue: 0,0:27:22.80,0:27:27.16,Default,,0000,0000,0000,,correctness bugs. Micro architectural\Ntransparency can able the fixes in SPECTRE
Dialogue: 0,0:27:27.16,0:27:30.25,Default,,0000,0000,0000,,like situations. So, you know, for\Nexample, you would love to be able to say
Dialogue: 0,0:27:30.25,0:27:33.75,Default,,0000,0000,0000,,we're entering a critical region. Let's\Nturn off all the micro architectural
Dialogue: 0,0:27:33.75,0:27:38.34,Default,,0000,0000,0000,,optimizations, sacrifice performance and\Nthen run the code securely and then go
Dialogue: 0,0:27:38.34,0:27:41.25,Default,,0000,0000,0000,,back into, who cares what mode, and just\Nget done fast, right? That would be a
Dialogue: 0,0:27:41.25,0:27:44.59,Default,,0000,0000,0000,,switch I would love to have. But without\Nthat sort of transparency or without the
Dialogue: 0,0:27:44.59,0:27:48.50,Default,,0000,0000,0000,,bill to review it, we can't do that. Also,\Nyou know, community driven features and
Dialogue: 0,0:27:48.50,0:27:51.39,Default,,0000,0000,0000,,community own designs is very empowering\Nand make sure that we're sort of building
Dialogue: 0,0:27:51.39,0:27:56.71,Default,,0000,0000,0000,,the right hardware for the job and that\Nit's upholding our standards. So there is
Dialogue: 0,0:27:56.71,0:28:01.85,Default,,0000,0000,0000,,a role. It's necessary, but it's not\Nsufficient for trustable hardware. Now the
Dialogue: 0,0:28:01.85,0:28:06.22,Default,,0000,0000,0000,,question is, OK, can we solve the point of\Nuse hardware verification problem? Is it
Dialogue: 0,0:28:06.22,0:28:09.51,Default,,0000,0000,0000,,all gloom and doom from here on? Well, I\Ndidn't bring us here to tell you it's just
Dialogue: 0,0:28:09.51,0:28:14.72,Default,,0000,0000,0000,,gloom and doom. I've thought about this\Nand I've kind of boiled it into three
Dialogue: 0,0:28:14.72,0:28:19.43,Default,,0000,0000,0000,,principles for building verifiable\Nhardware. The three principles are: 1)
Dialogue: 0,0:28:19.43,0:28:23.02,Default,,0000,0000,0000,,Complexity is the enemy of verification.\N2) We should verify entire systems, not
Dialogue: 0,0:28:23.02,0:28:26.40,Default,,0000,0000,0000,,just components. 3) And we need to empower\Nend-users to verify and seal their
Dialogue: 0,0:28:26.40,0:28:31.58,Default,,0000,0000,0000,,hardware. We'll go into this in the\Nremainder of the talk. The first one is
Dialogue: 0,0:28:31.58,0:28:37.09,Default,,0000,0000,0000,,that complexity is complicated. Right?\NWithout a hashing function, verification
Dialogue: 0,0:28:37.09,0:28:43.83,Default,,0000,0000,0000,,rolls back to bit-by-bit or atom-by-atom\Nverification. Modern phones just have so
Dialogue: 0,0:28:43.83,0:28:48.69,Default,,0000,0000,0000,,many components. Even if I gave you the\Nfull source code for the SOC inside of a
Dialogue: 0,0:28:48.69,0:28:51.96,Default,,0000,0000,0000,,phone down to the mass level, what are you\Ngoing to do with it? How are you going to
Dialogue: 0,0:28:51.96,0:28:56.56,Default,,0000,0000,0000,,know that this mass actually matches the\Nchip and those two haven't been modified?
Dialogue: 0,0:28:56.56,0:29:01.40,Default,,0000,0000,0000,,So more complexity, is more difficult. The\Nsolution is: Let's go to simplicity,
Dialogue: 0,0:29:01.40,0:29:04.25,Default,,0000,0000,0000,,right? Let's just build things from\Ndiscrete transistors. Someone's done this.
Dialogue: 0,0:29:04.25,0:29:08.25,Default,,0000,0000,0000,,The Monster 6502 is great. I love the\Nproject. Very easy to verify. Runs at 50
Dialogue: 0,0:29:08.25,0:29:13.25,Default,,0000,0000,0000,,kHz. So you're not going to do a lot\Nwith that. Well, let's build processors at
Dialogue: 0,0:29:13.25,0:29:16.49,Default,,0000,0000,0000,,a visually inspectable process node. Go to\N500 nanometers. You can see that with
Dialogue: 0,0:29:16.49,0:29:21.45,Default,,0000,0000,0000,,light. Well, you know, 100 megahertz clock\Nrate and a very high power consumption and
Dialogue: 0,0:29:21.45,0:29:25.42,Default,,0000,0000,0000,,you know, a couple kilobytes RAM probably\Nis not going to really do it either.
Dialogue: 0,0:29:25.42,0:29:30.10,Default,,0000,0000,0000,,Right? So the point of use verification is\Na tradeoff between ease of verification
Dialogue: 0,0:29:30.10,0:29:34.07,Default,,0000,0000,0000,,and features and usability. Right? So\Nthese two products up here largely do the
Dialogue: 0,0:29:34.07,0:29:39.28,Default,,0000,0000,0000,,same thing. Air pods. Right? And\Nheadphones on your head. Right? Air pods
Dialogue: 0,0:29:39.28,0:29:43.96,Default,,0000,0000,0000,,have something on the order of tens of\Nmillions of transistors for you to verify.
Dialogue: 0,0:29:43.96,0:29:47.57,Default,,0000,0000,0000,,The headphone that goes on your head. Like\NI can actually go to Maxwell's equations
Dialogue: 0,0:29:47.57,0:29:50.63,Default,,0000,0000,0000,,and actually tell you how the magnets work\Nfrom very first principles. And there's
Dialogue: 0,0:29:50.63,0:29:54.49,Default,,0000,0000,0000,,probably one transistor on the inside of\Nthe microphone to go ahead and amplify the
Dialogue: 0,0:29:54.49,0:29:59.74,Default,,0000,0000,0000,,membrane. And that's it. Right? So this\None, you do sacrifice some features and
Dialogue: 0,0:29:59.74,0:30:02.91,Default,,0000,0000,0000,,usability, when you go to a headset. Like\Nyou can't say, hey, Siri, and they will
Dialogue: 0,0:30:02.91,0:30:07.51,Default,,0000,0000,0000,,listen to you and know what you're doing,\Nbut it's very easy to verify and know
Dialogue: 0,0:30:07.51,0:30:13.25,Default,,0000,0000,0000,,what's going on. So in order to start a\Ndialog on user verification, we have to
Dialogue: 0,0:30:13.25,0:30:17.15,Default,,0000,0000,0000,,serve a set of context. So I started a\Nproject called 'Betrusted' because the
Dialogue: 0,0:30:17.15,0:30:22.10,Default,,0000,0000,0000,,right answer depends on the context. I\Nwant to establish what might be a minimum
Dialogue: 0,0:30:22.10,0:30:27.12,Default,,0000,0000,0000,,viable, verifiable product. And it's sort\Nof like meant to be user verifiable by
Dialogue: 0,0:30:27.12,0:30:30.23,Default,,0000,0000,0000,,design. And when we think of it as a\Nhardware software distro. So it's meant to
Dialogue: 0,0:30:30.23,0:30:34.29,Default,,0000,0000,0000,,be modified and changed and customized\Nbased upon the right context at the end of
Dialogue: 0,0:30:34.29,0:30:39.71,Default,,0000,0000,0000,,the day. This a picture of what it looks\Nlike. I actually have a little prototype
Dialogue: 0,0:30:39.71,0:30:43.92,Default,,0000,0000,0000,,here. Very, very, very early product here\Nat the Congress. If you wanna look at it.
Dialogue: 0,0:30:43.92,0:30:48.72,Default,,0000,0000,0000,,It's a mobile device that is meant for\Nsort of communication, sort of text based
Dialogue: 0,0:30:48.72,0:30:52.99,Default,,0000,0000,0000,,communication and maybe voice\Nauthentication. So authenticator tokens
Dialogue: 0,0:30:52.99,0:30:56.32,Default,,0000,0000,0000,,are like a crypto wall if you want. And\Nthe people were thinking about who might
Dialogue: 0,0:30:56.32,0:31:00.99,Default,,0000,0000,0000,,be users are either high value targets\Npolitically or financially. So you don't
Dialogue: 0,0:31:00.99,0:31:04.34,Default,,0000,0000,0000,,have to have a lot of money to be a high\Nvalue target. You could also be in a very
Dialogue: 0,0:31:04.34,0:31:08.62,Default,,0000,0000,0000,,politically risky for some people. And\Nalso, of course, looking at developers and
Dialogue: 0,0:31:08.62,0:31:12.30,Default,,0000,0000,0000,,enthusiasts and ideally we're thinking\Nabout a global demographic, not just
Dialogue: 0,0:31:12.30,0:31:15.89,Default,,0000,0000,0000,,English speaking users, which is sort of a\Nthing when you think about the complexity
Dialogue: 0,0:31:15.89,0:31:18.88,Default,,0000,0000,0000,,standpoint, this is where we really have\Nto sort of champ at the bit and figure out
Dialogue: 0,0:31:18.88,0:31:24.25,Default,,0000,0000,0000,,how to solve a lot of hard problems like\Ngetting Unicode and, you know, right to
Dialogue: 0,0:31:24.25,0:31:28.21,Default,,0000,0000,0000,,left rendering and pictographic fonts to\Nwork inside a very small tax surface
Dialogue: 0,0:31:28.21,0:31:34.42,Default,,0000,0000,0000,,device. So this leads me to the second\Npoint. In which we verify entire systems,
Dialogue: 0,0:31:34.42,0:31:37.78,Default,,0000,0000,0000,,not just components. We all say, well, why\Nnot just build a chip? Why not? You know,
Dialogue: 0,0:31:37.78,0:31:41.90,Default,,0000,0000,0000,,why are you thinking about a whole device?\NRight. The problem is, that private keys
Dialogue: 0,0:31:41.90,0:31:45.83,Default,,0000,0000,0000,,are not your private matters. Screens can\Nbe scraped and keyboards can be logged. So
Dialogue: 0,0:31:45.83,0:31:50.06,Default,,0000,0000,0000,,there's some efforts now to build\Nwonderful security enclaves like Keystone
Dialogue: 0,0:31:50.06,0:31:54.60,Default,,0000,0000,0000,,and Open Titan, which will build, you\Nknow, wonderful secure chips. The problem
Dialogue: 0,0:31:54.60,0:31:58.50,Default,,0000,0000,0000,,is, that even if you manage to keep your\Nkey secret, you still have to get that
Dialogue: 0,0:31:58.50,0:32:03.31,Default,,0000,0000,0000,,information through an insecure CPU from\Nthe screen to the keyboard and so forth.
Dialogue: 0,0:32:03.31,0:32:06.25,Default,,0000,0000,0000,,Right? And so, you know, people who have\Nused these, you know, on screen touch
Dialogue: 0,0:32:06.25,0:32:09.31,Default,,0000,0000,0000,,keyboards have probably seen something of\Na message like this saying that, by the
Dialogue: 0,0:32:09.31,0:32:11.94,Default,,0000,0000,0000,,way, this keyboard can see everything\Nyou're typing, clean your passwords.
Dialogue: 0,0:32:11.94,0:32:14.68,Default,,0000,0000,0000,,Right? And people probably clip and say,\Noh, yeah, sure, whatever. I trust that.
Dialogue: 0,0:32:14.68,0:32:18.84,Default,,0000,0000,0000,,Right? OK, well, this answer, this little\Nenclave on the site here isn't really
Dialogue: 0,0:32:18.84,0:32:22.41,Default,,0000,0000,0000,,doing a lot of good. When you go ahead and\Nyou say, sure, I'll run this implant
Dialogue: 0,0:32:22.41,0:32:28.89,Default,,0000,0000,0000,,method, they can go ahead and modify all\Nmy data and intercept all my data. So in
Dialogue: 0,0:32:28.89,0:32:32.82,Default,,0000,0000,0000,,terms of making a device variable, let's\Ntalk about the concept of practice flow.
Dialogue: 0,0:32:32.82,0:32:36.48,Default,,0000,0000,0000,,How do I take these three principles and\Nturn them into something? So this is you
Dialogue: 0,0:32:36.48,0:32:40.32,Default,,0000,0000,0000,,know, this is the ideal of taking these\Nthree requirements and turning it into the
Dialogue: 0,0:32:40.32,0:32:44.71,Default,,0000,0000,0000,,set of five features, a physical keyboard,\Na black and white LCD, a FPGA-based RISC-V
Dialogue: 0,0:32:44.71,0:32:49.31,Default,,0000,0000,0000,,SoC, users-sealable keys and so on. It's\Neasy to verify and physically protect. So
Dialogue: 0,0:32:49.31,0:32:53.25,Default,,0000,0000,0000,,let's talk about these features one by\None. First one is a physical keyboard. Why
Dialogue: 0,0:32:53.25,0:32:56.26,Default,,0000,0000,0000,,am I using a physical keyboard and not a\Nvirtual keyboard? People love the virtual
Dialogue: 0,0:32:56.26,0:33:00.22,Default,,0000,0000,0000,,keyboard. The problem is that captouch\Nscreens, which is necessary to do a good
Dialogue: 0,0:33:00.22,0:33:04.61,Default,,0000,0000,0000,,virtual keyboard, have a firmware block.\NThey have a microcontroller to do the
Dialogue: 0,0:33:04.61,0:33:07.65,Default,,0000,0000,0000,,touch screens, actually. It's actually\Nreally hard to build these things we want.
Dialogue: 0,0:33:07.65,0:33:10.63,Default,,0000,0000,0000,,If you can do a good job with it and build\Nan awesome open source one, that'll be
Dialogue: 0,0:33:10.63,0:33:15.02,Default,,0000,0000,0000,,great, but that's a project in and of\Nitself. So in order to sort of get an easy
Dialogue: 0,0:33:15.02,0:33:17.60,Default,,0000,0000,0000,,win here and we can, let's just go with\Nthe physical keyboard. So this is what the
Dialogue: 0,0:33:17.60,0:33:21.52,Default,,0000,0000,0000,,device looks like with this cover off. We\Nhave a physical keyboard, PCV with a
Dialogue: 0,0:33:21.52,0:33:24.96,Default,,0000,0000,0000,,little overlay that does, you know, so we\Ncan do multilingual inserts and you can go
Dialogue: 0,0:33:24.96,0:33:28.58,Default,,0000,0000,0000,,to change that out. And it's like it's\Njust a two layer daughter card. Right.
Dialogue: 0,0:33:28.58,0:33:32.65,Default,,0000,0000,0000,,Just hold up to like, you know, like, OK,\Nswitches, wires. Right? Not a lot of
Dialogue: 0,0:33:32.65,0:33:35.50,Default,,0000,0000,0000,,places to hide things. So I'll take that\Nas an easy win for an input surface,
Dialogue: 0,0:33:35.50,0:33:39.54,Default,,0000,0000,0000,,that's verifiable. Right? The output\Nsurface is a little more subtle. So we're
Dialogue: 0,0:33:39.54,0:33:44.47,Default,,0000,0000,0000,,doing a black and white LCD. If you say,\NOK, why not use a curiosity? If you ever
Dialogue: 0,0:33:44.47,0:33:52.28,Default,,0000,0000,0000,,take apart a liquid crystal display, look\Nfor a tiny little thin rectangle sort of
Dialogue: 0,0:33:52.28,0:33:57.13,Default,,0000,0000,0000,,located near the display area. That's\Nactually a silicon chip that's bonded to
Dialogue: 0,0:33:57.13,0:34:00.63,Default,,0000,0000,0000,,the glass. That's what it looks like at\Nthe end of the day. That contains a frame
Dialogue: 0,0:34:00.63,0:34:05.17,Default,,0000,0000,0000,,buffer and a command interface. It has\Nmillions of transistors on the inside and
Dialogue: 0,0:34:05.17,0:34:08.91,Default,,0000,0000,0000,,you don't know what it does. So if you're\Never assuming your adversary may be
Dialogue: 0,0:34:08.91,0:34:14.24,Default,,0000,0000,0000,,tampering with your CPU, this is also a\Nviable place you have to worry about. So I
Dialogue: 0,0:34:14.24,0:34:18.99,Default,,0000,0000,0000,,found a screen. It's called a memory LCD\Nby sharp electronics. It turns out they do
Dialogue: 0,0:34:18.99,0:34:22.98,Default,,0000,0000,0000,,all the drive electrons on glass. So this\Nis a picture of the driver electronics on
Dialogue: 0,0:34:22.98,0:34:26.78,Default,,0000,0000,0000,,the screen through like a 50x microscope\Nwith a bright light behind it. Right? You
Dialogue: 0,0:34:26.78,0:34:34.37,Default,,0000,0000,0000,,can actually see the transistors that are\Nused to to drive everything on the display
Dialogue: 0,0:34:34.37,0:34:37.98,Default,,0000,0000,0000,,it's a nondestructive method of\Nverification. But actually more important
Dialogue: 0,0:34:37.98,0:34:41.79,Default,,0000,0000,0000,,to the point is that there's so few places\Nto hide things, you probably don't need to
Dialogue: 0,0:34:41.79,0:34:45.36,Default,,0000,0000,0000,,check it, right? There's not - If you want\Nto add an implant to this, you would need
Dialogue: 0,0:34:45.36,0:34:50.47,Default,,0000,0000,0000,,to grow the glass area substantially or\Nadd a silicon chip, which is a thing that
Dialogue: 0,0:34:50.47,0:34:55.07,Default,,0000,0000,0000,,you'll notice, right. So at the end of the\Nday, the less places to hide things is
Dialogue: 0,0:34:55.07,0:34:58.51,Default,,0000,0000,0000,,less need to check things. And so I can\Nfeel like this is a screen where I can
Dialogue: 0,0:34:58.51,0:35:02.75,Default,,0000,0000,0000,,write data to, and it'll show what I want\Nto show. The good news is that display has
Dialogue: 0,0:35:02.75,0:35:07.12,Default,,0000,0000,0000,,a 200 ppi pixel density. So it's not -\Neven though it's black and white - it's
Dialogue: 0,0:35:07.12,0:35:12.41,Default,,0000,0000,0000,,kind of closer to E-Paper. EPD in terms of\Nresolution. So now we come to the hard
Dialogue: 0,0:35:12.41,0:35:16.87,Default,,0000,0000,0000,,part, right, the CPU. The silicon problem,\Nright? Any chip built in the last two
Dialogue: 0,0:35:16.87,0:35:20.56,Default,,0000,0000,0000,,decades is not going to be inspectable,\Nfully inspectable with optical microscope,
Dialogue: 0,0:35:20.56,0:35:24.47,Default,,0000,0000,0000,,right? Thorough analysis requires removing\Nlayers and layers of metal and dielectric.
Dialogue: 0,0:35:24.47,0:35:29.29,Default,,0000,0000,0000,,This is sort of a cross section of a\Nmodernish chip and you can see the sort of
Dialogue: 0,0:35:29.29,0:35:34.93,Default,,0000,0000,0000,,the huge stack of things to look at on\Nthis. This process is destructive and you
Dialogue: 0,0:35:34.93,0:35:37.57,Default,,0000,0000,0000,,can think of it as hashing, but it's a\Nlittle bit too literal, right? We want
Dialogue: 0,0:35:37.57,0:35:40.68,Default,,0000,0000,0000,,something where we can check the thing\Nthat we're going to use and then not
Dialogue: 0,0:35:40.68,0:35:46.72,Default,,0000,0000,0000,,destroy it. So I've spent quite a bit of\Ntime thinking about options for
Dialogue: 0,0:35:46.72,0:35:50.32,Default,,0000,0000,0000,,nondestructive silicon verification. The\Nbest I could come up with maybe was using
Dialogue: 0,0:35:50.32,0:35:54.39,Default,,0000,0000,0000,,optical fauilt induction somehow combined\Nwith some chip design techniques to go
Dialogue: 0,0:35:54.39,0:35:58.01,Default,,0000,0000,0000,,ahead and like scan a laser across and\Nlook at fault syndromes and figure out,
Dialogue: 0,0:35:58.01,0:36:02.02,Default,,0000,0000,0000,,you know, does the thing... do the gates\Nthat we put down correspond to the thing
Dialogue: 0,0:36:02.02,0:36:07.35,Default,,0000,0000,0000,,that I built. The problem is, I couldn't\Nthink of a strategy to do it that wouldn't
Dialogue: 0,0:36:07.35,0:36:10.46,Default,,0000,0000,0000,,take years and tens of millions of dollars\Nto develop, which puts it a little bit far
Dialogue: 0,0:36:10.46,0:36:13.55,Default,,0000,0000,0000,,out there and probably in the realm of\Nlike sort of venture funded activities,
Dialogue: 0,0:36:13.55,0:36:18.25,Default,,0000,0000,0000,,which is not really going to be very\Nempowering of everyday people. So let's
Dialogue: 0,0:36:18.25,0:36:22.38,Default,,0000,0000,0000,,say I want something a little more short\Nterm than that, then that sort of this,
Dialogue: 0,0:36:22.38,0:36:27.13,Default,,0000,0000,0000,,you know, sort of, you know, platonic\Nideal of verifiability. So the compromise
Dialogue: 0,0:36:27.13,0:36:32.30,Default,,0000,0000,0000,,I sort of arrived at is the FPGA. So field\Nprogrammable gate arrays, that's what FPGA
Dialogue: 0,0:36:32.30,0:36:37.07,Default,,0000,0000,0000,,stands for, are large arrays of logic and\Nwires that are user configured to
Dialogue: 0,0:36:37.07,0:36:42.11,Default,,0000,0000,0000,,implement hardware designs. So this here\Nis an image inside an FPGA design tool. On
Dialogue: 0,0:36:42.11,0:36:47.11,Default,,0000,0000,0000,,the top right is an example of one sort of\Nlogic sub cell. It's got a few flip flops
Dialogue: 0,0:36:47.11,0:36:51.92,Default,,0000,0000,0000,,and lookup tables in it. It's embedded in\Nthis huge mass of wires that allow you to
Dialogue: 0,0:36:51.92,0:36:56.07,Default,,0000,0000,0000,,wire it up at runtime to figure out what's\Ngoing on. And one thing that this diagram
Dialogue: 0,0:36:56.07,0:36:59.79,Default,,0000,0000,0000,,here shows is I'm able to sort of\Ncorrelate design. I can see "Okay. The
Dialogue: 0,0:36:59.79,0:37:04.30,Default,,0000,0000,0000,,decode_to_execute_INSTRUCTION_reg bit 26\Ncorresponds to this net." So now we're
Dialogue: 0,0:37:04.30,0:37:09.26,Default,,0000,0000,0000,,sort of like bring that Time Of Check a\Nlittle bit closer to Time Of Use. And so
Dialogue: 0,0:37:09.26,0:37:13.10,Default,,0000,0000,0000,,the idea is to narrow that ToCToU gap by\Ncompiling your own CPU. We can basically
Dialogue: 0,0:37:13.10,0:37:16.51,Default,,0000,0000,0000,,give you the CPU from source. You can\Ncompile it yourself. You can confirm the
Dialogue: 0,0:37:16.51,0:37:20.60,Default,,0000,0000,0000,,bit stream. So now we're sort of enabling\Na bit more of that trust transfer like
Dialogue: 0,0:37:20.60,0:37:24.99,Default,,0000,0000,0000,,software, right. But there's a subtlety in\Nthat the toolchains are not necessarily
Dialogue: 0,0:37:24.99,0:37:30.38,Default,,0000,0000,0000,,always open. There's some FOSS flows like\Nsymbiflow. They have a 100% open flow for
Dialogue: 0,0:37:30.38,0:37:35.15,Default,,0000,0000,0000,,ICE40 and ECP5 and there's like 7-series\Nwhere they've a coming-soon status, but
Dialogue: 0,0:37:35.15,0:37:41.52,Default,,0000,0000,0000,,they currently require some closed vendor\Ntools. So picking FPGA is a difficult
Dialogue: 0,0:37:41.52,0:37:45.23,Default,,0000,0000,0000,,choice. There's a usability versus\Nverification tradeoff here. The big
Dialogue: 0,0:37:45.23,0:37:49.12,Default,,0000,0000,0000,,usability issue is battery life. If we're\Ngoing for a mobile device, you want to use
Dialogue: 0,0:37:49.12,0:37:54.19,Default,,0000,0000,0000,,it all day long or you want to be dead by\Nnoon. It turns out that the best sort of
Dialogue: 0,0:37:54.19,0:37:57.95,Default,,0000,0000,0000,,chip in terms of battery life is a\NSpartan7. It gives you 4x, roughly 3 to
Dialogue: 0,0:37:57.95,0:38:05.33,Default,,0000,0000,0000,,4x, in terms of battery life. But the tool\Nflow is still semi-closed. But the, you
Dialogue: 0,0:38:05.33,0:38:09.20,Default,,0000,0000,0000,,know, I am optimistic that symbiflow will\Nget there and we can also fork and make an
Dialogue: 0,0:38:09.20,0:38:13.26,Default,,0000,0000,0000,,ECP5 version if that's a problem at the\Nend of day. So let's talk a little bit
Dialogue: 0,0:38:13.26,0:38:18.05,Default,,0000,0000,0000,,more about sort of FPGA features. So one\Nthing I like to say about FPGA is: they
Dialogue: 0,0:38:18.05,0:38:22.42,Default,,0000,0000,0000,,offer a sort of ASLR, so address-space\Nlayout randomization, but for hardware.
Dialogue: 0,0:38:22.42,0:38:27.27,Default,,0000,0000,0000,,Essentially, a design has a kind of\Npseudo-random mapping to the device. This
Dialogue: 0,0:38:27.27,0:38:31.02,Default,,0000,0000,0000,,is a sort of a screenshot of two\Ncompilation runs at the same source code
Dialogue: 0,0:38:31.02,0:38:35.38,Default,,0000,0000,0000,,with a very small modification to it. And\Nbasically a version number stored in a
Dialogue: 0,0:38:35.38,0:38:41.71,Default,,0000,0000,0000,,GPR. And then you can see that the\Nactually the locations of a lot of the
Dialogue: 0,0:38:41.71,0:38:45.61,Default,,0000,0000,0000,,registers are basically shifted around.\NThe reason why this is important is
Dialogue: 0,0:38:45.61,0:38:50.50,Default,,0000,0000,0000,,because this hinders a significant class\Nof silicon attacks. All those small mass
Dialogue: 0,0:38:50.50,0:38:53.85,Default,,0000,0000,0000,,level changes I talked about the ones\Nwhere we just "Okay, we're just gonna head
Dialogue: 0,0:38:53.85,0:38:58.46,Default,,0000,0000,0000,,and change a few wires or run a couple\Nlogic cells around", those become more
Dialogue: 0,0:38:58.46,0:39:02.33,Default,,0000,0000,0000,,less likely to capture a critical bit. So\Nif you want to go ahead and backdoor a
Dialogue: 0,0:39:02.33,0:39:05.76,Default,,0000,0000,0000,,full FPGA, you're going to have to change\Nthe die size. You have to make it
Dialogue: 0,0:39:05.76,0:39:09.97,Default,,0000,0000,0000,,substantially larger to be able to sort of\Nlike swap out the function in those cases.
Dialogue: 0,0:39:09.97,0:39:13.48,Default,,0000,0000,0000,,And so now the verification bar goes from\Nlooking for a needle in a haystack to
Dialogue: 0,0:39:13.48,0:39:16.96,Default,,0000,0000,0000,,measuring the size of the haystack, which\Nis a bit easier to do towards the user
Dialogue: 0,0:39:16.96,0:39:22.14,Default,,0000,0000,0000,,side of things. And it turns out, at least\Nin Xilinx-land, it's just a change of a
Dialogue: 0,0:39:22.14,0:39:28.82,Default,,0000,0000,0000,,random parameter does the trick. So some\Npotential attack vectors against FPGA is
Dialogue: 0,0:39:28.82,0:39:34.28,Default,,0000,0000,0000,,like "OK, well, it's closed silicon." What\Nare the backdoors there? Notably inside a
Dialogue: 0,0:39:34.28,0:39:38.59,Default,,0000,0000,0000,,7-series FPGA they actually document\Nintrospection features. You can pull out
Dialogue: 0,0:39:38.59,0:39:42.87,Default,,0000,0000,0000,,anything inside the chip by instantiating\Na certain special block. And then we still
Dialogue: 0,0:39:42.87,0:39:46.35,Default,,0000,0000,0000,,also have to worry about the whole class\Nof like man in the middle. I/O- and JTAG
Dialogue: 0,0:39:46.35,0:39:49.99,Default,,0000,0000,0000,,implants that I talked about earlier. So\NIt's easy, really easy, to mitigate the
Dialogue: 0,0:39:49.99,0:39:52.81,Default,,0000,0000,0000,,known blocks, basically lock them down,\Ntie them down, check them in the bit
Dialogue: 0,0:39:52.81,0:39:58.29,Default,,0000,0000,0000,,stream, right? In terms of the I/O-man-in-\Nthe-middle stuff, this is where we're
Dialogue: 0,0:39:58.29,0:40:02.75,Default,,0000,0000,0000,,talking about like someone goes ahead and\Nputs a chip in in the path of your FPGA.
Dialogue: 0,0:40:02.75,0:40:06.07,Default,,0000,0000,0000,,There's a few tricks you can do. We can do\Nsort of bust encryption on the RAM and the
Dialogue: 0,0:40:06.07,0:40:11.69,Default,,0000,0000,0000,,ROM at the design level that frustrates\Nthese. At the implementation, basically,
Dialogue: 0,0:40:11.69,0:40:15.19,Default,,0000,0000,0000,,we can use the fact that data pins and\Naddress pins can be permuted without
Dialogue: 0,0:40:15.19,0:40:19.26,Default,,0000,0000,0000,,affecting the device's function. So every\Ndesign can go ahead and permute those data
Dialogue: 0,0:40:19.26,0:40:24.67,Default,,0000,0000,0000,,and address pin mappings sort of uniquely.\NSo any particular implant that goes in
Dialogue: 0,0:40:24.67,0:40:28.15,Default,,0000,0000,0000,,will have to be able to compensate for all\Nthose combinations, making the implant a
Dialogue: 0,0:40:28.15,0:40:32.34,Default,,0000,0000,0000,,little more difficult to do. And of\Ncourse, we can also fall back to sort of
Dialogue: 0,0:40:32.34,0:40:37.96,Default,,0000,0000,0000,,careful inspection of the device. In terms\Nof the closed source silicon, the thing
Dialogue: 0,0:40:37.96,0:40:42.16,Default,,0000,0000,0000,,that I'm really optimistic for there is\Nthat so in terms of the closed source
Dialogue: 0,0:40:42.16,0:40:46.52,Default,,0000,0000,0000,,system, the thing that we have to worry\Nabout is that, for example, now that
Dialogue: 0,0:40:46.52,0:40:49.77,Default,,0000,0000,0000,,Xilinx knows that we're doing these\Ntrustable devices using a tool chain, they
Dialogue: 0,0:40:49.77,0:40:54.14,Default,,0000,0000,0000,,push a patch that compiles back doors into\Nyour bit stream. So not even as a silicon
Dialogue: 0,0:40:54.14,0:40:57.100,Default,,0000,0000,0000,,level implant, but like, you know, maybe\Nthe tool chain itself has a backdoor that
Dialogue: 0,0:40:57.100,0:41:04.94,Default,,0000,0000,0000,,recognizes that we're doing this. So the\Ncool thing is, this is a cool project: So
Dialogue: 0,0:41:04.94,0:41:08.79,Default,,0000,0000,0000,,there's a project called "Prjxray",\Nproject x-ray, it's part of the Symbiflow
Dialogue: 0,0:41:08.79,0:41:12.27,Default,,0000,0000,0000,,effort, and they're actually documenting\Nthe full bit stream of the 7-Series
Dialogue: 0,0:41:12.27,0:41:15.80,Default,,0000,0000,0000,,device. It turns out that we don't yet\Nknow what all the bit functions are, but
Dialogue: 0,0:41:15.80,0:41:19.40,Default,,0000,0000,0000,,the bit mappings are deterministic. So if\Nsomeone were to try and activate a
Dialogue: 0,0:41:19.40,0:41:22.97,Default,,0000,0000,0000,,backdoor in the bit stream through\Ncompilation, we can see it in a diff. We'd
Dialogue: 0,0:41:22.97,0:41:26.22,Default,,0000,0000,0000,,be like: Wow, we've never seen this bit\Nflip before. What is this? Do we can look
Dialogue: 0,0:41:26.22,0:41:29.95,Default,,0000,0000,0000,,into it and figure out if it's malicious\Nor not, right? So there's actually sort of
Dialogue: 0,0:41:29.95,0:41:33.80,Default,,0000,0000,0000,,a hope that essentially at the end of day\Nwe can build sort of a bit stream checker.
Dialogue: 0,0:41:33.80,0:41:37.15,Default,,0000,0000,0000,,We can build a thing that says: Here's a\Nbit stream that came out, does it
Dialogue: 0,0:41:37.15,0:41:40.79,Default,,0000,0000,0000,,correlate to the design source, do all the\Nbits check out, do they make sense? And so
Dialogue: 0,0:41:40.79,0:41:44.14,Default,,0000,0000,0000,,ideally we would come up with like a one\Nclick tool. And now we're at the point
Dialogue: 0,0:41:44.14,0:41:47.47,Default,,0000,0000,0000,,where the point of check is very close to\Nthe point of use. The users are now
Dialogue: 0,0:41:47.47,0:41:50.75,Default,,0000,0000,0000,,confirming that the CPUs are correctly\Nconstructed and mapped to the FPGA
Dialogue: 0,0:41:50.75,0:41:56.36,Default,,0000,0000,0000,,correctly. So the sort of the summary of\NFPGA vs. custom silicon is sort of like,
Dialogue: 0,0:41:56.36,0:42:02.21,Default,,0000,0000,0000,,the pros of custom silicon is that they\Nhave great performance. We can do a true
Dialogue: 0,0:42:02.21,0:42:05.48,Default,,0000,0000,0000,,single chip enclave with hundreds of\Nmegahertz speeds and tiny power
Dialogue: 0,0:42:05.48,0:42:09.75,Default,,0000,0000,0000,,consumption. But the cons of silicon is\Nthat it's really hard to verify. So, you
Dialogue: 0,0:42:09.75,0:42:13.53,Default,,0000,0000,0000,,know, open source doesn't help that\Nverification and Hard IP blocks are tough
Dialogue: 0,0:42:13.53,0:42:17.27,Default,,0000,0000,0000,,problems we talked about earlier. So FPGAs\Non the other side, they offer some
Dialogue: 0,0:42:17.27,0:42:20.32,Default,,0000,0000,0000,,immediate mitigation paths. We don't have\Nto wait until we solve this verification
Dialogue: 0,0:42:20.32,0:42:25.05,Default,,0000,0000,0000,,problem. We can inspect the bit streams,\Nwe can randomize the logic mapping and we
Dialogue: 0,0:42:25.05,0:42:30.03,Default,,0000,0000,0000,,can do per device unique pin mapping. It's\Nnot perfect, but it's better than I think
Dialogue: 0,0:42:30.03,0:42:34.53,Default,,0000,0000,0000,,any other solution I can offer right now.\NThe cons of it is that FPGAs are just
Dialogue: 0,0:42:34.53,0:42:37.96,Default,,0000,0000,0000,,barely good enough to do this today. So\Nyou need a little bit of external RAM
Dialogue: 0,0:42:37.96,0:42:42.22,Default,,0000,0000,0000,,which needs to be encrypted, but 100\Nmegahertz speed performance and about five
Dialogue: 0,0:42:42.22,0:42:47.53,Default,,0000,0000,0000,,to 10x the power consumption of a custom\Nsilicon solution, which in a mobile device
Dialogue: 0,0:42:47.53,0:42:51.85,Default,,0000,0000,0000,,is a lot. But, you know, actually part of\Nthe reason, the main thing that drives the
Dialogue: 0,0:42:51.85,0:42:55.80,Default,,0000,0000,0000,,thickness in this is the battery, right?\NAnd most of that battery is for the FPGA.
Dialogue: 0,0:42:55.80,0:43:01.49,Default,,0000,0000,0000,,If we didn't have to go with an FPGA it\Ncould be much, much thinner. So now let's
Dialogue: 0,0:43:01.49,0:43:05.02,Default,,0000,0000,0000,,talk a little about the last two points,\Nuser-sealable keys, and verification and
Dialogue: 0,0:43:05.02,0:43:08.37,Default,,0000,0000,0000,,protection. And this is that third point,\N"empowering end users to verify and seal
Dialogue: 0,0:43:08.37,0:43:13.35,Default,,0000,0000,0000,,their hardware". So it's great that we can\Nverify something but can it keep a secret?
Dialogue: 0,0:43:13.35,0:43:15.91,Default,,0000,0000,0000,,No, transparency is good up to a point,\Nbut you want to be able to keep secrets so
Dialogue: 0,0:43:15.91,0:43:19.57,Default,,0000,0000,0000,,that people won't come up and say: oh,\Nthere's your keys, right? So sealing a key
Dialogue: 0,0:43:19.57,0:43:23.97,Default,,0000,0000,0000,,in the FPGA, ideally we want user\Ngenerated keys that are hard to extract,
Dialogue: 0,0:43:23.97,0:43:28.48,Default,,0000,0000,0000,,we don't rely on a central keying\Nauthority and that any attack to remove
Dialogue: 0,0:43:28.48,0:43:32.91,Default,,0000,0000,0000,,those keys should be noticeable. So any\Nhigh level apps, I mean, someone with
Dialogue: 0,0:43:32.91,0:43:37.22,Default,,0000,0000,0000,,infinite funding basically should take\Nabout a day to extract it and the effort
Dialogue: 0,0:43:37.22,0:43:40.50,Default,,0000,0000,0000,,should be trivially evident. The solution\Nto that is basically self provisioning and
Dialogue: 0,0:43:40.50,0:43:45.01,Default,,0000,0000,0000,,sealing of the cryptographic keys in the\Nbit stream and a bit of epoxy. So let's
Dialogue: 0,0:43:45.01,0:43:49.72,Default,,0000,0000,0000,,talk a little bit about provisioning those\Nkeys. If we look at the 7-series FPGA
Dialogue: 0,0:43:49.72,0:43:56.13,Default,,0000,0000,0000,,security, they offer a sort of encrypted\NHMAC 256-AES, with 256-bit SHA bit
Dialogue: 0,0:43:56.13,0:44:02.17,Default,,0000,0000,0000,,streams. There's a paper which discloses a\Nknown weakness in it, so the attack takes
Dialogue: 0,0:44:02.17,0:44:06.50,Default,,0000,0000,0000,,about a day or 1.6 million chosen cipher\Ntext traces. The reason why it takes a day
Dialogue: 0,0:44:06.50,0:44:09.65,Default,,0000,0000,0000,,is because that's how long it takes to\Nload in that many chosen ciphertexts
Dialogue: 0,0:44:09.65,0:44:13.94,Default,,0000,0000,0000,,through the interfaces. The good news is\Nthere's some easy mitigations to this. You
Dialogue: 0,0:44:13.94,0:44:16.91,Default,,0000,0000,0000,,can just glue shut the JTAG-port or\Nimprove your power filtering and that
Dialogue: 0,0:44:16.91,0:44:21.60,Default,,0000,0000,0000,,should significantly complicate the\Nattack. But the point is that it will take
Dialogue: 0,0:44:21.60,0:44:24.11,Default,,0000,0000,0000,,a fixed amount of time to do this and you\Nhave to have direct access to the
Dialogue: 0,0:44:24.11,0:44:28.75,Default,,0000,0000,0000,,hardware. It's not the sort of thing that,\Nyou know, someone at customs or like an
Dialogue: 0,0:44:28.75,0:44:33.37,Default,,0000,0000,0000,,"evil maid" could easily pull off. And\Njust to put that in perspective, again,
Dialogue: 0,0:44:33.37,0:44:37.94,Default,,0000,0000,0000,,even if we improved dramatically the DPA-\Nresistance of the hardware, if we knew a
Dialogue: 0,0:44:37.94,0:44:41.83,Default,,0000,0000,0000,,region of the chip that we want to\Ninspect, probably with the SEM in it and a
Dialogue: 0,0:44:41.83,0:44:45.14,Default,,0000,0000,0000,,skilled technician, we could probably pull\Nit off in a matter of a day or a couple of
Dialogue: 0,0:44:45.14,0:44:49.02,Default,,0000,0000,0000,,days. Takes only an hour to decap the\Nsilicon, you know, an hour for a few
Dialogue: 0,0:44:49.02,0:44:52.64,Default,,0000,0000,0000,,layers, a few hours in the FIB to delayer\Na chip, and an afternoon in the the SEM
Dialogue: 0,0:44:52.64,0:44:57.78,Default,,0000,0000,0000,,and you can find out the keys, right? But\Nthe key point is that, this is kind of the
Dialogue: 0,0:44:57.78,0:45:03.71,Default,,0000,0000,0000,,level that we've agreed is OK for a lot of\Nthe silicon enclaves, and this is not
Dialogue: 0,0:45:03.71,0:45:07.44,Default,,0000,0000,0000,,going to happen at a customs checkpoint or\Nby an evil maid. So I think I'm okay with
Dialogue: 0,0:45:07.44,0:45:11.15,Default,,0000,0000,0000,,that for now. We can do better. But I\Nthink that's it's a good starting point,
Dialogue: 0,0:45:11.15,0:45:14.84,Default,,0000,0000,0000,,particularly for something that's so cheap\Nand accessible. So then how do we get
Dialogue: 0,0:45:14.84,0:45:17.73,Default,,0000,0000,0000,,those keys in FPGA and how do we keep them\Nfrom getting out? So those keys should be
Dialogue: 0,0:45:17.73,0:45:21.10,Default,,0000,0000,0000,,user generated, never leave device, not be\Naccessible by the CPU after it's
Dialogue: 0,0:45:21.10,0:45:24.30,Default,,0000,0000,0000,,provisioned, be unique per device. And it\Nshould be easy for the user to get it
Dialogue: 0,0:45:24.30,0:45:28.17,Default,,0000,0000,0000,,right. It should be. You don't have to\Nknow all the stuff and type a bunch
Dialogue: 0,0:45:28.17,0:45:35.34,Default,,0000,0000,0000,,commands to do it, right. So if you look\Ninside Betrusted there's two rectangles
Dialogue: 0,0:45:35.34,0:45:39.32,Default,,0000,0000,0000,,there, one of them is the ROM that\Ncontains a bit stream, the other one is
Dialogue: 0,0:45:39.32,0:45:43.40,Default,,0000,0000,0000,,the FPGA. So we're going to draw those in\Nthe schematic form. Inside the ROM, you
Dialogue: 0,0:45:43.40,0:45:47.59,Default,,0000,0000,0000,,start the day with an unencrypted bit\Nstream in ROM, which loads an FPGA. And
Dialogue: 0,0:45:47.59,0:45:50.86,Default,,0000,0000,0000,,then you have this little crypto engine.\NThere's no keys on the inside. There's no
Dialogue: 0,0:45:50.86,0:45:53.86,Default,,0000,0000,0000,,anywhere. You can check everything. You\Ncan build your own bitstream, and do what
Dialogue: 0,0:45:53.86,0:45:59.31,Default,,0000,0000,0000,,you want to do. The crypto engine then\Ngenerates keys from a TRNG that's located
Dialogue: 0,0:45:59.31,0:46:02.83,Default,,0000,0000,0000,,on chip. Probably some help of some off-\Nchip randomness as well, because I don't
Dialogue: 0,0:46:02.83,0:46:06.78,Default,,0000,0000,0000,,necessarily trust everything inside the\NFPGA. Then that crypto engine can go ahead
Dialogue: 0,0:46:06.78,0:46:12.01,Default,,0000,0000,0000,,and, as it encrypts the external bit\Nstream, inject those keys back into the
Dialogue: 0,0:46:12.01,0:46:15.33,Default,,0000,0000,0000,,bit stream because we know where that\Nblock-RAM is. We can go ahead and inject
Dialogue: 0,0:46:15.33,0:46:19.79,Default,,0000,0000,0000,,those keys back into that specific RAM\Nblock as we encrypt it. So now we have a
Dialogue: 0,0:46:19.79,0:46:26.09,Default,,0000,0000,0000,,sealed encrypted image on the ROM, which\Ncan then load the FPGA if it had the key.
Dialogue: 0,0:46:26.09,0:46:28.81,Default,,0000,0000,0000,,So after you've gone ahead and provisioned\Nthe ROM, hopefully at this point you don't
Dialogue: 0,0:46:28.81,0:46:35.66,Default,,0000,0000,0000,,lose power, you go ahead and you burn the\Nkey into the FPGA's keying engine which
Dialogue: 0,0:46:35.66,0:46:40.61,Default,,0000,0000,0000,,sets it to only boot from that encrypted\Nbit stream, blow out the readback-
Dialogue: 0,0:46:40.61,0:46:45.41,Default,,0000,0000,0000,,disabled-bit and the AES-only boot is\Nblown. So now at this point in time,
Dialogue: 0,0:46:45.41,0:46:48.83,Default,,0000,0000,0000,,basically there's no way to go ahead and\Nput in a bit stream that says tell me your
Dialogue: 0,0:46:48.83,0:46:52.08,Default,,0000,0000,0000,,keys, whatever it is. You have to go and\Ndo one of these hard techniques to pull
Dialogue: 0,0:46:52.08,0:46:56.93,Default,,0000,0000,0000,,out the key. You can maybe enable hardware\Nupgrade path if you want by having the
Dialogue: 0,0:46:56.93,0:47:00.96,Default,,0000,0000,0000,,crypto and just be able to retain a copy\Nof the master key and re-encrypt it, but
Dialogue: 0,0:47:00.96,0:47:04.53,Default,,0000,0000,0000,,that becomes a vulnerability because the\Nuser can be coerced to go ahead and load
Dialogue: 0,0:47:04.53,0:47:08.24,Default,,0000,0000,0000,,inside a bit stream that then leaks out\Nthe keys. So if you're really paranoid at
Dialogue: 0,0:47:08.24,0:47:13.72,Default,,0000,0000,0000,,some point in time, you seal this thing\Nand it's done. You know, you have to go
Dialogue: 0,0:47:13.72,0:47:18.11,Default,,0000,0000,0000,,ahead and do that full key extraction\Nroutine to go ahead and pull stuff out if
Dialogue: 0,0:47:18.11,0:47:21.100,Default,,0000,0000,0000,,you forget your passwords. So that's the\Nsort of user-sealable keys. I think we can
Dialogue: 0,0:47:21.100,0:47:27.73,Default,,0000,0000,0000,,do that with FPGA. Finally, easy to verify\Nand easy to protect. Just very quickly
Dialogue: 0,0:47:27.73,0:47:31.12,Default,,0000,0000,0000,,talking about this. So if you want to make\Nan expectable tamper barrier, a lot of
Dialogue: 0,0:47:31.12,0:47:34.62,Default,,0000,0000,0000,,people have talked about glitter seals.\NThose are pretty cool, right? The problem
Dialogue: 0,0:47:34.62,0:47:39.49,Default,,0000,0000,0000,,is, I find that glitter seals are too hard\Nto verify. Right. Like, I have tried
Dialogue: 0,0:47:39.49,0:47:42.66,Default,,0000,0000,0000,,glitter-seals before and I stare at the\Nthing and I'm like: Damn, I have no idea
Dialogue: 0,0:47:42.66,0:47:45.49,Default,,0000,0000,0000,,if this is the seal I put down. And so\Nthen I say, ok, we'll take a picture or
Dialogue: 0,0:47:45.49,0:47:50.08,Default,,0000,0000,0000,,write an app or something. Now I'm relying\Non this untrusted device to go ahead and
Dialogue: 0,0:47:50.08,0:47:55.70,Default,,0000,0000,0000,,tell me if the seal is verified or not. So\NI have a suggestion for a DIY watermark
Dialogue: 0,0:47:55.70,0:47:59.63,Default,,0000,0000,0000,,that relies not on an app to go and\Nverify, but our very, very well tuned
Dialogue: 0,0:47:59.63,0:48:03.09,Default,,0000,0000,0000,,neural networks inside our head to go\Nahead and verify things. So the idea is
Dialogue: 0,0:48:03.09,0:48:08.35,Default,,0000,0000,0000,,basically, there's this nice epoxy that I\Nfound. It comes in this Bi-packs, 2 part
Dialogue: 0,0:48:08.35,0:48:12.32,Default,,0000,0000,0000,,epoxy, you just put on the edge of a table\Nand you go like this and it goes ahead and
Dialogue: 0,0:48:12.32,0:48:17.25,Default,,0000,0000,0000,,mixes the epoxy and you're ready to use.\NIt's very easy for users to apply. And
Dialogue: 0,0:48:17.25,0:48:21.04,Default,,0000,0000,0000,,then you just draw a watermark on a piece\Nof tissue paper. It turns out humans are
Dialogue: 0,0:48:21.04,0:48:25.26,Default,,0000,0000,0000,,really good at identifying our own\Nhandwriting, our own signatures, these
Dialogue: 0,0:48:25.26,0:48:28.36,Default,,0000,0000,0000,,types of things. Someone can go ahead and\Ntry to forge it. There's people who are
Dialogue: 0,0:48:28.36,0:48:32.58,Default,,0000,0000,0000,,skilled in doing this, but this is way\Neasier than looking at a glitter-seal. You
Dialogue: 0,0:48:32.58,0:48:36.54,Default,,0000,0000,0000,,go ahead and put that down on your device.\NYou swab on the epoxy and at the end of
Dialogue: 0,0:48:36.54,0:48:41.12,Default,,0000,0000,0000,,day, you end up with a sort of tissue\Npaper plus a very easily recognizable
Dialogue: 0,0:48:41.12,0:48:44.50,Default,,0000,0000,0000,,seal. If someone goes ahead and tries to\Ntake this off or tamper with it, I can
Dialogue: 0,0:48:44.50,0:48:47.98,Default,,0000,0000,0000,,look at it easy and say, yes, this is a\Ndifferent thing than what I had yesterday,
Dialogue: 0,0:48:47.98,0:48:50.75,Default,,0000,0000,0000,,I don't have to open an app, I don't have\Nto look at glitter patterns, I don't have
Dialogue: 0,0:48:50.75,0:48:54.23,Default,,0000,0000,0000,,to do these sorts of things. And I can go\Nahead and swab onto all the I/O-ports that
Dialogue: 0,0:48:54.23,0:49:01.87,Default,,0000,0000,0000,,need to do. So it's a bit of a hack, but I\Nthink that it's a little closer towards
Dialogue: 0,0:49:01.87,0:49:09.90,Default,,0000,0000,0000,,not having to rely on third party apps to\Nverify a tamper evidence seal. So I've
Dialogue: 0,0:49:09.90,0:49:16.25,Default,,0000,0000,0000,,talked about sort of this implementation\Nand also talked about how it maps to these
Dialogue: 0,0:49:16.25,0:49:20.86,Default,,0000,0000,0000,,three principles for building trustable\Nhardware. So the idea is to try to build a
Dialogue: 0,0:49:20.86,0:49:25.73,Default,,0000,0000,0000,,system that is not too complex so that we\Ncan verify most the parts or all of them
Dialogue: 0,0:49:25.73,0:49:29.83,Default,,0000,0000,0000,,at the end-user point, look at the\Nkeyboard, look at the display and we can
Dialogue: 0,0:49:29.83,0:49:35.93,Default,,0000,0000,0000,,go ahead and compile the FPGA from source.\NWe're focusing on verifying the entire
Dialogue: 0,0:49:35.93,0:49:40.46,Default,,0000,0000,0000,,system, the keyboard and the display,\Nwe're not forgetting the user. They secret
Dialogue: 0,0:49:40.46,0:49:43.20,Default,,0000,0000,0000,,starts with the user and ends with the\Nuser, not with the edge of the silicon.
Dialogue: 0,0:49:43.20,0:49:47.94,Default,,0000,0000,0000,,And finally, we're empowering end-users to\Nverify and seal their own hardware. You
Dialogue: 0,0:49:47.94,0:49:52.05,Default,,0000,0000,0000,,don't have to go through a central keying\Nauthority to go ahead and make sure
Dialogue: 0,0:49:52.05,0:49:56.73,Default,,0000,0000,0000,,secrets are are inside your hardware. So\Nat the end of the day, the idea behind
Dialogue: 0,0:49:56.73,0:50:01.46,Default,,0000,0000,0000,,Betrusted is to close that hardware time\Nof check/time of use gap by moving the
Dialogue: 0,0:50:01.46,0:50:07.69,Default,,0000,0000,0000,,verification point closer to the point of\Nuse. So in this huge, complicated
Dialogue: 0,0:50:07.69,0:50:12.33,Default,,0000,0000,0000,,landscape of problems that we can have,\Nthe idea is that we want to, as much as
Dialogue: 0,0:50:12.33,0:50:19.28,Default,,0000,0000,0000,,possible, teach users to verify their own\Nstuff. So by design, it's meant to be a
Dialogue: 0,0:50:19.28,0:50:23.25,Default,,0000,0000,0000,,thing that hopefully anyone can be taught\Nto sort of verify and use, and we can
Dialogue: 0,0:50:23.25,0:50:27.52,Default,,0000,0000,0000,,provide tools that enable them to do that.\NBut if that ends up being too high of a
Dialogue: 0,0:50:27.52,0:50:31.92,Default,,0000,0000,0000,,bar, I would like it to be within like one\Nor two nodes in your immediate social
Dialogue: 0,0:50:31.92,0:50:35.55,Default,,0000,0000,0000,,network, so anyone in the world can find\Nsomeone who can do this. And the reason
Dialogue: 0,0:50:35.55,0:50:41.24,Default,,0000,0000,0000,,why I kind of set this bar is, I want to\Nsort of define the maximum level of
Dialogue: 0,0:50:41.24,0:50:45.33,Default,,0000,0000,0000,,technical competence required to do this,\Nbecause it's really easy, particularly
Dialogue: 0,0:50:45.33,0:50:48.100,Default,,0000,0000,0000,,when sitting in an audience of these\Nreally brilliant technical people to say,
Dialogue: 0,0:50:48.100,0:50:52.21,Default,,0000,0000,0000,,yeah, of course everyone can just hash\Nthings and compile things and look at
Dialogue: 0,0:50:52.21,0:50:55.50,Default,,0000,0000,0000,,things in microscopes and solder and then\Nyou get into life and reality and then be
Dialogue: 0,0:50:55.50,0:51:01.02,Default,,0000,0000,0000,,like: oh, wait, I had completely forgotten\Nwhat real people are like. So this tries
Dialogue: 0,0:51:01.02,0:51:06.77,Default,,0000,0000,0000,,to get me grounded and make sure that I'm\Nnot sort of drinking my own Kool-Aid in
Dialogue: 0,0:51:06.77,0:51:11.72,Default,,0000,0000,0000,,terms of how useful open hardware is as a\Nmechanism to verify anything. Because I
Dialogue: 0,0:51:11.72,0:51:14.46,Default,,0000,0000,0000,,hand a bunch of people schematics and say,\Ncheck this and they'll be like: I have no
Dialogue: 0,0:51:14.46,0:51:22.46,Default,,0000,0000,0000,,idea. So the current development status is\Nthat: The hardware is kind of an initial
Dialogue: 0,0:51:22.46,0:51:27.97,Default,,0000,0000,0000,,EVT stage for types subject to significant\Nchange, particularly part of the reason
Dialogue: 0,0:51:27.97,0:51:31.59,Default,,0000,0000,0000,,we're here is talking about this is to\Ncollect more ideas and feedback on this,
Dialogue: 0,0:51:31.59,0:51:35.87,Default,,0000,0000,0000,,to make sure we're doing it right. The\Nsoftware is just starting. We're writing
Dialogue: 0,0:51:35.87,0:51:40.81,Default,,0000,0000,0000,,our own OS called Xous, being done by Sean\NCross, and we're exploring the UX and
Dialogue: 0,0:51:40.81,0:51:44.18,Default,,0000,0000,0000,,applications being done by Tom Marble\Nshown here. And I actually want to give a
Dialogue: 0,0:51:44.18,0:51:48.89,Default,,0000,0000,0000,,big shout out to NLnet for funding us\Npartially. We have a grant, a couple of
Dialogue: 0,0:51:48.89,0:51:52.56,Default,,0000,0000,0000,,grants for under privacy and trust\Nenhancing technologies. This is really
Dialogue: 0,0:51:52.56,0:51:57.31,Default,,0000,0000,0000,,significant because now we can actually\Nthink about the hard problems, and not
Dialogue: 0,0:51:57.31,0:52:00.26,Default,,0000,0000,0000,,have to be like, oh, when do we go\Ncrowdfunded, when do we go fundraising.
Dialogue: 0,0:52:00.26,0:52:04.03,Default,,0000,0000,0000,,Like a lot of time, people are like: This\Nlooks like a product, can we sell this
Dialogue: 0,0:52:04.03,0:52:10.85,Default,,0000,0000,0000,,now? It's not ready yet. And I want to be\Nable to take the time to talk about it,
Dialogue: 0,0:52:10.85,0:52:15.78,Default,,0000,0000,0000,,listen to people, incorporate changes and\Nmake sure we're doing the right thing. So
Dialogue: 0,0:52:15.78,0:52:18.90,Default,,0000,0000,0000,,with that, I'd like to open up the floor\Nfor Q&A. Thanks to everyone, for coming to
Dialogue: 0,0:52:18.90,0:52:20.40,Default,,0000,0000,0000,,my talk.
Dialogue: 0,0:52:20.40,0:52:29.30,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:52:29.30,0:52:32.24,Default,,0000,0000,0000,,Herald: Thank you so much, bunnie, for the\Ngreat talk. We have about five minutes
Dialogue: 0,0:52:32.24,0:52:36.13,Default,,0000,0000,0000,,left for Q&A. For those who are leaving\Nearlier, you're only supposed to use the
Dialogue: 0,0:52:36.13,0:52:40.48,Default,,0000,0000,0000,,two doors on the left, not the one, not\Nthe tunnel you came in through, but only
Dialogue: 0,0:52:40.48,0:52:44.77,Default,,0000,0000,0000,,the doors on the left back, the very left\Ndoor and the door in the middle. Now, Q&A,
Dialogue: 0,0:52:44.77,0:52:49.31,Default,,0000,0000,0000,,you can pile up at the microphones. Do we\Nhave a question from the Internet? No, not
Dialogue: 0,0:52:49.31,0:52:54.17,Default,,0000,0000,0000,,yet. If someone wants to ask a question\Nbut is not present but in the stream, or
Dialogue: 0,0:52:54.17,0:52:57.79,Default,,0000,0000,0000,,maybe a person in the room who wants to\Nask a question, you can use the hashtag
Dialogue: 0,0:52:57.79,0:53:01.85,Default,,0000,0000,0000,,#Clark and Twitter. Mastodon and IRC are\Nbeing monitored. So let's start with
Dialogue: 0,0:53:01.85,0:53:04.49,Default,,0000,0000,0000,,microphone number one.\NYour question, please.
Dialogue: 0,0:53:04.49,0:53:10.17,Default,,0000,0000,0000,,Q: Hey, bunnie. So you mentioned that with\Nthe foundry process that the Hard IP-
Dialogue: 0,0:53:10.17,0:53:16.57,Default,,0000,0000,0000,,blocks, the prototyped IP-blocks are a\Nplace where attacks could be made. Do you
Dialogue: 0,0:53:16.57,0:53:22.47,Default,,0000,0000,0000,,have the same concern about the Hard IP\Nblocks in the FPGA, either the embedded
Dialogue: 0,0:53:22.47,0:53:27.56,Default,,0000,0000,0000,,block RAM or any of the other special\Nfeatures that you might be using?
Dialogue: 0,0:53:27.56,0:53:34.06,Default,,0000,0000,0000,,bunnie: Yeah, I think that we do have to\Nbe concerned about implants that have
Dialogue: 0,0:53:34.06,0:53:40.63,Default,,0000,0000,0000,,existed inside the FPGA prior to this\Nproject. And I think there is a risk, for
Dialogue: 0,0:53:40.63,0:53:44.93,Default,,0000,0000,0000,,example, that there's a JTAG-path that we\Ndidn't know about. But I guess the
Dialogue: 0,0:53:44.93,0:53:49.23,Default,,0000,0000,0000,,compensating side is that the military,\NU.S. military does use a lot of these in
Dialogue: 0,0:53:49.23,0:53:52.87,Default,,0000,0000,0000,,their devices. So they have a self-\Ninterest in not having backdoors inside of
Dialogue: 0,0:53:52.87,0:54:01.28,Default,,0000,0000,0000,,these things as well. So we'll see. I\Nthink that the answer is it's possible. I
Dialogue: 0,0:54:01.28,0:54:07.55,Default,,0000,0000,0000,,think the upside is that because the FPGA\Nis actually a very regular structure,
Dialogue: 0,0:54:07.55,0:54:11.10,Default,,0000,0000,0000,,doing like sort of a SEM-level analysis,\Nof the initial construction of it at
Dialogue: 0,0:54:11.10,0:54:15.22,Default,,0000,0000,0000,,least, is not insane. We can identify\Nthese blocks and look at them and make
Dialogue: 0,0:54:15.22,0:54:18.88,Default,,0000,0000,0000,,sure the right number of bits. That\Ndoesn't mean the one you have today is the
Dialogue: 0,0:54:18.88,0:54:22.76,Default,,0000,0000,0000,,same one. But if they were to go ahead and\Nmodify that block to do sort of the
Dialogue: 0,0:54:22.76,0:54:26.92,Default,,0000,0000,0000,,implant, my argument is that because of\Nthe randomness of the wiring and the
Dialogue: 0,0:54:26.92,0:54:29.84,Default,,0000,0000,0000,,number of factors they have to consider,\Nthey would have to actually grow the
Dialogue: 0,0:54:29.84,0:54:34.78,Default,,0000,0000,0000,,silicon area substantially. And that's a\Nthing that is a proxy for detection of
Dialogue: 0,0:54:34.78,0:54:38.46,Default,,0000,0000,0000,,these types of problems. So that would be\Nmy kind of half answer to that problem.
Dialogue: 0,0:54:38.46,0:54:41.27,Default,,0000,0000,0000,,It's a good question, though. Thank you.\NHerald: Thanks for the question. The next
Dialogue: 0,0:54:41.27,0:54:46.07,Default,,0000,0000,0000,,one from microphone number three, please.\NYeah. Move close to the microphone.
Dialogue: 0,0:54:46.07,0:54:50.97,Default,,0000,0000,0000,,Thanks.\NQ: Hello. My question is, in your proposed
Dialogue: 0,0:54:50.97,0:54:56.46,Default,,0000,0000,0000,,solution, how do you get around the fact\Nthat the attacker, whether it's an implant
Dialogue: 0,0:54:56.46,0:55:01.61,Default,,0000,0000,0000,,or something else, will just attack it\Nbefore they user self provisioning so
Dialogue: 0,0:55:01.61,0:55:04.77,Default,,0000,0000,0000,,it'll compromise a self provisioning\Nprocess itself?
Dialogue: 0,0:55:04.77,0:55:13.01,Default,,0000,0000,0000,,bunnie: Right. So the idea of the self\Nprovisioning process is that we send the
Dialogue: 0,0:55:13.01,0:55:18.51,Default,,0000,0000,0000,,device to you, you can look at the circuit\Nboards and devices and then you compile
Dialogue: 0,0:55:18.51,0:55:23.63,Default,,0000,0000,0000,,your own FPGA, which includes a self\Nprovisioning code from source and you can
Dialogue: 0,0:55:23.63,0:55:26.34,Default,,0000,0000,0000,,confirm, or if you don't want to compile,\Nyou can confirm that the signatures match
Dialogue: 0,0:55:26.34,0:55:30.05,Default,,0000,0000,0000,,with what's on the Internet. And so\Nsomeone wanting to go ahead and compromise
Dialogue: 0,0:55:30.05,0:55:34.39,Default,,0000,0000,0000,,that process and so stash away some keys\Nin some other place, that modification
Dialogue: 0,0:55:34.39,0:55:40.40,Default,,0000,0000,0000,,would either be evident in the bit stream\Nor that would be evident as a modification
Dialogue: 0,0:55:40.40,0:55:44.23,Default,,0000,0000,0000,,of the hash of the code that's running on\Nit at that point in time. So someone would
Dialogue: 0,0:55:44.23,0:55:49.71,Default,,0000,0000,0000,,have to then add a hardware implant, for\Nexample, to the ROM, but that doesn't help
Dialogue: 0,0:55:49.71,0:55:52.23,Default,,0000,0000,0000,,because it's already encrypted by the time\Nit hits the ROM. So it'd really have to be
Dialogue: 0,0:55:52.23,0:55:55.54,Default,,0000,0000,0000,,an implant that's inside the FPGA and then\Ntrammel's question just sort of talked
Dialogue: 0,0:55:55.54,0:56:01.61,Default,,0000,0000,0000,,about that situation itself. So I think\Nthe attack surface is limited at least for
Dialogue: 0,0:56:01.61,0:56:05.55,Default,,0000,0000,0000,,that.\NQ: So you talked about how the courier
Dialogue: 0,0:56:05.55,0:56:11.81,Default,,0000,0000,0000,,might be a hacker, right? So in this case,\Nyou know, the courier would put a
Dialogue: 0,0:56:11.81,0:56:17.72,Default,,0000,0000,0000,,hardware implant, not in the Hard IP, but\Njust in the piece of hardware inside the
Dialogue: 0,0:56:17.72,0:56:21.52,Default,,0000,0000,0000,,FPGA that provisions the bit stream.\Nbunnie: Right. So the idea is that you
Dialogue: 0,0:56:21.52,0:56:26.53,Default,,0000,0000,0000,,would get that FPGA and you would blow\Nyour own FPGA bitstream yourself. You
Dialogue: 0,0:56:26.53,0:56:30.34,Default,,0000,0000,0000,,don't trust my factory to give you a bit\Nstream. You get the device.
Dialogue: 0,0:56:30.34,0:56:34.21,Default,,0000,0000,0000,,Q: How do you trust that the bitstream is\Nbeing blown. You just get indicate your
Dialogue: 0,0:56:34.21,0:56:36.61,Default,,0000,0000,0000,,computer's saying this\Nbitstream is being blown.
Dialogue: 0,0:56:36.61,0:56:40.11,Default,,0000,0000,0000,,bunnie: I see, I see, I see. So how do you\Ntrust that the ROM actually doesn't have a
Dialogue: 0,0:56:40.11,0:56:43.50,Default,,0000,0000,0000,,backdoor in itself that's pulling in the\Nsecret bit stream that's not related to
Dialogue: 0,0:56:43.50,0:56:52.84,Default,,0000,0000,0000,,him. I mean, possible, I guess. I think\Nthere are things you can do to defeat
Dialogue: 0,0:56:52.84,0:56:58.64,Default,,0000,0000,0000,,that. So the way that we do the semi\Nrandomness in the compilation is that
Dialogue: 0,0:56:58.64,0:57:02.60,Default,,0000,0000,0000,,there's a random 64-Bit random number we\Ncompile into the bit stream. So we're
Dialogue: 0,0:57:02.60,0:57:07.10,Default,,0000,0000,0000,,compiling our own bitstream. You can read\Nout that number and see if it matches. At
Dialogue: 0,0:57:07.10,0:57:13.04,Default,,0000,0000,0000,,that point, if someone had pre burned a\Nbit stream onto it that is actually loaded
Dialogue: 0,0:57:13.04,0:57:16.50,Default,,0000,0000,0000,,instead of your own bit stream, it's not\Ngoing to be able to have that random
Dialogue: 0,0:57:16.50,0:57:21.31,Default,,0000,0000,0000,,number, for example, on the inside. So I\Nthink there's ways to tell if, for
Dialogue: 0,0:57:21.31,0:57:24.54,Default,,0000,0000,0000,,example, the ROM has been backdoored and\Nit has two copies of the ROM, one of the
Dialogue: 0,0:57:24.54,0:57:27.40,Default,,0000,0000,0000,,evil one and one of yours, and then\Nthey're going to use the evil one during
Dialogue: 0,0:57:27.40,0:57:31.17,Default,,0000,0000,0000,,provisioning, right? I think that's a\Nthing that can be mitigated.
Dialogue: 0,0:57:31.17,0:57:33.78,Default,,0000,0000,0000,,Herald: All right. Thank you very much. We\Ntake the very last question from
Dialogue: 0,0:57:33.78,0:57:39.31,Default,,0000,0000,0000,,microphone number five.\NQ: Hi, bunnie. So one of the options you
Dialogue: 0,0:57:39.31,0:57:44.57,Default,,0000,0000,0000,,sort of touched on in the talk but then\Ndidn't pursue was this idea of doing some
Dialogue: 0,0:57:44.57,0:57:49.77,Default,,0000,0000,0000,,custom silicon in a sort of very low-res\Nprocess that could be optically inspected
Dialogue: 0,0:57:49.77,0:57:51.77,Default,,0000,0000,0000,,directly.\Nbunnie: Yes.
Dialogue: 0,0:57:51.77,0:57:55.95,Default,,0000,0000,0000,,Q: Is that completely out of the question\Nin terms of being a usable route in the
Dialogue: 0,0:57:55.95,0:58:00.10,Default,,0000,0000,0000,,future or, you know, did you look into\Nthat and go to detail at all?
Dialogue: 0,0:58:00.10,0:58:05.07,Default,,0000,0000,0000,,bunnie: So I thought about that when\Nthere's a couple of issues: 1) Is that if
Dialogue: 0,0:58:05.07,0:58:10.11,Default,,0000,0000,0000,,we rely on optical verification now, users\Nneed optical verification prior to do it.
Dialogue: 0,0:58:10.11,0:58:14.21,Default,,0000,0000,0000,,So we have to somehow move those optical\Nverification tools to the edge towards
Dialogue: 0,0:58:14.21,0:58:17.56,Default,,0000,0000,0000,,that time of use. Right. So nice thing\Nabout the FPGA is everything I talked
Dialogue: 0,0:58:17.56,0:58:20.87,Default,,0000,0000,0000,,about building your own midstream,\Ninspecting the bit stream, checking the
Dialogue: 0,0:58:20.87,0:58:27.28,Default,,0000,0000,0000,,hashes. Those are things that don't\Nrequire particular sort of user equipment.
Dialogue: 0,0:58:27.28,0:58:32.22,Default,,0000,0000,0000,,But yes, if we if we were to go ahead and\Nbuild like an enclave out of 500
Dialogue: 0,0:58:32.22,0:58:36.37,Default,,0000,0000,0000,,nanometers, silicon like it probably run\Naround 100 megahertz, you'd have a few
Dialogue: 0,0:58:36.37,0:58:40.96,Default,,0000,0000,0000,,kilobytes of RAM on the inside. Not a lot.\NRight. So you have a limitation in how
Dialogue: 0,0:58:40.96,0:58:47.50,Default,,0000,0000,0000,,much capability you have on it and would\Nconsume a lot of power. But then every
Dialogue: 0,0:58:47.50,0:58:52.71,Default,,0000,0000,0000,,single one of those chips. Right. We put\Nthem in a black piece of epoxy. How do you
Dialogue: 0,0:58:52.71,0:58:55.42,Default,,0000,0000,0000,,like, you know, what keeps someone from\Nswapping that out with another chip?
Dialogue: 0,0:58:55.42,0:58:58.01,Default,,0000,0000,0000,,Q: Yeah. I mean, I was I was thinking of\Nlike old school, transparent top, like on
Dialogue: 0,0:58:58.01,0:59:00.11,Default,,0000,0000,0000,,a lark.\Nbunnie: So, yeah, you can go ahead and
Dialogue: 0,0:59:00.11,0:59:03.60,Default,,0000,0000,0000,,wire bond on the board, put some clear\Nepoxy on and then now people have to take
Dialogue: 0,0:59:03.60,0:59:11.01,Default,,0000,0000,0000,,a microscope to look at that. That's a\Npossibility. I think that that's the sort
Dialogue: 0,0:59:11.01,0:59:15.05,Default,,0000,0000,0000,,of thing that I think I am trying to\Nimagine. Like, for example, my mom using
Dialogue: 0,0:59:15.05,0:59:19.64,Default,,0000,0000,0000,,this and asking her do this sort of stuff.\NI just don't envision her knowing anyone
Dialogue: 0,0:59:19.64,0:59:22.72,Default,,0000,0000,0000,,who would have an optical microscope who\Ncould do this for except for me. Right.
Dialogue: 0,0:59:22.72,0:59:29.09,Default,,0000,0000,0000,,And I don't think that's a fair assessment\Nof what is verifiable by the end user. At
Dialogue: 0,0:59:29.09,0:59:33.60,Default,,0000,0000,0000,,the end of the day. So maybe for some\Nscenarios it's OK. But I think that the
Dialogue: 0,0:59:33.60,0:59:37.60,Default,,0000,0000,0000,,full optical verification of a chip and\Nmaking that sort of the only thing between
Dialogue: 0,0:59:37.60,0:59:42.59,Default,,0000,0000,0000,,you and implant, worries me. That's the\Nproblem with the hard chip is that
Dialogue: 0,0:59:42.59,0:59:46.59,Default,,0000,0000,0000,,basically if someone even if it's full,\Nyou know, it's just to get a clear thing
Dialogue: 0,0:59:46.59,0:59:51.70,Default,,0000,0000,0000,,and someone just swapped out the chip with\Nanother chip. Right. You still need to
Dialogue: 0,0:59:51.70,0:59:55.70,Default,,0000,0000,0000,,know, a piece of equipment to check that.\NRight. Whereas like when I talked about
Dialogue: 0,0:59:55.70,0:59:58.65,Default,,0000,0000,0000,,the display and the fact that you can look\Nat that, actually the argument for that is
Dialogue: 0,0:59:58.65,1:00:01.66,Default,,0000,0000,0000,,not that you have to check the display.\NIt's that you don't it's actually because
Dialogue: 0,1:00:01.66,1:00:04.70,Default,,0000,0000,0000,,it's so simple. You don't need to check\Nthe display. Right. You don't need the
Dialogue: 0,1:00:04.70,1:00:07.81,Default,,0000,0000,0000,,microscope to check it, because there is\Nno place to hide anything.
Dialogue: 0,1:00:07.81,1:00:11.17,Default,,0000,0000,0000,,Herald: All right, folks, we ran out of\Ntime. Thank you very much to everyone who
Dialogue: 0,1:00:11.17,1:00:14.32,Default,,0000,0000,0000,,asked a question. And please give another\Nbig round of applause to our great
Dialogue: 0,1:00:14.32,1:00:17.32,Default,,0000,0000,0000,,speaker, bunnie. Thank you so much for the\Ngreat talk. Thanks.
Dialogue: 0,1:00:17.32,1:00:18.32,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,1:00:18.32,1:00:20.87,Default,,0000,0000,0000,,bunnie: Thanks everyone!
Dialogue: 0,1:00:20.87,1:00:23.80,Default,,0000,0000,0000,,{\i1}Outro{\i0}
Dialogue: 0,1:00:23.80,1:00:46.00,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!