Glitching and Side-Channel Analysis for All
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 13 | |
| Anzahl der Teile | 18 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/32813 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
REcon 201513 / 18
1
2
3
4
10
12
14
15
18
00:00
ChiffrierungZahlenbereichWhiteboardAnalysisProgrammBitKartesische KoordinatenEinflussgrößeAlgorithmusSchlüsselverwaltungARM <Computerarchitektur>Leistung <Physik>MultiplikationsoperatorDatensatzMikrocontrollerMinimumGewicht <Ausgleichsrechnung>FestplatteHardwareSichtenkonzeptGüte der AnpassungMAPQuick-SortSchnittmengePhysikalische TheorieKryptologieEin-AusgabeProgrammbibliothekFunktion <Mathematik>GarbentheorieSelbst organisierendes SystemQuadratzahlRechteckPunktBitrateProjektive EbeneSchaltnetzOpen SourceVektorraumKorrelationCodierungImplementierungDeskriptive StatistikComputersimulationVersionsverwaltungOffene MengeReelle ZahlMetropolitan area networkCoxeter-GruppeMereologieIterationTabelleEnergiedichtePhysikalisches SystemPrivate-key-KryptosystemTouchscreenGeradeZwischenwertsatzPeripheres GerätDienst <Informatik>Symmetrische MatrixKontrollstrukturSeitenkanalattackeDemoszene <Programmierung>LastRechter WinkelPhysikalismusComputeranimation
07:36
VersionsverwaltungComputersicherheitHardwareBitSoftwarePunktProdukt <Mathematik>AnalysisOpen SourceComputeranimation
08:03
AnalysisProgrammbibliothekAnalogieschlussWhiteboardPhysikalische TheorieUmsetzung <Informatik>PunktSkriptspracheGarbentheorieWellenpaketQuick-SortProgrammSeitenkanalattackeVHDSL
08:54
SoftwareComputerspielRegulärer GraphDemoszene <Programmierung>WellenformQuick-SortDatensatzMotion CapturingChiffrierungLeistung <Physik>Computeranimation
09:39
Ein-AusgabeMessage-PassingAblaufverfolgungLeistung <Physik>ChiffrierungSoftwaretestProgrammbibliothekWechselsprungWellenformWhiteboardRauschenBitProjektive EbeneMinimumQuick-SortMotion CapturingMathematikRandomisierungDatensatzDifferenteLogischer SchlussComputeranimation
11:25
Leistung <Physik>ProgrammAnalysisSchlüsselverwaltungDemoszene <Programmierung>AblaufverfolgungKorrelationsfunktionChiffrierungPunktWellenformEndliche ModelltheorieBitInstantiierungUmwandlungsenthalpieNichtlinearer OperatorMultiplikationsoperatorSkriptspracheProzess <Informatik>InformationKorrelationElektronische PublikationQuellcodeDateiformatProjektive EbeneCASE <Informatik>MikrocontrollerDienst <Informatik>Coxeter-GruppeComputeranimation
13:39
SeitenkanalattackeAnalysisSoftwareEnergiedichteMultiplikationsoperatorDemo <Programm>Protokoll <Datenverarbeitungssystem>SoftwareentwicklerStandardabweichungPhysikalische SchichtLeistung <Physik>Interface <Schaltung>Internet der DingeQuick-SortGatewayDrahtloses lokales NetzPlastikkarteMessage-PassingBitZentralisatorPunktRouterPhysikalisches SystemWhiteboardMikrocontrollerDatenfeldSoftwareschwachstelleEinsMixed RealityFlächeninhaltSystem-on-ChipComputeranimation
16:03
RahmenproblemAdressraumDateiformatForcingBroadcastingverfahrenComputersicherheitMessage-PassingNichtlinearer OperatorComputeranimation
16:42
AnalysisChiffrierungKryptologieCASE <Informatik>Quick-SortMereologieAlgorithmusStandardabweichungVerschiebungsoperatorNichtlinearer OperatorSchlüsselverwaltungEin-AusgabeMessage-PassingFehlermeldungMathematikProgrammverifikationAutomatische DifferentiationLeistung <Physik>ATMTypentheorieUnrundheitRahmenproblemVariationsrechnungInformationDatensatzZweiHyperbelverfahrenComputeranimationTechnische ZeichnungDiagramm
18:41
SeitenkanalattackeUnrundheitLeistung <Physik>KryptologieInterface <Schaltung>InformationAnalysisReverse EngineeringSchlüsselverwaltungMultiplikationsoperatorProjektive EbeneQuick-SortGanze FunktionSystem-on-ChipBitp-BlockElektronische UnterschriftE-MailEin-AusgabeGeradeChiffrierungTypentheorieHardwareAdvanced Encryption StandardARM <Computerarchitektur>Ideal <Mathematik>Endliche ModelltheorieGamecontrollerFirmwareZahlenbereichBootenApp <Programm>MikrocontrollerProtokoll <Datenverarbeitungssystem>PunktSynchronisierungBitrateMessage-PassingMereologieNichtlinearer OperatorCASE <Informatik>Entropie <Informationstheorie>Peripheres GerätFontBetrag <Mathematik>ProgrammverifikationImplementierungElektronische PublikationBefehl <Informatik>SoftwareGenerizitätVerschlingungKlasse <Mathematik>WhiteboardGüte der AnpassungVersionsverwaltungATMAlgorithmusZeitumkehrAblaufverfolgungFinitismusOverlay-NetzComputeranimation
25:10
InformationLeistung <Physik>ChiffrierungCodierungPasswortMikrocontrollerGamecontrollerHumanoider RoboterZahlenbereichEinfacher RingRechenbuchAdditionLastLoopDifferenteParametersystemSeitenkanalattackeWellenformPolarkoordinatenBitrateCASE <Informatik>ComputerSmartphoneMultiplikationsoperatorComputeranimation
26:56
Coxeter-GruppeComputerLeistung <Physik>AnalysisBitPunktMultiplikationsoperatorSeitenkanalattackeQuick-Sort
Transkript: Englisch(automatisch erzeugt)
00:22
We're good. So it'll take a second when I switch for doing the demo to mirror it. But thanks for sticking around before the coffee break for a second here. So I hope you find this interesting and learn a little bit about sort of more hardware hacking level stuff. And in particular, I'll be talking about side channel power analysis and glitching.
00:43
So very quickly, I'm going to review what side channel power analysis is. Previous presentations have gone over this in a lot more detail. So this is going to be the super abridged version of that sort of talk. I'm not going to go over every little detail of how the theory of it works. You can see some of my previous talks
01:00
if you're interested in that. I'll give you two examples of where you can use side channel power analysis on real targets. And after that, I'll pretty briefly cover what glitching is and sort of an example of doing glitching against a Raspberry Pi running embedded Linux. All right, so about me. Right now, I'm doing a PhD at Dalhousie,
01:20
which is in Halifax, Canada. As part of that, I designed this open source project called ChipWhisperer, and it's gone through a few different iterations. And the most recent iteration is the one I'm talking about, ChipWhisperer Lite. And I've spun out a company to help commercialize that, but it's a completely open source project, so everything's open. It's a little like the talk before the previous one,
01:42
saying it's one man writing crappy code. Very much the same to the point that I learned Python during this project. So the early code is a lot sketchier than the later code. You can sort of see the progression, how well I've learned Python. And I've talked about this a little bit about various black hats.
02:01
Recon last year, there was sort of an earlier version. And I'll be at DEF CON and Black Hat again this year. So if you're there, you can hunt me down. All right, so what is side channel power analysis? Very briefly, what you need to do this is you need some sort of device. So we have a crypto device. And that device in the center is doing
02:20
whatever algorithm we're interested in, so be it AES, some sort of symmetric algorithm, or something else. We also have to have either input or output. It doesn't matter which. We don't need both, and we don't have to control it. But we have to be able to see what one of those pieces of data is, or be able to determine it. So if this is AES, for example, AES 128,
02:44
we would have to know either the cipher or the plain text. And the AES is what I'll be using. It also has to be operating with the secret key loaded. So that's sort of one of the other critical things we'll see. So you can't use side channel power analysis if you have a hard drive sitting on a table that's not encrypting or decrypting anything.
03:02
This won't work against that sort of target, so if it's a self-encrypting drive. If you can do these measurements while the drive is encrypting and decrypting, it is a viable attack vector. So that's sort of the only caveat you have to understand with it. It's not just a magical attack against encryption. It's very specifically attack against implementations
03:23
when they're doing specific work. So the super fast description of how it works is that if you look inside digital devices, inside a digital device, you have something like a bus line. So these are the data bus lines. And the data bus lines are just long wires.
03:40
These long wires, you can sort of simulate or view them as just capacitors. The long wire has a capacitance to it. To change the voltage on that capacitor takes physical power. So to change it from zero to a one takes a tiny amount of charge. And if we look in the chip, so here I have two data lines.
04:00
And those data lines always switch on the clock. And if two of the data lines switch from zero to one, it takes, I have two data lines here switching up, and you can see there's sort of a spike of power if you can see it on the screen. And then later on, for example, the data lines switch low, so I'm only looking at power consumed from one of the power rails.
04:20
They switch low, so it doesn't take any power from the positive rail, so you don't see that spike. So the idea is that there's some linear relationship between power consumption and the number of bits set to one on the data bus. And this is real. It's not sort of like, oh, it kind of works, hopefully. This is a measurement I did on a small eight-bit microcontroller,
04:41
and it's showing you for, on the bottom is what they call hamming weight, so this is number of bits set to one. And so either no bits are set to one or all bits are set to one. And on this axis is the current sort of consumed by the device. It's a measurement related to the current, so it's not directly milliamps or something.
05:02
But you can see there's a very beautiful linear relationship. Why this is useful to us is if we look at a lot of algorithms, so again, going back to AES, it's 128-bit key, so we can't guess the key any way we want. But what we could look at is we say, well, it operates on one byte at a time,
05:21
and if we just concentrate on one little section of the algorithm, so if I just sort of draw a crude square or rectangle around that section up there, what the power analysis will tell us is that we're gonna look just at, say, this point in the algorithm. We're gonna look at the data right at this output here.
05:41
So if you can, oh, I don't think it's trying, sorry. There we go, this output there. So we're only looking at one byte of the key, one byte of the key, and the output at that one spot. And we could figure out, based on the power analysis, that there is four bits set when I put in a plaintext of AB hex AB, and the only way we get four bits set
06:04
is if the key is some other byte. In reality, we'll, of course, get a candidate number of possible bytes for that key, so we could send in another piece of plaintext and say, well, we send this other byte of plaintext, there is two bits set at that intermediate value. We know all of them, how the algorithm works, so we can narrow down what that byte of the key is.
06:23
So the point is that we're doing this guess and check on a single byte of the key, and we just do it 16 times in a row. So it's just two to the eight guesses, 16 times. So it's very tractable and easy amount. To do the measurement of the power, all you really need is something that, like an oscilloscope, or something that is capable
06:42
of measuring the power. I have my own custom hardware to do this, but this is just an off-the-shelf USB scope. And I have a device that is running whatever the encryption example I'm interested in. So I just have a board that's a chip running some program using encryption. And that's really all that's involved in the attacks,
07:02
what you require. So to help simplify this, this is what I had showed last year. I did this ChipWhisperer project. So it's designed to be a combination of the hardware, which is replacing the oscilloscope, so doing the power measurement side, as well as a board for programming with,
07:21
if you want to analyze, say, a AES library, you can program it into the board and do the measurements there. You can, of course, target physical devices, so I'll show some examples of that. Last year, it was in second place in the Hackaday Prize in 2014. And that version of the hardware was then sold as a security analysis tool.
07:41
So again, all open source, the hardware and software. To make it even more accessible, so the problem with this is it was still a bit fiddly, a little bit more expensive, like $1,500. And we really need to push it to the point that all people know about this that might have to design these products or look at the security of products.
08:02
So I'd done a Kickstarter for, in the Kickstarter, about 200 US dollars, the ChipWhisperer light board, and it's doing almost the same thing. So it has a section of the board that is doing the target device. So this is the, it's an Atmel Xmega,
08:21
but you program it with whatever library you want. And then there's a portion of the board that does stuff like the analog to digital converter. It has a high speed USB, it has an FPGA and all that stuff. So it's effectively designed to give you a tool to learn about the theory behind these attacks. The critical thing with side channel analysis
08:42
is it's never going to be a script kitty point and click attack. You have to understand how everything works about them to even hope to apply them. So this tool is designed to give you that sort of training. And of course you don't, there's nothing special about it. You can just go back and build your own if you have an oscilloscope that works. The software works with anything.
09:01
It will work with regular oscilloscopes as that's what I used to use. All right, so let me give you a example of what this looks like in real life. So this was the super fast talk, the super fast demo that I had done last night. And I'll sort of do the same thing
09:21
just so you see what the waveforms look like. So if I run the capture tool, it's going to do that sending data to the device, record power, and see what the encryption is. Let me pull it over. Which way is it? So this is the tool.
09:40
It's all written in Python. And it's very fiddly on this monitor here. And it can attach to various targets. So I'm going to be attacking AES on this little Xmega board. So what it's doing is it's going to send
10:02
encryption messages to the device and then record the power. So you can see the sort of traces bouncing around. That's as it's recording different messages and you can view the AES 128 in input and outputs. Just raw. So in this example, I just am testing a library. So it just sends a message, encrypts it, and that's it.
10:22
What I can do, for example, to give you a more intuitive feel is that if I set this to fix, so if it's encrypting the same data repeatably, you'll sort of see the waveform doesn't jump around quite as much. There's a bit of noise. But the peaks, if you look at the bottom down here, don't change nearly as much.
10:41
And if I switch this back to encrypting random data, you can see those peaks jumping around a lot more. So it gives you a feeling there is a data dependency based just on what's being encrypted. All right, so what we're gonna do is we're just gonna capture 50 traces. So it just sends 50 messages to the device and encrypts them
11:03
and monitors the power while it's doing that encryption. And I'll save test recon 2015. And there's no undo in this GUI, so I don't need undo. And in fact, you can't close a project
11:20
and reopen a project without closing the whole thing. So it has lots of features like that. All right, and then the analysis side is a separate program. So the analyzer, previously, I mean, people have been doing this research for 15 to 20 years in the power analysis side alone. And you can use straight Python.
11:41
You can use MATLAB scripts. You don't have to use this. It's a very simple file format. The idea of the GUI is just to sort of get you started and give you a feel for what the traces look like. So if I open that project, what we see is the waveform here. So that was the waveform I just captured.
12:01
And the attack, so we have to know a little bit about the device to attack it. In this case, I know it's AES 128. And because it's on a microcontroller, there's certain power models we use. And I talked about that in previous presentations, so I'll skip that. And all it's going to do, it's doing the analysis, and the key in red is the correct encryption key.
12:20
And it knows what the correct key is because I've told it what the correct key is. So you can see in this example, in 50 traces, it almost entirely recovered the key. There's one byte that maybe it needed a few more traces for. But it's very, very fast like that. You know, it was a few minutes start to finish for the whole demo. One of the other questions people always ask is,
12:41
well, how do you know where the encryption is happening? And the analysis itself gives you some of those answers. And so what this is, this is graphing the correlation between, it looks for that linear relationship. And this peak is at various points in time as it's executing instructions.
13:01
So all I do is I say I send you data at some point between sending you data and getting data back. You're running the encryption algorithm and doing that operation I'm targeting. So I can compare, for example, this is recovering byte four. If I look at recovering byte five, what you'll sort of see is you notice that peak is marching on in time.
13:20
And this is because this is an AES software implementation. So it's doing byte five, byte six, byte seven. And you can see the specific instance in time where that operation of interest is occurring. So it also gives you some information about the underlying process. All right, so there's that.
13:40
That's what side channel analysis briefly looks like. So what could we do it against? So here's two sort of demos I've done or work I've done more recently. So this 802.15.4 standard was hoped to be a big protocol for the internet of things.
14:01
It never really turned out as much, but there's a few things using it. The Nest thermometers use it as one of the interfaces, I believe. There's some wireless light bulbs that used it. It's used a bit for smart energy sometimes for connecting to networks in the home. And you might know it better by other names. So 802.15.4 is the lower layer protocol
14:21
used by all of these. So all of the Zigbee ones, people have probably heard about, but all of these protocols are built on top of 802.15.4. And if you want more details, by the way, about the attack, it's in this paper here that I sort of just put online. So this is the first time I've really talked about it.
14:43
And what I'm doing is I have a 802.15.4 node. And this 802.15.4 node, I'm using a development board here that's sold by third party. And I'm targeting a 802.15.4 system on a ship so it has a microcontroller and the radio all on board.
15:01
And at the same time, I'm measuring the power using this shunt here of the board. So for this attack, I do physically need to have the device. You don't necessarily need to use the shunt. You can do stuff like a magnetic field probe, which doesn't require the soldering, but you still need to be close to the device. What's sort of interesting about this is, for example,
15:22
a lot of targets, a lot of central routers at some point will have a web-based interface as well as the 802.15.4. So the Nest thermometer, or I don't know if the thermometer does, but Nest Protect, I think one of the gateways has 15.4 on one side, your internal network on the other.
15:40
So while you couldn't get access to the gateway, you may be able to get access to a device that the gateway's talking to. And so maybe you can use the device the gateway's talking to to then fuzz into the gateway to find vulnerabilities. So there is a lot of reason why you should be concerned if we can break these devices fairly easily
16:00
and then spoof messages on the 802.15.4 network. So the 802.15.4 frame format looks something like this. And very briefly, when we're doing a secure message, the only stuff you really care about is the destination address we can set to a broadcast so we can just sort of force a node to receive it.
16:20
And any node that receives a valid-looking message is going to try decoding it. And if we set the security stuff up, what that's going to include is it's going to include the device we'll try to decrypt the message. It'll obviously throw it away as soon as it realizes it's invalid, but we can cause those operations we require to happen.
16:41
So way back here, I said for side-channel analysis, what we need is the ability to cause the device to do the encryption or decryption with data we know or control or something like that. So in this case, I'm sending the device a cipher text, and it's going to decrypt it just because that's what it'll do.
17:01
It's going to verify the MAC, which will fail, and it'll throw it away. But we don't care. We don't care about the verification. It's using AES encounter mode, which gives us one sort of problem in that only a few of these bytes we actually control, or even vary, is the real problem. So there's just this frame counter
17:20
that comes from the over-the-air message. The frame counters four of the bytes to the input. So if we looked at the input, what this means is that these, or no, not these, these four bytes are variable, and the rest are all fixed. So when you do that power analysis attack, I mentioned how it's doing this guess and check.
17:42
There's no way to guess when you don't have any variation in the input message. You'll only be able to recover the keys where there is some change in what the input data is. The bytes where the input is fixed won't give you any information for this type of standard attack.
18:00
There was previous work on AES counter mode showing how to push this into later rounds. So I sort of extended that a little to the specific mode used in 15.4. And what you end up with is that you basically are trying to push the attack into later rounds of AES. So AES itself, when we perform the attack,
18:20
we'll recover four bytes of the key. As part of the AES algorithm, it's going to do the shift rows operation here. So it effectively shifts around the keys, or shifts around the bytes, and then mixes them together. What this will mean is that if we looked at the second round of AES, we no longer have the case where only four of those bytes are constant.
18:40
A whole bunch of those bytes are going to vary because that's sort of the design of AES. And we can now recover a lot more of the key material. And we have to push this to about the fourth round, and eventually we can recover the entire key from the AES algorithm, even though only four of those bytes vary at the input. So it's also not always the case
19:02
that you can just look at it and say, oh, it's safe because a few bytes change only. There's a lot of tricks like this you can do. The second part of the attack is looking at the 15.4 system on a chip. It has a hardware AES peripheral. So the question is, can we attack that with side channel analysis? Does it leak?
19:20
In this case, the answer is yes, it does basically. So this is showing what's known as the guessing entropy. If the entropy goes to zero, we know the key with absolute certainty. So you can see the entropy is going down towards zero. Basically, if you can send the device 10 to 20,000 messages, you can recover the key.
19:42
And for the 15.4 node, that doesn't take very long. You just are firing at messages. The device is decrypting them. The verification fails, and it throws it away. It never tells the higher layer. And eventually, we can get the key and then send it a message as if it was properly encrypted or send a message from the device
20:01
encrypted with the key for whatever that link is. All right, that's example one. Example two is a AES-256 bootloader. And I sort of pulled this because if you look at app notes from a lot of silicon vendors, what they have is they'll say like, well, here's a AES bootloader. So atmel has one.
20:21
I can't even read freescale. And whatever this one is has one as well. And there's a few other ones, and they're all more or less the same. As a note, if you want more details, there's sort of a tutorial I wrote on this and a recent paper that was just published on this attack. And very briefly, all of these protocols
20:41
vaguely use this idea where you get the updated microcontroller firmware. They split it into whatever size blocks they're using. They prepend some fixed number of bytes in the front. So these fixed bytes effectively form the signature. And the idea being it's just going to decrypt every block and check those four bytes are correct
21:03
to ensure that it's supposed to be an update file. So this is kind of what they use. There's some variations, but it makes a good generic statement. So what's interesting to us, and it's used in a CBC mode, is that the data, if we just send the device
21:23
a block like this of encrypted data, we put the CRC on it, we put the header on it, it's going to decrypt it and check the signature. The signature will fail and it'll throw it away. But again, we don't care about that. We care that we were able to get the device to decrypt it properly.
21:42
And so this is great because we can do a side channel attack now because what we have is we have this situation. We have the input safe attacks here, the AES-256 decryption in the center, and after the decryption, it's applying the IV. So we don't even care what the IV is, in fact, at least initially. We have everything we need to do
22:02
the entire side channel analysis. The only caveat, because it's AES-256, it's a tiny bit more difficult in that you have to do the attack twice. So you'll do it first on the first round of the decryption or last round of the encryption, whichever way you want to look at it, and you'll recover all of the, so you'll recover the information here
22:21
to figure out what the final round key or the first round via decryption key is. Once you have that key, you can then attack the next round and recover the full 32-byte key for AES-256. And there's always tricks. As I say, it's never just a push-button attack with a side channel analysis.
22:41
So in this case, one of the problems might be that the AES implementation actually has a timing attack in it as well, and so things become unsynchronized. So we have the first round going here. At some point, there's a time-dependent operation. So what you can see is that if I overlay, I think, about 100 traces, power traces,
23:00
up until that point, they all look, the amplitude differs, but there's a very nice sort of outline. Beyond that point, things look crazy. It's not synchronized at all. And that's because there is some time-dependent or data operation where the time depends on the data giving us the timing attack, which we ignore.
23:22
So all we do is we can resynchronize. Basically, you try shifting each trace a little bit, a few points to figure out the synchronization again, and then you're good, and you can do the side channel power analysis attack on the next round. And what this looks like, so there's two success rates here. A success rate of one means I 100% of the time
23:43
recover the key with a certain number of encryption attempts. So for the first 16 bytes of the key, you can see that in about 60 traces, it almost with 100% certainty is able to recover the encryption key. It's a very wavy line, I know, but it should be about straight.
24:03
And it takes a few more to recover the last 16 bytes of the key, but we're still talking about 100 to maybe 200 encryption attempts. And each attempt is me just sending that garbage packet to the device. So this does not take very long at all to do that type of attack.
24:21
All right, so if that interests you, how can you get started? Really, all you need to get started is a few things. You need a simple target device. So do not try side-channel analysis for the first time on a Raspberry Pi or ARM or anything like that. You want a 8-bit microcontroller, ideally. So an AVR dev board, like I showed the one earlier,
24:42
the Arduino Uno, again, not the ARM stuff, or a PIC controller. And you just need some way to measure the power on it, so a scope with a USB API. So I like the PicoScope models. A lot of bench scopes have it. The only thing to be wary of is you can get really cheap off-brand scopes off eBay.
25:01
A lot of the time, the USB interface is poor, so it comes with software, and that's all it works with. You'll spend a lot of time reverse-engineering it. Or of course, there's one of the projects I have, so the ChipWhisperer or ChipWhisperer Lite, which are somewhat commercial, wherever it was back here. Or you can build one yourself. All the designs are open, all the PCBs are available.
25:23
All right, so that's the side-channel stuff. What about glitching? What is glitching, is the first question. Glitching is really when we make the device do something that it is not supposed to be doing. In this case, what we might have is I'm doing an example of glitching where I just have a simple loop,
25:43
and I just go through the loop, and it is doing some different things. It's just doing these additions. I can insert glitches using just a short on the power rail. And the short is just an electronic switch shorting the power rail. And you could do this against an AVR microcontroller. You can do it against Android device,
26:02
so this is a smartphone. Or even something like a Raspberry Pi running Linux. And what you end up with, so again, all I'm doing is I'm shorting the VCC power rail here. And what I end up with is a nice waveform like this.
26:20
So when I engage the short, it drops the power for a very controlled amount of time, and then generates a large ringing spike. And this will cause incorrect instructions to be executed. So in my test, all I'm looking for is the wrong numbers calculated. You can use this to calculate incorrect encryption information.
26:41
You can use it to bypass stuff like a password check or anything else. And again, you can get started really easily just to use a small target. You load some simple code like I showed you, like that for loop, and you just start trying different parameter sizes. So in the game, the chip whisperer light supports the same idea with having
27:01
that electronic switch all integrated on. So hopefully this really quick presentation has given you some pretty interesting sort of thoughts about why side channel power analysis is fun, and it's not that difficult, even though it might seem like a really complicated thing, just with a little bit of experimentation on your own, you can probably get started in it.
27:21
So at that point, if you want to contact me, there's various ways, and everything's posted on chipwhisperer.com, get and stuff like that. So, questions if there's time? One question? No questions.
27:42
Okay. Thank you.