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