36C3 - TrustZone-M(eh): Breaking ARMv8-M's security

36C3 preroll music

Herald: Our next speaker is way is paved
with broken trust zones. He's no stranger

to breaking ARM's, equipment or crypto
wallets or basically anything he touches.

It just dissolves in his fingers. He's one
of Forbes, 30 under 30s in tech. And

please give a warm round of applause to
Thomas Roth.

Applause.

Thomas: Test, okay. Wonderful. Yeah.
Welcome to my talk. TrustZone-M: Hardware

attacks on ARMv8-M security features. My
name is Thomas Roth. You can find me on

Twitter. I'm @stacksmashing and I'm a
security researcher, consultant and

trainer affiliated with a couple of
companies. And yeah, before we can start,

I need to to thank some people. So first
off, Josh Datko and Dimitri Nedospasov

who've been super helpful at anytime I was
stuck somewhere, or just wanted some

feedback. They immediately helped me. And
also Colin O'Flynn, who gave me constant

feedback and helped me with some troubles,
gave me tips and so on. And so without

these people and many more who paved the
way towards this research, I wouldn't be

here. Also, thanks to NXP and Microchip
who I had to work with as part of this

talk. And it was awesome. I had a lot of
very bad vendor experiences, but these two

were really nice to work with. Also some
prior work. So Colin O'Flynn and Alex

Dewar released a paper, I guess last year
or this year "On-Device Power Analysis

Across Hardware Security Domains". And
they basically looked at TrustZone from a

differential power analysis viewpoint and
otherwise TrustZone-M is pretty new, but

lots of work has been done on the big or
real TrustZone and also lots and lots of

works on fault injection would be far too
much to list here. So just google fault

injection and you'll see what I mean.
Before we start, what is TrustZone-M? So

TrustZone-M is the small TrustZone. It's
basically a simplified version of the big

TrustZone that you find on Cortex-A
processors. So basically if you have an

Android phone, chances are very high that
your phone actually runs TrustZone and

that, for example, your key store of
Android is backed by TrustZone. And

TrustZone basically splits the CPU into a
secure and a non-secure world. And so, for

example, you can say that a certain
peripheral should only be available to the

secure world. So, for example, if you have
a crypto accelerator, you might only want

to use it in the secure world. It also, if
you're wondering what's the difference to

an MPU - it also comes with two MPUs.
Sorry, not MMUs, MPUs. And so last year we

gave a talk on bitcoin wallets. And so
let's take those as an example on a

bitcoin wallet you often have different
apps, for example, for Bitcoin, Dogecoin

or Monaro, and then underneath you have an
operating system. The problem is kind of

this operating system is very complex
because it has to handle graphics

rendering and so on and so forth. And
chances are high that it gets compromised.

And if it gets compromised, all your funds
are gone. And so with TrustZone, you could

basically have a second operating system
separated from your normal one that

handles all the important stuff like
firmware update, key store attestation and

so on and reduces your attack surface. And
the reason I actually looked at

TrustZone-M is we got a lot of requests
for consulting on TrustZone-M. So

basically, after our talk last year, a lot
of companies reached out to us and said,

okay, we want to do this, but more
securely. And a lot of them try to use

TrustZone-M for this. And so far there's
been, as far as I know, little public

research into TrustZone-M and whether it's
protected against certain types of

attacks. And we also have companies that
start using them as secure chips. So, for

example, in the automotive industry, I
know somebody who was thinking about

putting them into car keys. I know about
some people in the payment industry

evaluating this. And as said, hardware
wallets. And one of the terms that come up

again and again is this is a secure chip.
But I mean, what is the secure chip

without a threat model? There's no such
thing as a secure chip because there are

so many attacks and you need to have a
threat model to understand what are you

actually protecting against. So, for
example, a chip might have software

features or hardware features that make
the software more secure, such as NX bit

and so on and so forth. And on the other
hand, you have hardware attacks, for

example, debug port side channel attacks
and fault injection. And often the

description of a chip doesn't really tell
you what it's protecting you against. And

often I would even say it's misleading in
some cases. And so you will see, oh, this

is a secure chip and you ask marketing and
they say, yeah, it has the most modern

security features. But it doesn't really
specify whether they are, for example,

protecting against fault injection attacks
or whether they consider this out of

scope. In this talk, we will exclusively
look at hardware attacks and more

specifically, we will look at fault
injection attacks on TrustZone-M. And so

all of the attacks we're going to see are
local to the device only you need to have

it in your hands. And there's no chance,
normally, of remotely exploiting them.

Yeah. So this will be our agenda. We will
start with a short introduction of

TrustZone-M, which will have a lot of
theory on like memory layouts and so on.

We will talk a bit about the fault-
injection setup and then we will start

attacking real chips. These 3, as you will
see. So on a Cortex-M processor you have a

flat memory map. You don't have a memory
management unit and all your peripherals,

your flash, your ram, it's all mapped to a
certain address in memory and TrustZone-M

allows you to partition your flash or your
ram into secure and non secure parts. And

so, for example, you could have a tiny
secure area because your secret code is

very small and a big non secure area. The
same is true for Ram and also for the

peripherals. So for example, if you have a
display and a crypto engine and so on. You

can decide whether these peripherals
should be secure or non secure. And so

