Don't Whisper my Chips
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 109 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/36343 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Cohen's kappaSource codeComputer hardwareRadio-frequency identificationFreewareOpen sourcePower (physics)BitHacker (term)NumberSide channel attackComputer hardwareMathematical analysisOpen sourceRevision controlInformationWave packetSlide ruleLink (knot theory)
01:02
Key (cryptography)Side channel attackFactory (trading post)Fundamental theorem of algebraVulnerability (computing)Physical systemImplementationDigitizing
01:40
Information securityComputer hardwareBlogMicrocontrollerComputer hardwareProjective planeObject (grammar)Motion capture
02:26
Side channel attackQuicksortPersonal identification numberHard disk driveLoop (music)Multiplication signFerry CorstenComputer animation
03:43
Product (business)Multiplication signDigitizingSide channel attackPasswordQuicksortPairwise comparisonReal number
04:19
Reverse engineeringMultiplication signComplex (psychology)Personal identification numberTime zoneCASE <Informatik>DigitizingPasswordMicrocontrollerPoint (geometry)Reverse engineeringComputer animation
05:28
InformationRead-only memoryPasswordoutputDependent and independent variablesSide channel attackSlide rulePhysical systemPasswordQuicksortDifferent (Kate Ryan album)Function (mathematics)outputDependent and independent variablesHash functionMultiplication signSerial communicationPower (physics)
06:38
Loop (music)Level (video gaming)Hydraulic jumpPasswordQuicksortDigitizingMultiplication signComputer animation
07:12
World Wide Web ConsortiumIdentity managementLoop (music)QuicksortMathematical analysisPower (physics)Line (geometry)Personal identification numberSurfaceBitMicrocontrollerRight angleComputer animation
08:01
outputKey (cryptography)Physical systemPower (physics)Field (computer science)Ocean currentPower (physics)Physical systemLinearer GraphBitLinear regressionQuicksortWavePhysicalismFunction (mathematics)1 (number)MicrocontrollerBus (computing)Line (geometry)WeightExclusive orMathematical analysisoutputDifferential (mechanical device)CASE <Informatik>Operator (mathematics)EncryptionType theoryCycle (graph theory)Real numberMultiplication signRandom matrixMeasurementLogic gateKey (cryptography)TheoryCommunications protocol
11:25
Exclusive orFunction (mathematics)Duality (mathematics)Function (mathematics)Point (geometry)WeightMatching (graph theory)Physical system1 (number)HypothesisoutputRandomizationHexagonKey (cryptography)Computer animation
12:53
Function (mathematics)Key (cryptography)Mathematical analysisMultiplication signExclusive orAlgorithmQuicksortCuboidControl flowPower (physics)output2 (number)Differential (mechanical device)Advanced Encryption StandardEngineering drawing
13:44
Military operationData recoveryFunction (mathematics)Operator (mathematics)Key (cryptography)CuboidOpen sourceAdvanced Encryption StandardSide channel attackLibrary (computing)Hard disk driveMathematical analysisCryptographyMicrocontrolleroutputPower (physics)Entire functionTracing (software)EncryptionSoftwareRow (database)RandomizationComputer animation
16:35
Advanced Encryption StandardAsynchronous Transfer ModeSide channel attackCartesian coordinate systemMultiplication signElectronic signatureLoop (music)EncryptionDirection (geometry)Roundness (object)Block (periodic table)Right angleBootingFirmwareInformation securitySheaf (mathematics)Latent heatMobile appMathematical analysisEmailImplementationOperator (mathematics)NumberCuboidMicrocontrollerComputer animation
19:37
Roundness (object)BitReverse engineeringBootingEncryptionMultiplication signTracing (software)Bit rateSoftware bugFirmwareCodeOperator (mathematics)2 (number)MereologyComputer file
21:16
Advanced Encryption StandardThread (computing)Similarity (geometry)Side channel attackVector spaceLink (knot theory)QuicksortUniform resource locatorMereologyWireless LANCommunications protocolFlow separationStack (abstract data type)Computer animation
22:14
Asynchronous Transfer ModeCoordinate systemKey (cryptography)Type theoryMultiplication signInterface (computing)Message passingFood energyQuicksortComputer animation
23:30
Stack (abstract data type)Frame problemInformation securityComputer configurationMessage passingAddress spaceCountingPrice indexThread (computing)Communications protocolStack (abstract data type)AuthenticationDenial-of-service attackComputer configurationMessage passingStandard deviationCodeCryptographyFrame problemQuicksortKey (cryptography)Computer wormSide channel attackCASE <Informatik>Condition numberEmailInformation securityValidity (statistics)Structural loadComputer animation
25:06
Thread (computing)Stack (abstract data type)WhiteboardMeasurementPower (physics)Open sourceMereologyNoise (electronics)Motion captureProjective planeAnalogyComputer hardware
25:49
outputComputer hardwareInterior (topology)Level (video gaming)Roundness (object)Computer hardwareForm (programming)MathematicsGame controllerKey (cryptography)Real numberPoint (geometry)Frame problemSoftwareAlgorithmWhiteboardPerfect groupEntropie <Informationstheorie>Field (computer science)Address spaceAsynchronous Transfer ModeoutputQuicksortInformation securitySource codeComputer animation
27:36
CountingSide channel attackPower (physics)Mathematical analysisComputer hardwareMessage passingQuicksortAuthenticationGeneric programmingCodeInformation securityPairwise comparisonObject (grammar)Point (geometry)Line (geometry)Operator (mathematics)Multiplication signProgrammschleifeLoop (music)Total S.A.Computer animation
29:10
MicrocontrolleroutputPoint (geometry)Right angle
29:44
Power (physics)Latent heatDemo (music)Computer animation
30:16
WhiteboardFunction (mathematics)MereologyVoltmeterComputer programmingSoftware testingProgrammschleifeComputer animation
31:03
Core dumpCodeMultiplication signCountingComputer animation
31:38
Crash (computing)Entire functionCodePersonal identification numberLoop (music)Information securityPower (physics)CountingPhysical systemMeasurementAndroid (robot)Point (geometry)Computer animation
32:14
BitCore dumpQuicksortRow (database)CalculationInsertion lossElectronic visual displayMobile appAndroid (robot)Multiplication signTouchscreenComputer animation
33:04
Point (geometry)CodeParameter (computer programming)QuicksortPower (physics)Android (robot)PiSound effectComputer animation
33:45
BitPower (physics)AnalogyVideo gamePattern languageComputer animation
34:24
Motion captureSheaf (mathematics)EncryptionCodeHydraulic jumpQuicksortDifferent (Kate Ryan album)Tracing (software)Pattern languageComputer fontComputer hardwareComputer animation
35:08
Process (computing)Mathematical analysisDigital signal1 (number)Side channel attackQuicksortComputer animation
35:44
Control flowAnalogyPower (physics)Projective planeWhiteboardMotion captureMeasurementComputer
36:17
Power (physics)Control flowAnalog-to-digital converterComputer hardwareAnalogyMotion captureComputer programmingWhiteboardInterface (computing)Very-high-bit-rate digital subscriber lineData Encryption StandardComputer animation
36:59
Analog-to-digital converterGamma functionControl flowComputer hardwareOpen setAreaOpen sourceHacker (term)Software
37:45
TwitterEmailHacker (term)System callMultiplication signDegree (graph theory)Product (business)NumberPlastikkarteSide channel attackMathematical analysisResultantField (computer science)Pay televisionSoftwareAlgorithmQuicksortMereologyMotion captureMinimal surfacePersonal area networkAnalogyStandard deviationComputer hardwareBootingCellular automatonHecke operatorDevice driverType theoryLine (geometry)Table (information)Auditory maskingFunction (mathematics)Projective planeDemo (music)Key (cryptography)Level (video gaming)WhiteboardDistanceReal numberMetreComputer animation
Transcript: English(auto-generated)
00:00
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
00:24
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
00:42
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 newae.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
01:05
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
01:20
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 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
01:44
embedded hardware design, not necessarily security. I worked for a while at a company that makes the microcontrollers and something called the Arduino. I've done 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
02:01
projects that have been ongoing with that. More interestingly, I did a kick starter 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
02:23
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
02:41
some of these talks before, I always have this 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, something 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
03:02
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 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.
03:22
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 it went to
03:40
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 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
04:01
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
04:22
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
04:43
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 0 6666, what you see is this time delay from this point here where I press that button
05:01
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 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
05:23
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 123666, 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
05:44
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
06:02
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
06:20
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. And we see
06:42
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 changed 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 is wrong
07:03
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, you know, if you, 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
07:21
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
07:40
connect to 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, 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
08:03
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
08:21
isn't a big deal. There's a few ways to do it and you can do it on real systems. Now what'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 you know changed a little bit. What's sort of a more fun attack is this differential power
08:40
analysis. And this uses a really simple you know 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
09:02
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 you know 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
09:23
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 you know one data line was set. So this
09:42
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 ATmega micro. And what I've done is measured how many ones the hamming
10:02
weight of the data on the data bus for you know 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 out why. But in
10:21
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
10:42
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
11:02
takes it and it XORs it with this secret key. That's all it does. So 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.
11:20
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 88. I'm just sending a bunch of random data to the device. If the secret key was EF, hex EF we'd get out 67 so hex 88,
11:45
XORed with EF is 67 and this has a hamming weight of 5. So this means there's 5 ones if you convert 67 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
12:00
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 not a pretty simple system where we do this
12:21
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, or the hypothesis doesn't match what we measured still. Eventually we
12:43
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
13:01
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 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
13:24
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 look up 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
13:42
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
14:06
S box is. So to use this, you have to have the crypto operation running with the secret key you want to recover. So if you have 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
14:23
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 AES128. This
14:44
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
15:02
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
15:23
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 reopened that same
15:48
project. So everything I'm showing you, this is the ChipWhisperer software. Again, it's written in Python and open source and everything. So you can see these are the
16:00
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
16:21
this device, doing the side channel analysis, it recovers the full AES128 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
16:42
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
17:02
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 1, byte 2, byte 3, 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 and
17:20
the S box look up. 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 boot loader. So this boot loader is loosely based on a whole bunch
17:43
of app notes. If you look on like app mail and who else do they have, NXP maybe, they have them secure. If you want to make an AES 256 boot loader, here's an 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
18:00
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 4 bytes and it's just a constant 4 bytes. The idea being that they encrypt that whole block with the signature. When you decrypt it, you verify you get the
18:20
expected 4 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
18:41
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
19:01
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
19:20
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
19:44
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
20:02
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 resynchronize. 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
20:22
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 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
20:43
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
21:01
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
21:20
initialization vector is. And you can do this in a similar way through side channel. I talk 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
21:43
example. Another example is 802.15.4 node. So IEEE 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
22:01
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
22:23
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
22:41
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
23:00
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 AES128 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
23:20
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,
23:41
you know, 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
24:00
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, you know, 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.
24:25
If present, it's optional but almost all of the actual standard to 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
24:40
that it will no longer listen to any lower frame counters. So any sort of really easy denial of 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
25:01
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
25:20
think I link up here. If you want to see, you know, a little 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 bins, this differential probe which reduces noise so nothing too crazy. And then this hardware in the background is
25:40
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
26:03
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
26:22
then the security level at 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
26:41
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
27:03
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
27:21
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. Yeah, so that's very briefly how the
27:41
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
28:02
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
28:22
hardware device perform the wrong operation there. And you can do the same thing, so 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, 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
28:43
the device. So to sort of make an easier demo, and by doing that, 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
29:02
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 pie, so I'm now looking at larger devices, not just an 8-bit microcontroller. And on this raspberry pie, all
29:21
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 on 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
29:42
how long do 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
30:02
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
30:26
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
30:41
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, 5,000, 5,000. So it ran through both loops 5,000 times, incremented the
31:03
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
31:23
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
31:40
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 on Android
32:04
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
32:20
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 setup here. I have the MOSFET. As a note, the program, all it's doing, it's
32:42
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
33:01
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
33:20
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
33:40
the raspberry pie 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 micros. I don't have a movie of that but there's a tutorial that runs you through
34:01
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
34:21
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 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
34:44
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
35:01
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
35:23
the side channel analysis you can resynchronize 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
35:41
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 spartan 6 FPGA here, analog capture board and then a base board with power and
36:01
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,
36:24
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 DES or whatever you want into that X mega device. If you want to
36:42
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 NotDuino, which is just an Atmel AVR base board. So
37:00
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? 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
37:21
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, hacker's warehouse in the vendor area. All right. So all of this works with this chip whisperer software I was using. And it's all open source written in
37:44
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
38:00
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 AVR target you can play around with and connect it to a scope.
38:21
So there's built-in drivers for PicoScope. You can add other scopes. Any connected device will work just fine. So 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
38:40
minutes. If there's any questions, I can take some now. Is there mics for the questions? Do you want to just shout and all? The question is how do you protect? The best answer is I don't know exactly. Most of my work has been on the
39:04
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 simply like have differential lines. So when one line goes high, another goes
39:22
low. And that reduces how much leakage you have. Pardon? Yeah, there's cost and time. 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
39:40
some of the data, you add random data at the input, try to remove that data at the output of the algorithm. All of these, as you say, it's a tradeoff. You may not care to some degree that it's vulnerable, but you always have to remember that, hey, this is a real threat. When you're using an AES boot loader, don't just use the same key everywhere. There's AES. It's invincible type
40:03
thing. This whole project is about showing people how these attacks work and how realistic they are. So the question is are discrete TPMs secure against these attacks? Those would typically, I don't want to say there always will be,
40:22
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
40:47
the question is if it works without a stand alone scope. So 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
41:03
another question there, sorry. 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 that I'll discover people are mad at when I cross the border. So I don't really talk a lot
41:22
about any commercial stuff I've done. Besides, I mean, anything public, so like that atmel device, the xmega has a hardware AES engine. It's been published to be breakable. There's a number of products that people publish these results on. The key lock, so a key fob for car was a
41:41
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 from the side channel, not that much of it actually. To some level it requires physical access. So what I've shown is
42:03
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 can put a probe within 10 millimeters. There is work done on using emissions at a distance. So some
42:21
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 device. So it's easier if you have physical access. It may or may not actually be required.
42:45
Well, I think that's all. Thank you, everyone, for coming out and hope you enjoyed it.