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