let's talk about these two security
states: secure and non secure. Well, if

you have code running in secure flash or
you have secure code running, it can call

anywhere into the non secure world. It's
basically the highest privilege level you

can have. And so there's no protection
there. However, the opposite, if we tried

to go from the non secure world and to the
secure world would be insecure because,

for example, you could jump to the parts
of the code that are behind certain

protections and so on. And so that's why,
if you tried to jump from an unsecured

code into a secure code, it will cause an
exception. And to handle that, there's a

third memory state which is called non
secure callable. And as the name implies,

basically you're non secure code can call
into the non secure callable code. More

specifically, it can only call to non
secure callable code addresses where

there's an SG instruction which stands for
Secure Gateway. And the idea behind the

secure gateway is that if you have a non
secure kernel running, you probably also

have a secure kernel of running. And
somehow this secure kernel will expose

certain system calls, for example. And so
we want to somehow call from the non

secure kernel into these system calls, but
as I've just mentioned, we can't do that

because this will unfortunately cause an
exception. And so the way this is handled

on TrustZone-M is that you create so-
called secure gateway veneer functions.

These are very short functions in the non
secure callable area. And so if we want,

for example, to call the load key system
call, we would call the load key veneer

function, which in turn would call the
real load key function. And these veneer

functions are super short. So if you look
at the disassembly of them, it's like two

instructions. It's the secure gateway
instruction and then a branch instruction

to what's your real function. And so if we
combine this, we end up with this diagram

secure can call into non secure, non
secure, can call into NSC and NSC can call

into your secure world. But how do we
manage these memory states? How do we know

what security state does an address have?
And so for this in TrustZone-M, we use

something called attribution units and
there're by default there are two

attribution units available. The first one
is the SAU the Security Attribution Unit,

which is standard across chips. It's
basically defined by ARM how you use this.

And then there's the IDAU. The
Implementation Defined Attribution Unit,

which is basically custom to the silicon
vendor, but can also be the same across

several chips. And to get the security
state of an address, the security

attribution of both the SAU and the IDAU
are combined and whichever one has the

higher privilege level will basically win.
And so let's say our SAU says this address

is secure and our IDAU says this address
is non secure the SAU wins because it's

the highest privilege level. And basically
our address would be considered secure.

This is a short table. If both the SAU and
the IDAU agree, we will be non secure if

both say, hey, this is secure, it will be
secure. However, if they disagree and the

SAU says, hey, this address is secure the
IDAU says it's non secure, it will still

be secure because secure is to have
privilege level. The opposite is true. And

with even with non secure callable, secure
is more privileged than NSC. And so secure

will win. But if we mix NS and NSC, we get
non-secular callable. Okay. My initial

hypothesis when I read all of this was if
we break or disable the attribution units,

we probably break the security. And so to
break these, we have to understand them.

And so let's look at the SAU the security
attribution unit. It's standardized by

ARM. It's not available on all chips. And
it basically allows you to create memory

regions with different security states.
So, for example, if the SAU is turned off,

everything will be considered secure. And
if we turn it on, but no regions are

configured, still, everything will be
secure. We can then go and add, for

example, address ranges and make them NSC
or non secure and so on. And this is done

very, very easily. You basically have
these five registers. You have the SAU

control register where you basically can
turn it on or off. You have the SAU type,

which gives you the number of supported
regions on your platform because this can

be different across different chips. And
then we have the region number register,

which you use to select the region you
want to configure and then you set the

base address and the limit address. And
that's basically it. So, for example, if

we want to set region zero, we simply set
the RNR register to zero. Then we set the

base address to 0x1000. We set the limit
address to 0x1FE0, which is identical to

1FFF because there are some other bits
behind there that we don't care about

right now. And then we turn on the
security attribution unit and now our

memory range is marked as secure if you
want to create a second region we simply

change RNR to, for example, 1 again insert
some nice addresses. Turn on the SAU and

we have a second region this time from
4000 to 5FFF. So to summarize, we have

three memory security states. We have S
secure and we have NSC non secure callable

and we have NS non secure. We also have
the two attribution units, the SAU

standard by ARM and the IDAU which is
potentially custom we will use SAU and

IDAU a lot. So this was very important.
Cool. Let's talk about fault injection. So

as I've mentioned, we want to use fault
injection to compromise TrustZone. And the

idea behind fault injection or as it's
also called glitching is to introduce

faults into a chip. So, for example, you
cut the power for a very short amount of

time while you change the period of the
clock signal or even you could go and

inject electromagnetic shocks in your
chip. You can also shoot at it with a

laser and so on and so forth. Lots of ways
to do this. And the goal of this is to is

to cause undefined behavior. And in this
talk, we will specifically look at

something called voltage glitching. And so
the idea behind voltage glitching is that

we cut the power to the chip for very,
very short amount of time at a very

precisely timed moment. And this will
cause some interesting behavior. So

basically, if you would look at this on an
oscilloscope, we would basically have a

stable voltage, stable voltage, stable
voltage, and then suddenly it drops and

immediately returns. And this drop will
only be a couple of nanoseconds long. And

so, for example, you can have glitches
that are 10 nanoseconds long or 15

nanoseconds long and so on. Depends on
your chip. And yeah. And this allows you

