*36C3 Intro* ♪ (intro music) ♪
Herald: Welcome, everybody, to our very first talk on the first day of Congress.
The talk is "Open Source is Insufficient to Solve Trust Problems in Hardware,"
and although there is a lot to be said for free and open software, it is
unfortunately not always inherently more secure than proprietary or closed software,
and the same goes for hardware as well. And this talk will take us into
the nitty gritty bits of how to build trustable hardware and how it it has to be
implemented and brought together with the software in order to be secure.
We have one speaker here today. It's bunnie.
He's a hardware and firmware hacker. But actually,
the talk was worked on by three people, so it's not just bunnie, but also
Sean "Xobs" Cross and Tom Marble. But the other two are not present today.
But I would like you to welcome our speaker, bunnie,
with a big, warm, round of applause, and have a lot of fun.
*Applause*
bunnie: Good morning, everybody. Thanks for braving the crowds
and making it in to the Congress. And thank you again to the Congress
for giving me the privilege to address the Congress again this year.
Very exciting being the first talk of the day. Had font problems,
so I'm running from a .pdf backup. So we'll see how this all goes.
Good thing I make backups. So the topic of today's talk is
"Open Source is Insufficient to Solve Trust Problems in Hardware,"
and sort of some things we can do about this.
So my background is, I'm a big proponent of open source hardware. I
love it. And I've built a lot of things in open source, using open source hardware
principles. But there's been sort of a nagging question in me about like, you
know, some people would say things like, oh, well, you know, you build open source
hardware because you can trust it more. And there's been sort of this gap in my
head and this talk tries to distill out that gap in my head between trust and open
source and hardware. So I'm sure people have opinions on which browsers you would
think is more secure or trustable than the others. But the question is why might you
think one is more trustable than the other is. You have everything and hear from like
Firefox and Iceweasel down to like the Samsung custom browser or the you know,
xiaomi custom browser. Which one would you rather use for your browsing if you
had to trust something? So I'm sure people have their biases and they might say that
open is more trustable. But why do we say open is more trustable? Is it because we
actually read the source thoroughly and check it every single release for this
browser? Is it because we compile our source, our browsers from source before we
use them? No, actually we don't have the time to do that. So let's take a closer
look as to why we like to think that open source software is more secure. So this is
a kind of a diagram of the lifecycle of, say, a software project. You have a bunch
of developers on the left. They'll commit code into some source management program
like git. It goes to a build. And then ideally, some person who carefully managed
the key signs that build goes into an untrusted cloud, then gets download onto
users disks, pulled into RAM, run by the user at the end of the day. Right? So the
reason why actually we find that we might be able to trust things more is because in
the case of open source, anyone can pull down that source code like someone doing
reproducible builds an audit of some type, build it, confirm that the hashes match
and that the keys are all set up correctly. And then the users also have
the ability to know developers and sort of enforce community norms and standards upon
them to make sure that they're acting in sort of in the favor of the community. So
in the case that we have bad actors who want to go ahead and tamper with builds
and clouds and all the things in the middle, it's much more difficult. So open
is more trustable because we have tools to transfer trust in software, things like
hashing, things like public keys, things like Merkle trees. Right? And also in the
case of open versus closed, we have social networks that we can use to reinforce our
community standards for trust and security. Now, it's worth looking a little
bit more into the hashing mechanism because this is a very important part of
our software trust chain. So I'm sure a lot of people know what hashing is, for
people who don't know. Basically it takes a big pile of bits and turns them into a
short sequence of symbols so that a tiny change in the big pile of bits makes a big
change in the output symbols. And also knowing those symbols doesn't reveal
anything about the original file. So in this case here, the file on the left is
hashed to sort of cat, mouse, panda, bear and the file on the right hashes to, you
know, peach, snake, pizza, cookie. And the thing is, as you may not even have noticed
necessarily that there was that one bit changed up there, but it's very easy to
see that short string of symbols have changed. So you don't actually have to go
through that whole file and look for that needle in the haystack. You have this hash
function that tells you something has changed very quickly. Then once you've
computed the hashes, we have a process called signing, where a secret key is used
to encrypt the hash, users decrypt that using the public key to compare against a
locally computed hash. You know, so we're not trusting the server to compute the
hash. We reproduce it on our site and then we can say that it is now difficult to
modify that file or the signature without detection. Now the problem is, that there
is a time of check, time of use issue with the system, even though we have this
mechanism, if we decouple the point of check from the point of use, it creates a
man in the middle opportunity or a person the middle if you want. The thing is that,
you know, it's a class of attacks that allows someone to tamper with data as it
is in transit. And I'm kind of symbolizing this evil guy, I guess, because hackers
all wear hoodies and, you know, they also keep us warm as well in very cold places.
So now an example of a time of check, time of use issue is that if, say, a user
downloads a copy of the program onto their disk and they just check it after the
download to the disc. And they say, okay, great, that's fine. Later on, an adversary
can then modify the file on a disk as it's cut before it's copied to RAM. And now
actually the user, even though they download the correct version of file,
they're getting the wrong version into the RAM. So the key point is the reason why in
software we feel it's more trustworthy, we have a tool to transfer trust and ideally,
we place that point of check as close to the users as possible. So idea that we're
sort of putting keys into the CPU or some secure enclave that, you know, just before
you run it, you've checked it, that software is perfect and has not been
modified, right? Now, an important clarification is that it's actually more
about the place of check versus the place of use. Whether you checked one second
prior or a minute prior doesn't actually matter. It's more about checking the copy
that's closest to the thing that's running it, right? We don't call it PoCPoU because
it just doesn't have quite the same ring to it. But now this is important. That
reason why I emphasize place of check versus place of use is, this is why
hardware is not the same as software in terms of trust. The place of check is not
the place of use or in other words, trust in hardware is a ToCToU problem all the
way down the supply chain. Right? So the hard problem is how do you trust your
computers? Right? So we have problems where we have firmware, pervasive hidden
bits of code that are inside every single part of your system that can break
abstractions. And there's also the issue of hardware implants. So it's tampering or
adding components that can bypass security in ways that we're not, according to the
specification, that you're building around. So from the firmer standpoint,
it's more here to acknowledge is an issue. The problem is this is actually a software
problem. The good news is we have things like openness and runtime verification,
they go going to frame these questions. If you're, you know, a big enough player or
you have enough influence or something, you can coax out all the firmware blobs
and eventually sort of solve that problem. The bad news is that you're still relying
on the hardware to obediently run the verification. So if your hardware isn't
running the verification correctly, it doesn't matter that you have all the
source code for the firmware. Which brings us to the world of hardware implants. So
very briefly, it's worth thinking about, you know, how bad can this get? What are
we worried about? What is the field? If we really want to be worried about trust and
security, how bad can it be? So I've spent many years trying to deal with supply
chains. They're not friendly territory. There's a lot of reasons people want to
screw with the chips in the supply chain. For example, here this is a small ST
microcontroller, claims to be a secure microcontroller. Someone was like: "Ah,
this is not a secure, you know, it's not behaving correctly." We digest off the top
of it. On the inside, it's an LCX244 buffer. Right. So like, you know, this was
not done because someone wanted to tamper with the secure microcontroller. It's
because someone wants to make a quick buck. Right. But the point is that that
marking on the outside is convincing. Right. You could've been any chip on the
inside in that situation. Another problem that I've had personally as I was building
a robot controller board that had an FPGA on the inside. We manufactured a thousand
of these and about 3% of them weren't passing tests, set them aside. Later on, I
pulled these units that weren't passing tests and looked at them very carefully.
And I noticed that all of the units, the FPGA units that weren't passing test had
that white rectangle on them, which is shown in a big more zoomed in version. It
turned out that underneath that white rectangle where the letters ES for
engineering sample, so someone had gone in and Laser blasted off the letters which
say that's an engineering sample, which means they're not qualified for regular
production, blending them into the supply chain at a 3% rate and managed to
essentially double their profits at the end of the day. The reason why this works
is because distributors make a small amount of money. So even a few percent
actually makes them a lot more profit at the end of day. But the key takeaway is
that this is just because 97% of your hardware is okay. It does not mean that
you're safe. Right? So it doesn't help to take one sample out of your entire set of
hardware and say all this is good. This is constructed correctly right, therefore all
of them should be good. That's a ToCToU problem, right? 100% hardware verification
is mandatory. If if you're worried about trust and verification. So let's go a bit
further down the rabbit hole. This is a diagram, sort of an ontology of supply
chain attacks. And I've kind of divided it into two axis. On the vertical axis, is
how easy is it to detect or how hard. Right? So in the bottom you might need a
SEM, a scanning electron microscope to do it, in the middle is an x-ray, a little
specialized and at the top is just visual or JTAG like anyone can do it at home.
Right? And then from left to right is execution difficulty. Right? Things are
going take millions of dollars and months. Things are going take 10$ and weeks. Or a
dollar in seconds. Right? There's sort of several broad classes I've kind of
outlined here. Adding components is very easy. Substituting components is very
easy. We don't have enough time to really go into those. But instead, we're gona
talk about kind of the two more scary ones, which are sort of adding a chip
inside a package and IC modifications. So let's talk about adding a chip in a
package. This one has sort of grabbed a bunch of headlines, so this sort of these
in the Snowden files, we've found these like NSA implants where they had put chips
literally inside of connectors and other chips to modify the computer's behavior.
Now, it turns out that actually adding a chip in a package is quite easy. It
happens every day. This is a routine thing, right? If you take open any SD
card, micro-SD card that you have, you're going to find that it has two chips on the
inside at the very least. One is a controller chip, one is memory chip. In
fact, they can stick 16, 17 chips inside of these packages today very handily.
Right? And so if you want to go ahead and find these chips, is the solution to go
ahead and X-ray all the things, you just take every single circuit board and throw
inside an x-ray machine. Well, this is what a circuit board looks like, in the
x-ray machine. Some things are very obvious. So on the left, we have our
Ethernet magnetic jacks and there's a bunch of stuff on the inside. Turns out
those are all OK right there. Don't worry about those. And on the right, we have our
chips. And this one here, you may be sort of tempted to look and say, oh, I see this
big sort of square thing on the bottom there. That must be the chip. Actually,
turns out that's not the chip at all. That's the solder pad that holds the chip
in place. You can't actually see the chip as the solder is masking it inside the
x-ray. So when we're looking at a chip inside of an x-ray, I've kind of giving
you a look right here on the left is what it looks like sort of in 3-D. And the
right is what looks like an x-ray, sort of looking from the top down. You're looking
at ghostly outlines with very thin spidery wires coming out of it. So if you were to
look at a chip-on-chip in an x-ray, this is actually an image of a chip. So in the
cross-section, you can see the several pieces of silicon that are stacked on top
of each other. And if you could actually do an edge on x-ray of it, this is what
you would see. Unfortunately, you'd have to take the chip off the board to do the
edge on x-ray. So what you do is you have to look at it from the top down and we
look at it from the top down, all you see are basically some straight wires. Like, I
can't it's not obvious from that top down x-ray, whether you're looking at multiple
chips, eight chips, one chip, how many chips are on the inside? That piece of
wire bonds all stitched perfectly in overlap over the chip. So you know. this
is what the chip-on-chip scenario might look like. You have a chip that's sitting
on top of a chip and wire bonds just sort of going a little bit further on from the
edge. And so in the X-ray, the only kind of difference you see is a slightly longer
wire bond in some cases. So it's actually, it's not not, you can find these, but it's
not like, you know, obvious that you've found an implant or not. So looking for
silicon is hard. Silicon is relatively transparent to X-rays. A lot of things
mask it. Copper traces, Solder masks the presence of silicon. This is like another
example of a, you know, a wire bonded chip under an X-ray. There's some mitigations.
If you have a lot of money, you can do computerized tomography. They'll build a
3D image of the chip. You can do X-ray diffraction spectroscopy, but it's not a
foolproof method. And so basically the threat of wirebonded package is actually
very well understood commodity technology. It's actually quite cheap. This is a I was
actually doing some wire bonding in China the other day. This is the wirebonding
machine. I looked up the price, it's 7000 dollars for a used one. And you
basically just walk into the guy with a picture where you want the bonds to go. He
sort of picks them out, programs the machines motion once and he just plays
back over and over again. So if you want to go ahead and modify a chip and add a
wirebond, it's not as crazy as it sounds. The mitigation is that this is a bit
detectable inside X-rays. So let's go down the rabbit hole a little further. So
there's nother concept of threat use called the Through-Silicon Via. So this
here is a cross-section of a chip. On the bottom is the base chip and the top is a
chip that's only 0.1 to 0.2 millimeters thick, almost the width of a human hair.
And they actually have drilled Vias through the chip. So you have circuits on
the top and circuits on the bottom. So this is kind of used to sort of, you know,
putting interposer in between different chips, also used to stack DRAM and HBM. So
this is a commodity process to be able today. It's not science fiction. And the
second concept I want to throw at you is a thing called a Wafer Level Chip Scale
Package, WLCSP. This is actually a very common method for packaging chips today.
Basically it's solder bolts directly on top of chips. They're everywhere. If you
look inside of like an iPhone, basically almost all the chips are WLCSP package
types. Now, if I were to take that Wafer Level Chip Scale Package and cross-section
and look at it, it looks like a circuit board with some solder-balls and the
silicon itself with some backside passivation. If you go ahead and combine
this with a Through-Silicon Via implant, a man in the middle attack using Through-
Silicon Vias, this is what it looks like at the end of the day, you basically have
a piece of silicon this size, the original silicon, sitting in original pads, in
basically all the right places with the solder-balls masking the presence of that
chip. So it's actually basically a nearly undetectable implant if you want to
execute it, if you go ahead and look at the edge of the chip. They already have
seams on the sides. You can't even just look at the side and say, oh, I see a seam
on my chip. Therefore, it's a problem. The seam on the edge often times is because of
a different coding as the back or passivations, these types of things. So if
you really wanted to sort of say, OK, how well can we hide implant, this is probably
the way I would do it. It's logistically actually easier than to worry about an
implant because you don't have to get the chips in wire-bondable format, you
literally just buy them off the Internet. You can just clean off the solder-balls
with a hot air gun and then the hard part is building it so it can be a template for
doing the attack, which will take some hundreds of thousands of dollars to do and
probably a mid-end fab. But if you have almost no budget constraint and you have a
set of chips that are common and you want to build a template for, this could be a
pretty good way to hide an implant inside of a system. So that's sort of adding
chips inside packages. Let's talk a bit about chip modification itself. So how
hard is it to modify the chip itself? Let's say we've managed to eliminate the
possibility of someone's added chip, but what about the chip itself? So this sort
of goes, a lot of people said, hey, bunnie, why don't you spin an open source,
silicon processor, this will make it trustable, right?. This is not a problem.
Well, let's think about the attack surface of IC fabrication processes. So on the
left hand side here I've got kind of a flowchart of what I see fabrication looks
like. You start with a high level chip design, it's a RTL, like Verilog, or VHDL
these days or Python. You go into some backend and then you have a decision to
make: Do you own your backend tooling or not? And so I will go into this a little
more. If you don't, you trust the fab to compile it and assemble it. If you do, you
assemble the chip with some blanks for what's called "hard IP", we'll get into
this. And then you trust the fab to assemble that, make masks and go to mass
production. So there's three areas that I think are kind of ripe for tampering now,
"Netlist tampering", "hard IP tampering" and "mask tampering". We'll go into each
of those. So "Netlist tampering", a lot of people think that, of course, if you wrote
the RTL, you're going to make the chip. It turns out that's actually kind of a
minority case. We hear about that. That's on the right hand side called customer
owned tooling. That's when the customer does a full flow, down to the mask set.
The problem is it costs several million dollars and a lot of extra headcount of
very talented people to produce these and you usually only do it for flagship
products like CPUs, and GPUs or high-end routers, these sorts of things. I would
say most chips tend to go more towards what's called an ASIC side, "Application
Specific Integrated Circuit". What happens is that the customer will do some RTL and
maybe a high level floorplan and then the silicon foundry or service will go ahead
and do the place/route, the IP integration, the pad ring. This is quite
popular for cheap support chips, like your baseboard management controller inside
your server probably went through this flow, disk controllers probably got this
flow, mid-to-low IO controllers . So all those peripheral chips that we don't like
to think about, that we know that can handle our data probably go through a flow
like this. And, to give you an idea of how common it is, but how little you've heard
of it, there's a company called SOCIONEXT. There are a billion dollar company,
actually, you've probably never heard of them, and they offer services. You
basically just throw a spec over the wall and they'll build a chip to you all the
way to the point where you've done logic, synthesis and physical design and then
they'll go ahead and do the manufacturing and test and sample shipment for it. So
then, OK, fine, now, obviously, if you care about trust, you don't do an ASIC
flow, you pony up the millions of dollars and you do a COT flow, right? Well, there
is a weakness in COT flows. And this is it's called the "Hard IP problem". So this
here on the right hand side is an amoeba plot of the standard cells alongside a
piece of SRAM, a highlight this year. The image wasn't great for presentation, but
this region here is the SRAM-block. And all those little colorful blocks are
standard cells, representing your AND- gates and NAND-gates and that sort of
stuff. What happens is that the foundry will actually ask you, just leave an open
spot on your mask-design and they'll go ahead and merge in the RAM into that spot
just before production. The reason why they do this is because stuff like RAM is
a carefully guarded trade secret. If you can increase the RAM density of your
foundry process, you can get a lot more customers. There's a lot of knowhow in it,
and so foundries tend not to want to share the RAM. You can compile your own RAM,
there are open RAM projects, but their performance or their density is not as
good as the foundry specific ones. So in terms of Hard IP, what are the blocks that
tend to be Hard IP? Stuff like RF and analog, phase-locked-loops, ADCs, DACs,
bandgaps. RAM tends to be Hard IP, ROM tends to be Hard IP, eFuze that stores
your keys is going to be given to you as an opaque block, the pad ring around your
chip, the thing that protects your chip from ESD, that's going to be an opaque
block. Basically all the points you need to backdoor your RTL are going to be
trusted in the foundry in a modern process. So OK, let's say, fine, we're
going ahead and build all of our own IP blocks as well. We're gonna compile our
RAMs, do our own IO, everything, right?. So we're safe, right? Well, turns out that
masks can be tampered with post- processing. So if you're going to do
anything in a modern process, the mask designs change quite dramatically from
what you drew them to what actually ends up in the line: They get fractured into
multiple masks, they have resolution correction techniques applied to them and
then they always go through an editing phase. So masks are not born perfect. Masks
have defects on the inside. And so you can look up papers about how they go and they
inspect the mask, every single line on the inside when they find an error, they'll
patch over it, they'll go ahead and add bits of metal and then take away bits of
glass to go ahead and make that mask perfect or, better in some way, if you
have access to the editing capability. So what can you do with mask-editing? Well,
there's been a lot of papers written on this. You can look up ones on, for
example, "Dopant tampering". This one actually has no morphological change. You
can't look at it under a microscope and detect Dopant tampering. You have to have
something and either you have to do some wet chemistry or some X-ray-spectroscopy
to figure it out. This allows for circuit level change without a gross morphological
change of the circuit. And so this can allow for tampering with things like RNGs
or some logic paths. There are oftentimes spare cells inside of your ASIC, since
everyone makes mistakes, including chip designers and so you want a patch over
that. It can be done at the mask level, by signal bypassing, these types of things.
So some certain attacks can still happen at the mask level. So that's a very quick
sort of idea of how bad can it get. When you talk about the time of check, time of
use trust problem inside the supply chain. The short summary of implants is that
there's a lot of places to hide them. Not all of them are expensive or hard. I
talked about some of the more expensive or hard ones. But remember, wire bonding is
actually a pretty easy process. It's not hard to do and it's hard to detect. And
there's really no actual essential correlation between detection difficulty
and difficulty of the attack, if you're very careful in planning the attack. So,
okay, implants are possible. It's just this. Let's agree on that maybe. So now
the solution is we should just have trustable factories. Let's go ahead and
bring the fabs to the EU. Let's have a fab in my backyard or whatever it is, these
these types of things. Let's make sure all the workers are logged and registered,
that sort of thing. Let's talk about that. So if you think about hardware, there's
you, right?. And then we can talk about evil maids. But let's not actually talk
about those, because that's actually kind of a minority case to worry about. But
let's think about how stuff gets to you. There's a distributor, who goes through a
courier, who gets to you. All right. So we've gone and done all this stuff for the
trustful factory. But it's actually documented that couriers have been
intercepted and implants loaded. You know, by for example, the NSA on Cisco products.
Now, you don't even have to have access to couriers, now. Thanks to the way modern
commerce works, other customers can go ahead and just buy a product, tamper with
it, seal it back in the box, send it back to your distributor. And then maybe you
get one, right? That can be good enough. Particularly, if you know a corporation is
in a particular area. Targeting them, you buy a bunch of hard drives in the area,
seal them up, send them back and eventually one of them ends up in the
right place and you've got your implant, right? So there's a great talk last year
at 35C3. I recommend you check it out. That talks a little bit more about the
scenario, sort of removing tamper stickers and you know, the possibility that some
crypto wallets were sent back in the supply chain then and tampered with. OK,
and then let's let's take that back. We have to now worry about the wonderful
people in customs. We have to worry about the wonderful people in the factory who
have access to your hardware. And so if you cut to the chase, it's a huge attack
surface in terms of the supply chain, right? From you to the courier to the
distributor, customs, box build, the box build factory itself. Oftentimes we'll use
gray market resources to help make themselves more profitable, right? You
have distributors who go to them. You don't even know who those guys are. PCB
assembly, components, boards, chip fab, packaging, the whole thing, right? Every
single point is a place where someone can go ahead and touch a piece of hardware
along the chain. So can open source save us in this scenario? Does open hardware
solve this problem? Right. Let's think about it. Let's go ahead and throw some
developers with git on the left hand side. How far does it get, right? Well, we can
have some continuous integration checks that make sure that you know the hardware
is correct. We can have some open PCB designs. We have some open PDK, but then
from that point, it goes into a rather opaque machine and then, OK, maybe we can
put some test on the very edge before exit the factory to try and catch some
potential issues, right? But you can see all the area, other places, where a time
of check, time of use problem can happen. And this is why, you know, I'm saying that
open hardware on its own is not sufficient to solve this trust problem. Right? And
the big problem at the end of the day is that you can't hash hardware. Right? There
is no hash function for hardware. That's why I want to go through that early today.
There's no convenient, easy way to basically confirming the correctness of
your hardware before you use it. Some people say, well, bunnie, said once, there
is always a bigger microscope, right? You know, I do some, security reverse
engineering stuff. This is true, right? So there's a wonderful technique called
ptychographic X-ray Imaging, there is a great paper in nature about it, where they
take like a modern i7 CPU and they get down to the gate level nondestructively
with it, right? It's great for reverse engineering or for design verification.
The problem number one is it literally needs a building sized microscope. It was
done at the Swiss light source, that donut shaped thing is the size of the light
source for doing that type of verification, right? So you're not going
to have one at your point of use, right? You're going to check it there and then
probably courier it to yourself again. Time of check is not time of use. Problem
number two, it's expensive to do so. Verifying one chip only verifies one chip
and as I said earlier, just because 99.9% of your hardware is OK, doesn't mean
you're safe. Sometimes all it takes is one server out of a thousand, to break some
fundamental assumptions that you have about your cloud. And random sampling just
isn't good enough, right? I mean, would you random sample signature checks on
software that you install? Download? No. You insist 100% check and everything. If
you want that same standard of reliability, you have to do that for
hardware. So then, is there any role for open source and trustful hardware?
Absolutely, yes. Some of you guys may be familiar with that little guy on the
right, the SPECTRE logo. So correctness is very, very hard. Peer review can help fix
correctness bugs. Micro architectural transparency can able the fixes in SPECTRE
like situations. So, you know, for example, you would love to be able to say
we're entering a critical region. Let's turn off all the micro architectural
optimizations, sacrifice performance and then run the code securely and then go
back into, who cares what mode, and just get done fast, right? That would be a
switch I would love to have. But without that sort of transparency or without the
bill to review it, we can't do that. Also, you know, community driven features and
community own designs is very empowering and make sure that we're sort of building
the right hardware for the job and that it's upholding our standards. So there is
a role. It's necessary, but it's not sufficient for trustable hardware. Now the
question is, OK, can we solve the point of use hardware verification problem? Is it
all gloom and doom from here on? Well, I didn't bring us here to tell you it's just
gloom and doom. I've thought about this and I've kind of boiled it into three
principles for building verifiable hardware. The three principles are: 1)
Complexity is the enemy of verification. 2) We should verify entire systems, not
just components. 3) And we need to empower end-users to verify and seal their
hardware. We'll go into this in the remainder of the talk. The first one is
that complexity is complicated. Right? Without a hashing function, verification
rolls back to bit-by-bit or atom-by-atom verification. Modern phones just have so
many components. Even if I gave you the full source code for the SOC inside of a
phone down to the mass level, what are you going to do with it? How are you going to
know that this mass actually matches the chip and those two haven't been modified?
So more complexity, is more difficult. The solution is: Let's go to simplicity,
right? Let's just build things from discrete transistors. Someone's done this.
The Monster 6502 is great. I love the project. Very easy to verify. Runs at 50
kHz. So you're not going to do a lot with that. Well, let's build processors at
a visually inspectable process node. Go to 500 nanometers. You can see that with
light. Well, you know, 100 megahertz clock rate and a very high power consumption and
you know, a couple kilobytes RAM probably is not going to really do it either.
Right? So the point of use verification is a tradeoff between ease of verification
and features and usability. Right? So these two products up here largely do the
same thing. Air pods. Right? And headphones on your head. Right? Air pods
have something on the order of tens of millions of transistors for you to verify.
The headphone that goes on your head. Like I can actually go to Maxwell's equations
and actually tell you how the magnets work from very first principles. And there's
probably one transistor on the inside of the microphone to go ahead and amplify the
membrane. And that's it. Right? So this one, you do sacrifice some features and
usability, when you go to a headset. Like you can't say, hey, Siri, and they will
listen to you and know what you're doing, but it's very easy to verify and know
what's going on. So in order to start a dialog on user verification, we have to
serve a set of context. So I started a project called 'Betrusted' because the
right answer depends on the context. I want to establish what might be a minimum
viable, verifiable product. And it's sort of like meant to be user verifiable by
design. And when we think of it as a hardware software distro. So it's meant to
be modified and changed and customized based upon the right context at the end of
the day. This a picture of what it looks like. I actually have a little prototype
here. Very, very, very early product here at the Congress. If you wanna look at it.
It's a mobile device that is meant for sort of communication, sort of text based
communication and maybe voice authentication. So authenticator tokens
are like a crypto wall if you want. And the people were thinking about who might
be users are either high value targets politically or financially. So you don't
have to have a lot of money to be a high value target. You could also be in a very
politically risky for some people. And also, of course, looking at developers and
enthusiasts and ideally we're thinking about a global demographic, not just
English speaking users, which is sort of a thing when you think about the complexity
standpoint, this is where we really have to sort of champ at the bit and figure out
how to solve a lot of hard problems like getting Unicode and, you know, right to
left rendering and pictographic fonts to work inside a very small tax surface
device. So this leads me to the second point. In which we verify entire systems,
not just components. We all say, well, why not just build a chip? Why not? You know,
why are you thinking about a whole device? Right. The problem is, that private keys
are not your private matters. Screens can be scraped and keyboards can be logged. So
there's some efforts now to build wonderful security enclaves like Keystone
and Open Titan, which will build, you know, wonderful secure chips. The problem
is, that even if you manage to keep your key secret, you still have to get that
information through an insecure CPU from the screen to the keyboard and so forth.
Right? And so, you know, people who have used these, you know, on screen touch
keyboards have probably seen something of a message like this saying that, by the
way, this keyboard can see everything you're typing, clean your passwords.
Right? And people probably clip and say, oh, yeah, sure, whatever. I trust that.
Right? OK, well, this answer, this little enclave on the site here isn't really
doing a lot of good. When you go ahead and you say, sure, I'll run this implant
method, they can go ahead and modify all my data and intercept all my data. So in
terms of making a device variable, let's talk about the concept of practice flow.
How do I take these three principles and turn them into something? So this is you
know, this is the ideal of taking these three requirements and turning it into the
set of five features, a physical keyboard, a black and white LCD, a FPGA-based RISC-V
SoC, users-sealable keys and so on. It's easy to verify and physically protect. So
let's talk about these features one by one. First one is a physical keyboard. Why
am I using a physical keyboard and not a virtual keyboard? People love the virtual
keyboard. The problem is that captouch screens, which is necessary to do a good
virtual keyboard, have a firmware block. They have a microcontroller to do the
touch screens, actually. It's actually really hard to build these things we want.
If you can do a good job with it and build an awesome open source one, that'll be
great, but that's a project in and of itself. So in order to sort of get an easy
win here and we can, let's just go with the physical keyboard. So this is what the
device looks like with this cover off. We have a physical keyboard, PCV with a
little overlay that does, you know, so we can do multilingual inserts and you can go
to change that out. And it's like it's just a two layer daughter card. Right.
Just hold up to like, you know, like, OK, switches, wires. Right? Not a lot of
places to hide things. So I'll take that as an easy win for an input surface,
that's verifiable. Right? The output surface is a little more subtle. So we're
doing a black and white LCD. If you say, OK, why not use a curiosity? If you ever
take apart a liquid crystal display, look for a tiny little thin rectangle sort of
located near the display area. That's actually a silicon chip that's bonded to
the glass. That's what it looks like at the end of the day. That contains a frame
buffer and a command interface. It has millions of transistors on the inside and
you don't know what it does. So if you're ever assuming your adversary may be
tampering with your CPU, this is also a viable place you have to worry about. So I
found a screen. It's called a memory LCD by sharp electronics. It turns out they do
all the drive electrons on glass. So this is a picture of the driver electronics on
the screen through like a 50x microscope with a bright light behind it. Right? You
can actually see the transistors that are used to to drive everything on the display
it's a nondestructive method of verification. But actually more important
to the point is that there's so few places to hide things, you probably don't need to
check it, right? There's not - If you want to add an implant to this, you would need
to grow the glass area substantially or add a silicon chip, which is a thing that
you'll notice, right. So at the end of the day, the less places to hide things is
less need to check things. And so I can feel like this is a screen where I can
write data to, and it'll show what I want to show. The good news is that display has
a 200 ppi pixel density. So it's not - even though it's black and white - it's
kind of closer to E-Paper. EPD in terms of resolution. So now we come to the hard
part, right, the CPU. The silicon problem, right? Any chip built in the last two
decades is not going to be inspectable, fully inspectable with optical microscope,
right? Thorough analysis requires removing layers and layers of metal and dielectric.
This is sort of a cross section of a modernish chip and you can see the sort of
the huge stack of things to look at on this. This process is destructive and you
can think of it as hashing, but it's a little bit too literal, right? We want
something where we can check the thing that we're going to use and then not
destroy it. So I've spent quite a bit of time thinking about options for
nondestructive silicon verification. The best I could come up with maybe was using
optical fauilt induction somehow combined with some chip design techniques to go
ahead and like scan a laser across and look at fault syndromes and figure out,
you know, does the thing... do the gates that we put down correspond to the thing
that I built. The problem is, I couldn't think of a strategy to do it that wouldn't
take years and tens of millions of dollars to develop, which puts it a little bit far
out there and probably in the realm of like sort of venture funded activities,
which is not really going to be very empowering of everyday people. So let's
say I want something a little more short term than that, then that sort of this,
you know, sort of, you know, platonic ideal of verifiability. So the compromise
I sort of arrived at is the FPGA. So field programmable gate arrays, that's what FPGA
stands for, are large arrays of logic and wires that are user configured to
implement hardware designs. So this here is an image inside an FPGA design tool. On
the top right is an example of one sort of logic sub cell. It's got a few flip flops
and lookup tables in it. It's embedded in this huge mass of wires that allow you to
wire it up at runtime to figure out what's going on. And one thing that this diagram
here shows is I'm able to sort of correlate design. I can see "Okay. The
decode_to_execute_INSTRUCTION_reg bit 26 corresponds to this net." So now we're
sort of like bring that Time Of Check a little bit closer to Time Of Use. And so
the idea is to narrow that ToCToU gap by compiling your own CPU. We can basically
give you the CPU from source. You can compile it yourself. You can confirm the
bit stream. So now we're sort of enabling a bit more of that trust transfer like
software, right. But there's a subtlety in that the toolchains are not necessarily
always open. There's some FOSS flows like symbiflow. They have a 100% open flow for
ICE40 and ECP5 and there's like 7-series where they've a coming-soon status, but
they currently require some closed vendor tools. So picking FPGA is a difficult
choice. There's a usability versus verification tradeoff here. The big
usability issue is battery life. If we're going for a mobile device, you want to use
it all day long or you want to be dead by noon. It turns out that the best sort of
chip in terms of battery life is a Spartan7. It gives you 4x, roughly 3 to
4x, in terms of battery life. But the tool flow is still semi-closed. But the, you
know, I am optimistic that symbiflow will get there and we can also fork and make an
ECP5 version if that's a problem at the end of day. So let's talk a little bit
more about sort of FPGA features. So one thing I like to say about FPGA is: they
offer a sort of ASLR, so address-space layout randomization, but for hardware.
Essentially, a design has a kind of pseudo-random mapping to the device. This
is a sort of a screenshot of two compilation runs at the same source code
with a very small modification to it. And basically a version number stored in a
GPR. And then you can see that the actually the locations of a lot of the
registers are basically shifted around. The reason why this is important is
because this hinders a significant class of silicon attacks. All those small mass
level changes I talked about the ones where we just "Okay, we're just gonna head
and change a few wires or run a couple logic cells around", those become more
less likely to capture a critical bit. So if you want to go ahead and backdoor a
full FPGA, you're going to have to change the die size. You have to make it
substantially larger to be able to sort of like swap out the function in those cases.
And so now the verification bar goes from looking for a needle in a haystack to
measuring the size of the haystack, which is a bit easier to do towards the user
side of things. And it turns out, at least in Xilinx-land, it's just a change of a
random parameter does the trick. So some potential attack vectors against FPGA is
like "OK, well, it's closed silicon." What are the backdoors there? Notably inside a
7-series FPGA they actually document introspection features. You can pull out
anything inside the chip by instantiating a certain special block. And then we still
also have to worry about the whole class of like man in the middle. I/O- and JTAG
implants that I talked about earlier. So It's easy, really easy, to mitigate the
known blocks, basically lock them down, tie them down, check them in the bit
stream, right? In terms of the I/O-man-in- the-middle stuff, this is where we're
talking about like someone goes ahead and puts a chip in in the path of your FPGA.
There's a few tricks you can do. We can do sort of bust encryption on the RAM and the
ROM at the design level that frustrates these. At the implementation, basically,
we can use the fact that data pins and address pins can be permuted without
affecting the device's function. So every design can go ahead and permute those data
and address pin mappings sort of uniquely. So any particular implant that goes in
will have to be able to compensate for all those combinations, making the implant a
little more difficult to do. And of course, we can also fall back to sort of
careful inspection of the device. In terms of the closed source silicon, the thing
that I'm really optimistic for there is that so in terms of the closed source
system, the thing that we have to worry about is that, for example, now that
Xilinx knows that we're doing these trustable devices using a tool chain, they
push a patch that compiles back doors into your bit stream. So not even as a silicon
level implant, but like, you know, maybe the tool chain itself has a backdoor that
recognizes that we're doing this. So the cool thing is, this is a cool project: So
there's a project called "Prjxray", project x-ray, it's part of the Symbiflow
effort, and they're actually documenting the full bit stream of the 7-Series
device. It turns out that we don't yet know what all the bit functions are, but
the bit mappings are deterministic. So if someone were to try and activate a
backdoor in the bit stream through compilation, we can see it in a diff. We'd
be like: Wow, we've never seen this bit flip before. What is this? Do we can look
into it and figure out if it's malicious or not, right? So there's actually sort of
a hope that essentially at the end of day we can build sort of a bit stream checker.
We can build a thing that says: Here's a bit stream that came out, does it
correlate to the design source, do all the bits check out, do they make sense? And so
ideally we would come up with like a one click tool. And now we're at the point
where the point of check is very close to the point of use. The users are now
confirming that the CPUs are correctly constructed and mapped to the FPGA
correctly. So the sort of the summary of FPGA vs. custom silicon is sort of like,
the pros of custom silicon is that they have great performance. We can do a true
single chip enclave with hundreds of megahertz speeds and tiny power
consumption. But the cons of silicon is that it's really hard to verify. So, you
know, open source doesn't help that verification and Hard IP blocks are tough
problems we talked about earlier. So FPGAs on the other side, they offer some
immediate mitigation paths. We don't have to wait until we solve this verification
problem. We can inspect the bit streams, we can randomize the logic mapping and we
can do per device unique pin mapping. It's not perfect, but it's better than I think
any other solution I can offer right now. The cons of it is that FPGAs are just
barely good enough to do this today. So you need a little bit of external RAM
which needs to be encrypted, but 100 megahertz speed performance and about five
to 10x the power consumption of a custom silicon solution, which in a mobile device
is a lot. But, you know, actually part of the reason, the main thing that drives the
thickness in this is the battery, right? And most of that battery is for the FPGA.
If we didn't have to go with an FPGA it could be much, much thinner. So now let's
talk a little about the last two points, user-sealable keys, and verification and
protection. And this is that third point, "empowering end users to verify and seal
their hardware". So it's great that we can verify something but can it keep a secret?
No, transparency is good up to a point, but you want to be able to keep secrets so
that people won't come up and say: oh, there's your keys, right? So sealing a key
in the FPGA, ideally we want user generated keys that are hard to extract,
we don't rely on a central keying authority and that any attack to remove
those keys should be noticeable. So any high level apps, I mean, someone with
infinite funding basically should take about a day to extract it and the effort
should be trivially evident. The solution to that is basically self provisioning and
sealing of the cryptographic keys in the bit stream and a bit of epoxy. So let's
talk a little bit about provisioning those keys. If we look at the 7-series FPGA
security, they offer a sort of encrypted HMAC 256-AES, with 256-bit SHA bit
streams. There's a paper which discloses a known weakness in it, so the attack takes
about a day or 1.6 million chosen cipher text traces. The reason why it takes a day
is because that's how long it takes to load in that many chosen ciphertexts
through the interfaces. The good news is there's some easy mitigations to this. You
can just glue shut the JTAG-port or improve your power filtering and that
should significantly complicate the attack. But the point is that it will take
a fixed amount of time to do this and you have to have direct access to the
hardware. It's not the sort of thing that, you know, someone at customs or like an
"evil maid" could easily pull off. And just to put that in perspective, again,
even if we improved dramatically the DPA- resistance of the hardware, if we knew a
region of the chip that we want to inspect, probably with the SEM in it and a
skilled technician, we could probably pull it off in a matter of a day or a couple of
days. Takes only an hour to decap the silicon, you know, an hour for a few
layers, a few hours in the FIB to delayer a chip, and an afternoon in the the SEM
and you can find out the keys, right? But the key point is that, this is kind of the
level that we've agreed is OK for a lot of the silicon enclaves, and this is not
going to happen at a customs checkpoint or by an evil maid. So I think I'm okay with
that for now. We can do better. But I think that's it's a good starting point,
particularly for something that's so cheap and accessible. So then how do we get
those keys in FPGA and how do we keep them from getting out? So those keys should be
user generated, never leave device, not be accessible by the CPU after it's
provisioned, be unique per device. And it should be easy for the user to get it
right. It should be. You don't have to know all the stuff and type a bunch
commands to do it, right. So if you look inside Betrusted there's two rectangles
there, one of them is the ROM that contains a bit stream, the other one is
the FPGA. So we're going to draw those in the schematic form. Inside the ROM, you
start the day with an unencrypted bit stream in ROM, which loads an FPGA. And
then you have this little crypto engine. There's no keys on the inside. There's no
anywhere. You can check everything. You can build your own bitstream, and do what
you want to do. The crypto engine then generates keys from a TRNG that's located
on chip. Probably some help of some off- chip randomness as well, because I don't
necessarily trust everything inside the FPGA. Then that crypto engine can go ahead
and, as it encrypts the external bit stream, inject those keys back into the
bit stream because we know where that block-RAM is. We can go ahead and inject
those keys back into that specific RAM block as we encrypt it. So now we have a
sealed encrypted image on the ROM, which can then load the FPGA if it had the key.
So after you've gone ahead and provisioned the ROM, hopefully at this point you don't
lose power, you go ahead and you burn the key into the FPGA's keying engine which
sets it to only boot from that encrypted bit stream, blow out the readback-
disabled-bit and the AES-only boot is blown. So now at this point in time,
basically there's no way to go ahead and put in a bit stream that says tell me your
keys, whatever it is. You have to go and do one of these hard techniques to pull
out the key. You can maybe enable hardware upgrade path if you want by having the
crypto and just be able to retain a copy of the master key and re-encrypt it, but
that becomes a vulnerability because the user can be coerced to go ahead and load
inside a bit stream that then leaks out the keys. So if you're really paranoid at
some point in time, you seal this thing and it's done. You know, you have to go
ahead and do that full key extraction routine to go ahead and pull stuff out if
you forget your passwords. So that's the sort of user-sealable keys. I think we can
do that with FPGA. Finally, easy to verify and easy to protect. Just very quickly
talking about this. So if you want to make an expectable tamper barrier, a lot of
people have talked about glitter seals. Those are pretty cool, right? The problem
is, I find that glitter seals are too hard to verify. Right. Like, I have tried
glitter-seals before and I stare at the thing and I'm like: Damn, I have no idea
if this is the seal I put down. And so then I say, ok, we'll take a picture or
write an app or something. Now I'm relying on this untrusted device to go ahead and
tell me if the seal is verified or not. So I have a suggestion for a DIY watermark
that relies not on an app to go and verify, but our very, very well tuned
neural networks inside our head to go ahead and verify things. So the idea is
basically, there's this nice epoxy that I found. It comes in this Bi-packs, 2 part
epoxy, you just put on the edge of a table and you go like this and it goes ahead and
mixes the epoxy and you're ready to use. It's very easy for users to apply. And
then you just draw a watermark on a piece of tissue paper. It turns out humans are
really good at identifying our own handwriting, our own signatures, these
types of things. Someone can go ahead and try to forge it. There's people who are
skilled in doing this, but this is way easier than looking at a glitter-seal. You
go ahead and put that down on your device. You swab on the epoxy and at the end of
day, you end up with a sort of tissue paper plus a very easily recognizable
seal. If someone goes ahead and tries to take this off or tamper with it, I can
look at it easy and say, yes, this is a different thing than what I had yesterday,
I don't have to open an app, I don't have to look at glitter patterns, I don't have
to do these sorts of things. And I can go ahead and swab onto all the I/O-ports that
need to do. So it's a bit of a hack, but I think that it's a little closer towards
not having to rely on third party apps to verify a tamper evidence seal. So I've
talked about sort of this implementation and also talked about how it maps to these
three principles for building trustable hardware. So the idea is to try to build a
system that is not too complex so that we can verify most the parts or all of them
at the end-user point, look at the keyboard, look at the display and we can
go ahead and compile the FPGA from source. We're focusing on verifying the entire
system, the keyboard and the display, we're not forgetting the user. They secret
starts with the user and ends with the user, not with the edge of the silicon.
And finally, we're empowering end-users to verify and seal their own hardware. You
don't have to go through a central keying authority to go ahead and make sure
secrets are are inside your hardware. So at the end of the day, the idea behind
Betrusted is to close that hardware time of check/time of use gap by moving the
verification point closer to the point of use. So in this huge, complicated
landscape of problems that we can have, the idea is that we want to, as much as
possible, teach users to verify their own stuff. So by design, it's meant to be a
thing that hopefully anyone can be taught to sort of verify and use, and we can
provide tools that enable them to do that. But if that ends up being too high of a
bar, I would like it to be within like one or two nodes in your immediate social
network, so anyone in the world can find someone who can do this. And the reason
why I kind of set this bar is, I want to sort of define the maximum level of
technical competence required to do this, because it's really easy, particularly
when sitting in an audience of these really brilliant technical people to say,
yeah, of course everyone can just hash things and compile things and look at
things in microscopes and solder and then you get into life and reality and then be
like: oh, wait, I had completely forgotten what real people are like. So this tries
to get me grounded and make sure that I'm not sort of drinking my own Kool-Aid in
terms of how useful open hardware is as a mechanism to verify anything. Because I
hand a bunch of people schematics and say, check this and they'll be like: I have no
idea. So the current development status is that: The hardware is kind of an initial
EVT stage for types subject to significant change, particularly part of the reason
we're here is talking about this is to collect more ideas and feedback on this,
to make sure we're doing it right. The software is just starting. We're writing
our own OS called Xous, being done by Sean Cross, and we're exploring the UX and
applications being done by Tom Marble shown here. And I actually want to give a
big shout out to NLnet for funding us partially. We have a grant, a couple of
grants for under privacy and trust enhancing technologies. This is really
significant because now we can actually think about the hard problems, and not
have to be like, oh, when do we go crowdfunded, when do we go fundraising.
Like a lot of time, people are like: This looks like a product, can we sell this
now? It's not ready yet. And I want to be able to take the time to talk about it,
listen to people, incorporate changes and make sure we're doing the right thing. So
with that, I'd like to open up the floor for Q&A. Thanks to everyone, for coming to
my talk.
*Applause*
Herald: Thank you so much, bunnie, for the great talk. We have about five minutes
left for Q&A. For those who are leaving earlier, you're only supposed to use the
two doors on the left, not the one, not the tunnel you came in through, but only
the doors on the left back, the very left door and the door in the middle. Now, Q&A,
you can pile up at the microphones. Do we have a question from the Internet? No, not
yet. If someone wants to ask a question but is not present but in the stream, or
maybe a person in the room who wants to ask a question, you can use the hashtag
#Clark and Twitter. Mastodon and IRC are being monitored. So let's start with
microphone number one. Your question, please.
Q: Hey, bunnie. So you mentioned that with the foundry process that the Hard IP-
blocks, the prototyped IP-blocks are a place where attacks could be made. Do you
have the same concern about the Hard IP blocks in the FPGA, either the embedded
block RAM or any of the other special features that you might be using?
bunnie: Yeah, I think that we do have to be concerned about implants that have
existed inside the FPGA prior to this project. And I think there is a risk, for
example, that there's a JTAG-path that we didn't know about. But I guess the
compensating side is that the military, U.S. military does use a lot of these in
their devices. So they have a self- interest in not having backdoors inside of
these things as well. So we'll see. I think that the answer is it's possible. I
think the upside is that because the FPGA is actually a very regular structure,
doing like sort of a SEM-level analysis, of the initial construction of it at
least, is not insane. We can identify these blocks and look at them and make
sure the right number of bits. That doesn't mean the one you have today is the
same one. But if they were to go ahead and modify that block to do sort of the
implant, my argument is that because of the randomness of the wiring and the
number of factors they have to consider, they would have to actually grow the
silicon area substantially. And that's a thing that is a proxy for detection of
these types of problems. So that would be my kind of half answer to that problem.
It's a good question, though. Thank you. Herald: Thanks for the question. The next
one from microphone number three, please. Yeah. Move close to the microphone.
Thanks. Q: Hello. My question is, in your proposed
solution, how do you get around the fact that the attacker, whether it's an implant
or something else, will just attack it before they user self provisioning so
it'll compromise a self provisioning process itself?
bunnie: Right. So the idea of the self provisioning process is that we send the
device to you, you can look at the circuit boards and devices and then you compile
your own FPGA, which includes a self provisioning code from source and you can
confirm, or if you don't want to compile, you can confirm that the signatures match
with what's on the Internet. And so someone wanting to go ahead and compromise
that process and so stash away some keys in some other place, that modification
would either be evident in the bit stream or that would be evident as a modification
of the hash of the code that's running on it at that point in time. So someone would
have to then add a hardware implant, for example, to the ROM, but that doesn't help
because it's already encrypted by the time it hits the ROM. So it'd really have to be
an implant that's inside the FPGA and then trammel's question just sort of talked
about that situation itself. So I think the attack surface is limited at least for
that. Q: So you talked about how the courier
might be a hacker, right? So in this case, you know, the courier would put a
hardware implant, not in the Hard IP, but just in the piece of hardware inside the
FPGA that provisions the bit stream. bunnie: Right. So the idea is that you
would get that FPGA and you would blow your own FPGA bitstream yourself. You
don't trust my factory to give you a bit stream. You get the device.
Q: How do you trust that the bitstream is being blown. You just get indicate your
computer's saying this bitstream is being blown.
bunnie: I see, I see, I see. So how do you trust that the ROM actually doesn't have a
backdoor in itself that's pulling in the secret bit stream that's not related to
him. I mean, possible, I guess. I think there are things you can do to defeat
that. So the way that we do the semi randomness in the compilation is that
there's a random 64-Bit random number we compile into the bit stream. So we're
compiling our own bitstream. You can read out that number and see if it matches. At
that point, if someone had pre burned a bit stream onto it that is actually loaded
instead of your own bit stream, it's not going to be able to have that random
number, for example, on the inside. So I think there's ways to tell if, for
example, the ROM has been backdoored and it has two copies of the ROM, one of the
evil one and one of yours, and then they're going to use the evil one during
provisioning, right? I think that's a thing that can be mitigated.
Herald: All right. Thank you very much. We take the very last question from
microphone number five. Q: Hi, bunnie. So one of the options you
sort of touched on in the talk but then didn't pursue was this idea of doing some
custom silicon in a sort of very low-res process that could be optically inspected
directly. bunnie: Yes.
Q: Is that completely out of the question in terms of being a usable route in the
future or, you know, did you look into that and go to detail at all?
bunnie: So I thought about that when there's a couple of issues: 1) Is that if
we rely on optical verification now, users need optical verification prior to do it.
So we have to somehow move those optical verification tools to the edge towards
that time of use. Right. So nice thing about the FPGA is everything I talked
about building your own midstream, inspecting the bit stream, checking the
hashes. Those are things that don't require particular sort of user equipment.
But yes, if we if we were to go ahead and build like an enclave out of 500
nanometers, silicon like it probably run around 100 megahertz, you'd have a few
kilobytes of RAM on the inside. Not a lot. Right. So you have a limitation in how
much capability you have on it and would consume a lot of power. But then every
single one of those chips. Right. We put them in a black piece of epoxy. How do you
like, you know, what keeps someone from swapping that out with another chip?
Q: Yeah. I mean, I was I was thinking of like old school, transparent top, like on
a lark. bunnie: So, yeah, you can go ahead and
wire bond on the board, put some clear epoxy on and then now people have to take
a microscope to look at that. That's a possibility. I think that that's the sort
of thing that I think I am trying to imagine. Like, for example, my mom using
this and asking her do this sort of stuff. I just don't envision her knowing anyone
who would have an optical microscope who could do this for except for me. Right.
And I don't think that's a fair assessment of what is verifiable by the end user. At
the end of the day. So maybe for some scenarios it's OK. But I think that the
full optical verification of a chip and making that sort of the only thing between
you and implant, worries me. That's the problem with the hard chip is that
basically if someone even if it's full, you know, it's just to get a clear thing
and someone just swapped out the chip with another chip. Right. You still need to
know, a piece of equipment to check that. Right. Whereas like when I talked about
the display and the fact that you can look at that, actually the argument for that is
not that you have to check the display. It's that you don't it's actually because
it's so simple. You don't need to check the display. Right. You don't need the
microscope to check it, because there is no place to hide anything.
Herald: All right, folks, we ran out of time. Thank you very much to everyone who
asked a question. And please give another big round of applause to our great
speaker, bunnie. Thank you so much for the great talk. Thanks.
*Applause*
bunnie: Thanks everyone!
*Outro*
Subtitles created by c3subtitles.de in the year 2020. Join, and help us!