This is don't whisper my chips and I'm going to be talking about various methods of hardware hacking, a bit of glitching, more importantly how you can do it.  I'm from Canada.  If you've had Canada jokes, I've probably heard them.  Entertain new ones.  A number out there.  One of the things about this talk is everything I'm doing is open source.  Going to be a bunch of hardware, and it's all commercially available, if you don't want to build it.  All this stuff I've been working on is open hardware.  Whatever you want.  All GPL, no restrictions, 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 ChipWhisperer.com, and -- I founded help some of the commercial versions and 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 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.
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 Atmel, makes the microcontrollers, some various consulting projects, right now I'm doing a PhD at Dalhousie University, and I have a blog that has various projects that have been ongoing with that.
More interestingly, I did a Kickstarter recently, so this was for a project called ChipWhisperer-Lite, basically my objective to make the cheapest possible capture hardware that I could.  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 ten minute intro, so you can zone out for ten minutes.  Pin code, something that needs to check the pin code, you might implement it like this.  So we have a PCP-Code, reads into the entire pin, so it's not doing something dumb, checking after every digit and 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 some things really implement it.  What this means is that, as soon as the pin is run, you see some -- there's some finite time it takes for this loop to actually execute.  And we can take something like there's some pin protected hard drive, this isn't an encrypted hard drive.  I have to point that out.  It had a simple pin code on it.  Wouldn't enumerate without pin in it.  Vulnerable to this timing attack.  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 do is, we have some scope probe set up.  One at the top here is just -- there's an LED 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 -- red on red.  But what we're trying to see, what is the time delay when we put in the last digit of the pin and start 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 in real life.  Microcontroller, button press.  Not just when the user presses it.  So you have to go through reverse engineer a tiny bit, how is it actually reading the buttons, and 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 123456, so very hard to guess here.
And so if I put in 06666, 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 -- 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 if I put in 1666, 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 123, 666, you see it's an even longer delay.  So again you compare this slide with this one.
So that's sort of some of the most basics attacks you might do, and this is using the time delay of some output based on the input.  This is a pretty obvious one.  Has been known for a long time, so people want to avoid that.
The correct way to do this is something like you don't directly compare the password, so we're using the hash.  But what you also might do is just not give any response when it's wrong or add some random delays, 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 the 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 a date and never responds if password is right or wrong, starts ignoring stuff with the wrong password.
So what we can see here is that -- yeah, here it's processing a mostly correct password and we see this sort of -- this is the power consumption in blue and the top is the serial data, we sort of see these chunks of data here but the power consumption changed drastically all the sudden here, sort of jumps up, so you can see that average level.  This is the processor spinning into infinite loop because the wrong password was sent and you can see digit is wrong, it receives one digit and 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, if you -- after this return, you had a while loop or something, waited a bit.  You can see in the microcontroller, it's sitting there doing nothing, based on the power consumption, so that's a simple attack.  To do this, all you need is a way to measure, it's easy.  Insert a resistor in the VCC line of your device.  This is micro, or whatever we're attacking.  And we -- resistor and connect the scope across that.  In real life, here is 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 -- not resistor, so it might look a little weird but it's not terribly difficult with a microscope -- [ Indiscernible ]
You can also do stuff like use magnetic field probe, so all of this is changing the current will generate a change in magnetic field, so this means you 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, measuring the power isn't a big deal.  There's a few ways to do it and you can do it on real systems.
Even more interesting, 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, you know, idea, and this is 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, it takes power to do that, even though it seems this tiny minuscule thing it does take power and in the microcontroller, setting a data line from zero to one, therefore takes, you know, more power than not setting a 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, when we look at the microcontroller power rail, on every clock cycle, because conveniently the digit system switches the lines on a clock cycle, how is the power consumption?  If there's a bigger spike, we know more data lines are set than if there's a smaller spike, in which case one data line was set.  This is the real basic idea between differential power analysis, 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 -- AT mega micro, and what I've done is measured how many ones, the weight on the data bus for all the different data I can push across the bus, and you can see really beautiful linear graph where it goes from zero, ones -- lowest power consumption -- a kink in there, I never figured out why.  In between, nice linear fit.  This does work.  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 quick example of this.
Let's say I have this system here, I have an X -- device, and all it's doing is it's XOR'g, whatever I send to the system.  Takes, and XORs with secret key.  Encryption type operation and goes through the output and we don't know where the output goes, magic land or something.  We don't care.  What we can do.  We can do this power measurement at the same time.  So we have a resistor inserted and I'm doing the power measurement of the XOR gate.
So if -- if we're the user and we're encrypting one -- I say encrypting, we could say, okay, I sent it in hex 80, a bunch of random data to the device.  If the secret key was -- we get out six, seven.  XOR'd, 67, and this has a to five, five ones, count the ones, you get the hemming weight.  But remember, we don't know the secret key.  We don't know the output.  What we see is this.  We see the input because we sent it to the device.  But the designer assumes that's useless because you just know what you've sent it.  Don't know what the output was.  We can observe what the hemming weight output is.  How many ones are in the output.  It's not a simple system -- if the secret key were zero, zero, we would have got an output of eight, eight, which would have had two, ones and we do that for all the inputs.  That doesn't match.  So if it was zero, one, we'd get this and that -- and 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, and now each of those hypothetical outputs actually match what we observe and so we can say, yes, it's probable that the secret key was yeah, and why I picked XOR, that's how differential power analysis works.  How we apply it.  Let's break a real algorithm.  AES128.  At the input of AES128, conveniently it's 16 bits wide but we can break it, as I'll show shortly, in just a few seconds, really.  And why is possible is because it applies the algorithm one byte at a time so it takes one byte of the key or sub key.  It XORs it with -- plain text, and passes it through what is a -- Xbox, it goes on.  It goes on for several rounds.  We just don't care about that.  All we care about is -- [ Indiscernible ], because what we're able to do is do this guess and check operation with the idea of attacking whatever the -- Xbox is.
So the one thing I really want to stress here, 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 a AVR microcontroller, it's programmed with AES128.  This works with 256.  It doesn't matter.
And I'm sending data to it.  It's encrypting it and measuring the power.  These are what the spikes are.  If I change the data, monitor the -- output data here, so you can see it's sending random data and gets 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 power consumption jumping all over.  Data dependency.
I would just do this again where I send a bunch of random datas, like 50 random packets to the device, record the power consumption, and then do that guess and check operations.  Let's just save this.
Here.
And I reopened that same project.  So everything I'm showing you, this is the ChipWhisperer software, 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, 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 also told it what the correct key is, just so it can highlight in red.  You see almost immediately it recovers almost the entire encryption key.  Sending 30 packets to this device, side channel analysis, recovers A -- 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 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, a whole section of that power consumption and I can ask, for example, where in time, these big red spikes, was there a high correlation?  Where in time did you see that data dependency, and we can see as I turned on each byte, so I'm asking it, byte one, byte two, byte three, it's marching forward in time and this is because it's an eight bit micro, doing Xbox, key application.  So that's very quickly how side channel analysis works and how you use them against an unprotected AES implementation.
So now let's look at some real applications of it.
Number one, AES-256 bootloader, so this bootloader is loosely based on a whole bunch of app notes.  If you look on app -- who else, they have secure, if you want to make an AES-256 bootloader, here's an example of what you can do.  Very briefly, how it works, you have the updated microfirmware file, split into a bunch of chunks like that.  You -- they add what they call a signature.  Kick go ahead me out of that.  Add what they call signature operation here.  These four bytes and it's just a constant four bytes.  The idea being they encrypt that whole block with the signature.  When you decrypt, you verify you get the expected four bytes.  After the encryption -- pretty simple after the encryption.  Completely on the microcontroller side, if you send encrypted file, it's going to try to decrypt it and that's all we need for a side channel attack, so on the -- the microside of it, what we'll do is, we'll look and we'll say, okay, here's the text log zero, it came in, decrypted.  CBC mode so after the decryption, with the IV, and you get the first byte of the plain text right here.
So here's the -- 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 read it for the attack itself, because the ciphertext is decrypted directly.  Because AES-256, two -- or two rounds we attack.  Us a 32 byte key but not fundamentally any different, really.  The only complication, so we'll attack one round, 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 a random jitter in it.  This is really easy to deal with in the software.  We can see here for example, this is the, you know, first decryption round.  It becomes unsynchronized with the second round because some time dependent operations.  Shouldn't be time dependent but they screwed up in a few ways here.
And so we just resynchronized.  Same traces as the previous one, 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 I able to get the key, and the first round encryption, talk about 120.  So we're talking about, you know, a bootloader on a micro, and we can send this data really quickly.  This is like five minutes of data that you had to capture to -- bootloader.  At this point we have the full decryption key, if we hadn't updated firmware file we could decrypt because maybe we were trying to hide bugs in code, don't want us to reverse engineer, and 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.  All these slides by the way, if you go to -- dot com, they're posted there, you don't have to write down a million URLs.  That's the first example.
Another example is 802.15.4 mode, so I -- 802.15.4, used by a whole bunch of wireless protocols.  I sort of listed a bunch of them here, ZigBee is probably the one you might have heard of the most. 
But there's, you know, nest uses as part of the communications.  Mesh -- has their own.  So there's several things using 802.15.4, and what makes this interesting is that a lot of 802.15.4 are really, really cheap.  It's sort of a competitor to Bluetooth low energy-type stuff, so this node out here might be a light switch or outdoor light.  Something the attacker can easily get access to and a lot of the time when you have these attacks people say, yeah, well, we don't care about that end node, if they break, whatever.  But the interesting thing is that if you -- interesting ring tone selection here.  If -- coordinator, Ethernet device as well as 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 be appeared to be signed correctly, so the coordinator will process them.  If you did not have the encryption key on this link, so 802.15.4 -- 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, fuzzing, 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, all these protocols have a lower layer running this 802.15.4 wireless stack.  It defines how you deal with messages, everything like that.  If you send a message that's -- 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, to avoid replay attacks.  Looks up a secret key, 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 XY -- here's the secret key in use.  The standard doesn't specify how you do it.  Code whatever key, on that link, decrypts key load and validates the message, authentication code.  Present -- almost all the actual standards use it and finally it stores the new frame -- they have to do this last during the new one to prevent you from just sending an unauthenticated message to device -- no longer listen to any lower frame cameras, really easy denial service attack.
So what this means to us is that remember the conditions we needed for 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 pay load, or it will try to decrypt the pay load and it's going to try using the key of interest.
So to test this, I have a 802.15.4 development board.  On this I just loaded a commercial 802.15.4 stack.  This is doing the parameasurement, a paper with all the details, I think I have 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, differential, which reduces noise, so nothing too crazy and this hardware in the background is the analog capture.  So this is part of ChipWhisperer project I'm talking about, again open-source hardware but you don't need that specifically.
The only sort of caveat here, it's not decrypting, whatever you send it it doesn't just fire into AES.  It uses a form of counter mode in AES.  Sixteen byte input in AES, 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 -- this wireless -- 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, we have to push it into more -- of the AES algorithm, so we're no longer just attacking that one point.  We have to attack multiple points and there's details LinkedIn that paper but at the -- linked in that paper.  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 guessing entropy, when it 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 straight forward metric and you can really see that after about that 10,000 traces, able to recover.  This is a core stack, on a real device, on a real DEV core, no tricks to make it easy here.  That's very briefly how the side channel power analysis works.
And how you can perform it against redevices.
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, when you look at the code, all sorts of lines like this, so this is -- logging into Linux, at some point, it 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, on an Android device, on the lock screen, there's always some point where it says, hey, did this operation pass or not?  And with glitching is, the objective is we can cause the wrong -- to be executed.  So it's a way to skip over security in the device.  So sort of make an easier demo and by easier, I mean something you can replicate, what I have here, I have a four loop, and there's basically 24 loops that should increment this -- two four loops that should increment this value.  It prints the results -- how many times it ran through each loop and how many times this value got incremented in total.  If it works correctly, it should have incremented it 25 million times, and I did this on a Raspberry Pi, so I'm looking at larger devices, not just an eight bit microcontroller.  On this Raspberry Pi, all I've done, a wire here and where this wire connects to is one of the capacitors, so you can see I've soldered it to positive point on the capacitor and to this point.  It's basically an electronic switch.  And it's going to short these two points together, and have some input that says how long do I short this for?  And so that's the M. I'm using.  So the newer design I have, this ChipWhisperer-Lite has these glitching tools built in.  But again, you can just build your own like this, if you want.
And all you do, when you short that for a very specific amount of time, when you look at the power rail, it generates massive spikes.  Huge voltage transients and cause undesired behavior.
So let's take a look at what that looks like.
So this -- this demo sort of trying to show the setup.  I'm going to shift to the interesting right.  Same Raspberry Pi, same board I was showing you before.
It has -- I'm pinging the board.  You can see the reply, this is to show us running at the time and I had that wire set up 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, ran through both loops 5,000 times, incremented the final value 25 million times.  1.2-volt rail.  Core voltage for Raspberry Pi and when we hit trigger button, it's generating the glitch.  If you want to generate the glitch, you can make an -- anything that can set that -- 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.  It's still pinging the board.  Everything like that.  It just caused some incorrect code path to be executed.  That's the interesting thing you can do about glyphing, causing entire incorrect code paths to occur and you can use that for bypassing various security measures.  Another example on Android smartphone.  I've done the exact same thing.  Sign of wired a pin to one of the power pins to a system on a chip on it.  I think I have a close-up here.  There you go.  You can see it's this Qualcomm chip, whatever it is.  Core voltage, takes a bit of experimentation to figure out what voltages are but once you do that, very possible.  Same sort of setup here.  I have the Mosfet.  As a note, the program, all it's doing, it's doing that calculation and 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, one of those calculations was wrong and I can do it again.  Does that calculation five times in a row and then displays it.
So I want to 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 on real device so it might glitch the wrong code or something like that.  So that's sort of the -- the simple way to do power glitches.  It's really good.  You might have heard, transients, can't on Raspberry Pi or 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 -- 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, you know, 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, there's certain sections of the code, you know, when it's jumping to the encryption operation, that it's -- just run it again.  It has some very well defined sort of outline of paratrace 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 for 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 ChipWhisperer hardware variance, not the Lite, some can perform.  When I send data, here's the request to encrypt.  Trigger when I send that request.
For the side channel analysis, you can resynchronize afterwards, you don't have to have everything perfectly synchronized, we can do that as post processing, not a big deal.  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 ChipWhisperer and FPGA based board, Spartan FPGA here, capture board and baseboard with power and stuff.
And you can set that up.  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.  Still the analog capture hardware, high speed USB interface, also a target device.  So this device is what you program if you say, I want to play with AES.
That -- whatever you want into that X mega device.  If you want to target a real target, your own thing, break it away here and wire into your own target.  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 dwena, app -- baseboard.
So what we'll do here, as an -- these -- as I said, Kickstarter, being sold at the hardware hacking village.  I have one I'm going to throw into the crowd here.  Try this way.  Okay.  It's open box, so there's nothing in it.  So come up here.
Oh.  Because it's open box, it didn't fly very well.  I'm sorry.
That's one way to get it.  There's also a signed one being auctioned off down at the hardware hacking village -- not hardware hacking -- hackers' warehouse in the vendor area.
All right.
So all of this works with this ChipWhisperer software I was using.  And it's all open source written this 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 documentations, so you know it goes through tutorials, 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 have built my own using some other FPGA boards before and that's documented.  You can build your own target device, AVR target you can play around with sane connect it to a scope, so there's built in drivers, you can add other scopes, any connected device will work just fine.
Yeah, so that's sort of the overview of what 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 mics for the question?  Do you want to just shout?
>>   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 checks, smart card chips, are designed not to do this leakage, so you can do stuff simply like have differential lines, one line goes high, another goes low, and that reduces how much leakage you have.
There's -- 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.  You can mask some of the data, try to remove that data at the output of the algorithm.  All of these, though, as you say, it's a tradeoff.  You may not care to some degree that it's vulnerable, but you have to remember, this is a real threat.  When you're using an AES bootloader, don't use the same key everywhere.  AES.  Invincible type thing. 
This whole project is about showing people how these attacks work, and how realistic they are.
Are there other -- so the question is, secrete TPM -- 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, the standards involved you should have some side channel resistant, so the answer should be yes.
>>   [ Inaudible ]
>>   So the question is, if it works without a stand alone scope.  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 just to get away from needing any sort of scope.  I think there's another question.
>>   [ Inaudible ]
>>   I'm from Canada and this means I have to cross the border when I come here, so I try to avoid doing stuff -- 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, anything public, device, the X meg, hardware engine, published to be breakable.  There's a number of products that people have published these results on.  The key lock, so key fab for car was a popular one, side channel analysis.  Was able to break it.
So there has been a number of real products, all the smart code hacking stuff from pay TV.  Some of that was side channeled.  Not that much of it actually.
>>   [ Inaudible ]
>>   To some level, it requires physical access, so what I've shown, you know, was using a resistive shunt.  You have to be able to solder to it.  EM probe of the if you have close access you can do it pretty easy as well, you can put a probe within 10 millimeters.  There is work on using emissions at a distance, so some companies have demos where they have cryptography -- where 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 device.  So it's easier if you have physical access.  It may or may not actually be required.  I think that's all.  Thank you, everyone, for coming out and I hope you've enjoyed it.
[ Applause ]