to do different things. So, for example, a
glitch can allow you to skip instructions.

It can corrupt flash reads or flash
writes. It can corrupt memory registers or

register reads and writes. And skipping
instructions for me is always the most

interesting one, because it allows you to
directly go from disassembly to

understanding what you can potentially
jump over. So, for example, if we have

some code, this would be a basic firmware
boot up code. We have an initialized

device function. Then we have a function
that basically verifies the firmware

that's in flash and then we have this
boolean check whether our firmware was

valid. And now if we glitch at just the
right time, we might be able to glitch

over this check and boot our potentially
compromised firmware, which is super nice.

So how does this relate to TrustZone?
Well, if we manage to glitch over enable

TrustZone, we might be able to break
TrustZone. So how do you actually do this?

Well, we need something to wait for a
certain delay and generate a pulse at just

the right time with very high precision.
We are talking about nano seconds here,

and we also need something to drop the
power to the target. And so if you need

precise timing and so on, what works very
well is an FPGA. And so, for example, the

code that was released as part of this all
runs on the Lattice iCEstick, which is

roughly 30 bucks and you need a cheap
MOSFET and so together this is like thirty

one dollars of equipment. And on a setup
side, this looks something like this. You

would have your FPGA, which has a trigger
input. And so, for example, if you want to

glitch something doing the boot up of a
chip, you could connect this to the reset

line of the chip. And then we have an
output for the glitch pulse. And then if

we hook this all up, we basically have our
power supply to the chip run over a

MOSFET. And then if the glitch pulls goes
high, we drop the power to ground and the

chip doesn't get power for a couple of
nanoseconds. Let's talk about this power

supply, because a chip has a lot of
different things inside of it. So, for

example, a microcontroller has a CPU core.
We have a Wi-Fi peripheral. We have GPIO.

We might have Bluetooth and so on. And
often these peripherals run at different

voltages. And so while our microcontroller
might just have a 3.3 volt input,

internally there are a lot of different
voltages at play. And the way these

voltages are generated often is using
in-chip regulators. And basically these

regulators connect with the 3.3 voltage in
and then generate the different voltages

for the CPU core and so on. But what's
nice is that on a lot of chips there are

behind the core regulator, so called
bypass capacitors, and these external

capacitors are basically there to
stabilize the voltage because regulators

tend to have a very noisy output and you
use the capacitor to make it more smooth.

But if you look at this, this also gives
us direct access to the CPU core power

supply. And so if we just take a heat gun
and remove the capacitor, we actually kind

of change the pin out of the processor
because now we have a 3.3 voltage in, we

have a point to input the core voltage and
we have ground. So we basically gained

direct access to the internal CPU core
voltage rails. The only problem is these

capacitors are for a reason. And so if we
remove them, then your chip might stop

working. But very easy solution. You just
hook up a power supply to it, set it to

1.2 volts or whatever, and then suddenly
it works. And this also allows you to

glitch very easily. You just glitch on
your power rail towards the chip. And so

this is our current setup. So we have the
Lattice iCEstick. We also use a

multiplexer as an analog switch to cut the
power to the entire device. If we want to

reboot everything, we have the MOSFET and
we have a power supply. Now hooking this

all up on a bread board is fun the first
time, it's okay the second time. But the

third time it begins to really, really
suck. And as soon as something breaks with

like 100 jumper wires on your desk, the
only way to debug is to start over. And so

that's why I decided to design a small
hardware platform that combines all of

these things. So it has an FPGA on it. It
has analog input and it has a lot of

glitch circuitry and it's called the Mark
Eleven. If you've read William Gibson, you

might know where this is from. And it
contains a Lattice iCE40, which has a

fully open source toolchain, thanks to
Clifford Wolf and so. And this allows us

to very, very quickly develop new
triggers, develop new glitched code and so

on. And it makes compilation and
everything really really fast. It also

comes with three integrated power
supplies. So we have a 1.2 watt power

supply, 3.3, 5 volts and so on, and you
can use it for DPA. And this is based

around some existing devices. So, for
example, the FPGA part is based on the

1BitSquared iCEBreaker. The analog front
end, thanks to Colin O'Flynn, is based on

the ChipWhisperer Nano. And then the
glitch circuit is basically what we've

been using on bread boards for quite a
while. Just combined on a single device.

And so unfortunately, as always with
hardware production takes longer than you

might assume. But if you drop me a message
on Twitter, I'm happy to send you a PCB as

soon as they work well. And the BOM is
around 50 bucks. Cool. So now that we are

ready to have to actually attack chips,
let's look at an example. So the very

first chip that I encountered that used
TrustZone-M was the Microchip SAM 11. And

so this chip was released in June 2018.
And it's kind of it's a small, slow chip.

It's runs at 32 megahertz. It has up to 64
kilobytes of flash and 16 kilobytes of

SRAM, but it's super cheap. It's like one
dollar eighty at quantity one. And so it's

really nice, really affordable. And we had
people come up to us and suggest, hey, I

want to build a TPM on top of this or I
want to build a hardware wallet on top of

this. And so on and so forth. And if we
look at the website of this chip. It has a

lot of security in it, so it's the best
contribution to IOT security winner of

2018. And if you just type secure into the
word search, you get like 57 hits. So this

