 So this is don't whisper my chips and I'm going to be talking a little bit about various methods of hardware hacking is really what it comes down to. So 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. So 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 AE.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, 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 at Mel that makes the microcontrollers and the Arduino. Some other stuff. I've done some various consulting projects. Right now I'm doing a Ph.D. at Dalhousie University. And I have a blog on Oflin.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 Lite, 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 know, 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, you know, 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's really implemented. What this means is that as soon as the pin's 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 it went enumerate 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 probes 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, sorry 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'll 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 one, two, three, four, five, six. So very hard to guess here. And so if I put in zero, six, six, six, six, 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 one, six, six, six, so now the first digit's correct, we can look at that time delay again and you notice it's longer. So this means we now know the first digit's correct. So we can just guess one digit at a time. We don't have to guess the whole pin. And you know, if we go through and put in one, two, three, six, six, six, 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, 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's 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, if you, after this return, you had a while loop or something that were weighted a little bit, you would 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. So this is, you know, the micro or whatever we're attacking. And we insert a resistor and connect a scope across that. In real life, so you know, 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 probe. 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 a 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 is 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 it 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, 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 0, 0, we would have got an output of 8, 8, 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 0, 1, we'd get this and that 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 why I picked XOR, that's sort of how differential power analysis works. How we apply it. So let's break a real algorithm, AES 128. At the input of AES 128, 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 sub key, 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 you 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 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 reopen 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, you know, 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, you know, 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 four loop in there doing the S-Box, the key application in the S-Box lookup. So that's, you know, 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 bootloader. So this bootloader is loosely based on a whole bunch of app notes. If you look on, like, AppMail and who else did it have? NXP maybe. They have them secure. You know, if you want to make an AES-256 bootloader, 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, oops, kicked me out of that. 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, you know, 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 CypherTex, 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 CypherTex 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, you know, 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, you know, 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 tripled 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, 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 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 it 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 during 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, you know, a lot 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 it 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 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 there's 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. Now what I have here is I have a for loop and there's basically two for 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 I've 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. This 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 that 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 you know 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 5000 5000. So it ran through both loops 5000 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 know 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 ran 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 you know 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 you know various security measures. Another example on Android smartphone 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 you know 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 you know 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 you know at this point I'm just confirming the device is vulnerable and experimenting with the required parameters and sometimes it crashes you know I'm running this on the real device so it might glitch the wrong code or something like that. 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 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. Alright 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 so this is the analog power data I can match patterns in the power data and for example if I switch back to the 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 alright 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 it's 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 whisper and it's an FPGA based board so there's an FPGA spartan six 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 you know 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 DDes or whatever you want into that XMega device if you want to target a real target your own thing you know you can break it away here and then 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 AAPNEL AVR based board so what we'll do here as an interest these as I said I did a Kickstarter 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 it's open box there's nothing in it so come up here what oh because it's open box didn't fly very well I'm sorry alright 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 a hacker's warehouse in the vendor area alright so all of this works with this chip whisperer 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 a good documentation so you know 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 you 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 no AVR target you can play around with and connected 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 the overview of what the heck side channel analysis is how it works how you perform it and 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 alright do you want to just shout and all yes the question is how do you protect the best answer is I don't know exactly most of my work is 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 care chips are designed not to do this leakage so you can do stuff very simply like have differential lines when one line goes high another goes low and that reduces how much leakage you have yeah that 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 you know this is a huge field of research like you can mask some of the data so you 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 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 you know when you're using an AES bootloader don't just use the same key everywhere it's like ah there's AES 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 our 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 will go out of their way to use the specialized hardware and they all almost always do the testing you know the standards involve hey you should have some side channel resistant so the answer should be yes so the question is if it works without a standalone 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 the board so the idea was to get away from needing any sort of scope I think there's another question there 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 I don't really talk a lot about the any commercial stuff I've done besides I mean anything public so like that at now you know device the X mega has a hardware a s engine it's been published to be breakable there's a number of products that people 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 with side channel not that much of it actually but to some level it requires physical access so what I've shown you know is using a resistive shunt so you need to be able to solder to it you can use that e.m. 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 you know 20 feet away and are able to do this type of attack on the on the device so it's easier if you have physical access it may or may not actually be required well I think that's all thank you everyone for coming out and hope you enjoyed it