This subtitle is not finished yet. If you are able to, please support us and watch the talk in amara for the last changes: https://c3subtitles.de/talk/1286 Thanks!
*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!