chip is 57 secure. laughter And even on
the website itself, you have like chip

level security. And then if you look at
the first of the descriptions, you have a

robust chip level security include chip
level, tamper resistance, active shield

protects against physical attacks and
resists micro probing attacks. And even in

the datasheet, where I got really worried
because I said I do a lot with a core

voltage it has a brown-out detector that
has been calibrated in production and must

not be changed and so on. Yeah. To be
fair, when I talked to my microchip, they

mentioned that they absolutely want to
communicate that this chip is not hardened

against hardware attacks, but I can see
how somebody who looks at this would get

the wrong impression given all the terms
and so on. Anyway, so let's talk about the

TrustZone in this chip. So the SAM L11
does not have a security attribution unit.

Instead, it only has the implementation
defined attribution unit. And the

configuration for this implementation
defined attribution unit is stored in the

user row, which is basically the
configuration flash. It's also called

fuses in the data sheet sometimes, but
it's really I think it's flash based. I

haven't checked, but I am pretty sure it
is because you can read it, write it,

change it and so on. And then the IDAU,
once you've configured it, will be

configured by the boot ROM during the
start of the chip. And the idea behind the

IDAU is that all your flash is partitioned
into two parts of the bootloader part and

the application part, and both of these
can be split into secure, non secure

callable and non secure. So you can have a
bootloader, a secure and a non secure one,

and you can have an application, a secure
and a non secure one. And the size of

these regions is controlled by these five
registers. And for example, if we want to

change our non secure application to be
bigger and make our secure application a

bit smaller, we just fiddle with these
registers and the sizes will adjust and

the same with the bootloader. So this is
pretty simple. How do we attack it? My

goal initially was I want to somehow read
data from the secure world while running

code in the non secret world. So jump the
security gap. My code in non secure should

be able to, for example, extract keys from
the secure world and my attack path for

that was well, I glitched the boot ROM
code that loads the IDAU you

configuration. But before we can actually
do this, we need to understand, is this

chip actually glitchable and can we? Is it
susceptible to glitches or do we

immediately get get thrown out? And so I
used a very simple setup where just had a

firmware and tried to glitch out of the
loop and enable an LED. And I had success

in less than five minutes and super stable
glitches almost immediately. Like when I

saw this, I was 100 percent sure that I
messed up my setup or that the compiler

optimized out my loop or that I did
something wrong because I never glitch to

chip in five minutes. And so this was
pretty awesome, but I also spend another

two hours verifying my setup. So. OK.
Cool, we know that ship is glitchable, so

let's glitch it. What do we glitch? Well,
if we think about it somewhere during the

boot ROM, these registers are red from
flash and then some hardware is somehow

configured. We don't know how because we
can't dump the boot from we don't know

what's going on in the chip. And the
datasheet has a lot of pages. And I'm a

millennial. So, yeah, I read what I have
to read and that's it. But my basic idea

is if we somehow manage to glitch the
point where it tries to read the value of

the AS Register, we might be able to set
it to zero because most chip peripherals

will initialize to zero. And if we glitch
with the instruction that reads AS, maybe

we can make our non secure application
bigger so that we, that actually we can

read the secure application data because
now it's considered non secure. But.

Problem 1 The boot ROM is not dumpable. So
we cannot just disassemble it and figure

out when does it roughly do this. And the
problem 2 is that we don't know when

exactly this read occures and our glitch
needs to be instruction precise. We need

to hit just the right instruction to make
this work. And the solution is brute

force. But I mean like nobody has time for
that. Right? So if the chip boots for 2

milliseconds. That's a long range we have
to search for glitches. And so very easy

solution power analysis. And it turns out
that, for example, a riscure has done this

before where basically they tried to
figure out where in time a JTAG lock is

set by comparing the power consumption.
And so the idea is, we basically write

different values to the AS register, then
we collect a lot of power traces and then

we look for the differences. And this is
relatively simple to do. If you have a

ChipWhisperer. So. This was my rough
setup. So we just have the ChipWhisperer-

Lite. We have a breakout with the chip we
want to attack and a programmer. And then

we basically collect a couple of traces.
And in my case, even just 20 traces are

enough, which takes, I don't know, like
half a second to run. And if you have 20

traces in unsecure mode, 20 traces in
secure mode and you compare them, you can

see that there are clear differences in
the power consumption starting at a

certain point. And so I wrote a script
that does some more statistics on it and

so on. And that basically told me the best
glitch candidate starts at 2.18

milliseconds. And this needs to be so
precise because I said we're in the milli

and the nano seconds range. And so we want
to make sure that we at the right point in

time. Now, how do you actually configure?
How do you build the setup where you

basically you get a success indication
once you broke this? For this, I needed to

write a firmware that basically attempts
to read secure data. And then if it's

successful, enabled the GPIO. And if it
fails, it does nothing. And I just reset

and try again. And so I know I knew my
rough delay and I was triggering of the

reset of the chip that I just tried. Any
delay after it and tried different glitch

pulse length and so on. And eventually I
had a success. And these glitches you will

see with the glitcher which we released a
while back is super easy to write because

all you have is like 20 lines of Python.
You basically set up a loop delay from

delay to your setup, the pulse length. You
iterate over a range of pulses. And then

