Don't Whisper my Chips
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
O'Flynn, Colin
If you thought the security practices of regular software was bad, just wait until you start learning about the security of embedded hardware systems. Recent open-source hardware tools have made this field accessible to a wider range of researchers, and this presentation will show you how to perform these attacks for equipment costing $200. Attacks against a variety of real systems will be presented: AES-256 bootloaders, internet of things devices, hardware crypto tokens, and more. All of the attacks can be replicated by the attendees, using either their own tools if such equipped (such as oscilloscopes and pulse generators), the open-hardware ChipWhisperer-Lite, or an FPGA board of their own design. The hands-on nature of this talk is designed to introduce you to the field, and give you the confidence to pick up some online tutorials or books and work through them. Even if you've never tried hardware hacking before, the availability of open-source hardware makes it possible to follow published tutorials and learn all about side-channel power analysis and glitching attacks for yourself. Speaker Bio: Colin O'Flynn has been working with security on embedded systems for several years. He has designed the open-source ChipWhisperer project which won 2nd place in the 2014 Hackaday Prize, and developed an even lower-cost version called the ChipWhisperer-Lite, which was the focus of a Kickstarter in 2015. Twitter: @colinoflynn
 So this is don't whisper my chips and I'm going to be talking about various methods of hardware hacking is what it comes down to. Side channel power analysis and a bit of glitching and more importantly how you can do it. So I'm from Halifax, Nova Scotia, Canada. If you have some Canada jokes I've probably heard them but I always entertain new ones. There's a number out there. So one of the things about this talk is everything I'm doing is open source. There's going to be a bunch of hardware and it's all commercially available if you don't want to build it but all the stuff I've been working on is open hardware. So you can get the Gerbers, you can make the circuit boards yourself, whatever you want. And it's all GPL so there's no restrictions that oh you have to only use it yourself or something like that. So the main tools and there will be a slide with links at the end is on the chip whisperer.com and new way.com is a company I founded to help sell some of the commercial versions and sell trainings and stuff like that. So both of those resources have all the information here. Okay. So there's one sort of caveat I have to give at the beginning and that's that everyone with all these attacks wants the sausage. They want to just eat that and be done. And that is they want the attack. They want to put something on the desk, run a side channel attack and get the magic keys out. But what I'm taking you through is the sausage factory. So you're going to learn how it works, whether you like it or not. Because that's the only way these attacks are possible. They're not a, you know, it's not a vulnerability against some specific implementation. It's fundamental about the entire way we implement things on digital systems. So very briefly, my background is in embedded hardware design, not necessarily security. I worked for a while at a company, that makes the microcontrollers and the Arduino. Some other stuff. I've done some various consulting projects. Right now I'm doing a PhD at Dalhousie University. And I have a blog on Ophelin.com that has various projects that have been ongoing with that. More interestingly, I did a Kickstarter recently. So this was for a project called chip whisperer light, which was basically my objective to make the cheapest possible capture hardware that I could. So my talk will use this a bit, but as I said, it is open and you don't specifically have to use this hardware. This isn't about my hardware. It's about how you do these attacks in general. All right. So what is the side channel? When we say, you know, side channel analysis, this is the most fundamental thing you need to sort of start to realize. The easiest side channel I can explain, and apologies if you've seen some of these talks before, I always have the same 10 minute intro. So you can zone out for 10 minutes, but come back. So if you had something like a pin code, so you have a safe, you have something that needs to check the pin code, you might implement it like this. So we have a piece of C code. It reads in the entire pin, so it's not doing something dumb like checking after every digit. And then it checks that pin with the correct pin. But what you could see is that as soon as the pin is wrong, so you know, once it's not equal to the entered pin, it's going to exit this loop. So it's just going to return out. And this is pretty common how something is really implemented. What this means is that as soon as the pin is wrong, you see some time delay. So there's some finite time it takes for this loop to actually execute. And we can take something like there's this pin protected hard drive. This isn't an encrypted hard drive. I have to point that out. It just had a simple pin code on it and went to numerate properly without the pin in. But this was vulnerable to this sort of timing attack. So it's a real thing you'll see in a lot of products. In this example, to do a side channel timing attack on this, what we would do is we have some scope probe set up. One at the top here is just probing, there's an LED that says your password was wrong. And there's another one that's just connected to one of the buttons. Down here you can sort of see, sort of see it's in red on red. But what we're trying to see is what is the time delay between when we put in the last digit of the pin and it will start the comparison and when that LED goes on. And if there's a timing attack, we can use that time difference to really quickly discover what the pin for that hard drive is. So there's always a few complexities to this in real life. You have to consider when the microcontroller detects that button press, not when just when the user presses it. So you have to go through reverse engineer a tiny bit, how is it actually reading the buttons, stuff like that. But it's all fairly reasonable. So in this case what we see is that the correct password, by the way, is 1, 2, 3, 4, 5, 6. So very hard to guess here. And so if I put in 0, 6666, what you see is this time delay from this point here where I press that button to this point over here and this is where the bad LED goes on. And there's this, you know, whatever this time delay is, we don't care. What we do care about is that if I put in 1, 6666, so now the first digit is correct, we can look at that time delay again and you notice it's longer. So this means we now know the first digit is correct. So we can just guess one digit at a time. We don't have to guess the whole pin. And if we go through and put in 1, 2, 3, 6666, you see it's an even longer delay. So again, we compare this slide with this one. So that's sort of some of the most basic side channel attacks you might do and this is using the time delay of some output based on the input. Now this is a pretty obvious one, has been known for a long time. So people, you know, want to avoid that. The correct way to do this is something like you don't directly compare the password, so we're using a hash. But what you also might do is just not give any response when it's wrong or add some random delay. You say, well, we always wait some random amount. The problem with the second solution is you could start to look at the power difference then. And what this is, is that this is a different system that compares a password being sent over a serial bus and it gives no response for a wrong password. It just doesn't ever respond. And so it's able to do this because you send it a big password, there's some delay where it processes and then you would send it data. And it never responds if the password is right or wrong. It just starts ignoring stuff with the wrong password. So what we can see here is that, yeah, so here it's processing a mostly correct password. We see this sort of, this is the power consumption in blue and the top is the serial data. And you sort of see these chunks of data here. But the power consumption changes drastically all of a sudden up here. It sort of jumps up. So you can see that average level. And this is actually the processor spinning into an infinite loop because the wrong password was sent. And we can see if the first digit is wrong, it receives one digit and then jumps up in power consumption. So we can do the same timing style attack just based on the power consumption. So if we went back here, you know, after this return you had a while loop or something that were weighted a little bit. You'd see in the microcontroller, hey, it's just sitting there doing nothing based on the power consumption. So that's sort of a really simple power analysis attack. And to do this, all you need is a way to measure the power. That's actually really easy. You can insert a resistor in the VCC line of your device. This is the micro or whatever we're attacking. And we insert a resistor and connect the scope across that. In real life, so here's a microcontroller pin. And we can see I've lifted the pin a bit and added a resistor right here. And that's sort of a, this is a surface mount resistor. So it might look a little weird, but it's not terribly difficult with a microscope and sharp soldering iron. You can also do stuff like use magnetic field probes. So all this is the changing current will generate a changing magnetic field. So this means you just have a device like this and you physically put it on top of the chip. You don't need to solder anything to it. So it's all very practical. That's really all I'm trying to show you is that measuring the power isn't a big deal. There's a few ways to do it and you can do it on real systems. Now, it's even more interesting. So all that stuff I showed you was simple power analysis, effectively it's called. And that's just looking at oh, I can see the power changed a little bit. What's sort of a more fun attack is this differential power analysis. And this uses a really simple idea. And this is that inside the microcontroller, we have these data lines. And these data lines are just long wires and it's effectively a capacitor. And if you sort of remember vaguely from high school physics, changing the voltage on a capacitor physically takes a charge. It takes power to do that. Even though it seems like this tiny minuscule thing, it does take power. And in the microcontroller, setting a data line from zero to one, therefore takes more power than not setting the data line. If we set two data lines from zero to one, it takes even more power than if just one data line was set. So what this means is that when we look at the microcontroller power rail, we can say hey, on every clock cycle, because conveniently the digital system switches the lines on a clock cycle, how is the power consumption? If there's a bigger spike, we know more data lines were set than if there's a smaller spike, in which case one data line was set. So this is the real basic idea between differential power analysis, is we can actually figure out how many ones are going across the data bus inside the microcontroller. And this is a real thing. So this is an atmel 80 mega micro. And what I've done is measured how many ones the Hamming weight of the data on the data bus for all the different data I can push across the bus. And you can see it's this really beautiful linear graph where it goes from zero ones, it has the lowest power consumption up there and sort of up to eight. And there's a bit of a kink in it. I never actually figured it why. But in between that, it's this really nice linear fit. So this really does work. Again, this isn't just hand waving. You can do these measurements and you can see it's a real thing. So all we got so far is we can look at the device and we can see how many ones are going across the data bus. What else do we need? We need a way of using that to break the cryptographic protocols. So let me give you, this is sort of getting towards the end of the theory bit, don't worry. A really quick example of this. Let's say I have this system here. I have an XOR device and all it's doing is it's XORing whatever this input data is that I send to the system, it takes it and XORs it with this secret key. That's all it does. So a real simple encryption type operation and it goes to the output and we don't know where the output goes. Just magic, land or something. You don't care. But what we can do is we can do this power measurement at the same time. So I have a resistor inserted and I'm doing the power measurement of the XOR gate. So if we're the user and we're encrypting one byte of data, I say encrypting, just XORing, we could say, okay, well I sent in hex 8a, I'm just sending a bunch of random data to the device. If the secret key was EF, we'd get out 6, 7, so hex 8a XORed with EF is 6, 7. And this has a hamming weight of 5. So this means there's 5 ones. If you convert 6, 7 to binary and count the ones, you get the hamming weight. But remember, we don't know the secret key, we don't know the output. So really what we see is this. We see the input because we sent it to the device. But the designer assumes that that's useless because you just know what you sent it. You don't know what the output was. We can also observe what that hamming weight value is. So what the output, how many ones were in the output. It's then a pretty simple system where we do this guess and check. So we say, well, if the secret key was 00, we would have got an output of 88 which would have had two ones. And we do that for all the inputs. And we say, well, that doesn't match our hypothesis. So if it was 01, we'd get this. And that doesn't matter. The hypothesis doesn't match what we measured still. Eventually we get up to the point where we say, hey, what if the secret key was EF? And now each of those hypothetical outputs actually match what we observed. And so we can say, yes, it's probable that the secret key was EF. So in Y-Epict XOR, that's sort of how differential power analysis works. How we apply it. So let's break a real algorithm, AES128. At the input of AES128, conveniently, you know, it's 16 bytes wide. But we can break it as I'll show shortly in just a few seconds, really. And why this is possible is because it applies the algorithm one byte at a time. So it takes one byte of the key or the subkey. It XORs it with one byte of the input plain text, does a bitwise XOR and passes it through what's basically a lookup table, the S-Box as it's called. And then it goes on elsewhere in the algorithm. It goes on for several rounds. We just don't care about that. All we care about is that beginning part. Because what we're able to do is do this guess and check operation with the idea of attacking whatever the output of that S-Box is. So the one thing I really want to stress here is remember all this guess and check is doing is it's asking what is the secret key that the algorithm was running with. So to use this, you have to have the crypto operation running with the secret key you want to recover. So if you had an encrypted hard drive sitting on the table, that's no good to you. Because if it's not running with that key, if it's not actively encrypting or decrypting, you can't do this side channel analysis. And what I'll show you is two examples where you can do side channel analysis. The device does have the key. It is able to run with it. All right. So before I show you the types of devices it can work with, let me show you what a side channel analysis looks like. So I have a device up here and it's an AVR microcontroller. It's programmed with AES 128. This works with 256 to it. Doesn't matter. And I'm sending data to it. It's encrypting it and measuring the power. So this is what these spikes are. If I change the data, so I can monitor the input and output data here. So you can see it's sending random data and get something back. You don't really need to see it. What's interesting is, for example, if I send it the same input data, so it's fixed, you'll notice that the power consumption is no longer varying as much. So I'm still doing the encryptions. But you see the power consumption is very similar. If I change it back to random, you see the power consumption jumping all over. So this is showing you there is data dependency. It does matter what's being encrypted. To do an actual attack, I would just do this again where I send a bunch of random data, so like 50 random packets to the device, record the power consumption, and then do that guess and check operation. So let's just save this here. And I've reopened that same project. So everything I'm showing you, this is the chip whisperer software. Again, it's written in Python and open source and everything. So you can see these are the traces I captured. And what I'm going to do is I'm going to ask it to perform that guess and check and tell me for every byte what it thinks the correct encryption key is. I've also told it what the correct key is just so it can highlight in red. And you'll see almost immediately it recovers the entire encryption key. So that's by sending like 30 packets to this device doing the side channel analysis, it recovers the full AES 128 key. And that's using, I believe it was AVR CryptoLib, so it's an open source crypto library. It doesn't really matter which crypto library I use. If there's no protection against this stuff, it's going to be vulnerable. And you might also ask, well, how did I know where that specific operation occurred? And it actually doesn't matter because I just said you sent some device data to the device, you encrypted it, you responded. I just took a whole section of that power consumption. And I can ask it, for example, where in time, and these are these big red spikes, was there a high correlation? Where in time did you see that data dependency? And we can see that as I turn on each byte, so I'm asking it for byte one, byte two, byte three, it's marching forward in time. And this is because it's an 8-bit micro, there's a big for loop in there doing the S-Box, the key application in the S-Box lookup. So that's very quickly how a side channel analysis works and how you use them against an unprotected AES implementation. All right, so now let's look at some real applications of it. Number one, an AES 256 boot loader. So this boot loader is loosely based on a whole bunch of app notes. If you look on like App Mail and who else to have NXP maybe, they have them secure. If you want to make an AES 256 boot loader, here's some example of what you can do. And very briefly how it works is you have the updated micro firmware file, you split it up into a bunch of chunks like that, you prepend, so they add what they call a signature, they add what they call a signature operation here, so there's these four bytes and it's just a constant four bytes. The idea being that they encrypt that whole block with the signature, when you decrypt it, you verify you get the expected four bytes. After the encryption, they just add a CRC and stuff like that. So pretty simple after the encryption. Conveniently on the microcontroller side, if you send it an encrypted file, it's going to try to decrypt it. And that's all we need for a side channel attack. So on the micro side of it, what we'll do is we'll look and we'll say, okay, well, here's the cipher text, you know, block zero, it came in, it gets decrypted, it's in CBC mode, so after the decryption, they XOR it with the IV and you get the first byte of the plain text right here. So here's the IV, which is another thing we can discover through the side channel analysis attack. But we don't actually need it. The important thing to realize is we don't necessarily need it for the attack itself because the cipher text is decrypted directly. And because it's AES 256, there's two rounds we attack. It's a 32 byte key, but it's not fundamentally any different really. The only complication, so we'll attack one round, get the first 15 bytes of the key, attack the second round, get the next 16 bytes of the key, sorry. And then continue with the attack as before. The only sort of tricky business is you do get into stuff like the attack might have a bit of random jitter in it. So this is really easy to deal with in the software. We can see here, for example, this is the first decryption round. So this is the first decrypt round. And we see it becomes unsynchronized with the second round. And that's because there's some time dependent operations. They actually shouldn't be time dependent, but they screwed up in a few ways here. And so we just resynchronized. So this is the second operation, the second round here. And it's the same traces as the previous one. I've just resynchronized it to help with the alignment. So it's not a big deal to do this attack on a real device. And what we see is the success rate. So the success rate being how often was able to get the key. And the first round decryption key I get in about 60 traces. So I just sent it 60 packets. And the second part of the key, so the 16 next bytes, it took about 120 packets. So we're talking a boot loader on a micro. And we can send it this data really quickly. This is like five minutes of data that you had to capture to break the boot loader. And at this point, we have the full decryption key so we could decrypt, you know, if we had an updated firmware file, we could just decrypt it because maybe they're trying to hide, you know, bugs in their code. They don't want us to reverse engineer. Stuff like that. Or you could actually send it a new firmware file and it's going to decrypt it and use that file. So to do that last part, you would also need to determine what the initialization vector is. And you can do this in a similar way through side channel. I talk a bit about that in the paper I link here. And there's sort of a tutorial that steps you through everything. All these slides, by the way, if you go to oflin.com, they're posted there. So you don't have to write down a million URLs. All right. So that's the first example. Another example is 802.15.4 node. So I triple E 802.15.4, this is used by a whole bunch of wireless protocols. I sort of listed a bunch of them here. So like Zigbee is probably the one you might have heard of the most. But there's, you know, Nest uses it as part of their communications. DigiMesh, Atmel has their own stack. So there's several things using 802.15.4. And what makes this interesting is that a lot of 802.15.4 nodes are really, really cheap. You know, it's sort of a competitor to Bluetooth low energy type stuff. So this node out here might just be a light switch or an outdoor light. Something the attacker can easily get access to. And a lot of the time when you have these attacks, people say, oh, well, you know, we don't care about that end node if they break it, whatever. But the interesting thing is that if you ‑‑ interesting ringtone selections here. If you have the coordinator, it has an ethernet device as well as an 802.15.4 side to it. So if you can send messages back to the coordinator, you can start to fuzz that coordinator's 802.15.4 interface. These messages will appear to be, you know, signed correctly. So the coordinator will process them. If you did not have the encryption key on this link, so 802.15.4 has AES 128 encryption, it's just going to throw them away right away. So what we want to do is recover that key so we're able to send messages to the coordinator as if we were that node for whatever reason, be it fuzzing or something else you want to do. So what makes us able to do this is that ‑‑ I guess I'll talk about this first. The 802.15.4 wireless stack. So all of these protocols have a lower layer running this 802.15.4 wireless stack. And it defines how you deal with messages, everything like that. So if you send it a message that claims to be encrypted, it's going to do some basic validation of the headers and security options. And it's then going to check a few things. It's going to check what they call the received frame counter is greater than the last stored frame counter. So that's just to avoid replay attacks. It looks up a secret key so it says what secret key should I be using to talk to whatever this device is. So you have to have set up out of bound. When you talk to device XYZ, here's the secret key in use. The standard doesn't specify how you do that. So once it loads whatever the key is in use on that link, it decrypts the payload and finally validates the message authentication code. If present, it's optional but almost all of the actual standard use it. And finally it stores the new frame counter. So obviously they have to do this last storing the new one to prevent you from just sending an unauthenticated message to a device and with a really high frame counter such that it will no longer listen to any lower frame counters. So any sort of really easy denial service attack. So what this means to us is that remember the conditions we needed for a side channel attack? We need to run the crypto and it needs to be running with the key in use. So in this case we have that. We can decrypt the payload or it will try to decrypt the payload and it's going to try using the key of interest. So to test this I have a 802.15.4 development board. So on this I just loaded a commercial 802.15.4 stack. And this probe here is doing the power measurement. So there's a paper with all the details I think I link up here. If you want to see more details on how this was set up it's all in that paper. So there's a resistor inserted into one of the power pins, this differential probe which reduces noise so nothing too crazy. And then this hardware in the background is the analog capture. So this is part of the chip whisper project that I'm talking about. And again it's all open source hardware. But you don't need that specifically. The only sort of caveat here is that it's not decrypting whatever you send it, it doesn't just fire into AES. It uses a form of counter mode in AES. So what you have is the 16 byte input to AES. It has the source long address which is an 8 byte field and you have to specify that correctly. So you can spoof it easily but you have to pretend you're a node that this wireless node was previously talking to. You have the frame counter which is something you control and then the security level of the AES counter or you don't control so the AES counter increments slowly. So there's a few tricks within this to get it to work as in the previous attacks. Basically you do math is the short form of it. But in reality what we're doing is we have to push it into more rounds of the AES algorithm so we're no longer just attacking that one point. We have to attack multiple points. And there's details linked in that paper. But at the end of the day what you get is that if I take that hardware device and it has a hardware AES engine inside it, not a software AES implementation, we can see stuff like after sending it about 10,000 or so packets we can almost completely recover the AES key. So I'm using a metric here called the guessing entropy which is simply when the entropy is zero, I know the key perfectly. If the entropy is two, I needed to do two wrong byte guesses. So it's a fairly straightforward metric and you can really see that after about that 10,000 traces I was able to recover the key. And again this is a real AES 802.15.4 stack on a real device on a real dev board. There's no sort of tricks to make it easier here. So that's very briefly how the side channel power analysis works and how you can perform it against real devices. The other thing I want to talk about is glitching and in particular power glitching. So glitching is just where we make a device do something, you know, unintended is the generic term. Really what we're looking at is when you look at the code, there's all sorts of lines like this. So this is, you know, logging into Linux. At some point that says hey, if your user ID is not equal to zero, check the various authentication methods. If it is equal to zero, just skip out. And so with glitching, what we want to do is we want to actually screw up that comparison. We want to make the hardware device perform the wrong operation there. And you can do the same thing. So on an Android device, you know, on the lock screen, there's always some point where it says hey, did this operation pass or not? And with glitching, the objective is we can actually cause the wrong code paths to be executed. So it's a way to completely skip over security in the device. So to sort of make an easier demo, and by easier I mean something you can replicate, what I have here is I have a for loop and there's basically two, four loops that should increment this value. And it prints what the results, how many times it ran through each loop and how many times this value got incremented in total. So if it works correctly, it should have incremented it 25 million times. And I did this on a Raspberry Pi, so I'm now looking at, you know, larger devices, not just an 8-bit microcontroller. And on this Raspberry Pi, all I've done is I have a wire here and where this wire connects to is one of the capacitors. So you can see I've just soldered it to the positive point of the capacitor. And it's this point right here. And all I'm wiring this to is what's called a MOSFET. So it's basically an electronic switch. And it's going to short these two points together. And I have some input that says how long I short this for. And so that's the MOSFET I'm using. So the newer design I have, this chip whisper light has these glitching tools built in. But again, you can just build your own like this if you want. And all you do is when you short that for a very specific amount of time, when you look at the power rail, it generates these massive spikes. So it shorts the power down to zero. When it releases it, there's these huge voltage transients. And these voltage transients cause undesired behavior. So let's take a look at what that looks like. So this demo is sort of trying to show the setup. I'm just going to skip to the interesting part. So there's the same Raspberry Pi. It's the same board I was showing you before. It has, I'm pinging the board. You can see the reply from. So this is just to show that it's running at the time. And I have that wire setup that I had before. And the glitching board is again just shorting the output. And what I'm going to do is run the test program here. And you can see the correct output is that 25 million, 5,000, 5,000. So it ran through both loops 5,000 times, incremented the final value 25 million times. This is the 1.2 volt rail. This is the core voltage for the Raspberry Pi. And when we hit trigger button, it's just generating a glitch. If you want to generate a glitch, you could make an Arduino code to do this. You can use a signal generator. Anything that can set that MOSFET, activate it for the correct period of time. And what you might see, I think I run it again here, is that that count value when I hit trigger becomes incorrect. So I don't know if it's too visible. But you can see this count value here. It skipped out of that loop at one point. So the glitch, it didn't crash anything else. It's still pinging the board, everything like that. It just caused some incorrect code path to be executed. So that's the interesting thing you can do about glitching is that you're causing entire incorrect code paths to occur. And then you can use that for bypassing various security measures. Another example, an Android smart phone. So I've done the exact same thing. I've wired a pin to one of the power pins on the system on a chip on it. I think I have a close up here. There you go. So you can see it's this Qualcomm chip, whatever it is. And I've done the same deal. It just goes to one of the core voltage or MPU voltage, something like that. So it takes a bit of experimentation to figure out what those voltages are. But once you do that, it's very possible. And the same sort of set up here. I have the MOSFET. As a note, the program, all it's doing, it's doing that calculation and then it displays it on screen. So this was like the first Android app I ever wrote. So it's very high quality. And I left the hello world in because I didn't want to risk screwing it up. But what you can see is one of those calculations was wrong. And I can do it again. So I'll just hit start. It just does that calculation five times in a row and then displays it. So when I hit start, insert the trigger, you'll see a different one is wrong. So I'm not triggering it reliably right here. At this point, I'm just confirming the device is vulnerable and experimenting with the required parameters. And sometimes it crashes. I'm running this on the real device. So it might glitch the wrong code or something like that. All right. So that's sort of the simple way to do power glitching. Power glitching is really good. You might have also heard about clock glitching, which is where we insert transients into a clock. The problem with clock glitching, you cannot easily apply it on the Raspberry Pi or the Android. They use an internal clock generator effectively. So that's why this method is really fun because you don't have to worry about that. You're using this power glitching and you can also do it against the small 8-bit micro. So that's ‑‑ I don't have a movie of that, but there's a tutorial that runs you through it. All right. So one of the first things people always ask is, you know, well, that's great, but how do you trigger it? Because clearly all of this is dependent on me knowing when it's doing some operation. And there's a few ways that we can do this in real life. One of them is I can actually match ‑‑ this is the analog power data ‑‑ I can match patterns in the power data. And for example, if I switch back to the capture device, what you'll find is there's certain sections of the code, you know, when it's jumping to the encryption operation, that it's ‑‑ let me just run it again ‑‑ that it has some very well‑defined sort of outline of the power trace and it doesn't vary a whole lot with different data. So I'm just going to change this. So as I hit sort of capture one, there's this section in here and you'll notice the data doesn't jump around, you know, for like the second half, there's a little section in there. So you can actually trigger based on a pattern in the analog data. So that's something that some of the chip whisper hardware variants, not the light, but other ones can actually perform. The other thing you can easily do is triggering on the digital data. So when I send it data, I say, you know, here's the request to encrypt trigger when I send that request. For the side‑channel analysis, you can re‑synchronize afterwards. You don't have to have everything perfectly synchronized. We can do that as a post‑processing. It's not a big deal. All right. So that's sort of a super quick, you know, run‑through of side‑channel analysis and glitching. I really want to give you that quick overview to sort of convince you it's fun and it's something you can do. And if you want to do it yourself, some of the projects I've worked on, so this was the original chip whisperer and it's an FPGA‑based board. So there's an FPGA‑spur ‑‑ Spartan‑6 FPGA here, analog capture board, and then a base board with power and stuff. And you can set that up, you know, you can connect to a target device. So this is a target and you have your computer to do the power measurements and the attack and everything like that. You can also use ‑‑ this was the second project I did. It basically tried to take this and make it much smaller. So we have ‑‑ there's still an FPGA here, there's still the analog capture hardware and there's a high‑speed USB interface. There's also a target device. So this device is what you program if you say I want to play with AES. Something like that. You program AES or DES or whatever you want into that X‑Meg device. If you want to target a real target, your own thing, you can break it away here and wire it into your own target. So what I have on stage, I won't move it because it's all wired in, is I have that connected to another board called the not‑dweeno, which is just an AAPNL AVR base board. So what we'll do here, as an interest, these ‑‑ as I said, I did a kick‑starter, they're being sold at the hardware hacking village and I have one I'm just going to throw into the crowd here. So ‑‑ interest? Which way? This way? Okay. It's open box, so there's nothing in it. So come up here. What? Oh. Because it's open box, it didn't fly very well. I'm sorry. All right. So that's one way to get it. There's also a signed one that's being auctioned off for the EFF and that's also done at the hardware hacking village or not hardware hacking, hackers warehouse in the vendor area. All right. So all of this works with this chip whisper software I was using and it's all open source written in Python so you can hack away at it. And there's a ton of documentation. That's one thing people are always surprised with for some reason, is that I spent a lot of time trying to make good documentation so it goes through tutorials of how to set up everything like that and play with your own tools. You really don't need ‑‑ don't think this is like oh, this software only works with this one variant of the hardware. You know, I've built my own using some other FPGA boards before and that's documented. You can build your own target device so this is an at mail AVR target you can play around with and connect it to a scope. So there's built‑in drivers for Pico scope. You can add other scopes. Any connected device will work just fine. Yes, that's sort of the overview of what the heck side channel analysis is, how it works, how you perform it, what glitching is and what tools can do it. So I think I actually have a few minutes. If there's any questions, I can take some now. Is there ‑‑ is there mics for the questions or ‑‑ all right. Do you want to shout and all? Yes, the question is how do you protect? The best answer is I don't know exactly. Most of my work has been on the attack. So very briefly, there's two major ways. One is to use hardware that doesn't have these leaks. And specialized chips or smart card chips are designed not to do this leakage. So you can do stuff very simply like have differential lines. One line goes high, another goes low. And that reduces how much leakage you have. Pardon? Yeah, there's cost on power and time. And the other way you can do it in software as well, there's some various ‑‑ there's a whole bunch of ‑‑ this is a huge field of research. You can mask some of the data, add random data at the input, try to remove that data at the output of the algorithm. All of these, though, as you say, it's a trade‑off. You may not care to some degree that it's vulnerable, but you always have to remember that, hey, this is a real threat. So when you're using an AES boot loader, don't just use the same key everywhere. It's like, there's AES. It's invincible type thing. So that's sort of what ‑‑ this whole project is about showing people how these attacks work and how realistic they are. Other ‑‑ so the question is are discrete TPM secure against these attacks? So those would typically ‑‑ I don't want to say there always will be ‑‑ they'll be designed to be a lot more resistant to it. So they'll go out of their way to use the specialized hardware. And they almost always do the testing, you know. The standards involve, hey, you should have some side‑channel resistance. So the answer should be yes. So the question is if it works with out of stand‑alone scope. So this ‑‑ the board I made is designed just ‑‑ it has everything on it. So you don't need a scope. It has the analog capture hardware as part of the board. So the idea was to get away from needing any sort of scope. I think there's another question there, sorry. What are examples of the real‑all of the device that you use in the extension? So I'm from Canada and this means I have to cross the border when I come here. So I try to avoid doing stuff. But I'll discover people are mad at when I cross the border. So I don't really talk a lot about any commercial stuff I've done. Besides, I mean, anything public should look that at now, you know, device. The X‑Mega has a hardware AES engine. It's been published to be breakable. There's a number of products that people have published these results on. The key lock, so a key fob for car was a popular one. The side‑channel analysis was able to break it. So there has been a number of real products and all the smart card hacking stuff from pay TV. Some of that was side‑channel. Not that much of it actually. Questions, yeah? To some level, it requires physical access. So what I've shown is using a resistive shunt. So you need to be able to solder to it. You can use that EM probe. So if you have close access, you can do it pretty easily as well, which is to say, you know, you can put a probe within 10 millimeters. There is work done on using emissions at a distance. So some companies have demos where they have ‑‑ cryptography research in particular has a demo. They put a cell phone on a table. They monitor the emissions of the cell phone using a radio receiver 20 feet away and are able to do this type of attack on the device. So it's easier if you have physical access. It may or may not actually be required. All right. Well, I think that's all. Thank you everyone for coming out and hope you enjoyed it. Thank you.
 So this is don't whisper my chips and I'm going to be talking about various methods of  hardware hacking is what it comes down to. Side channel power analysis and a bit of glitching  and more importantly how you can do it. So I'm from Halifax, Nova Scotia, Canada. If you have  some Canada jokes I've probably heard them but I always entertain new ones. There's a number  out there. So one of the things about this talk is everything I'm doing is open source. There's  going to be a bunch of hardware and it's all commercially available if you don't want to  build it but all the stuff I've been working on is open hardware. So you can get the Gerbers,  you can make the circuit boards yourself, whatever you want. And it's all GPL so there's no  restrictions that oh you have to only use it yourself or something like that. So the main  tools and there will be a slide with links at the end is on the chip whisperer.com and new  way.com is a company I founded to help sell some of the commercial versions and sell trainings  and stuff like that. So both of those resources have all the information here. Okay. So there's  one sort of caveat I have to give at the beginning and that's that everyone with all these  attacks wants the sausage. They want to just eat that and be done. And that is they want the  attack. They want to put something on the desk, run a side channel attack and get the magic  keys out. But what I'm taking you through is the sausage factory. So you're going to learn  how it works, whether you like it or not. Because that's the only way these attacks are  possible. They're not a, you know, it's not a vulnerability against some specific  implementation. It's fundamental about the entire way we implement things on digital  systems. So very briefly, my background is in embedded hardware design, not necessarily  security. I worked for a while at a company, that makes the microcontrollers and the  Arduino. Some other stuff. I've done some various consulting projects. Right now I'm doing a  PhD at Dalhousie University. And I have a blog on Ophelin.com that has various projects that  have been ongoing with that. More interestingly, I did a Kickstarter recently. So this was for  a project called chip whisperer light, which was basically my objective to make the cheapest  possible capture hardware that I could. So my talk will use this a bit, but as I said,  it is open and you don't specifically have to use this hardware. This isn't about my  hardware. It's about how you do these attacks in general. All right. So what is the side  channel? When we say, you know, side channel analysis, this is the most fundamental thing  you need to sort of start to realize. The easiest side channel I can explain, and apologies  if you've seen some of these talks before, I always have the same 10 minute intro. So  you can zone out for 10 minutes, but come back. So if you had something like a pin code,  so you have a safe, you have something that needs to check the pin code, you might implement  it like this. So we have a piece of C code. It reads in the entire pin, so it's not doing  something dumb like checking after every digit. And then it checks that pin with the correct  pin. But what you could see is that as soon as the pin is wrong, so you know, once it's  not equal to the entered pin, it's going to exit this loop. So it's just going to return  out. And this is pretty common how something is really implemented. What this means is  that as soon as the pin is wrong, you see some time delay. So there's some finite time  it takes for this loop to actually execute. And we can take something like there's this  pin protected hard drive. This isn't an encrypted hard drive. I have to point that out. It just  had a simple pin code on it and went to numerate properly without the pin in. But this was  vulnerable to this sort of timing attack. So it's a real thing you'll see in a lot of  products. In this example, to do a side channel timing attack on this, what we would do is  we have some scope probe set up. One at the top here is just probing, there's an LED that  says your password was wrong. And there's another one that's just connected to one of  the buttons. Down here you can sort of see, sort of see it's in red on red. But what we're  trying to see is what is the time delay between when we put in the last digit of the pin and  it will start the comparison and when that LED goes on. And if there's a timing attack,  we can use that time difference to really quickly discover what the pin for that hard  drive is. So there's always a few complexities to this in real life. You have to consider  when the microcontroller detects that button press, not when just when the user presses  it. So you have to go through reverse engineer a tiny bit, how is it actually reading the  buttons, stuff like that. But it's all fairly reasonable. So in this case what we see is  that the correct password, by the way, is 1, 2, 3, 4, 5, 6. So very hard to guess here.  And so if I put in 0, 6666, what you see is this time delay from this point here where  I press that button to this point over here and this is where the bad LED goes on. And  there's this, you know, whatever this time delay is, we don't care. What we do care about  is that if I put in 1, 6666, so now the first digit is correct, we can look at that time  delay again and you notice it's longer. So this means we now know the first digit is  correct. So we can just guess one digit at a time. We don't have to guess the whole pin.  And if we go through and put in 1, 2, 3, 6666, you see it's an even longer delay. So again,  we compare this slide with this one. So that's sort of some of the most basic side channel  attacks you might do and this is using the time delay of some output based on the input.  Now this is a pretty obvious one, has been known for a long time. So people, you know,  want to avoid that. The correct way to do this is something like you don't directly  compare the password, so we're using a hash. But what you also might do is just not give  any response when it's wrong or add some random delay. You say, well, we always wait some  random amount. The problem with the second solution is you could start to look at the  power difference then. And what this is, is that this is a different system that compares  a password being sent over a serial bus and it gives no response for a wrong password.  It just doesn't ever respond. And so it's able to do this because you send it a big password,  there's some delay where it processes and then you would send it data. And it never  responds if the password is right or wrong. It just starts ignoring stuff with the wrong  password. So what we can see here is that, yeah, so here it's processing a mostly correct  password. We see this sort of, this is the power consumption in blue and the top is the  serial data. And you sort of see these chunks of data here. But the power consumption changes  drastically all of a sudden up here. It sort of jumps up. So you can see that average level.  And this is actually the processor spinning into an infinite loop because the wrong password  was sent. And we can see if the first digit is wrong, it receives one digit and then jumps  up in power consumption. So we can do the same timing style attack just based on the  power consumption. So if we went back here, you know, after this return you had a while  loop or something that were weighted a little bit. You'd see in the microcontroller, hey,  it's just sitting there doing nothing based on the power consumption. So that's sort of  a really simple power analysis attack. And to do this, all you need is a way to measure  the power. That's actually really easy. You can insert a resistor in the VCC line of your  device. This is the micro or whatever we're attacking. And we insert a resistor and connect  the scope across that. In real life, so here's a microcontroller pin. And we can see I've  lifted the pin a bit and added a resistor right here. And that's sort of a, this is a  surface mount resistor. So it might look a little weird, but it's not terribly difficult  with a microscope and sharp soldering iron. You can also do stuff like use magnetic field  probes. So all this is the changing current will generate a changing magnetic field. So  this means you just have a device like this and you physically put it on top of the chip.  You don't need to solder anything to it. So it's all very practical. That's really all  I'm trying to show you is that measuring the power isn't a big deal. There's a few ways  to do it and you can do it on real systems. Now, it's even more interesting. So all that  stuff I showed you was simple power analysis, effectively it's called. And that's just looking  at oh, I can see the power changed a little bit. What's sort of a more fun attack is this  differential power analysis. And this uses a really simple idea. And this is that inside  the microcontroller, we have these data lines. And these data lines are just long wires and  it's effectively a capacitor. And if you sort of remember vaguely from high school physics,  changing the voltage on a capacitor physically takes a charge. It takes power to do that.  Even though it seems like this tiny minuscule thing, it does take power. And in the microcontroller,  setting a data line from zero to one, therefore takes more power than not setting the data  line. If we set two data lines from zero to one, it takes even more power than if just  one data line was set. So what this means is that when we look at the microcontroller  power rail, we can say hey, on every clock cycle, because conveniently the digital system  switches the lines on a clock cycle, how is the power consumption? If there's a bigger  spike, we know more data lines were set than if there's a smaller spike, in which case  one data line was set. So this is the real basic idea between differential power analysis,  is we can actually figure out how many ones are going across the data bus inside the microcontroller.  And this is a real thing. So this is an atmel 80 mega micro. And what I've done is measured  how many ones the Hamming weight of the data on the data bus for all the different data  I can push across the bus. And you can see it's this really beautiful linear graph where  it goes from zero ones, it has the lowest power consumption up there and sort of up to eight.  And there's a bit of a kink in it. I never actually figured it why. But in between that,  it's this really nice linear fit. So this really does work. Again, this isn't just hand  waving. You can do these measurements and you can see it's a real thing. So all we got so far  is we can look at the device and we can see how many ones are going across the data bus. What  else do we need? We need a way of using that to break the cryptographic protocols. So let me  give you, this is sort of getting towards the end of the theory bit, don't worry. A really quick  example of this. Let's say I have this system here. I have an XOR device and all it's doing is  it's XORing whatever this input data is that I send to the system, it takes it and XORs it with  this secret key. That's all it does. So a real simple encryption type operation and it goes to  the output and we don't know where the output goes. Just magic, land or something. You don't  care. But what we can do is we can do this power measurement at the same time. So I have a  resistor inserted and I'm doing the power measurement of the XOR gate. So if we're the user and  we're encrypting one byte of data, I say encrypting, just XORing, we could say, okay, well I  sent in hex 8a, I'm just sending a bunch of random data to the device. If the secret key was  EF, we'd get out 6, 7, so hex 8a XORed with EF is 6, 7. And this has a hamming weight of 5. So  this means there's 5 ones. If you convert 6, 7 to binary and count the ones, you get the hamming  weight. But remember, we don't know the secret key, we don't know the output. So really what we  see is this. We see the input because we sent it to the device. But the designer assumes that  that's useless because you just know what you sent it. You don't know what the output was. We  can also observe what that hamming weight value is. So what the output, how many ones were in  the output. It's then a pretty simple system where we do this guess and check. So we say, well,  if the secret key was 00, we would have got an output of 88 which would have had two ones. And  we do that for all the inputs. And we say, well, that doesn't match our hypothesis. So if it was  01, we'd get this. And that doesn't matter. The hypothesis doesn't match what we measured  still. Eventually we get up to the point where we say, hey, what if the secret key was EF? And  now each of those hypothetical outputs actually match what we observed. And so we can say, yes,  it's probable that the secret key was EF. So in Y-Epict XOR, that's sort of how differential  power analysis works. How we apply it. So let's break a real algorithm, AES128. At the input of  AES128, conveniently, you know, it's 16 bytes wide. But we can break it as I'll show shortly in  just a few seconds, really. And why this is possible is because it applies the algorithm one  byte at a time. So it takes one byte of the key or the subkey. It XORs it with one byte of the  input plain text, does a bitwise XOR and passes it through what's basically a lookup table, the  S-Box as it's called. And then it goes on elsewhere in the algorithm. It goes on for several  rounds. We just don't care about that. All we care about is that beginning part. Because what  we're able to do is do this guess and check operation with the idea of attacking whatever the  output of that S-Box is. So the one thing I really want to stress here is remember all this  guess and check is doing is it's asking what is the secret key that the algorithm was running  with. So to use this, you have to have the crypto operation running with the secret key you  want to recover. So if you had an encrypted hard drive sitting on the table, that's no good to  you. Because if it's not running with that key, if it's not actively encrypting or decrypting, you  can't do this side channel analysis. And what I'll show you is two examples where you can do  side channel analysis. The device does have the key. It is able to run with it. All right. So  before I show you the types of devices it can work with, let me show you what a side channel  analysis looks like. So I have a device up here and it's an AVR microcontroller. It's  programmed with AES 128. This works with 256 to it. Doesn't matter. And I'm sending data to it.  It's encrypting it and measuring the power. So this is what these spikes are. If I change the  data, so I can monitor the input and output data here. So you can see it's sending random data and  get something back. You don't really need to see it. What's interesting is, for example, if I send  it the same input data, so it's fixed, you'll notice that the power consumption is no longer  varying as much. So I'm still doing the encryptions. But you see the power consumption is  very similar. If I change it back to random, you see the power consumption jumping all over. So  this is showing you there is data dependency. It does matter what's being encrypted. To do an  actual attack, I would just do this again where I send a bunch of random data, so like 50 random  packets to the device, record the power consumption, and then do that guess and check  operation. So let's just save this here. And I've reopened that same project. So everything I'm  showing you, this is the chip whisperer software. Again, it's written in Python and open source  and everything. So you can see these are the traces I captured. And what I'm going to do is I'm  going to ask it to perform that guess and check and tell me for every byte what it thinks the  correct encryption key is. I've also told it what the correct key is just so it can highlight  in red. And you'll see almost immediately it recovers the entire encryption key. So that's by  sending like 30 packets to this device doing the side channel analysis, it recovers the full AES 128  key. And that's using, I believe it was AVR CryptoLib, so it's an open source crypto library. It  doesn't really matter which crypto library I use. If there's no protection against this stuff,  it's going to be vulnerable. And you might also ask, well, how did I know where that specific  operation occurred? And it actually doesn't matter because I just said you sent some device data to  the device, you encrypted it, you responded. I just took a whole section of that power  consumption. And I can ask it, for example, where in time, and these are these big red spikes, was  there a high correlation? Where in time did you see that data dependency? And we can see that as  I turn on each byte, so I'm asking it for byte one, byte two, byte three, it's marching forward in  time. And this is because it's an 8-bit micro, there's a big for loop in there doing the S-Box,  the key application in the S-Box lookup. So that's very quickly how a side channel analysis  works and how you use them against an unprotected AES implementation. All right, so now let's look  at some real applications of it. Number one, an AES 256 boot loader. So this boot loader is  loosely based on a whole bunch of app notes. If you look on like App Mail and who else to have  NXP maybe, they have them secure. If you want to make an AES 256 boot loader, here's some example  of what you can do. And very briefly how it works is you have the updated micro firmware file,  you split it up into a bunch of chunks like that, you prepend, so they add what they call a  signature, they add what they call a signature operation here, so there's these four bytes and  it's just a constant four bytes. The idea being that they encrypt that whole block with the  signature, when you decrypt it, you verify you get the expected four bytes. After the encryption,  they just add a CRC and stuff like that. So pretty simple after the encryption. Conveniently on  the microcontroller side, if you send it an encrypted file, it's going to try to decrypt it.  And that's all we need for a side channel attack. So on the micro side of it, what we'll do is  we'll look and we'll say, okay, well, here's the cipher text, you know, block zero, it came in,  it gets decrypted, it's in CBC mode, so after the decryption, they XOR it with the IV and you  get the first byte of the plain text right here. So here's the IV, which is another thing we can  discover through the side channel analysis attack. But we don't actually need it. The important  thing to realize is we don't necessarily need it for the attack itself because the cipher text is  decrypted directly. And because it's AES 256, there's two rounds we attack. It's a 32 byte key, but  it's not fundamentally any different really. The only complication, so we'll attack one round, get  the first 15 bytes of the key, attack the second round, get the next 16 bytes of the key, sorry.  And then continue with the attack as before. The only sort of tricky business is you do get  into stuff like the attack might have a bit of random jitter in it. So this is really easy to  deal with in the software. We can see here, for example, this is the first decryption round. So  this is the first decrypt round. And we see it becomes unsynchronized with the second round.  And that's because there's some time dependent operations. They actually shouldn't be time  dependent, but they screwed up in a few ways here. And so we just resynchronized. So this is the  second operation, the second round here. And it's the same traces as the previous one. I've  just resynchronized it to help with the alignment. So it's not a big deal to do this attack on a  real device. And what we see is the success rate. So the success rate being how often was able to  get the key. And the first round decryption key I get in about 60 traces. So I just sent it 60  packets. And the second part of the key, so the 16 next bytes, it took about 120 packets. So  we're talking a boot loader on a micro. And we can send it this data really quickly. This is like  five minutes of data that you had to capture to break the boot loader. And at this point, we have  the full decryption key so we could decrypt, you know, if we had an updated firmware file, we  could just decrypt it because maybe they're trying to hide, you know, bugs in their code. They  don't want us to reverse engineer. Stuff like that. Or you could actually send it a new  firmware file and it's going to decrypt it and use that file. So to do that last part, you would  also need to determine what the initialization vector is. And you can do this in a similar way  through side channel. I talk a bit about that in the paper I link here. And there's sort of a  tutorial that steps you through everything. All these slides, by the way, if you go to  oflin.com, they're posted there. So you don't have to write down a million URLs. All right. So  that's the first example. Another example is 802.15.4 node. So I triple E 802.15.4, this is  used by a whole bunch of wireless protocols. I sort of listed a bunch of them here. So like  Zigbee is probably the one you might have heard of the most. But there's, you know, Nest uses it  as part of their communications. DigiMesh, Atmel has their own stack. So there's several things  using 802.15.4. And what makes this interesting is that a lot of 802.15.4 nodes are really, really  cheap. You know, it's sort of a competitor to Bluetooth low energy type stuff. So this node  out here might just be a light switch or an outdoor light. Something the attacker can easily get  access to. And a lot of the time when you have these attacks, people say, oh, well, you know, we  don't care about that end node if they break it, whatever. But the interesting thing is that if  you ‑‑ interesting ringtone selections here. If you have the coordinator, it has an ethernet  device as well as an 802.15.4 side to it. So if you can send messages back to the coordinator, you  can start to fuzz that coordinator's 802.15.4 interface. These messages will appear to be, you  know, signed correctly. So the coordinator will process them. If you did not have the encryption  key on this link, so 802.15.4 has AES 128 encryption, it's just going to throw them away right  away. So what we want to do is recover that key so we're able to send messages to the coordinator  as if we were that node for whatever reason, be it fuzzing or something else you want to do. So  what makes us able to do this is that ‑‑ I guess I'll talk about this first. The 802.15.4  wireless stack. So all of these protocols have a lower layer running this 802.15.4 wireless  stack. And it defines how you deal with messages, everything like that. So if you send it a  message that claims to be encrypted, it's going to do some basic validation of the headers and  security options. And it's then going to check a few things. It's going to check what they call  the received frame counter is greater than the last stored frame counter. So that's just to avoid  replay attacks. It looks up a secret key so it says what secret key should I be using to talk to  whatever this device is. So you have to have set up out of bound. When you talk to device XYZ,  here's the secret key in use. The standard doesn't specify how you do that. So once it loads  whatever the key is in use on that link, it decrypts the payload and finally validates the  message authentication code. If present, it's optional but almost all of the actual standard  use it. And finally it stores the new frame counter. So obviously they have to do this last  storing the new one to prevent you from just sending an unauthenticated message to a device and  with a really high frame counter such that it will no longer listen to any lower frame  counters. So any sort of really easy denial service attack. So what this means to us is that  remember the conditions we needed for a side channel attack? We need to run the crypto and it  needs to be running with the key in use. So in this case we have that. We can decrypt the  payload or it will try to decrypt the payload and it's going to try using the key of interest.  So to test this I have a 802.15.4 development board. So on this I just loaded a commercial 802.15.4  stack. And this probe here is doing the power measurement. So there's a paper with all the  details I think I link up here. If you want to see more details on how this was set up it's  all in that paper. So there's a resistor inserted into one of the power pins, this differential  probe which reduces noise so nothing too crazy. And then this hardware in the background is the  analog capture. So this is part of the chip whisper project that I'm talking about. And again  it's all open source hardware. But you don't need that specifically. The only sort of caveat here  is that it's not decrypting whatever you send it, it doesn't just fire into AES. It uses a form  of counter mode in AES. So what you have is the 16 byte input to AES. It has the source long  address which is an 8 byte field and you have to specify that correctly. So you can spoof it  easily but you have to pretend you're a node that this wireless node was previously talking to.  You have the frame counter which is something you control and then the security level of the AES  counter or you don't control so the AES counter increments slowly. So there's a few tricks  within this to get it to work as in the previous attacks. Basically you do math is the short  form of it. But in reality what we're doing is we have to push it into more rounds of the AES  algorithm so we're no longer just attacking that one point. We have to attack multiple points.  And there's details linked in that paper. But at the end of the day what you get is that if I  take that hardware device and it has a hardware AES engine inside it, not a software AES  implementation, we can see stuff like after sending it about 10,000 or so packets we can  almost completely recover the AES key. So I'm using a metric here called the guessing entropy  which is simply when the entropy is zero, I know the key perfectly. If the entropy is two, I  needed to do two wrong byte guesses. So it's a fairly straightforward metric and you can really  see that after about that 10,000 traces I was able to recover the key. And again this is a real  AES 802.15.4 stack on a real device on a real dev board. There's no sort of tricks to make it  easier here. So that's very briefly how the side channel power analysis works and how you can  perform it against real devices. The other thing I want to talk about is glitching and in  particular power glitching. So glitching is just where we make a device do something, you know,  unintended is the generic term. Really what we're looking at is when you look at the code,  there's all sorts of lines like this. So this is, you know, logging into Linux. At some point  that says hey, if your user ID is not equal to zero, check the various authentication methods.  If it is equal to zero, just skip out. And so with glitching, what we want to do is we want to  actually screw up that comparison. We want to make the hardware device perform the wrong  operation there. And you can do the same thing. So on an Android device, you know, on the  lock screen, there's always some point where it says hey, did this operation pass or not? And  with glitching, the objective is we can actually cause the wrong code paths to be executed. So  it's a way to completely skip over security in the device. So to sort of make an easier demo,  and by easier I mean something you can replicate, what I have here is I have a for loop and  there's basically two, four loops that should increment this value. And it prints what the  results, how many times it ran through each loop and how many times this value got  incremented in total. So if it works correctly, it should have incremented it 25 million  times. And I did this on a Raspberry Pi, so I'm now looking at, you know, larger devices,  not just an 8-bit microcontroller. And on this Raspberry Pi, all I've done is I have a  wire here and where this wire connects to is one of the capacitors. So you can see I've just  soldered it to the positive point of the capacitor. And it's this point right here. And all I'm  wiring this to is what's called a MOSFET. So it's basically an electronic switch. And it's  going to short these two points together. And I have some input that says how long I short  this for. And so that's the MOSFET I'm using. So the newer design I have, this chip whisper  light has these glitching tools built in. But again, you can just build your own like this  if you want. And all you do is when you short that for a very specific amount of time, when  you look at the power rail, it generates these massive spikes. So it shorts the power down  to zero. When it releases it, there's these huge voltage transients. And these voltage  transients cause undesired behavior. So let's take a look at what that looks like. So this  demo is sort of trying to show the setup. I'm just going to skip to the interesting part.  So there's the same Raspberry Pi. It's the same board I was showing you before. It has,  I'm pinging the board. You can see the reply from. So this is just to show that it's running  at the time. And I have that wire setup that I had before. And the glitching board is again  just shorting the output. And what I'm going to do is run the test program here. And you  can see the correct output is that 25 million, 5,000, 5,000. So it ran through both loops  5,000 times, incremented the final value 25 million times. This is the 1.2 volt rail.  This is the core voltage for the Raspberry Pi. And when we hit trigger button, it's just  generating a glitch. If you want to generate a glitch, you could make an Arduino code to  do this. You can use a signal generator. Anything that can set that MOSFET, activate it for  the correct period of time. And what you might see, I think I run it again here, is that  that count value when I hit trigger becomes incorrect. So I don't know if it's too visible.  But you can see this count value here. It skipped out of that loop at one point. So the  glitch, it didn't crash anything else. It's still pinging the board, everything like that.  It just caused some incorrect code path to be executed. So that's the interesting thing  you can do about glitching is that you're causing entire incorrect code paths to occur. And  then you can use that for bypassing various security measures. Another example, an Android  smart phone. So I've done the exact same thing. I've wired a pin to one of the power pins  on the system on a chip on it. I think I have a close up here. There you go. So you can  see it's this Qualcomm chip, whatever it is. And I've done the same deal. It just goes  to one of the core voltage or MPU voltage, something like that. So it takes a bit of  experimentation to figure out what those voltages are. But once you do that, it's very  possible. And the same sort of set up here. I have the MOSFET. As a note, the program,  all it's doing, it's doing that calculation and then it displays it on screen. So this  was like the first Android app I ever wrote. So it's very high quality. And I left the  hello world in because I didn't want to risk screwing it up. But what you can see is one  of those calculations was wrong. And I can do it again. So I'll just hit start. It just  does that calculation five times in a row and then displays it. So when I hit start,  insert the trigger, you'll see a different one is wrong. So I'm not triggering it reliably  right here. At this point, I'm just confirming the device is vulnerable and experimenting  with the required parameters. And sometimes it crashes. I'm running this on the real device.  So it might glitch the wrong code or something like that. All right. So that's sort of the  simple way to do power glitching. Power glitching is really good. You might have also heard  about clock glitching, which is where we insert transients into a clock. The problem with  clock glitching, you cannot easily apply it on the Raspberry Pi or the Android. They use  an internal clock generator effectively. So that's why this method is really fun because  you don't have to worry about that. You're using this power glitching and you can also  do it against the small 8-bit micro. So that's ‑‑ I don't have a movie of that, but there's  a tutorial that runs you through it. All right. So one of the first things people always ask  is, you know, well, that's great, but how do you trigger it? Because clearly all of this  is dependent on me knowing when it's doing some operation. And there's a few ways that  we can do this in real life. One of them is I can actually match ‑‑ this is the analog  power data ‑‑ I can match patterns in the power data. And for example, if I switch  back to the capture device, what you'll find is there's certain sections of the code, you  know, when it's jumping to the encryption operation, that it's ‑‑ let me just run  it again ‑‑ that it has some very well‑defined sort of outline of the power trace and it  doesn't vary a whole lot with different data. So I'm just going to change this. So as I  hit sort of capture one, there's this section in here and you'll notice the data doesn't  jump around, you know, for like the second half, there's a little section in there. So  you can actually trigger based on a pattern in the analog data. So that's something that  some of the chip whisper hardware variants, not the light, but other ones can actually  perform. The other thing you can easily do is triggering on the digital data. So when  I send it data, I say, you know, here's the request to encrypt trigger when I send that  request. For the side‑channel analysis, you can re‑synchronize afterwards. You don't  have to have everything perfectly synchronized. We can do that as a post‑processing. It's  not a big deal. All right. So that's sort of a super quick, you know, run‑through of  side‑channel analysis and glitching. I really want to give you that quick overview  to sort of convince you it's fun and it's something you can do. And if you want to do  it yourself, some of the projects I've worked on, so this was the original chip whisperer  and it's an FPGA‑based board. So there's an FPGA‑spur ‑‑ Spartan‑6 FPGA here,  analog capture board, and then a base board with power and stuff. And you can set that  up, you know, you can connect to a target device. So this is a target and you have your  computer to do the power measurements and the attack and everything like that. You can  also use ‑‑ this was the second project I did. It basically tried to take this and  make it much smaller. So we have ‑‑ there's still an FPGA here, there's still the analog  capture hardware and there's a high‑speed USB interface. There's also a target device.  So this device is what you program if you say I want to play with AES. Something like  that. You program AES or DES or whatever you want into that X‑Meg device. If you want  to target a real target, your own thing, you can break it away here and wire it into your  own target. So what I have on stage, I won't move it because it's all wired in, is I have  that connected to another board called the not‑dweeno, which is just an AAPNL AVR  base board. So what we'll do here, as an interest, these ‑‑ as I said, I did a kick‑starter,  they're being sold at the hardware hacking village and I have one I'm just going to throw  into the crowd here. So ‑‑ interest? Which way? This way? Okay. It's open box, so  there's nothing in it. So come up here. What? Oh. Because it's open box, it didn't fly  very well. I'm sorry. All right. So that's one way to get it. There's also a signed one  that's being auctioned off for the EFF and that's also done at the hardware hacking village  or not hardware hacking, hackers warehouse in the vendor area. All right. So all of this  works with this chip whisper software I was using and it's all open source written in  Python so you can hack away at it. And there's a ton of documentation. That's one thing people  are always surprised with for some reason, is that I spent a lot of time trying to make  good documentation so it goes through tutorials of how to set up everything like that and  play with your own tools. You really don't need ‑‑ don't think this is like oh, this  software only works with this one variant of the hardware. You know, I've built my own  using some other FPGA boards before and that's documented. You can build your own target device  so this is an at mail AVR target you can play around with and connect it to a scope. So  there's built‑in drivers for Pico scope. You can add other scopes. Any connected device  will work just fine. Yes, that's sort of the overview of what the heck side channel  analysis is, how it works, how you perform it, what glitching is and what tools can do  it. So I think I actually have a few minutes. If there's any questions, I can take some  now. Is there ‑‑ is there mics for the questions or ‑‑ all right. Do you want  to shout and all? Yes, the question is how do you protect? The best answer is I don't  know exactly. Most of my work has been on the attack. So very briefly, there's two major  ways. One is to use hardware that doesn't have these leaks. And specialized chips or  smart card chips are designed not to do this leakage. So you can do stuff very simply like  have differential lines. One line goes high, another goes low. And that reduces how much  leakage you have. Pardon? Yeah, there's cost on power and time. And the other way you can  do it in software as well, there's some various ‑‑ there's a whole bunch of ‑‑ this  is a huge field of research. You can mask some of the data, add random data at the input,  try to remove that data at the output of the algorithm. All of these, though, as you say,  it's a trade‑off. You may not care to some degree that it's vulnerable, but you always  have to remember that, hey, this is a real threat. So when you're using an AES boot loader,  don't just use the same key everywhere. It's like, there's AES. It's invincible type thing.  So that's sort of what ‑‑ this whole project is about showing people how these attacks  work and how realistic they are. Other ‑‑ so the question is are discrete TPM secure  against these attacks? So those would typically ‑‑ I don't want to say there always will  be ‑‑ they'll be designed to be a lot more resistant to it. So they'll go out of  their way to use the specialized hardware. And they almost always do the testing, you  know. The standards involve, hey, you should have some side‑channel resistance. So the  answer should be yes. So the question is if it works with out of stand‑alone scope.  So this ‑‑ the board I made is designed just ‑‑ it has everything on it. So you  don't need a scope. It has the analog capture hardware as part of the board. So the idea  was to get away from needing any sort of scope. I think there's another question there, sorry.  What are examples of the real‑all of the device that you use in the extension?  So I'm from Canada and this means I have to cross the border when I come here. So I try  to avoid doing stuff. But I'll discover people are mad at when I cross the border. So I don't  really talk a lot about any commercial stuff I've done. Besides, I mean, anything public  should look that at now, you know, device. The X‑Mega has a hardware AES engine. It's  been published to be breakable. There's a number of products that people have published  these results on. The key lock, so a key fob for car was a popular one. The side‑channel  analysis was able to break it. So there has been a number of real products and all the  smart card hacking stuff from pay TV. Some of that was side‑channel. Not that much  of it actually. Questions, yeah?  To some level, it requires physical access. So what I've shown is using a resistive shunt.  So you need to be able to solder to it. You can use that EM probe. So if you have close  access, you can do it pretty easily as well, which is to say, you know, you can put a probe  within 10 millimeters. There is work done on using emissions at a distance. So some companies  have demos where they have ‑‑ cryptography research in particular has a demo. They put  a cell phone on a table. They monitor the emissions of the cell phone using a radio  receiver 20 feet away and are able to do this type of attack on the device. So it's easier  if you have physical access. It may or may not actually be required.  All right. Well, I think that's all. Thank you everyone for coming out and hope you enjoyed  it.  Thank you.
DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_0_515.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_516_3659.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_3660_5255.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_5256_10799.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_10800_11159.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_11160_11231.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_11232_11543.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_11544_12035.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_12036_21851.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_21852_35483.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_35484_45419.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_45420_45527.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_45528_45587.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_45588_46559.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_46560_47039.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47040_47147.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47148_47231.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47232_47411.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47412_47459.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47460_47663.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47664_47843.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47844_47915.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47916_47987.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_47988_48203.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_48204_48347.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_48348_48803.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_48804_48959.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_48960_49007.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49008_49127.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49128_49427.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49428_49607.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49608_49667.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49668_49907.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_49908_50147.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_50148_51623.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_51624_51671.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_51672_51791.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_51792_52667.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_52668_52739.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_52740_53603.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_53604_54419.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_54420_54503.png DEF_CON_23_-_Colin_Flynn_-_Dont_Whisper_my_Chips__Sidechannel_and_Glitching_for_Fun_and_Profit_BHqrA_54504_64404.png