1
00:00:00,000 --> 00:00:14,790
36C3 preroll music
2
00:00:14,790 --> 00:00:25,539
Herald: Our next speaker is way is paved
with broken trust zones. He's no stranger
3
00:00:25,539 --> 00:00:31,599
to breaking ARM's, equipment or crypto
wallets or basically anything he touches.
4
00:00:31,599 --> 00:00:39,591
It just dissolves in his fingers. He's one
of Forbes, 30 under 30s in tech. And
5
00:00:39,591 --> 00:00:42,840
please give a warm round of applause to
Thomas Roth.
6
00:00:42,840 --> 00:00:48,100
Applause.
7
00:00:48,100 --> 00:00:54,680
Thomas: Test, okay. Wonderful. Yeah.
Welcome to my talk. TrustZone-M: Hardware
8
00:00:54,680 --> 00:01:00,630
attacks on ARMv8-M security features. My
name is Thomas Roth. You can find me on
9
00:01:00,630 --> 00:01:05,860
Twitter. I'm @stacksmashing and I'm a
security researcher, consultant and
10
00:01:05,860 --> 00:01:11,049
trainer affiliated with a couple of
companies. And yeah, before we can start,
11
00:01:11,049 --> 00:01:15,990
I need to to thank some people. So first
off, Josh Datko and Dimitri Nedospasov
12
00:01:15,990 --> 00:01:20,110
who've been super helpful at anytime I was
stuck somewhere, or just wanted some
13
00:01:20,110 --> 00:01:25,969
feedback. They immediately helped me. And
also Colin O'Flynn, who gave me constant
14
00:01:25,969 --> 00:01:30,729
feedback and helped me with some troubles,
gave me tips and so on. And so without
15
00:01:30,729 --> 00:01:36,909
these people and many more who paved the
way towards this research, I wouldn't be
16
00:01:36,909 --> 00:01:41,520
here. Also, thanks to NXP and Microchip
who I had to work with as part of this
17
00:01:41,520 --> 00:01:47,950
talk. And it was awesome. I had a lot of
very bad vendor experiences, but these two
18
00:01:47,950 --> 00:01:54,799
were really nice to work with. Also some
prior work. So Colin O'Flynn and Alex
19
00:01:54,799 --> 00:01:59,499
Dewar released a paper, I guess last year
or this year "On-Device Power Analysis
20
00:01:59,499 --> 00:02:04,270
Across Hardware Security Domains". And
they basically looked at TrustZone from a
21
00:02:04,270 --> 00:02:10,301
differential power analysis viewpoint and
otherwise TrustZone-M is pretty new, but
22
00:02:10,301 --> 00:02:15,860
lots of work has been done on the big or
real TrustZone and also lots and lots of
23
00:02:15,860 --> 00:02:21,440
works on fault injection would be far too
much to list here. So just google fault
24
00:02:21,440 --> 00:02:26,220
injection and you'll see what I mean.
Before we start, what is TrustZone-M? So
25
00:02:26,220 --> 00:02:31,890
TrustZone-M is the small TrustZone. It's
basically a simplified version of the big
26
00:02:31,890 --> 00:02:35,940
TrustZone that you find on Cortex-A
processors. So basically if you have an
27
00:02:35,940 --> 00:02:40,280
Android phone, chances are very high that
your phone actually runs TrustZone and
28
00:02:40,280 --> 00:02:44,950
that, for example, your key store of
Android is backed by TrustZone. And
29
00:02:44,950 --> 00:02:50,620
TrustZone basically splits the CPU into a
secure and a non-secure world. And so, for
30
00:02:50,620 --> 00:02:54,340
example, you can say that a certain
peripheral should only be available to the
31
00:02:54,340 --> 00:02:58,190
secure world. So, for example, if you have
a crypto accelerator, you might only want
32
00:02:58,190 --> 00:03:03,990
to use it in the secure world. It also, if
you're wondering what's the difference to
33
00:03:03,990 --> 00:03:10,870
an MPU - it also comes with two MPUs.
Sorry, not MMUs, MPUs. And so last year we
34
00:03:10,870 --> 00:03:14,650
gave a talk on bitcoin wallets. And so
let's take those as an example on a
35
00:03:14,650 --> 00:03:19,730
bitcoin wallet you often have different
apps, for example, for Bitcoin, Dogecoin
36
00:03:19,730 --> 00:03:24,590
or Monaro, and then underneath you have an
operating system. The problem is kind of
37
00:03:24,590 --> 00:03:28,620
this operating system is very complex
because it has to handle graphics
38
00:03:28,620 --> 00:03:33,060
rendering and so on and so forth. And
chances are high that it gets compromised.
39
00:03:33,060 --> 00:03:37,900
And if it gets compromised, all your funds
are gone. And so with TrustZone, you could
40
00:03:37,900 --> 00:03:43,380
basically have a second operating system
separated from your normal one that
41
00:03:43,380 --> 00:03:47,250
handles all the important stuff like
firmware update, key store attestation and
42
00:03:47,250 --> 00:03:52,930
so on and reduces your attack surface. And
the reason I actually looked at
43
00:03:52,930 --> 00:03:57,280
TrustZone-M is we got a lot of requests
for consulting on TrustZone-M. So
44
00:03:57,280 --> 00:04:02,510
basically, after our talk last year, a lot
of companies reached out to us and said,
45
00:04:02,510 --> 00:04:07,100
okay, we want to do this, but more
securely. And a lot of them try to use
46
00:04:07,100 --> 00:04:12,190
TrustZone-M for this. And so far there's
been, as far as I know, little public
47
00:04:12,190 --> 00:04:16,780
research into TrustZone-M and whether it's
protected against certain types of
48
00:04:16,780 --> 00:04:21,250
attacks. And we also have companies that
start using them as secure chips. So, for
49
00:04:21,250 --> 00:04:24,990
example, in the automotive industry, I
know somebody who was thinking about
50
00:04:24,990 --> 00:04:28,810
putting them into car keys. I know about
some people in the payment industry
51
00:04:28,810 --> 00:04:34,820
evaluating this. And as said, hardware
wallets. And one of the terms that come up
52
00:04:34,820 --> 00:04:40,469
again and again is this is a secure chip.
But I mean, what is the secure chip
53
00:04:40,469 --> 00:04:45,130
without a threat model? There's no such
thing as a secure chip because there are
54
00:04:45,130 --> 00:04:49,310
so many attacks and you need to have a
threat model to understand what are you
55
00:04:49,310 --> 00:04:53,280
actually protecting against. So, for
example, a chip might have software
56
00:04:53,280 --> 00:04:59,080
features or hardware features that make
the software more secure, such as NX bit
57
00:04:59,080 --> 00:05:03,229
and so on and so forth. And on the other
hand, you have hardware attacks, for
58
00:05:03,229 --> 00:05:08,460
example, debug port side channel attacks
and fault injection. And often the
59
00:05:08,460 --> 00:05:14,289
description of a chip doesn't really tell
you what it's protecting you against. And
60
00:05:14,289 --> 00:05:19,139
often I would even say it's misleading in
some cases. And so you will see, oh, this
61
00:05:19,139 --> 00:05:22,850
is a secure chip and you ask marketing and
they say, yeah, it has the most modern
62
00:05:22,850 --> 00:05:28,310
security features. But it doesn't really
specify whether they are, for example,
63
00:05:28,310 --> 00:05:31,759
protecting against fault injection attacks
or whether they consider this out of
64
00:05:31,759 --> 00:05:37,530
scope. In this talk, we will exclusively
look at hardware attacks and more
65
00:05:37,530 --> 00:05:42,439
specifically, we will look at fault
injection attacks on TrustZone-M. And so
66
00:05:42,439 --> 00:05:47,180
all of the attacks we're going to see are
local to the device only you need to have
67
00:05:47,180 --> 00:05:52,470
it in your hands. And there's no chance,
normally, of remotely exploiting them.
68
00:05:52,470 --> 00:05:58,599
Yeah. So this will be our agenda. We will
start with a short introduction of
69
00:05:58,599 --> 00:06:01,990
TrustZone-M, which will have a lot of
theory on like memory layouts and so on.
70
00:06:01,990 --> 00:06:05,610
We will talk a bit about the fault-
injection setup and then we will start
71
00:06:05,610 --> 00:06:13,229
attacking real chips. These 3, as you will
see. So on a Cortex-M processor you have a
72
00:06:13,229 --> 00:06:17,270
flat memory map. You don't have a memory
management unit and all your peripherals,
73
00:06:17,270 --> 00:06:21,719
your flash, your ram, it's all mapped to a
certain address in memory and TrustZone-M
74
00:06:21,719 --> 00:06:27,669
allows you to partition your flash or your
ram into secure and non secure parts. And
75
00:06:27,669 --> 00:06:31,400
so, for example, you could have a tiny
secure area because your secret code is
76
00:06:31,400 --> 00:06:36,909
very small and a big non secure area. The
same is true for Ram and also for the
77
00:06:36,909 --> 00:06:42,569
peripherals. So for example, if you have a
display and a crypto engine and so on. You
78
00:06:42,569 --> 00:06:48,599
can decide whether these peripherals
should be secure or non secure. And so
79
00:06:48,599 --> 00:06:53,419
let's talk about these two security
states: secure and non secure. Well, if
80
00:06:53,419 --> 00:06:57,949
you have code running in secure flash or
you have secure code running, it can call
81
00:06:57,949 --> 00:07:02,729
anywhere into the non secure world. It's
basically the highest privilege level you
82
00:07:02,729 --> 00:07:08,009
can have. And so there's no protection
there. However, the opposite, if we tried
83
00:07:08,009 --> 00:07:12,479
to go from the non secure world and to the
secure world would be insecure because,
84
00:07:12,479 --> 00:07:15,469
for example, you could jump to the parts
of the code that are behind certain
85
00:07:15,469 --> 00:07:20,330
protections and so on. And so that's why,
if you tried to jump from an unsecured
86
00:07:20,330 --> 00:07:26,749
code into a secure code, it will cause an
exception. And to handle that, there's a
87
00:07:26,749 --> 00:07:32,249
third memory state which is called non
secure callable. And as the name implies,
88
00:07:32,249 --> 00:07:37,909
basically you're non secure code can call
into the non secure callable code. More
89
00:07:37,909 --> 00:07:43,210
specifically, it can only call to non
secure callable code addresses where
90
00:07:43,210 --> 00:07:49,569
there's an SG instruction which stands for
Secure Gateway. And the idea behind the
91
00:07:49,569 --> 00:07:53,539
secure gateway is that if you have a non
secure kernel running, you probably also
92
00:07:53,539 --> 00:07:57,610
have a secure kernel of running. And
somehow this secure kernel will expose
93
00:07:57,610 --> 00:08:02,520
certain system calls, for example. And so
we want to somehow call from the non
94
00:08:02,520 --> 00:08:09,069
secure kernel into these system calls, but
as I've just mentioned, we can't do that
95
00:08:09,069 --> 00:08:15,039
because this will unfortunately cause an
exception. And so the way this is handled
96
00:08:15,039 --> 00:08:19,729
on TrustZone-M is that you create so-
called secure gateway veneer functions.
97
00:08:19,729 --> 00:08:24,689
These are very short functions in the non
secure callable area. And so if we want,
98
00:08:24,689 --> 00:08:29,650
for example, to call the load key system
call, we would call the load key veneer
99
00:08:29,650 --> 00:08:35,370
function, which in turn would call the
real load key function. And these veneer
100
00:08:35,370 --> 00:08:40,199
functions are super short. So if you look
at the disassembly of them, it's like two
101
00:08:40,199 --> 00:08:44,120
instructions. It's the secure gateway
instruction and then a branch instruction
102
00:08:44,120 --> 00:08:51,630
to what's your real function. And so if we
combine this, we end up with this diagram
103
00:08:51,630 --> 00:08:57,199
secure can call into non secure, non
secure, can call into NSC and NSC can call
104
00:08:57,199 --> 00:09:04,190
into your secure world. But how do we
manage these memory states? How do we know
105
00:09:04,190 --> 00:09:09,300
what security state does an address have?
And so for this in TrustZone-M, we use
106
00:09:09,300 --> 00:09:13,940
something called attribution units and
there're by default there are two
107
00:09:13,940 --> 00:09:19,089
attribution units available. The first one
is the SAU the Security Attribution Unit,
108
00:09:19,089 --> 00:09:24,430
which is standard across chips. It's
basically defined by ARM how you use this.
109
00:09:24,430 --> 00:09:29,490
And then there's the IDAU. The
Implementation Defined Attribution Unit,
110
00:09:29,490 --> 00:09:34,070
which is basically custom to the silicon
vendor, but can also be the same across
111
00:09:34,070 --> 00:09:41,259
several chips. And to get the security
state of an address, the security
112
00:09:41,259 --> 00:09:47,310
attribution of both the SAU and the IDAU
are combined and whichever one has the
113
00:09:47,310 --> 00:09:53,149
higher privilege level will basically win.
And so let's say our SAU says this address
114
00:09:53,149 --> 00:09:59,209
is secure and our IDAU says this address
is non secure the SAU wins because it's
115
00:09:59,209 --> 00:10:05,880
the highest privilege level. And basically
our address would be considered secure.
116
00:10:05,880 --> 00:10:12,340
This is a short table. If both the SAU and
the IDAU agree, we will be non secure if
117
00:10:12,340 --> 00:10:17,240
both say, hey, this is secure, it will be
secure. However, if they disagree and the
118
00:10:17,240 --> 00:10:22,640
SAU says, hey, this address is secure the
IDAU says it's non secure, it will still
119
00:10:22,640 --> 00:10:27,459
be secure because secure is to have
privilege level. The opposite is true. And
120
00:10:27,459 --> 00:10:33,850
with even with non secure callable, secure
is more privileged than NSC. And so secure
121
00:10:33,850 --> 00:10:41,170
will win. But if we mix NS and NSC, we get
non-secular callable. Okay. My initial
122
00:10:41,170 --> 00:10:45,880
hypothesis when I read all of this was if
we break or disable the attribution units,
123
00:10:45,880 --> 00:10:52,220
we probably break the security. And so to
break these, we have to understand them.
124
00:10:52,220 --> 00:10:57,560
And so let's look at the SAU the security
attribution unit. It's standardized by
125
00:10:57,560 --> 00:11:02,430
ARM. It's not available on all chips. And
it basically allows you to create memory
126
00:11:02,430 --> 00:11:08,740
regions with different security states.
So, for example, if the SAU is turned off,
127
00:11:08,740 --> 00:11:13,190
everything will be considered secure. And
if we turn it on, but no regions are
128
00:11:13,190 --> 00:11:16,990
configured, still, everything will be
secure. We can then go and add, for
129
00:11:16,990 --> 00:11:23,850
example, address ranges and make them NSC
or non secure and so on. And this is done
130
00:11:23,850 --> 00:11:28,920
very, very easily. You basically have
these five registers. You have the SAU
131
00:11:28,920 --> 00:11:34,890
control register where you basically can
turn it on or off. You have the SAU type,
132
00:11:34,890 --> 00:11:38,329
which gives you the number of supported
regions on your platform because this can
133
00:11:38,329 --> 00:11:42,779
be different across different chips. And
then we have the region number register,
134
00:11:42,779 --> 00:11:46,149
which you use to select the region you
want to configure and then you set the
135
00:11:46,149 --> 00:11:50,460
base address and the limit address. And
that's basically it. So, for example, if
136
00:11:50,460 --> 00:11:57,380
we want to set region zero, we simply set
the RNR register to zero. Then we set the
137
00:11:57,380 --> 00:12:05,649
base address to 0x1000. We set the limit
address to 0x1FE0, which is identical to
138
00:12:05,649 --> 00:12:08,970
1FFF because there are some other bits
behind there that we don't care about
139
00:12:08,970 --> 00:12:14,910
right now. And then we turn on the
security attribution unit and now our
140
00:12:14,910 --> 00:12:19,420
memory range is marked as secure if you
want to create a second region we simply
141
00:12:19,420 --> 00:12:25,980
change RNR to, for example, 1 again insert
some nice addresses. Turn on the SAU and
142
00:12:25,980 --> 00:12:33,860
we have a second region this time from
4000 to 5FFF. So to summarize, we have
143
00:12:33,860 --> 00:12:40,470
three memory security states. We have S
secure and we have NSC non secure callable
144
00:12:40,470 --> 00:12:46,149
and we have NS non secure. We also have
the two attribution units, the SAU
145
00:12:46,149 --> 00:12:53,070
standard by ARM and the IDAU which is
potentially custom we will use SAU and
146
00:12:53,070 --> 00:13:00,120
IDAU a lot. So this was very important.
Cool. Let's talk about fault injection. So
147
00:13:00,120 --> 00:13:06,060
as I've mentioned, we want to use fault
injection to compromise TrustZone. And the
148
00:13:06,060 --> 00:13:10,740
idea behind fault injection or as it's
also called glitching is to introduce
149
00:13:10,740 --> 00:13:14,610
faults into a chip. So, for example, you
cut the power for a very short amount of
150
00:13:14,610 --> 00:13:19,310
time while you change the period of the
clock signal or even you could go and
151
00:13:19,310 --> 00:13:23,600
inject electromagnetic shocks in your
chip. You can also shoot at it with a
152
00:13:23,600 --> 00:13:29,170
laser and so on and so forth. Lots of ways
to do this. And the goal of this is to is
153
00:13:29,170 --> 00:13:34,399
to cause undefined behavior. And in this
talk, we will specifically look at
154
00:13:34,399 --> 00:13:40,440
something called voltage glitching. And so
the idea behind voltage glitching is that
155
00:13:40,440 --> 00:13:44,930
we cut the power to the chip for very,
very short amount of time at a very
156
00:13:44,930 --> 00:13:49,100
precisely timed moment. And this will
cause some interesting behavior. So
157
00:13:49,100 --> 00:13:56,720
basically, if you would look at this on an
oscilloscope, we would basically have a
158
00:13:56,720 --> 00:14:02,569
stable voltage, stable voltage, stable
voltage, and then suddenly it drops and
159
00:14:02,569 --> 00:14:08,100
immediately returns. And this drop will
only be a couple of nanoseconds long. And
160
00:14:08,100 --> 00:14:12,760
so, for example, you can have glitches
that are 10 nanoseconds long or 15
161
00:14:12,760 --> 00:14:18,829
nanoseconds long and so on. Depends on
your chip. And yeah. And this allows you
162
00:14:18,829 --> 00:14:24,230
to do different things. So, for example, a
glitch can allow you to skip instructions.
163
00:14:24,230 --> 00:14:29,110
It can corrupt flash reads or flash
writes. It can corrupt memory registers or
164
00:14:29,110 --> 00:14:34,920
register reads and writes. And skipping
instructions for me is always the most
165
00:14:34,920 --> 00:14:40,000
interesting one, because it allows you to
directly go from disassembly to
166
00:14:40,000 --> 00:14:45,079
understanding what you can potentially
jump over. So, for example, if we have
167
00:14:45,079 --> 00:14:50,610
some code, this would be a basic firmware
boot up code. We have an initialized
168
00:14:50,610 --> 00:14:55,439
device function. Then we have a function
that basically verifies the firmware
169
00:14:55,439 --> 00:15:00,339
that's in flash and then we have this
boolean check whether our firmware was
170
00:15:00,339 --> 00:15:05,329
valid. And now if we glitch at just the
right time, we might be able to glitch
171
00:15:05,329 --> 00:15:12,879
over this check and boot our potentially
compromised firmware, which is super nice.
172
00:15:12,879 --> 00:15:19,480
So how does this relate to TrustZone?
Well, if we manage to glitch over enable
173
00:15:19,480 --> 00:15:25,899
TrustZone, we might be able to break
TrustZone. So how do you actually do this?
174
00:15:25,899 --> 00:15:30,810
Well, we need something to wait for a
certain delay and generate a pulse at just
175
00:15:30,810 --> 00:15:36,250
the right time with very high precision.
We are talking about nano seconds here,
176
00:15:36,250 --> 00:15:40,259
and we also need something to drop the
power to the target. And so if you need
177
00:15:40,259 --> 00:15:46,450
precise timing and so on, what works very
well is an FPGA. And so, for example, the
178
00:15:46,450 --> 00:15:51,649
code that was released as part of this all
runs on the Lattice iCEstick, which is
179
00:15:51,649 --> 00:15:56,610
roughly 30 bucks and you need a cheap
MOSFET and so together this is like thirty
180
00:15:56,610 --> 00:16:02,440
one dollars of equipment. And on a setup
side, this looks something like this. You
181
00:16:02,440 --> 00:16:06,830
would have your FPGA, which has a trigger
input. And so, for example, if you want to
182
00:16:06,830 --> 00:16:10,430
glitch something doing the boot up of a
chip, you could connect this to the reset
183
00:16:10,430 --> 00:16:14,769
line of the chip. And then we have an
output for the glitch pulse. And then if
184
00:16:14,769 --> 00:16:20,820
we hook this all up, we basically have our
power supply to the chip run over a
185
00:16:20,820 --> 00:16:26,529
MOSFET. And then if the glitch pulls goes
high, we drop the power to ground and the
186
00:16:26,529 --> 00:16:33,189
chip doesn't get power for a couple of
nanoseconds. Let's talk about this power
187
00:16:33,189 --> 00:16:39,360
supply, because a chip has a lot of
different things inside of it. So, for
188
00:16:39,360 --> 00:16:45,370
example, a microcontroller has a CPU core.
We have a Wi-Fi peripheral. We have GPIO.
189
00:16:45,370 --> 00:16:50,899
We might have Bluetooth and so on. And
often these peripherals run at different
190
00:16:50,899 --> 00:16:56,529
voltages. And so while our microcontroller
might just have a 3.3 volt input,
191
00:16:56,529 --> 00:17:00,079
internally there are a lot of different
voltages at play. And the way these
192
00:17:00,079 --> 00:17:05,410
voltages are generated often is using
in-chip regulators. And basically these
193
00:17:05,410 --> 00:17:11,449
regulators connect with the 3.3 voltage in
and then generate the different voltages
194
00:17:11,449 --> 00:17:16,740
for the CPU core and so on. But what's
nice is that on a lot of chips there are
195
00:17:16,740 --> 00:17:21,620
behind the core regulator, so called
bypass capacitors, and these external
196
00:17:21,620 --> 00:17:26,240
capacitors are basically there to
stabilize the voltage because regulators
197
00:17:26,240 --> 00:17:32,120
tend to have a very noisy output and you
use the capacitor to make it more smooth.
198
00:17:32,120 --> 00:17:36,730
But if you look at this, this also gives
us direct access to the CPU core power
199
00:17:36,730 --> 00:17:42,390
supply. And so if we just take a heat gun
and remove the capacitor, we actually kind
200
00:17:42,390 --> 00:17:46,730
of change the pin out of the processor
because now we have a 3.3 voltage in, we
201
00:17:46,730 --> 00:17:52,700
have a point to input the core voltage and
we have ground. So we basically gained
202
00:17:52,700 --> 00:17:59,990
direct access to the internal CPU core
voltage rails. The only problem is these
203
00:17:59,990 --> 00:18:04,630
capacitors are for a reason. And so if we
remove them, then your chip might stop
204
00:18:04,630 --> 00:18:09,770
working. But very easy solution. You just
hook up a power supply to it, set it to
205
00:18:09,770 --> 00:18:14,650
1.2 volts or whatever, and then suddenly
it works. And this also allows you to
206
00:18:14,650 --> 00:18:23,150
glitch very easily. You just glitch on
your power rail towards the chip. And so
207
00:18:23,150 --> 00:18:27,450
this is our current setup. So we have the
Lattice iCEstick. We also use a
208
00:18:27,450 --> 00:18:31,430
multiplexer as an analog switch to cut the
power to the entire device. If we want to
209
00:18:31,430 --> 00:18:36,779
reboot everything, we have the MOSFET and
we have a power supply. Now hooking this
210
00:18:36,779 --> 00:18:42,300
all up on a bread board is fun the first
time, it's okay the second time. But the
211
00:18:42,300 --> 00:18:47,080
third time it begins to really, really
suck. And as soon as something breaks with
212
00:18:47,080 --> 00:18:52,450
like 100 jumper wires on your desk, the
only way to debug is to start over. And so
213
00:18:52,450 --> 00:18:57,320
that's why I decided to design a small
hardware platform that combines all of
214
00:18:57,320 --> 00:19:03,070
these things. So it has an FPGA on it. It
has analog input and it has a lot of
215
00:19:03,070 --> 00:19:07,560
glitch circuitry and it's called the Mark
Eleven. If you've read William Gibson, you
216
00:19:07,560 --> 00:19:13,260
might know where this is from. And it
contains a Lattice iCE40, which has a
217
00:19:13,260 --> 00:19:18,130
fully open source toolchain, thanks to
Clifford Wolf and so. And this allows us
218
00:19:18,130 --> 00:19:23,230
to very, very quickly develop new
triggers, develop new glitched code and so
219
00:19:23,230 --> 00:19:27,450
on. And it makes compilation and
everything really really fast. It also
220
00:19:27,450 --> 00:19:31,741
comes with three integrated power
supplies. So we have a 1.2 watt power
221
00:19:31,741 --> 00:19:38,250
supply, 3.3, 5 volts and so on, and you
can use it for DPA. And this is based
222
00:19:38,250 --> 00:19:42,880
around some existing devices. So, for
example, the FPGA part is based on the
223
00:19:42,880 --> 00:19:48,820
1BitSquared iCEBreaker. The analog front
end, thanks to Colin O'Flynn, is based on
224
00:19:48,820 --> 00:19:53,570
the ChipWhisperer Nano. And then the
glitch circuit is basically what we've
225
00:19:53,570 --> 00:19:58,520
been using on bread boards for quite a
while. Just combined on a single device.
226
00:19:58,520 --> 00:20:02,549
And so unfortunately, as always with
hardware production takes longer than you
227
00:20:02,549 --> 00:20:07,440
might assume. But if you drop me a message
on Twitter, I'm happy to send you a PCB as
228
00:20:07,440 --> 00:20:13,440
soon as they work well. And the BOM is
around 50 bucks. Cool. So now that we are
229
00:20:13,440 --> 00:20:19,580
ready to have to actually attack chips,
let's look at an example. So the very
230
00:20:19,580 --> 00:20:25,390
first chip that I encountered that used
TrustZone-M was the Microchip SAM 11. And
231
00:20:25,390 --> 00:20:32,010
so this chip was released in June 2018.
And it's kind of it's a small, slow chip.
232
00:20:32,010 --> 00:20:37,929
It's runs at 32 megahertz. It has up to 64
kilobytes of flash and 16 kilobytes of
233
00:20:37,929 --> 00:20:44,210
SRAM, but it's super cheap. It's like one
dollar eighty at quantity one. And so it's
234
00:20:44,210 --> 00:20:50,230
really nice, really affordable. And we had
people come up to us and suggest, hey, I
235
00:20:50,230 --> 00:20:54,659
want to build a TPM on top of this or I
want to build a hardware wallet on top of
236
00:20:54,659 --> 00:21:01,120
this. And so on and so forth. And if we
look at the website of this chip. It has a
237
00:21:01,120 --> 00:21:06,530
lot of security in it, so it's the best
contribution to IOT security winner of
238
00:21:06,530 --> 00:21:14,899
2018. And if you just type secure into the
word search, you get like 57 hits. So this
239
00:21:14,899 --> 00:21:23,610
chip is 57 secure. laughter And even on
the website itself, you have like chip
240
00:21:23,610 --> 00:21:28,700
level security. And then if you look at
the first of the descriptions, you have a
241
00:21:28,700 --> 00:21:33,950
robust chip level security include chip
level, tamper resistance, active shield
242
00:21:33,950 --> 00:21:38,301
protects against physical attacks and
resists micro probing attacks. And even in
243
00:21:38,301 --> 00:21:42,440
the datasheet, where I got really worried
because I said I do a lot with a core
244
00:21:42,440 --> 00:21:47,649
voltage it has a brown-out detector that
has been calibrated in production and must
245
00:21:47,649 --> 00:21:53,809
not be changed and so on. Yeah. To be
fair, when I talked to my microchip, they
246
00:21:53,809 --> 00:21:58,490
mentioned that they absolutely want to
communicate that this chip is not hardened
247
00:21:58,490 --> 00:22:03,680
against hardware attacks, but I can see
how somebody who looks at this would get
248
00:22:03,680 --> 00:22:10,550
the wrong impression given all the terms
and so on. Anyway, so let's talk about the
249
00:22:10,550 --> 00:22:16,669
TrustZone in this chip. So the SAM L11
does not have a security attribution unit.
250
00:22:16,669 --> 00:22:21,270
Instead, it only has the implementation
defined attribution unit. And the
251
00:22:21,270 --> 00:22:25,580
configuration for this implementation
defined attribution unit is stored in the
252
00:22:25,580 --> 00:22:29,789
user row, which is basically the
configuration flash. It's also called
253
00:22:29,789 --> 00:22:33,610
fuses in the data sheet sometimes, but
it's really I think it's flash based. I
254
00:22:33,610 --> 00:22:36,750
haven't checked, but I am pretty sure it
is because you can read it, write it,
255
00:22:36,750 --> 00:22:42,190
change it and so on. And then the IDAU,
once you've configured it, will be
256
00:22:42,190 --> 00:22:49,370
configured by the boot ROM during the
start of the chip. And the idea behind the
257
00:22:49,370 --> 00:22:54,100
IDAU is that all your flash is partitioned
into two parts of the bootloader part and
258
00:22:54,100 --> 00:23:00,289
the application part, and both of these
can be split into secure, non secure
259
00:23:00,289 --> 00:23:05,100
callable and non secure. So you can have a
bootloader, a secure and a non secure one,
260
00:23:05,100 --> 00:23:09,510
and you can have an application, a secure
and a non secure one. And the size of
261
00:23:09,510 --> 00:23:14,040
these regions is controlled by these five
registers. And for example, if we want to
262
00:23:14,040 --> 00:23:18,740
change our non secure application to be
bigger and make our secure application a
263
00:23:18,740 --> 00:23:23,649
bit smaller, we just fiddle with these
registers and the sizes will adjust and
264
00:23:23,649 --> 00:23:31,390
the same with the bootloader. So this is
pretty simple. How do we attack it? My
265
00:23:31,390 --> 00:23:36,940
goal initially was I want to somehow read
data from the secure world while running
266
00:23:36,940 --> 00:23:41,559
code in the non secret world. So jump the
security gap. My code in non secure should
267
00:23:41,559 --> 00:23:47,350
be able to, for example, extract keys from
the secure world and my attack path for
268
00:23:47,350 --> 00:23:52,790
that was well, I glitched the boot ROM
code that loads the IDAU you
269
00:23:52,790 --> 00:23:57,140
configuration. But before we can actually
do this, we need to understand, is this
270
00:23:57,140 --> 00:24:01,549
chip actually glitchable and can we? Is it
susceptible to glitches or do we
271
00:24:01,549 --> 00:24:07,360
immediately get get thrown out? And so I
used a very simple setup where just had a
272
00:24:07,360 --> 00:24:13,210
firmware and tried to glitch out of the
loop and enable an LED. And I had success
273
00:24:13,210 --> 00:24:19,090
in less than five minutes and super stable
glitches almost immediately. Like when I
274
00:24:19,090 --> 00:24:23,190
saw this, I was 100 percent sure that I
messed up my setup or that the compiler
275
00:24:23,190 --> 00:24:28,710
optimized out my loop or that I did
something wrong because I never glitch to
276
00:24:28,710 --> 00:24:33,530
chip in five minutes. And so this was
pretty awesome, but I also spend another
277
00:24:33,530 --> 00:24:41,549
two hours verifying my setup. So. OK.
Cool, we know that ship is glitchable, so
278
00:24:41,549 --> 00:24:47,149
let's glitch it. What do we glitch? Well,
if we think about it somewhere during the
279
00:24:47,149 --> 00:24:53,330
boot ROM, these registers are red from
flash and then some hardware is somehow
280
00:24:53,330 --> 00:24:57,890
configured. We don't know how because we
can't dump the boot from we don't know
281
00:24:57,890 --> 00:25:01,539
what's going on in the chip. And the
datasheet has a lot of pages. And I'm a
282
00:25:01,539 --> 00:25:09,160
millennial. So, yeah, I read what I have
to read and that's it. But my basic idea
283
00:25:09,160 --> 00:25:14,250
is if we somehow manage to glitch the
point where it tries to read the value of
284
00:25:14,250 --> 00:25:19,100
the AS Register, we might be able to set
it to zero because most chip peripherals
285
00:25:19,100 --> 00:25:25,060
will initialize to zero. And if we glitch
with the instruction that reads AS, maybe
286
00:25:25,060 --> 00:25:30,290
we can make our non secure application
bigger so that we, that actually we can
287
00:25:30,290 --> 00:25:39,220
read the secure application data because
now it's considered non secure. But.
288
00:25:39,220 --> 00:25:44,409
Problem 1 The boot ROM is not dumpable. So
we cannot just disassemble it and figure
289
00:25:44,409 --> 00:25:50,659
out when does it roughly do this. And the
problem 2 is that we don't know when
290
00:25:50,659 --> 00:25:55,130
exactly this read occures and our glitch
needs to be instruction precise. We need
291
00:25:55,130 --> 00:26:01,159
to hit just the right instruction to make
this work. And the solution is brute
292
00:26:01,159 --> 00:26:08,140
force. But I mean like nobody has time for
that. Right? So if the chip boots for 2
293
00:26:08,140 --> 00:26:12,820
milliseconds. That's a long range we have
to search for glitches. And so very easy
294
00:26:12,820 --> 00:26:17,160
solution power analysis. And it turns out
that, for example, a riscure has done this
295
00:26:17,160 --> 00:26:23,029
before where basically they tried to
figure out where in time a JTAG lock is
296
00:26:23,029 --> 00:26:30,450
set by comparing the power consumption.
And so the idea is, we basically write
297
00:26:30,450 --> 00:26:35,649
different values to the AS register, then
we collect a lot of power traces and then
298
00:26:35,649 --> 00:26:41,029
we look for the differences. And this is
relatively simple to do. If you have a
299
00:26:41,029 --> 00:26:46,429
ChipWhisperer. So. This was my rough
setup. So we just have the ChipWhisperer-
300
00:26:46,429 --> 00:26:51,740
Lite. We have a breakout with the chip we
want to attack and a programmer. And then
301
00:26:51,740 --> 00:26:56,710
we basically collect a couple of traces.
And in my case, even just 20 traces are
302
00:26:56,710 --> 00:27:01,779
enough, which takes, I don't know, like
half a second to run. And if you have 20
303
00:27:01,779 --> 00:27:07,370
traces in unsecure mode, 20 traces in
secure mode and you compare them, you can
304
00:27:07,370 --> 00:27:11,230
see that there are clear differences in
the power consumption starting at a
305
00:27:11,230 --> 00:27:15,470
certain point. And so I wrote a script
that does some more statistics on it and
306
00:27:15,470 --> 00:27:20,970
so on. And that basically told me the best
glitch candidate starts at 2.18
307
00:27:20,970 --> 00:27:24,720
milliseconds. And this needs to be so
precise because I said we're in the milli
308
00:27:24,720 --> 00:27:31,220
and the nano seconds range. And so we want
to make sure that we at the right point in
309
00:27:31,220 --> 00:27:37,519
time. Now, how do you actually configure?
How do you build the setup where you
310
00:27:37,519 --> 00:27:44,429
basically you get a success indication
once you broke this? For this, I needed to
311
00:27:44,429 --> 00:27:50,039
write a firmware that basically attempts
to read secure data. And then if it's
312
00:27:50,039 --> 00:27:54,139
successful, enabled the GPIO. And if it
fails, it does nothing. And I just reset
313
00:27:54,139 --> 00:27:59,460
and try again. And so I know I knew my
rough delay and I was triggering of the
314
00:27:59,460 --> 00:28:04,590
reset of the chip that I just tried. Any
delay after it and tried different glitch
315
00:28:04,590 --> 00:28:11,169
pulse length and so on. And eventually I
had a success. And these glitches you will
316
00:28:11,169 --> 00:28:16,029
see with the glitcher which we released a
while back is super easy to write because
317
00:28:16,029 --> 00:28:21,940
all you have is like 20 lines of Python.
You basically set up a loop delay from
318
00:28:21,940 --> 00:28:28,320
delay to your setup, the pulse length. You
iterate over a range of pulses. And then
319
00:28:28,320 --> 00:28:34,250
in this case you just check whether your
GPIO is high or low. That's all it takes.
320
00:28:34,250 --> 00:28:38,309
And then once you have this running in a
stable fashion, it's amazing how fast it
321
00:28:38,309 --> 00:28:43,190
works. So this is now a recorded video of
a life glitch, of a real glitch,
322
00:28:43,190 --> 00:28:49,730
basically. And you can see we have like 20
attempts per second. And after a couple of
323
00:28:49,730 --> 00:28:57,370
seconds, we actually get a success
indication we just broke a chip. Sweet.
324
00:28:57,370 --> 00:29:02,049
But one thing I moved to a part of Germany
to the very south is called the
325
00:29:02,049 --> 00:29:09,590
Schwabenland. And I mean, 60 bucks. We are
known to be very cheap and 60 bucks
326
00:29:09,590 --> 00:29:15,440
translates to like six beers at
Oktoberfest. Just to convert this to the
327
00:29:15,440 --> 00:29:24,460
local currency, that's like 60 Club Mate.
Unacceptable. We need to go cheaper, much
328
00:29:24,460 --> 00:29:33,650
cheaper, and so.
laughter and applause
329
00:29:33,650 --> 00:29:40,380
What if we take a chip that is 57 secure
and we tried to break it with the smallest
330
00:29:40,380 --> 00:29:46,730
chip. And so this is an ATTiny which
costs, I don't know, a a euro or two euro.
331
00:29:46,730 --> 00:29:52,929
We combine it with a MOSFET to keep the
comparison that's roughly 3 Club Mate and
332
00:29:52,929 --> 00:29:57,820
we hook it all up on a jumper board and
turns out: This works like you can have a
333
00:29:57,820 --> 00:30:02,649
relatively stable glitch, a glitcher with
like 120 lines of assembly running all the
334
00:30:02,649 --> 00:30:07,019
ATTiny and this will glitch your chip
successfully and can break TrustZone on
335
00:30:07,019 --> 00:30:13,590
the SAM L11. The problem is chips are very
complex and it's always very hard to do an
336
00:30:13,590 --> 00:30:17,830
attack on a chip that you configured
yourself because as you will see, chances
337
00:30:17,830 --> 00:30:21,380
are very high that you messed up the
configuration and for example, missed a
338
00:30:21,380 --> 00:30:26,020
security bit, forgot to set something and
so on and so forth. But luckily, in the
339
00:30:26,020 --> 00:30:32,169
case of the SAM L11, there's a version of
this chip which is already configured and
340
00:30:32,169 --> 00:30:39,590
only ships in non secure mode. And so this
is called the SAM L11 KPH. And so it comes
341
00:30:39,590 --> 00:30:43,990
pre provisioned with a key and it comes
pre provisioned with a trusted execution
342
00:30:43,990 --> 00:30:49,750
environment already loaded into the secure
part of the chips and ships completely
343
00:30:49,750 --> 00:30:54,700
secured and the customer can write and
debug non secure code only. And also you
344
00:30:54,700 --> 00:30:59,620
can download the SDK for it and write your
own trustlets and so on. But I couldn't
345
00:30:59,620 --> 00:31:04,289
because it requires you to agree to their
terms and conditions so which exclude
346
00:31:04,289 --> 00:31:08,980
reverse engineering. So no chance,
unfortunately. But anyway, this is the
347
00:31:08,980 --> 00:31:14,601
perfect example to test our attack. You
can buy these chips on DigiKey and then
348
00:31:14,601 --> 00:31:18,990
try to break into the secure world because
these chips are hopefully decently secured
349
00:31:18,990 --> 00:31:24,779
and have everything set up and so on. And
yeah. So this was the setup. We designed
350
00:31:24,779 --> 00:31:29,779
our own breakout port for the SAM L11,
which makes it a bit more accessible, has
351
00:31:29,779 --> 00:31:35,100
JTAG and has no capacitors in the way. So
you get access to all the core voltages
352
00:31:35,100 --> 00:31:42,130
and so on and you have the FPGA on the top
left the super cheap 20 bucks power supply
353
00:31:42,130 --> 00:31:47,220
and the programmer. And then we just
implemented a simple function that uses
354
00:31:47,220 --> 00:31:53,230
openOCD to try to read an address that we
normally can't read. So we basically we
355
00:31:53,230 --> 00:31:59,029
glitch. Then we start OpenOCD, which uses
the JTAG adapter to try to read secure
356
00:31:59,029 --> 00:32:10,320
memory. And so I hooked it all up, wrote a
nice script and let it rip. And so after a
357
00:32:10,320 --> 00:32:16,980
while or in well, a couple of seconds
immediately again got successful, I got a
358
00:32:16,980 --> 00:32:20,340
successful attack on the chip and more and
more. And you can see just how stable you
359
00:32:20,340 --> 00:32:26,610
can get these glitches and how well you
can attack this. Yeah. So sweet hacked. We
360
00:32:26,610 --> 00:32:31,309
can compromise the root of trust and the
trusted execution environment. And this is
361
00:32:31,309 --> 00:32:36,080
perfect for supply chain attacks. Right.
Because if you can compromise a part of
362
00:32:36,080 --> 00:32:42,139
the chip that the customer will not be
able to access, he will never find you.
363
00:32:42,139 --> 00:32:45,769
But the problem with supply chain attacks
is, they're pretty hard to scale and they
364
00:32:45,769 --> 00:32:51,140
are only for sophisticated actors normally
and far too expensive is what most people
365
00:32:51,140 --> 00:32:58,779
will tell you, except if you hack the
distributor. And so as I guess last year
366
00:32:58,779 --> 00:33:04,341
or this year, I don't know, I actually
found a vulnerability in DigiKey, which
367
00:33:04,341 --> 00:33:09,179
allowed me to access any invoice on
DigiKey, including the credentials you
368
00:33:09,179 --> 00:33:16,779
need to actually change the invoice. And
so basically the bug is that they did not
369
00:33:16,779 --> 00:33:20,770
check when you basically requested an
invoice, they did not check whether you
370
00:33:20,770 --> 00:33:25,509
actually had permission to access it. And
you have the web access id on top and the
371
00:33:25,509 --> 00:33:30,370
invoice number. And that's all you need to
call DigiKey and change the delivery,
372
00:33:30,370 --> 00:33:37,169
basically. And so this also is all data
that you need to reroute the shipment. I
373
00:33:37,169 --> 00:33:41,490
disclosed this. It's fixed. It's been
fixed again afterwards. And now hopefully
374
00:33:41,490 --> 00:33:45,990
this should be fine. So I feel good to
talk about it. And so let's walk through
375
00:33:45,990 --> 00:33:52,050
the scenarios. We have Eve and we have
DigiKey and Eve builds this new super
376
00:33:52,050 --> 00:33:58,090
sophisticated IOT toilet and she needs a
secure chip. So she goes to DigiKey and
377
00:33:58,090 --> 00:34:06,610
orders some SAM L11 KPHs and Mallory.
Mallory scans all new invoices on DigiKey.
378
00:34:06,610 --> 00:34:13,240
And as soon as somebody orders a SAM L11,
they talk to DigiKey with the API or via a
379
00:34:13,240 --> 00:34:17,840
phone call to change the delivery address.
And because you know who the chips are
380
00:34:17,840 --> 00:34:23,409
going to, you can actually target this
very, very well. So now the chips get
381
00:34:23,409 --> 00:34:30,450
delivered to Mallory Mallory backdoors the
chips. And then sends the backdoored chips
382
00:34:30,450 --> 00:34:34,419
to Eve who is none the wiser, because it's
the same carrier, it's the same, it looks
383
00:34:34,419 --> 00:34:38,149
the same. You have to be very, very
mindful of these types of attack to
384
00:34:38,149 --> 00:34:43,310
actually recognize them. And even if they
open the chips and they say they open the
385
00:34:43,310 --> 00:34:48,530
package and they try the chip, they scan
everything they can scan the backdoor will
386
00:34:48,530 --> 00:34:53,580
be in the part of the chip that they
cannot access. And so we just supply chain
387
00:34:53,580 --> 00:35:02,329
attacked whoever using an UPS envelope,
basically. So, yeah. Interesting attack
388
00:35:02,329 --> 00:35:07,119
vector. So I talked to microchip and it's
been great. They've been super nice. It
389
00:35:07,119 --> 00:35:13,460
was really a pleasure. I also talked to
Trustonic, who were very open to this and
390
00:35:13,460 --> 00:35:19,890
wanted to understand it. And so it was
great. And they explicitly state that this
391
00:35:19,890 --> 00:35:23,760
chip only protects against software
attacks while it has some hardware
392
00:35:23,760 --> 00:35:29,530
features like tamper ressistant RAM. It is
not built to withstand fault injection
393
00:35:29,530 --> 00:35:34,130
attacks. And even if you compare it now,
different revisions of the data sheet, you
394
00:35:34,130 --> 00:35:38,760
can see that some data sheets, the older
ones they mention some fault injection
395
00:35:38,760 --> 00:35:42,550
resistance and it's now gone from the data
sheet. And they are also asking for
396
00:35:42,550 --> 00:35:46,980
feedback on making it more clear what this
chip protects against, which I think is a
397
00:35:46,980 --> 00:35:52,620
noble goal because we all know marketing
versus technicians is always an
398
00:35:52,620 --> 00:36:00,580
interesting fight. Let's say, cool first
chip broken time for the next one, right?
399
00:36:00,580 --> 00:36:07,270
So the next chip I looked at was the
Nuvoton NuMicro M2351 rolls off the
400
00:36:07,270 --> 00:36:14,150
tongue. It's a Cortex-M23 processor. It
has TrustZone-M. And I was super excited
401
00:36:14,150 --> 00:36:19,690
because this finally has an SAU, a
security attribution unit and an IDAU and
402
00:36:19,690 --> 00:36:23,490
also I talked to the marketing. It
explicitly protects against fault
403
00:36:23,490 --> 00:36:31,790
injection. So that's awesome. I was
excited. Let's see how that turns out.
404
00:36:31,790 --> 00:36:37,010
Let's briefly talk about the TrustZone in
the Nuvoton chip. So as I've mentioned
405
00:36:37,010 --> 00:36:45,329
before, the SAU if it's turned off or
turned on without regions will be to fully
406
00:36:45,329 --> 00:36:49,630
secure. And no matter what the IDAU is,
the most privileged level always wins. And
407
00:36:49,630 --> 00:36:55,150
so if our entire security attribution unit
is secure, our final security state will
408
00:36:55,150 --> 00:37:00,880
also be secure. And so if we now add some
small regions, the final state will also
409
00:37:00,880 --> 00:37:08,240
have the small, non secure regions. I
mean, I saw this looked at how this this
410
00:37:08,240 --> 00:37:14,980
code works. And you can see that at the
very bottom SAU control is set to 1 simple
411
00:37:14,980 --> 00:37:19,340
right. We glitch over the SAU enabling and
all our code will be secure and we'll just
412
00:37:19,340 --> 00:37:26,480
run our code in secret mode, no problem -
is what I fought. And so basically the
413
00:37:26,480 --> 00:37:31,201
secure bootloader starts execution of non
secure code. We disable the SAU by
414
00:37:31,201 --> 00:37:35,859
glitching over the instruction and now
everything is secure. So our code runs in
415
00:37:35,859 --> 00:37:43,700
a secure world. It's easy except read the
fucking manual. So turns out these
416
00:37:43,700 --> 00:37:49,760
thousands of pages of documentation
actually contain useful information and
417
00:37:49,760 --> 00:37:55,060
you need a special instruction to
transition from secure to non secure state
418
00:37:55,060 --> 00:38:02,230
which is called BLXNS, which stands for
branch optionally linked and exchange to
419
00:38:02,230 --> 00:38:08,300
non secure. This is exactly made to
prevent this. It prevents accidentally
420
00:38:08,300 --> 00:38:13,290
jumping into non secure code. It will
cause a secure fault if you try to do it.
421
00:38:13,290 --> 00:38:19,390
And what's interesting is that even if you
use this instruction, it will not always
422
00:38:19,390 --> 00:38:24,530
transition. The state depends on the last
bit in the destination address, whether
423
00:38:24,530 --> 00:38:30,060
the status transition and the way the
bootloader will actually get these
424
00:38:30,060 --> 00:38:34,410
addresses it jumps to is from what's
called the reset table, which is basically
425
00:38:34,410 --> 00:38:38,610
where your reset handlers are, where your
stack pointer, your initial stack pointer
426
00:38:38,610 --> 00:38:43,710
is and so on. And you will notice that the
last bit is always set. And if the last
427
00:38:43,710 --> 00:38:49,600
bit is set, it will jump to secure code.
So somehow they managed to branch to this
428
00:38:49,600 --> 00:38:56,790
address and run it into non secure. So how
do they do this? They use an explicit bit
429
00:38:56,790 --> 00:39:02,700
clear instruction. What do we know about
instructions? We can glitch over them. And
430
00:39:02,700 --> 00:39:09,109
so basically we can with two glitches, we
can glitch over the SAU control enable now
431
00:39:09,109 --> 00:39:16,369
our entire memory is secure and then we
glitch over the bitclear instruction and
432
00:39:16,369 --> 00:39:23,609
then branch linked ex non secure again
rolls off the tongue will run secure code.
433
00:39:23,609 --> 00:39:29,260
And now our normal world code is running
in secure mode. The problem is it works,
434
00:39:29,260 --> 00:39:33,780
but it's very hard to get stable. So, I
mean, this was I somehow got it working,
435
00:39:33,780 --> 00:39:40,840
but it was not very stable and it was a
big pain to to actually make use of. So I
436
00:39:40,840 --> 00:39:45,010
wanted a different vulnerability. And I
read up on the implementation defined
437
00:39:45,010 --> 00:39:52,190
attribution unit of the M2351. And it
turns out that each flash RAM peripheral
438
00:39:52,190 --> 00:39:59,780
and so on is mapped twice into memory. And
so basically once as secure as the address
439
00:39:59,780 --> 00:40:08,710
0x2000 and once as non secure at the
address 0x3000. And so you have the flash
440
00:40:08,710 --> 00:40:15,410
twice and you have the the RAM twice. This
is super important. This is the same
441
00:40:15,410 --> 00:40:22,220
memory. And so I came up with an attack
that I called CroeRBAR because a
442
00:40:22,220 --> 00:40:27,820
vulnerability basically doesn't exist if
it doesn't have a fancy name. And the
443
00:40:27,820 --> 00:40:32,079
basic point of this is that the security
of the system relies on the region
444
00:40:32,079 --> 00:40:36,569
configuration of the SAU. What if we
glitch this initialization combined with
445
00:40:36,569 --> 00:40:43,170
this IDAU layout again with the IDAU
mirrors the memory. Has it once a secure
446
00:40:43,170 --> 00:40:48,500
and once it's not secure. Now let's say we
have at the very bottom of our flash. We
447
00:40:48,500 --> 00:40:54,520
have a secret which is in the secure area.
It will also be in the mirror of this
448
00:40:54,520 --> 00:41:00,550
memory. But again, because our SAU
configuration is fine, it will not be
449
00:41:00,550 --> 00:41:06,309
accessible by the non secure region.
However, the start of this non secret area
450
00:41:06,309 --> 00:41:14,339
is configured by the RBAR register. And so
maybe if we glitch this RBAR being set, we
451
00:41:14,339 --> 00:41:18,210
can increase the size of the non secure
area. And if you check the ARM
452
00:41:18,210 --> 00:41:22,950
documentation on the RBAR register, the
reset values state of this register is
453
00:41:22,950 --> 00:41:28,079
unknown. So unfortunately it doesn't just
say zero, but I tried this on all chips I
454
00:41:28,079 --> 00:41:33,839
had access to and it is zero on all chips
I tested. And so now what we can do is we
455
00:41:33,839 --> 00:41:38,800
glitch over this RBAR and now our final
security state will be bigger and our
456
00:41:38,800 --> 00:41:43,390
secure code is still running in the bottom
half. But then the jump into non secure
457
00:41:43,390 --> 00:41:50,750
will also give us access to the secret and
it works. We get a fully stable glitch,
458
00:41:50,750 --> 00:41:56,650
takes roughly 30 seconds to bypass it. I
should mention that this is what I think
459
00:41:56,650 --> 00:42:00,440
happens. All I know is that I inject a
glitch and I can read the secret. I cannot
460
00:42:00,440 --> 00:42:05,180
tell you exactly what happens, but this is
the best interpretation I have so far. So
461
00:42:05,180 --> 00:42:10,970
wuhu we have an attack with a cool name?
And so I looked at another chip called the
462
00:42:10,970 --> 00:42:18,930
NXP LPC55S69, and this one has 2
Cortex-M33 cores, one of which has
463
00:42:18,930 --> 00:42:26,599
TrustZone-M. The IDAU and the overall
TrustZone layout seem to be very similar
464
00:42:26,599 --> 00:42:31,640
to the NuMicro. And I got the dual glitch
attack working and also the CrowRBAR
465
00:42:31,640 --> 00:42:38,730
attack working. And the vendor response
was amazing. Like holy crap, they called
466
00:42:38,730 --> 00:42:42,500
me and wanted to fully understand it. They
reproduced that. They got me on the phone
467
00:42:42,500 --> 00:42:48,250
with an expert and the expert was super
nice. But what he said came down to was
468
00:42:48,250 --> 00:42:55,480
RTFM. But again, this is a long document,
but it turns out that the example code did
469
00:42:55,480 --> 00:43:01,900
not enable a certain security feature. And
this security feature is helpfully named
470
00:43:01,900 --> 00:43:10,820
Miscellaneous Control Register, basically,
laughter which stands for Secure Control
471
00:43:10,820 --> 00:43:21,120
Register, laughter obviously. And this
register has a bit. If you set it, it
472
00:43:21,120 --> 00:43:26,640
enables secure checking. And if I read
just a couple of sentences first further,
473
00:43:26,640 --> 00:43:31,119
when I read about the TrustZone on the
chip, I would have actually seen this. But
474
00:43:31,119 --> 00:43:37,630
Millennial sorry. Yeah. And so what this
enables is called the memory protection
475
00:43:37,630 --> 00:43:41,420
checkers and this is an additional memory
security check that gives you finer
476
00:43:41,420 --> 00:43:46,481
control over the memory layout. And so it
basically checks if the attribution unit
477
00:43:46,481 --> 00:43:51,870
security state is identical with the
memory protection checker security state.
478
00:43:51,870 --> 00:43:57,960
And so, for example, if our attack code
tries to access memory, the MPC will check
479
00:43:57,960 --> 00:44:04,280
whether this was really a valid request.
So to say and stop you if you are unlucky
480
00:44:04,280 --> 00:44:10,250
as I was. But turns out it's glitchable,
but it's much, much harder to glitch and
481
00:44:10,250 --> 00:44:15,550
you need multiple glitches. And the vendor
response was awesome. They also say
482
00:44:15,550 --> 00:44:22,010
they're working on improving the
documentation for this. So yeah, super
483
00:44:22,010 --> 00:44:26,770
cool. But still like it's not a full
protection against glitching, but it gives
484
00:44:26,770 --> 00:44:33,041
you certain security. And I think that's
pretty awesome. Before we finish. Is
485
00:44:33,041 --> 00:44:38,260
everything broken? No. These chips are not
insecure. They are not protected against a
486
00:44:38,260 --> 00:44:43,930
very specific attack scenario and align
the chips that you want to use with your
487
00:44:43,930 --> 00:44:47,510
threat model. If fault injection is part
of your threat models. So, for example,
488
00:44:47,510 --> 00:44:51,700
you're building a carkey. Maybe you should
protect against glitching. If you're
489
00:44:51,700 --> 00:44:56,340
building a hardware wallet, definitely you
should protect against glitching. Thank
490
00:44:56,340 --> 00:45:00,829
you. Also, by the way, if you want to play
with some awesome fault injection
491
00:45:00,829 --> 00:45:05,579
equipment, I have an EMFI glitcher with me
and so. So just hit me up on Twitter and
492
00:45:05,579 --> 00:45:09,540
I'm happy to show it to you. So thanks a
lot.
493
00:45:09,540 --> 00:45:17,700
applause
494
00:45:17,700 --> 00:45:24,780
Herald: Thank you very much, Thomas. We do
have an awesome 15 minutes for Q and A. So
495
00:45:24,780 --> 00:45:30,391
if you line up, we have three microphones.
Microphone number 3 actually has an
496
00:45:30,391 --> 00:45:34,119
induction loop. So if you're hearing
impaired and have a suitable device, you
497
00:45:34,119 --> 00:45:39,130
can go to microphone 3 and actually hear
the answer. And we're starting off with
498
00:45:39,130 --> 00:45:41,980
our signal angel with questions from the
Internet.
499
00:45:41,980 --> 00:45:47,710
Thomas: Hello, Internet.
Signal Angel: Hello. Are you aware of the
500
00:45:47,710 --> 00:45:53,560
ST Cortex-M4 firewall? And can your
research be somehow related to it? Or
501
00:45:53,560 --> 00:45:56,880
maybe do you have plans to explore it in
the future?
502
00:45:56,880 --> 00:46:02,440
Thomas: I. So, yes, I'm very aware of the
ST M3 and M4. If you watch our talk last
503
00:46:02,440 --> 00:46:06,680
year at CCC called Wallet.fail, we
actually exploited the sister chip, the
504
00:46:06,680 --> 00:46:12,950
STM32 F2. The F4 has this strange firewall
thing which feels very similar to
505
00:46:12,950 --> 00:46:18,680
TrustZone-M. However, I cannot yet share
any research related to that chip,
506
00:46:18,680 --> 00:46:22,090
unfortunately. Sorry.
Signal Angel: Thank you.
507
00:46:22,090 --> 00:46:28,720
Herald: Microphone number 1, please.
Mic 1: Hello. I'm just wondering, have you
508
00:46:28,720 --> 00:46:34,280
tried to replicate this attack on
multicore CPUs with higher frequency such
509
00:46:34,280 --> 00:46:38,859
like 2GHz and others, how would you go
about that?
510
00:46:38,859 --> 00:46:43,599
Thomas: So I have not because there there
are no TrustZone-M chips with this
511
00:46:43,599 --> 00:46:48,190
frequency. However, people have done it on
mobile phones and other equipment. So, for
512
00:46:48,190 --> 00:46:54,960
example, yeah, there's a lot of materials
on glitching higher frequency stuff. But
513
00:46:54,960 --> 00:46:59,170
yeah, it will get expensive really quickly
because the scope, the way you can even
514
00:46:59,170 --> 00:47:03,819
see a two gigahertz clock, that's a nice
car oscilloscope.
515
00:47:03,819 --> 00:47:09,410
Herald: Microphone number 2, please.
Mic 2: Thank you for your talk. Is the
516
00:47:09,410 --> 00:47:15,750
more functionality to go from non-secure
to secure area? Are there same standard
517
00:47:15,750 --> 00:47:19,740
defined functionalities or the proprietory
libraries from NXP?
518
00:47:19,740 --> 00:47:25,130
Thomas: So the the veneer stuff is
standard and you will find ARM documents
519
00:47:25,130 --> 00:47:29,299
basically recommending you to do this. But
all the tool chains, for example, the one
520
00:47:29,299 --> 00:47:34,799
for the SAM L11 will generate the veneers
for you. And so I have to be honest, I
521
00:47:34,799 --> 00:47:37,900
have not looked at how exactly they are
generated.
522
00:47:37,900 --> 00:47:42,480
However, I did some rust stuff to play
around with it. And yeah, it's relatively
523
00:47:42,480 --> 00:47:44,751
simple for the tool chain and it's
standard. So
524
00:47:44,751 --> 00:47:51,720
Herald: the signal angel is signaling.
Signal Angel: Yeah. That's not another
525
00:47:51,720 --> 00:47:56,180
question from the internet but from me and
I wanted to know how important is the
526
00:47:56,180 --> 00:48:00,680
hardware security in comparison to the
software security because you cannot hack
527
00:48:00,680 --> 00:48:06,490
these devices without having physical
access to them except of this supply chain
528
00:48:06,490 --> 00:48:09,300
attack.
Thomas: Exactly. And that depends on your
529
00:48:09,300 --> 00:48:14,210
threat model. So that's basically if you
build a door, if you build a hardware
530
00:48:14,210 --> 00:48:18,280
wallet, you want to have hardware
protection because somebody can steal it
531
00:48:18,280 --> 00:48:22,200
potentially very easily and then... And if
you, for example, look at your phone, you
532
00:48:22,200 --> 00:48:27,720
probably maybe don't want to have anyone
at customs be able to immediately break
533
00:48:27,720 --> 00:48:31,339
into your phone. And that's another point
where hardware security is very important.
534
00:48:31,339 --> 00:48:36,090
And there with a car key, it's the same.
If you rent a car, you hopefully the car
535
00:48:36,090 --> 00:48:41,920
rental company doesn't want you to copy
the key. And interestingly, the more
536
00:48:41,920 --> 00:48:45,559
probably one of the most protected things
in your home is your printer cartridge,
537
00:48:45,559 --> 00:48:49,700
because I can tell you that the vendor
invests a lot of money into you not being
538
00:48:49,700 --> 00:48:54,500
able to clone the printer cartridge. And
so there are a lot of cases where it's
539
00:48:54,500 --> 00:48:58,270
maybe not the user who wants to protect
against hardware attacks, but the vendor
540
00:48:58,270 --> 00:49:02,200
who wants to protect against it.
Herald: Microphone number 1, please.
541
00:49:02,200 --> 00:49:04,750
Mic 1: So thank you again for the amazing
Talk.
542
00:49:04,750 --> 00:49:07,730
Thomas: Thank you.
Mic 1: You mentioned higher order attacks,
543
00:49:07,730 --> 00:49:12,099
I think twice. And for the second chip,
you actually said you you broke it with
544
00:49:12,099 --> 00:49:14,750
two glitches, two exploiteable glitches.
Thomas: Yes.
545
00:49:14,750 --> 00:49:19,370
Mic 1: So what did you do to reduce the
search space or did you just search over
546
00:49:19,370 --> 00:49:22,190
the entire space?
Thomas: So the nice thing about these
547
00:49:22,190 --> 00:49:27,900
chips is that you can actually you can if
you have a security attribution unit, you
548
00:49:27,900 --> 00:49:33,720
can decide when you turn it on, because
you can just, I had the GPIO go up. Then I
549
00:49:33,720 --> 00:49:39,609
enable the SAU. And then I had my search
space very small because I knew it would
550
00:49:39,609 --> 00:49:45,150
be just after I pulled up the GPIO. And so
I was able to very precisely time where I
551
00:49:45,150 --> 00:49:50,280
glitch and I was able because I wrote the
code basically that does it. I could
552
00:49:50,280 --> 00:49:53,470
almost count on the oscilloscope which
instruction I'm hitting.
553
00:49:53,470 --> 00:49:56,520
Mic 1: Thank you.
Herald: Next question from microphone
554
00:49:56,520 --> 00:49:59,839
number 2, please.
Mic 2: Thank you for the talk. I was just
555
00:49:59,839 --> 00:50:05,170
wondering if the vendor was to include the
capacitor directly on the die, howfixed
556
00:50:05,170 --> 00:50:10,520
would you consider it to be?
Thomas: So against voltage glitching? It
557
00:50:10,520 --> 00:50:14,530
might help. It depends. But for example,
on a recent chip, we just used the
558
00:50:14,530 --> 00:50:19,309
negative voltage to suck out the power
from the capacitor. And also, you will
559
00:50:19,309 --> 00:50:23,820
have EMFI glitching as a possibility and
EMFI glitching is awesome because you
560
00:50:23,820 --> 00:50:28,140
don't even have to solder. You just
basically put a small coil on top of your
561
00:50:28,140 --> 00:50:33,070
chip and inject the voltage directly into
it behind any of the capacitors. And so
562
00:50:33,070 --> 00:50:39,570
on. So it it helps, but it's not a. Often
it's not done for security reasons. Let's
563
00:50:39,570 --> 00:50:42,650
see.
Herald: Next question again from our
564
00:50:42,650 --> 00:50:46,359
Signal Angel.
Signal Angel: Did you get to use your own
565
00:50:46,359 --> 00:50:55,970
custom hardware to help you?
Thomas: I partially the part that worked
566
00:50:55,970 --> 00:50:59,310
is the summary.
Herald: Microphone number 1, please.
567
00:50:59,310 --> 00:51:05,010
Mic 1: Hi. Thanks for the interesting
talk. All these vendors pretty much said
568
00:51:05,010 --> 00:51:08,420
this sort of attack is sort of not really
in scope for what they're doing.
569
00:51:08,420 --> 00:51:10,880
Thomas: Yes.
Mic 1: Are you aware of anyone like in
570
00:51:10,880 --> 00:51:15,490
this sort of category of chip actually
doing anything against glitching attacks?
571
00:51:15,490 --> 00:51:20,190
Thomas: Not in this category, but there
are secure elements that explicitly
572
00:51:20,190 --> 00:51:25,891
protect against it. A big problem with
researching those is that it's also to a
573
00:51:25,891 --> 00:51:30,280
large degree security by NDA, at least for
me, because I have no idea what's going
574
00:51:30,280 --> 00:51:35,450
on. I can't buy one to play around with
it. And so I can't tell you how good these
575
00:51:35,450 --> 00:51:39,130
are. But I know from some friends that
there are some chips. Are very good at
576
00:51:39,130 --> 00:51:42,930
protecting against glitches. And
apparently the term you need to look for
577
00:51:42,930 --> 00:51:47,420
it is called glitch monitor. And if you
see that in the data sheet, that tells you
578
00:51:47,420 --> 00:51:52,230
that they at least thought about it
Herald: Microphone number 2, please.
579
00:51:52,230 --> 00:51:59,950
Mic 2: So what about brown-out or
detection? Did microchip say why it didn't
580
00:51:59,950 --> 00:52:03,490
catch your glitching attempts?
Thomas: It's not meet to glitch it at two
581
00:52:03,490 --> 00:52:08,170
to catch glitching attacks. Basically, a
brownout detector is mainly there to keep
582
00:52:08,170 --> 00:52:13,580
your chip stable. And so, for example, if
you're supply voltage drops, you want to
583
00:52:13,580 --> 00:52:17,210
make sure that you notice and don't
accidentally glitch yourself. So, for
584
00:52:17,210 --> 00:52:21,250
example, if it is running on a battery and
your battery goes empty, you want your
585
00:52:21,250 --> 00:52:25,490
chip to run stable, stable, stable off.
And that's the idea behind a brownout
586
00:52:25,490 --> 00:52:30,590
detector is my understanding. But yeah,
they are not made to be fast enough to
587
00:52:30,590 --> 00:52:36,119
catch glitching attacks.
Herald: Do we have any more questions from
588
00:52:36,119 --> 00:52:39,150
the hall?
Thomas: Yes.
589
00:52:39,150 --> 00:52:45,359
Herald: Yes? Where?
Mic ?: Thank you for your amazing talk.
590
00:52:45,359 --> 00:52:49,320
You have shown that it gets very
complicated if you have two consecutive
591
00:52:49,320 --> 00:52:55,390
glitches. So wouldn't it be an easy
protection to just do the stuff twice or
592
00:52:55,390 --> 00:53:00,809
three times and maybe randomize it? Would
you consider this then impossible to be
593
00:53:00,809 --> 00:53:04,160
glitched?
Thomas: So adding randomization to the
594
00:53:04,160 --> 00:53:08,010
point in time where you enable it helps,
but then you can trigger off the power
595
00:53:08,010 --> 00:53:12,880
consumption and so on. And I should add, I
only tried to to trigger once and then use
596
00:53:12,880 --> 00:53:16,880
just a simple delay. But in theory, if you
do it twice, you could also glitch on the
597
00:53:16,880 --> 00:53:21,830
power consumption signature and so on. So
it might help. But somebody very motivated
598
00:53:21,830 --> 00:53:27,910
will still be able to do it. Probably.
Herald: OK. We have another question from
599
00:53:27,910 --> 00:53:31,059
the Internet.
Signal Angel: Is there a mitigation for
600
00:53:31,059 --> 00:53:36,510
such a attack that I can do on PCB level
or it can be addressed only on chip level?
601
00:53:36,510 --> 00:53:40,250
Thomas: Only on chip level, because if you
have a heat, can you just pull the chip
602
00:53:40,250 --> 00:53:45,650
off and do it in a socket or if you do
EMFI glitching, you don't even have to
603
00:53:45,650 --> 00:53:50,240
touch the chip. You just go over it with
the coil and inject directly into the
604
00:53:50,240 --> 00:53:54,800
chip. So the chip needs to be secured
against this type of stuff or you can add
605
00:53:54,800 --> 00:54:00,130
a tamper protection case around your
chips. So, yeah.
606
00:54:00,130 --> 00:54:02,700
Herald: Another question from microphone
number 1.
607
00:54:02,700 --> 00:54:08,270
Mic 1: So I was wondering if you've heard
anything or know anything about the STM32
608
00:54:08,270 --> 00:54:11,260
L5 series?
Thomas: I've heard a lot. I've seen
609
00:54:11,260 --> 00:54:17,020
nothing. So, yes, I've heard about it. But
it doesn't ship yet as far as I know. We
610
00:54:17,020 --> 00:54:20,470
are all eagerly awaiting it.
Mic 1: Thank you.
611
00:54:20,470 --> 00:54:24,440
Herald: Microphone number 2, please
Mic 2: Hey, very good talk. Thank you. Do
612
00:54:24,440 --> 00:54:29,089
you, Will you release all the hardware
design of the board and those scripts?
613
00:54:29,089 --> 00:54:30,799
Thomas: Yes.
Mic 2: Is there anything already
614
00:54:30,799 --> 00:54:33,109
availability even if I understood it's not
all finished?
615
00:54:33,109 --> 00:54:38,349
Thomas: Oh, yes. So on chip.fail. There
are thoughtful domains. It's awesome.
616
00:54:38,349 --> 00:54:44,160
Chip.fail has the source code to our
glitcher. I've also ported it to the
617
00:54:44,160 --> 00:54:48,990
Lattice and I need to push that hopefully
in the next few days. But then all the
618
00:54:48,990 --> 00:54:53,109
hardware would be open sourced also
because it's based on open source hardware
619
00:54:53,109 --> 00:54:59,100
and yeah, I'm not planning to make any
money or anything using it. It's just to
620
00:54:59,100 --> 00:55:02,590
make life easier.
Herald: Microphone number 2, please.
621
00:55:02,590 --> 00:55:07,340
Mic 2: So you said already you don't
really know what happens at the exact
622
00:55:07,340 --> 00:55:14,990
moment of the glitch and you were lucky
that you that you skipped an instruction
623
00:55:14,990 --> 00:55:24,339
maybe. Do you have. Yes. A feeling what is
happening inside the chip at the moment of
624
00:55:24,339 --> 00:55:28,730
the glitch?
Thomas: So I asked this precise question,
625
00:55:28,730 --> 00:55:36,579
what exactly happens to multiple people? I
got multiple answers. But basically my my
626
00:55:36,579 --> 00:55:41,280
understanding is that you basically pull
the voltage that it needs to set, for
627
00:55:41,280 --> 00:55:45,770
example, the register. But I'm it's
absolutely out of my domain to give an
628
00:55:45,770 --> 00:55:50,710
educated comment on this. I'm a breaker,
unfortunately, not a maker when it comes
629
00:55:50,710 --> 00:55:54,030
to chips.
Herald: Microphone number 2, please.
630
00:55:54,030 --> 00:56:01,750
Mic 2: OK. Thank you. You said a lot of
the chip attack. Can you tell us something
631
00:56:01,750 --> 00:56:07,510
about JTAG attacks? So I just have a
connection to JTAG?
632
00:56:07,510 --> 00:56:12,280
Thomas: Yeah. So, for example, the attack
on the KPH version of the chip was
633
00:56:12,280 --> 00:56:17,290
basically a JTAG attack. I used JTAG to
read out the chip, but I did have JTAG in
634
00:56:17,290 --> 00:56:23,630
normal world. However, it's possible on
most - on a lot of chips to reenable JTAG
635
00:56:23,630 --> 00:56:28,690
even if it's locked. And for example,
again, referencing last year's talk, we
636
00:56:28,690 --> 00:56:34,330
were able to re enable JTAG on the STM32F2
and I would assume was something similar
637
00:56:34,330 --> 00:56:39,440
as possible on this chip as well. But I
haven't tried.
638
00:56:39,440 --> 00:56:47,260
Herald: Are there any more questions we
still have a few minutes. I guess not.
639
00:56:47,260 --> 00:56:51,600
Well, a big, warm round of applause for
Thomas Roth.
640
00:56:51,600 --> 00:56:55,110
applause
641
00:56:55,110 --> 00:56:59,210
postroll music
642
00:56:59,210 --> 00:57:06,250
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!