in this case you just check whether your
GPIO is high or low. That's all it takes.

And then once you have this running in a
stable fashion, it's amazing how fast it

works. So this is now a recorded video of
a life glitch, of a real glitch,

basically. And you can see we have like 20
attempts per second. And after a couple of

seconds, we actually get a success
indication we just broke a chip. Sweet.

But one thing I moved to a part of Germany
to the very south is called the

Schwabenland. And I mean, 60 bucks. We are
known to be very cheap and 60 bucks

translates to like six beers at
Oktoberfest. Just to convert this to the

local currency, that's like 60 Club Mate.
Unacceptable. We need to go cheaper, much

cheaper, and so.
laughter and applause

What if we take a chip that is 57 secure
and we tried to break it with the smallest

chip. And so this is an ATTiny which
costs, I don't know, a a euro or two euro.

We combine it with a MOSFET to keep the
comparison that's roughly 3 Club Mate and

we hook it all up on a jumper board and
turns out: This works like you can have a

relatively stable glitch, a glitcher with
like 120 lines of assembly running all the

ATTiny and this will glitch your chip
successfully and can break TrustZone on

the SAM L11. The problem is chips are very
complex and it's always very hard to do an

attack on a chip that you configured
yourself because as you will see, chances

are very high that you messed up the
configuration and for example, missed a

security bit, forgot to set something and
so on and so forth. But luckily, in the

case of the SAM L11, there's a version of
this chip which is already configured and

only ships in non secure mode. And so this
is called the SAM L11 KPH. And so it comes

pre provisioned with a key and it comes
pre provisioned with a trusted execution

environment already loaded into the secure
part of the chips and ships completely

secured and the customer can write and
debug non secure code only. And also you

can download the SDK for it and write your
own trustlets and so on. But I couldn't

because it requires you to agree to their
terms and conditions so which exclude

reverse engineering. So no chance,
unfortunately. But anyway, this is the

perfect example to test our attack. You
can buy these chips on DigiKey and then

try to break into the secure world because
these chips are hopefully decently secured

and have everything set up and so on. And
yeah. So this was the setup. We designed

our own breakout port for the SAM L11,
which makes it a bit more accessible, has

JTAG and has no capacitors in the way. So
you get access to all the core voltages

and so on and you have the FPGA on the top
left the super cheap 20 bucks power supply

and the programmer. And then we just
implemented a simple function that uses

openOCD to try to read an address that we
normally can't read. So we basically we

glitch. Then we start OpenOCD, which uses
the JTAG adapter to try to read secure

memory. And so I hooked it all up, wrote a
nice script and let it rip. And so after a

while or in well, a couple of seconds
immediately again got successful, I got a

successful attack on the chip and more and
more. And you can see just how stable you

can get these glitches and how well you
can attack this. Yeah. So sweet hacked. We

can compromise the root of trust and the
trusted execution environment. And this is

perfect for supply chain attacks. Right.
Because if you can compromise a part of

the chip that the customer will not be
able to access, he will never find you.

But the problem with supply chain attacks
is, they're pretty hard to scale and they

are only for sophisticated actors normally
and far too expensive is what most people

will tell you, except if you hack the
distributor. And so as I guess last year

or this year, I don't know, I actually
found a vulnerability in DigiKey, which

allowed me to access any invoice on
DigiKey, including the credentials you

need to actually change the invoice. And
so basically the bug is that they did not

check when you basically requested an
invoice, they did not check whether you

actually had permission to access it. And
you have the web access id on top and the

invoice number. And that's all you need to
call DigiKey and change the delivery,

basically. And so this also is all data
that you need to reroute the shipment. I

disclosed this. It's fixed. It's been
fixed again afterwards. And now hopefully

this should be fine. So I feel good to
talk about it. And so let's walk through

the scenarios. We have Eve and we have
DigiKey and Eve builds this new super

sophisticated IOT toilet and she needs a
secure chip. So she goes to DigiKey and

orders some SAM L11 KPHs and Mallory.
Mallory scans all new invoices on DigiKey.

And as soon as somebody orders a SAM L11,
they talk to DigiKey with the API or via a

phone call to change the delivery address.
And because you know who the chips are

going to, you can actually target this
very, very well. So now the chips get

delivered to Mallory Mallory backdoors the
chips. And then sends the backdoored chips

to Eve who is none the wiser, because it's
the same carrier, it's the same, it looks

the same. You have to be very, very
mindful of these types of attack to

actually recognize them. And even if they
open the chips and they say they open the

package and they try the chip, they scan
everything they can scan the backdoor will

be in the part of the chip that they
cannot access. And so we just supply chain

attacked whoever using an UPS envelope,
basically. So, yeah. Interesting attack

vector. So I talked to microchip and it's
been great. They've been super nice. It

was really a pleasure. I also talked to
Trustonic, who were very open to this and

wanted to understand it. And so it was
great. And they explicitly state that this

chip only protects against software
attacks while it has some hardware

features like tamper ressistant RAM. It is
not built to withstand fault injection

attacks. And even if you compare it now,
different revisions of the data sheet, you

can see that some data sheets, the older
ones they mention some fault injection

resistance and it's now gone from the data
sheet. And they are also asking for

feedback on making it more clear what this
chip protects against, which I think is a

noble goal because we all know marketing
versus technicians is always an

interesting fight. Let's say, cool first
chip broken time for the next one, right?

So the next chip I looked at was the
Nuvoton NuMicro M2351 rolls off the

tongue. It's a Cortex-M23 processor. It
has TrustZone-M. And I was super excited

because this finally has an SAU, a
security attribution unit and an IDAU and

also I talked to the marketing. It
explicitly protects against fault

injection. So that's awesome. I was
excited. Let's see how that turns out.

Let's briefly talk about the TrustZone in
the Nuvoton chip. So as I've mentioned

before, the SAU if it's turned off or
turned on without regions will be to fully

secure. And no matter what the IDAU is,
the most privileged level always wins. And

so if our entire security attribution unit
is secure, our final security state will

also be secure. And so if we now add some
small regions, the final state will also

have the small, non secure regions. I
mean, I saw this looked at how this this

code works. And you can see that at the
very bottom SAU control is set to 1 simple

right. We glitch over the SAU enabling and
all our code will be secure and we'll just

run our code in secret mode, no problem -
is what I fought. And so basically the

secure bootloader starts execution of non
secure code. We disable the SAU by

glitching over the instruction and now
everything is secure. So our code runs in

a secure world. It's easy except read the
fucking manual. So turns out these

thousands of pages of documentation
actually contain useful information and

you need a special instruction to
transition from secure to non secure state

which is called BLXNS, which stands for
branch optionally linked and exchange to

non secure. This is exactly made to
prevent this. It prevents accidentally

jumping into non secure code. It will
cause a secure fault if you try to do it.

And what's interesting is that even if you
use this instruction, it will not always

transition. The state depends on the last
bit in the destination address, whether

the status transition and the way the
bootloader will actually get these

addresses it jumps to is from what's
called the reset table, which is basically

where your reset handlers are, where your
stack pointer, your initial stack pointer

is and so on. And you will notice that the
last bit is always set. And if the last

bit is set, it will jump to secure code.
So somehow they managed to branch to this

address and run it into non secure. So how
do they do this? They use an explicit bit

clear instruction. What do we know about
instructions? We can glitch over them. And

so basically we can with two glitches, we
can glitch over the SAU control enable now

our entire memory is secure and then we
glitch over the bitclear instruction and

then branch linked ex non secure again
rolls off the tongue will run secure code.

And now our normal world code is running
in secure mode. The problem is it works,

but it's very hard to get stable. So, I
mean, this was I somehow got it working,

but it was not very stable and it was a
big pain to to actually make use of. So I

wanted a different vulnerability. And I
read up on the implementation defined

attribution unit of the M2351. And it
turns out that each flash RAM peripheral

and so on is mapped twice into memory. And
so basically once as secure as the address

0x2000 and once as non secure at the
address 0x3000. And so you have the flash

twice and you have the the RAM twice. This
is super important. This is the same

memory. And so I came up with an attack
that I called CroeRBAR because a

vulnerability basically doesn't exist if
it doesn't have a fancy name. And the

basic point of this is that the security
of the system relies on the region

configuration of the SAU. What if we
glitch this initialization combined with

this IDAU layout again with the IDAU
mirrors the memory. Has it once a secure

and once it's not secure. Now let's say we
have at the very bottom of our flash. We

have a secret which is in the secure area.
It will also be in the mirror of this

memory. But again, because our SAU
configuration is fine, it will not be

accessible by the non secure region.
However, the start of this non secret area

is configured by the RBAR register. And so
maybe if we glitch this RBAR being set, we

can increase the size of the non secure
area. And if you check the ARM

documentation on the RBAR register, the
reset values state of this register is

unknown. So unfortunately it doesn't just
say zero, but I tried this on all chips I

had access to and it is zero on all chips
I tested. And so now what we can do is we

glitch over this RBAR and now our final
security state will be bigger and our

secure code is still running in the bottom
half. But then the jump into non secure

will also give us access to the secret and
it works. We get a fully stable glitch,

takes roughly 30 seconds to bypass it. I
should mention that this is what I think

happens. All I know is that I inject a
glitch and I can read the secret. I cannot

tell you exactly what happens, but this is
the best interpretation I have so far. So

wuhu we have an attack with a cool name?
And so I looked at another chip called the

NXP LPC55S69, and this one has 2
Cortex-M33 cores, one of which has

TrustZone-M. The IDAU and the overall
TrustZone layout seem to be very similar

to the NuMicro. And I got the dual glitch
attack working and also the CrowRBAR

attack working. And the vendor response
was amazing. Like holy crap, they called

me and wanted to fully understand it. They
reproduced that. They got me on the phone

with an expert and the expert was super
nice. But what he said came down to was

RTFM. But again, this is a long document,
but it turns out that the example code did

not enable a certain security feature. And
this security feature is helpfully named

Miscellaneous Control Register, basically,
laughter which stands for Secure Control

Register, laughter obviously. And this
register has a bit. If you set it, it

enables secure checking. And if I read
just a couple of sentences first further,

when I read about the TrustZone on the
chip, I would have actually seen this. But

Millennial sorry. Yeah. And so what this
enables is called the memory protection

checkers and this is an additional memory
security check that gives you finer

control over the memory layout. And so it
basically checks if the attribution unit

security state is identical with the
memory protection checker security state.

And so, for example, if our attack code
tries to access memory, the MPC will check

whether this was really a valid request.
So to say and stop you if you are unlucky

as I was. But turns out it's glitchable,
but it's much, much harder to glitch and

you need multiple glitches. And the vendor
response was awesome. They also say

they're working on improving the
documentation for this. So yeah, super

cool. But still like it's not a full
protection against glitching, but it gives

you certain security. And I think that's
pretty awesome. Before we finish. Is

everything broken? No. These chips are not
insecure. They are not protected against a

very specific attack scenario and align
the chips that you want to use with your

threat model. If fault injection is part
of your threat models. So, for example,

you're building a carkey. Maybe you should
protect against glitching. If you're

building a hardware wallet, definitely you
should protect against glitching. Thank

you. Also, by the way, if you want to play
with some awesome fault injection

equipment, I have an EMFI glitcher with me
and so. So just hit me up on Twitter and

I'm happy to show it to you. So thanks a
lot.

applause

Herald: Thank you very much, Thomas. We do
have an awesome 15 minutes for Q and A. So

if you line up, we have three microphones.
Microphone number 3 actually has an

induction loop. So if you're hearing
impaired and have a suitable device, you

can go to microphone 3 and actually hear
the answer. And we're starting off with

our signal angel with questions from the
Internet.

Thomas: Hello, Internet.
Signal Angel: Hello. Are you aware of the

ST Cortex-M4 firewall? And can your
research be somehow related to it? Or

maybe do you have plans to explore it in
the future?

Thomas: I. So, yes, I'm very aware of the
ST M3 and M4. If you watch our talk last

year at CCC called Wallet.fail, we
actually exploited the sister chip, the

STM32 F2. The F4 has this strange firewall
thing which feels very similar to

TrustZone-M. However, I cannot yet share
any research related to that chip,

unfortunately. Sorry.
Signal Angel: Thank you.

Herald: Microphone number 1, please.
Mic 1: Hello. I'm just wondering, have you

tried to replicate this attack on
multicore CPUs with higher frequency such

like 2GHz and others, how would you go
about that?

Thomas: So I have not because there there
are no TrustZone-M chips with this

frequency. However, people have done it on
mobile phones and other equipment. So, for

example, yeah, there's a lot of materials
on glitching higher frequency stuff. But

yeah, it will get expensive really quickly
because the scope, the way you can even

see a two gigahertz clock, that's a nice
car oscilloscope.

Herald: Microphone number 2, please.
Mic 2: Thank you for your talk. Is the

more functionality to go from non-secure
to secure area? Are there same standard

defined functionalities or the proprietory
libraries from NXP?

Thomas: So the the veneer stuff is
standard and you will find ARM documents

basically recommending you to do this. But
all the tool chains, for example, the one

for the SAM L11 will generate the veneers
for you. And so I have to be honest, I

have not looked at how exactly they are
generated.

However, I did some rust stuff to play
around with it. And yeah, it's relatively

simple for the tool chain and it's
standard. So

Herald: the signal angel is signaling.
Signal Angel: Yeah. That's not another

question from the internet but from me and
I wanted to know how important is the

hardware security in comparison to the
software security because you cannot hack

these devices without having physical
access to them except of this supply chain

attack.
Thomas: Exactly. And that depends on your

threat model. So that's basically if you
build a door, if you build a hardware

wallet, you want to have hardware
protection because somebody can steal it

potentially very easily and then... And if
you, for example, look at your phone, you

probably maybe don't want to have anyone
at customs be able to immediately break

into your phone. And that's another point
where hardware security is very important.

And there with a car key, it's the same.
If you rent a car, you hopefully the car

rental company doesn't want you to copy
the key. And interestingly, the more

probably one of the most protected things
in your home is your printer cartridge,

because I can tell you that the vendor
invests a lot of money into you not being

able to clone the printer cartridge. And
so there are a lot of cases where it's

maybe not the user who wants to protect
against hardware attacks, but the vendor

who wants to protect against it.
Herald: Microphone number 1, please.

Mic 1: So thank you again for the amazing
Talk.

Thomas: Thank you.
Mic 1: You mentioned higher order attacks,

I think twice. And for the second chip,
you actually said you you broke it with

two glitches, two exploiteable glitches.
Thomas: Yes.

Mic 1: So what did you do to reduce the
search space or did you just search over

the entire space?
Thomas: So the nice thing about these

chips is that you can actually you can if
you have a security attribution unit, you

can decide when you turn it on, because
you can just, I had the GPIO go up. Then I

enable the SAU. And then I had my search
space very small because I knew it would

be just after I pulled up the GPIO. And so
I was able to very precisely time where I

glitch and I was able because I wrote the
code basically that does it. I could

almost count on the oscilloscope which
instruction I'm hitting.

Mic 1: Thank you.
Herald: Next question from microphone

number 2, please.
Mic 2: Thank you for the talk. I was just

wondering if the vendor was to include the
capacitor directly on the die, howfixed

would you consider it to be?
Thomas: So against voltage glitching? It

might help. It depends. But for example,
on a recent chip, we just used the

negative voltage to suck out the power
from the capacitor. And also, you will

have EMFI glitching as a possibility and
EMFI glitching is awesome because you

don't even have to solder. You just
basically put a small coil on top of your

chip and inject the voltage directly into
it behind any of the capacitors. And so

on. So it it helps, but it's not a. Often
it's not done for security reasons. Let's

see.
Herald: Next question again from our

Signal Angel.
Signal Angel: Did you get to use your own

custom hardware to help you?
Thomas: I partially the part that worked

is the summary.
Herald: Microphone number 1, please.

Mic 1: Hi. Thanks for the interesting
talk. All these vendors pretty much said

this sort of attack is sort of not really
in scope for what they're doing.

Thomas: Yes.
Mic 1: Are you aware of anyone like in

this sort of category of chip actually
doing anything against glitching attacks?

Thomas: Not in this category, but there
are secure elements that explicitly

protect against it. A big problem with
researching those is that it's also to a

large degree security by NDA, at least for
me, because I have no idea what's going

on. I can't buy one to play around with
it. And so I can't tell you how good these

are. But I know from some friends that
there are some chips. Are very good at

protecting against glitches. And
apparently the term you need to look for

it is called glitch monitor. And if you
see that in the data sheet, that tells you

that they at least thought about it
Herald: Microphone number 2, please.

Mic 2: So what about brown-out or
detection? Did microchip say why it didn't

catch your glitching attempts?
Thomas: It's not meet to glitch it at two

to catch glitching attacks. Basically, a
brownout detector is mainly there to keep

your chip stable. And so, for example, if
you're supply voltage drops, you want to

make sure that you notice and don't
accidentally glitch yourself. So, for

example, if it is running on a battery and
your battery goes empty, you want your

chip to run stable, stable, stable off.
And that's the idea behind a brownout

detector is my understanding. But yeah,
they are not made to be fast enough to

catch glitching attacks.
Herald: Do we have any more questions from

the hall?
Thomas: Yes.

Herald: Yes? Where?
Mic ?: Thank you for your amazing talk.

You have shown that it gets very
complicated if you have two consecutive

glitches. So wouldn't it be an easy
protection to just do the stuff twice or

three times and maybe randomize it? Would
you consider this then impossible to be

glitched?
Thomas: So adding randomization to the

point in time where you enable it helps,
but then you can trigger off the power

consumption and so on. And I should add, I
only tried to to trigger once and then use

just a simple delay. But in theory, if you
do it twice, you could also glitch on the

power consumption signature and so on. So
it might help. But somebody very motivated

will still be able to do it. Probably.
Herald: OK. We have another question from

the Internet.
Signal Angel: Is there a mitigation for

such a attack that I can do on PCB level
or it can be addressed only on chip level?

Thomas: Only on chip level, because if you
have a heat, can you just pull the chip

off and do it in a socket or if you do
EMFI glitching, you don't even have to

touch the chip. You just go over it with
the coil and inject directly into the

chip. So the chip needs to be secured
against this type of stuff or you can add

a tamper protection case around your
chips. So, yeah.

Herald: Another question from microphone
number 1.

Mic 1: So I was wondering if you've heard
anything or know anything about the STM32

L5 series?
Thomas: I've heard a lot. I've seen

nothing. So, yes, I've heard about it. But
it doesn't ship yet as far as I know. We

are all eagerly awaiting it.
Mic 1: Thank you.

Herald: Microphone number 2, please
Mic 2: Hey, very good talk. Thank you. Do

you, Will you release all the hardware
design of the board and those scripts?

Thomas: Yes.
Mic 2: Is there anything already

availability even if I understood it's not
all finished?

Thomas: Oh, yes. So on chip.fail. There
are thoughtful domains. It's awesome.

Chip.fail has the source code to our
glitcher. I've also ported it to the

Lattice and I need to push that hopefully
in the next few days. But then all the

hardware would be open sourced also
because it's based on open source hardware

and yeah, I'm not planning to make any
money or anything using it. It's just to

make life easier.
Herald: Microphone number 2, please.

Mic 2: So you said already you don't
really know what happens at the exact

moment of the glitch and you were lucky
that you that you skipped an instruction

maybe. Do you have. Yes. A feeling what is
happening inside the chip at the moment of

the glitch?
Thomas: So I asked this precise question,

what exactly happens to multiple people? I
got multiple answers. But basically my my

understanding is that you basically pull
the voltage that it needs to set, for

example, the register. But I'm it's
absolutely out of my domain to give an

educated comment on this. I'm a breaker,
unfortunately, not a maker when it comes

to chips.
Herald: Microphone number 2, please.

Mic 2: OK. Thank you. You said a lot of
the chip attack. Can you tell us something

about JTAG attacks? So I just have a
connection to JTAG?

Thomas: Yeah. So, for example, the attack
on the KPH version of the chip was

basically a JTAG attack. I used JTAG to
read out the chip, but I did have JTAG in

normal world. However, it's possible on
most - on a lot of chips to reenable JTAG

even if it's locked. And for example,
again, referencing last year's talk, we

were able to re enable JTAG on the STM32F2
and I would assume was something similar

as possible on this chip as well. But I
haven't tried.

Herald: Are there any more questions we
still have a few minutes. I guess not.

Well, a big, warm round of applause for
Thomas Roth.

applause

postroll music

Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!