 Our next speakers we have Ramiro and Niels and about two years ago at the CCC camp Ramiro told us about how to hack microcontrollers cheaply with an Arduino and similar electronics. Now here Niels are going to present the topic of Niels master's thesis. They are both security analysts and they have turned their attention towards cars and towards all the little microcontrollers and all the electronics inside it and they will show us why even a car that's where the code is coded to safety standards isn't necessarily secure. So please give a big warm welcome to Ramiro and Niels. Thanks everybody for being here. In the next 45 minutes more or less we'll talk about automotive microcontroller security. So first we will introduce a little bit what is for injection we will introduce what is the standards for automotive security. We'll explain as specific experiments we run on these microcontrollers and how we break how can we break JTAG in these microcontrollers and finally we will do some recommendations about how to prevent these attacks. So first let me introduce ourselves. I am Ramiro I am security analyst senior security analyst and my colleague is Niels maybe Niels you can move there so they can see you in the screen. We work at RISCure which is a small hardware security lab. We are specialized in hardware. We sell tools for hacking hardware and we also sell services, evaluations for embedded systems and chips. We have a lot of experience in many markets as markards, embedded systems, payment and in the maybe last two years we also focus on automotive. So when we came into this industry or we started to work with this industry we found the following. So this is what most of the people is doing or other analysts or other hackers are working on. So they are working on the services online or the connectivity between the car and the services or the car gateway, the buses, the cab buses and at the lowest level some of them are working at the ECU. So the ECU is the computer in the car. Maybe you know about these hacks, the Jeep hack I guess everybody knows this. Maybe you know about Tesla recently also has been hacked a few times in the past. The Nissan, Mitsubishi this was hacked with the application. So probably do you know many more examples than this. I think that in the past week they saw another attack on the car. So there are many of this. So a lot of people is working on these layers, especially in the communication between these layers, but we are focusing on what we are better in the lowest level of the hardware. So we are focusing on attacking the car from the microcontroller. This normally means side channel attacks and full injection attacks, which I don't know if you are familiar with this. So in case you are not familiar, I will explain what is full injection. So when you design embedded system, you choose a chip, a microcontroller, and then you go to the data set. And normally you find something like this. Like you can operate this microcontroller between 1.8 volts and 5.5. If you operate at lower voltage or higher voltage, they tell you that it's not safe, but they don't tell you really what is going to happen. But we can imagine that if we run for a long time about 5.5 volts, which is the limit in this microcontroller, for example, or below 1.8, we can imagine, we can guess that probably if we run about 5.5 volts, we will have fire. The chip is going to burn probably. And if we run below 1.8, the chip is going not to work, it's just going to sleep, it's not powered. But the question is, what happens if we have something like this? So we operate the microcontroller or the chip for just a few nanoseconds or microseconds above or under the range of recommended or the safe range of voltage. So when this happens, this is what we call a glitz. We have a glitz. Normally what happens is that because this signal, the glitz, the power peak is transferred to or is distributed across the chip in a different way. Certain IPs or certain hardware blocks will be affected by the glitz and certain will not. So for example, we affect the CPU and for few clock cycles, the CPU will not work, but the rest of the chip will work. So it can be that the inclusion model is still working all the way around. So when we do these glitzes, normally we have these kind of effects. We can have bits that flips. So we have in the memory or in the register, we have 0s and then they flip to 1s or we have 1s and they flip to 0s. We can prevent accesses to memories. So for example, the CPU tries to access to an internal SRAM or to an internal register and then with a glitz, you prevent the access. You make the logic to access to the memory to fail and then you return, you get 0s or you don't write whatever you wanted to write in the memory. We can skip instructions. So we have a CPU and it's running a set of instructions and then we inject a glitz in just one specific point. That point, the instruction that is running that point probably will not be executed. It will just skip. Sometimes we can disable modules. So we inject a glitz and a hardware module just will fail. JITAC or will be encryption or whatever. And sometimes we have a chip destruction. So we inject a glitz. Even for few nanoseconds or microseconds we have a set of voltage. It happens that maybe an internal trace of the power within the chip will be fused, will be burned. So this can happen. So in order to understand better what is if I for injection, I will let my colleague Nils to do a demo. Okay. So now to show you that it actually works. I have a small setup to demonstrate what fault injection can do. And I have a camera here to show you what I have on the table. So what I'm attacking is this small Arduino nano. It communicates over UR through these cables here. And the power comes through these two cables here. And if we follow the power, it goes through this amplifier which increases the amps because the tool that actually sends the power signal does not provide enough amps. And this power line will be glitched like we saw in the few slides ago. Now we need to figure out when we have to do this glitch. And for this we monitored the UART communication coming out here, which goes into this GPIO pin and it watches for a certain UART pattern. And when that pattern happens, this to this cable, a glitch, a trigger signal goes from one core to the other core. Because this little box here, spider is one of our in-house tools. And it is it contains two cores, spider core one and two. And spider core two can sniff data and then using the GPIO pins here, we send the signal to the other spider core. On this Arduino, there's a small piece of code running from a hardware capture deflect that we were running last year called the riskier hack me. And this is one of the challenges from that capture deflect. So what it does is it prints an initial message that says level one. And then it goes into an infinite loop here, which will print lock all the time. And now you have to exit this loop in order to obtain the flag in this final lines of code. And this code is running right now on the target, which I will show you in this terminal. So you can see here the lock message going on and on and if I reset, I get this level one message and then chip status lock, lock, lock, lock, lock. And now the goal is to use fault injection on this loop here. And then we go out of this loop and we try to get the flag that's hidden here. So for this, I have a small Python script to control the spider. Here's some setup, blah, blah, blah, blah. And this is where we I program the trigger on UART on the pattern lock. And then here we wait for this trigger. And when we see the trigger, we do a glitch, which is the short drop in power that we called the glitch before. So this will run with, will run not. Okay, so now it tries various parameters for this glitch to try and find parameters for which the glitch causes a fault. And that fault should contain the flag message in its output. So here we see a bunch of attempts being made. And depending on how difficult your target is, this can take days or weeks or minutes. In this case, the target is not that complicated. So if we leave this running for about an hour, we will start seeing a bunch of successful glitches. For this demo, I have some parameters that will do that a little quicker that I already found, which I will run now. And now you can see in the output that we get this flag message that we were looking for. And that's fault injection. Okay, one comment, we did the demo with our own hardware, but you can do the same with just very cheap hardware. You can just spend 20 years and a half a setup to do exactly the same. Actually, my colleagues here are going to think today or tomorrow to do some demonstrations of how to use cheap hardware to do this kind of attacks. If you're interested, just come to our village, RISKUFEFE, and then we can show you. Okay, so we see that if we, in this case, we were dropping the voltage. It was dropping the voltage, right? We were dropping the voltage below the recommended, and we were having these glitches. We could also go higher, and probably we would get also glitches. But we can also do more things. So for example, we can just try to play in this area, which is not recommended. So operate at higher speed, this micro controller, and with a voltage which is not in the safe area, and then we will have glitches. But basically, if we go to the data set of the micro controller, and we find specifications that the data set recommends you not to exceed, that's an interesting point to do a glitch. So for example, this is the data set of this device. Oh, sorry. Sorry, back. Yes. Exceeding these specifications will produce a glitch. Always that you exceed it in a very short period of time. If we go through the data set, for example, we find this specification for clock. And this is very interesting. Here they tell you that you cannot have between two periods, clock periods, you cannot have a difference bigger than 2% of the period. What happens if you exceed it? They don't tell you. What will happen is that you have a glitch, a clock glitch. The same with the reset. They tell you in the data set that what is the voltage for the reset, and what is the minimum pulse width of the reset. If you have a reset which is smaller, that 2.5 microseconds, what happens? They will not tell you, but you will have a glitch. So we have different techniques to do glitching. We have voltage glitching, which is the one we have to do. We have the clock glitching, reset glitching, and then we have fancy ways of doing glitching, which is electromagnetic fall injection. We use a coil that generates EM pools to affect specific areas of the chip. So we want only to affect, for example, the crypto hardware. So then we put this coil on the surface of the chip, just wherever is the crypto hardware, and we inject EM pools. And then it will create a glitch in this IP. Only the IP we are targeting. Or we can use lasers. We can decap the chip, remove the packets of the chip, and then we inject photons with the laser to affect gates. So we can literally chain bits using this technique. Then you can also play with the temperature, but the problem is that you cannot do it very quickly. If the chip is operating at a room temperature, you cannot set it very high, very quickly, and then drop it again. So we use this mostly by raising the temperature, you can make the chip more sensitive to other glitches. So any of these previous techniques, I mentioned it, will have similar effects, all these effects. So you might think that this is not very common attack, that this is not very useful, that right now there is not many examples on life, on the wheel, that I will use these hardware techniques. But the thing is that many industries have been dealing with this problem for many years. And maybe you are not even aware of that. So maybe you know this. The Xbox, the chip for the Xbox was a recent glitch. You could hack the Xbox by putting a specific circuit which was glitching the recent line of the Xbox. The same with the Nintendo Wii. This one was doing a power glitch on the voltage of the CPU. This is a wasabi chip, I think. And if we go back in the time, I think it's the first reference I heard of using a glitching for breaking a game station console. The oldness, there was a way to break the anti-copy protection in the card rights in the games by using power glitch on a CPU or a security chip that they had. And maybe this is the ultimate age test. Anybody? Anybody knows the relation between these two? Yeah. Okay. You are too old. Yes. Okay. Yeah. So I don't know. I remember when I was a kid, you could go to one of these arcade machines and use the PSO electric for a lighter. And this will generate a spark that will confuse the coin, the electronics that detect the coin and will give you credits for free. So still this trick is working. So there is some people that is doing it. This is a video from YouTube. They are not using a lighter. They are using something more sophisticated. It's creating electromagnetic pools. See the screen? I wonder if you can overflow it. Okay. Let's stop it. So games industry have been dealing with this problem for many years. But probably the industry that have been dealing with this problem for longest is smart cards. So this, for example, maybe you know what you heard about this. This is called Unlooper. This device at the right. It was used in the around year 2000 to unprotect, to glitch smart cards and protect them so you could watch pay TV for free. So this was used 17 years ago. The good news is that we have some techniques to prevent these kind of attacks. We can use software and we can use hardware to prevent. So we can design, we can code the software in a way that is more secure against these kind of fall-in-checking attacks. Normally these techniques are based on checking things twice. So for example, if you are checking a password, so you check first time and then you check a second time. Maybe they inject a glitch in the first time you were checking the password. But then you have a second check that will detect if there is any error and will not allow you to access to the system. So there are different techniques for software, software techniques, and there is also a lot of techniques for hardware. So team manufacturers can do something at hardware level to prevent glitches. Smart card manufacturers and secure chips manufacturers have been implementing these contraversers for many years now. One of the most common, or the two most common contraversers are monitoring the signals. So detecting any glitch, any peak in the power or in the clock or in the reset. And adding redundancy. So those models that are important or are critical for the security of the chip, they duplicate it and they run in parallel. So maybe a glitch will affect one of the modules but not the other. So by running in parallel, you have more chances of detecting the glitch. So when we started to work or to research in the automotive market, we already have a lot of experience in other segments, in other markets. And we tried to find or to assess what was the security level in automotive for against this kind of attacks, all injected on the side channel. Then the first thing we did is try to find standards against standards that define some kind of contraversers or regulations against this kind of attacks. The problem is that there is no standards. The closest thing is the ISO 26262, which is not a security standard. It's a safety standard. So if this standard regulates what happened, there is a problem in the chip that is in your car. So because the chips in the cars operate in a very noisy environment, there is a lot of noise because the engine or because, yeah, the engine, the sparks from the, you know, the book coils, I don't know the English word, the sparks for the engine. They introduce a lot of noise in the power of the ECUs, the computers in the car. There is a lot of regulations to prevent the chips to crash. So in this standard, ISO 26262, they talk about full injection, but as a technique to test if your chip is safe against this noise in normal operation of the engine or the car, the ECU. This standard defines the ACL, Automotive Safety Integrity Level. So this basically is a level which is given to devices based on the risk, the pressure to a risk, how it is to control the risk and the severity of the risk, and then you will get a level which can be from A to D, being A, the chips or, well, the system that are less safe, and D, the more safe systems in an automotive or in a car. There is also a QN level which is only given to devices that have no special mechanism to prevent anything, basically. So QM is just normal chips. So we took a look at this ACL-D safety mechanism that this automotive micro-controls have, and then we found the following that they implement these two mechanisms to prevent errors in the chip. So one is the CPU lockstep. So two CPUs run the same code at the same time, only that they are separated by a number of clock cycles. So if there is a problem, because, I don't know, gamma ray or because noise coming from the engine, whatever, maybe one CPU cannot execute properly the instruction, but the second CPU will. So the two CPUs are running in parallel, and they are comparing the output of the seclusion to see if there is the same. If it's not the same, there will be an interruption and there will be some kind of routine that stops in a safe way, the car, or whatever. And we also found that there is a lot of redundancy in memories. So many memories are redundant, so this way you can inject a glitch in one of the memories, flip one of the bits in the memory, but not the other. So these mechanisms are very similar to those that we found, or we find, in a full injection protected chips. So smart cars, for example. So we were wondering. We know ISO 2626, too, is about safety, can be also used as security, can be also protected, this standard against full injection techniques, because this is something that many people think. Many people think that the lockstep in the CPUs will prevent full injection to succeed in these chips. So this is the research we did. Nils? Yes. So this is where the experiments of my master thesis come in. So to investigate how effective these particular counter measures are that we find in the automotive target that microcontrollers, we took three chips. Two that fall on the ACLD spectrum, and one that falls all the way in the other side on the QM spectrum. So these two, the red and the blue chip will have these particular counter measures, so lockstep and parity checks, to prevent faults. And they also use various degrees of architecture. So these two have, the bottom two have arm, use the arm architecture, and the blue one uses PowerPC, which are the two most common architectures found in the automotive world. Then we took two techniques from the techniques that were just listed. We took voltage glitching that I demonstrated, and we also had a look at electromagnetic glitching. And the nice thing about electromagnetic glitching is that you can localize your glitch more than with voltage. In voltage you affect the entire power plane that you are glitching while with EM you can sort of target your glitch to a specific point on the chip. It's not as precise as a laser, of course, but it is still a nice upside. The downside here is that you also, in addition to finding when to glitch and how hard to glitch, you now also have to find where to glitch. So the initial thing we found in our experiments is that we could not successfully glitch the blue target with EM with voltage, so this was only glitched with EM, and the other two targets we could do both. Then we did two kinds of experiments. First we did characterization experiments, which are very simple snippets of code that was also similar to the snippet of code that was running on the Arduino that we just glitched. And the purpose of this is to find out if you can successfully inject falls in your target at all. One of the nicest characterization experiments we did here is where you simulate the behavior that happens when some authentication happens, and the result of that is stored in a flag, and in this case we just set it to one, and then if the flag is equal to zero, we are authenticated, and otherwise we are not authenticated. And you see here that the branch that says not authenticated should happen because flag is not zero. And what you can do with fault injection here, it's better to see if we switch to an assembly view of this code, so you will get a load flag instruction, then you will get a compare instruction, then based on the compare we will branch to a certain line in our instruction set. In this case we will go to the not authenticated line and continue. So if we just change this one red bit from one to zero, all of a sudden our branch instruction changes to a store instruction, which if it does not corrupt our execution flow in such a way that the system outright crashes will mean that effectively we have just erased this if check, and we are now authenticated. So any fancy authentication crypto stuff you can just bypass it afterwards. So we did these characterization experiments on the targets, and then what we have left with finding is when exactly this if check happens, and how hard we have to glitch to affect the amount of the bits that we want. So in order to do this, first we look at what happens in normal behavior, and from that we determine windows where we expect that glitches might be successful, and then we just start shooting that for a day or two, and we start plotting them in nice graphs to identify where sensitive areas are. So first you will see some green spots, which means nothing happened, and then you will also see yellow spots, which means that the target either died or reset. So we are glitching too hard in the yellow case, but not hard enough in the green case. And then if you set up your experiment correctly, you also start seeing successful glitches, and that's indicated by this red dot in this particular plot. And then we have one additional category, which is this pink on the left, which means that the glitch was detected by the countermesh is present in the targets. And then when you run this overnight, you do 100, 200, 300,000 attempts, and then you start getting these nice graphs where you can see that if you are glitching hard enough, but not too hard, then if you go into that sweet spot, you will have successful glitches, which in this case are not detected, which was a surprising result. So in this particular case, about 25% of the attempts were detected. And if we look into the registers of the target, we see that over 90% of these detections originate from the lock step mechanism, so where you have two cores doing the same thing. And then a smaller amount is because of the parity checks that are in place. Yeah, just to draw some numbers at you, if we find very specific fixed parameters for our ideal glitch, we are able to glitch the simple targets all the time. We are successful with our more ASIL D targets around 60% of the time. So for us this confirmed that safety is not the same as security, at least according to this standard. No, just a single fault. The question was, do we need two glitches? And the answer is no, we only have one glitch to do this. Why? That's a good question. We have some theories about that. We were expecting to have two glitches to need two glitches for affecting both CPUs, but we found that one single glitch is enough. And then we have two theories. One is that we are affecting the flash, so the flash pad. We are basically glitching before we are going here. So here somewhere. And the second theory is that because this is an ARM core, ARM Air 4, I think. It has seven stages pipeline. I think it was seven stages pipeline. So maybe because the pipeline seven stages needs, its instruction needs seven clock cycles. The CPU lockstep is separated for two clock cycles. If we inject a glitch, we are actually affecting the same instruction, but in different stages. So maybe the first core we affect during the fetching and the second core we affect during the seclusion. So still, we found this quite surprising to be honest. We were expecting to have, to need double glitch. Yeah, but we don't have detailed documentation and views into these targets, so it's very hard to determine exactly what happens. Okay, so now that we know that successfully inject false at our target, we wanted to do something more meaningful. And for this, we chose to attack the locking mechanisms in these targets that lock the JTAG down. And people, yeah, you want to lock your JTAG when you put your chips out in the field so you, so people can't just extract confidential firmware or valuable intellectual property. And from a more academic point of view, this is also interesting because before we knew what was running roughly so we can make guesses about where we have to inject our fault. And all these locking mechanisms happen in hardware or in ROM code that we don't have access to. So now we are basically, we have no idea where we have to glitch. So we need to find other techniques to investigate where we need to do fault injection. For this, we resorted to site channel analysis because by looking at the power consumption of a target in a locked target and in an unlocked target and then comparing the two power traces, we thought well, maybe we'll see a difference and that's likely where the JTAG is being locked. And we, if we do fault injection on that point, we will either keep the target in an unlocked state or unlock it. So, yes, what we do here, we take our power measurement, we see that we have power on, power off, but we still have no idea what's happening in the middle. And that's why we look at an unlocked and a locked version. So for the first target, we have, you see here, a brown line and a blue line. And that's, those lines represent the locked and the unlocked power trace. And when, here we see a very clear difference at this point. So here we do fault injection and we were able to keep the JTAG unlocked. Sorry, just to clarify what we did is just, we run. So from the data set, we knew that somehow the JTAG lock is being set up during the boot process of the chip. So we run the chip, unlock it, unlock it. So we have this chip, we both have developed a development board and then we program this board, one board with the JTAG lock and the other board without the JTAG lock. And then we were acquiring with a scope the boot up process and we compare both boot up process and we found a place where the power signal was different and we were assuming that because the only thing that changed from one board to the other is the JTAG lock, we assume that this is the point where the JTAG is configured. So what happens if we click here? Yes, thanks for clarifying that. We did the same on the other target and we found a similar pattern that if we configure more or less configurations for JTAG, we see a clear difference in how much power is consumed at this point and we do a fault injection here and again we were able to keep it open. The success rates are slightly lower than for the characterization. So if we start again with broad parameters, we narrow them down to what we find to be the optimal parameters and you see the percentages here. The simple target was very trivially unlockable, however the ACLD targets were slightly harder. We need around 100 attempts to get one unlocked also before we were able to completely bypass all the detection mechanisms and in this case we were not able to do this around 3% of the attempts were detected which means that if these detections are handled in a smart way you might break a few devices before you are actually able to unlock one however when you see the difference between 1 and 3% it means that you might just kill 3 out of 100 but 1 in 100 will be successful so if you just buy 10 you'll be fine and now my colleague will explain some of the consequences of what Okay, so we proved that using glitches in this ACLD automotive SOCs, microcontrollers we can change the flow of this program and with this technique we were able to unlock the gyta so what are the consequences of this so the most obvious one is that we can unlock the gyta we can steal the IP in the ECU in the microcontroller let's imagine for example there is a lot of companies which is putting a lot of money in researching autopilot for cars a competitor can take this ECU that do the autopilot break the gyta and extract the IP which will help them to develop their own autopilot for the car so this is an example of what can happen but if you dump the software then you can also try to reverse this software, this binary and use it to find vulnerabilities these vulnerabilities can be remote so if you dump, I don't know the telemetrics the telematic module or the module in the car that connects to web services dump the firmware, reverse and then try to find a buffer flow or something that you can exploit remotely you can also try to find keys so many of these these ECUs have some keys for example for the remote the remote to open the doors or for the OTAs for updating the firmware of the car remotely so there is some keys so you can try to reverse them so for example we are interested in the UDS keys these are the ones that are used to to update the firmware using the ODB2 port on the fly on the air update keys the remote and the mobilizer of course so to prevent the car to be stolen there are some keys maybe you remember this last year Flavio did a demonstration in Eusnix he was able to dump the firmware from a remote sorry not a remote it's from an ECU the ECU in the Volkswagen car that controls the remote he was able to dump the firmware he reversed the firmware and he found that in some cases the keys share and all the cars use the same key in other cases the keys derive it in a very simple way he was able to unlock almost all the Volkswagen cars so this is an example of what can happen with this if you can unlock the JTAH and extract the firmware you can use it to find more exploits or more vulnerabilities and maybe less obvious something that you can do also you open the JTAH is to modify the firmware this can be useful for tuning there is a lot of people that has been doing this for many years to add more power to the cars or to other things in the cars but this can also be used for sabotage let's imagine that somebody wants to kill a person in the past you cut the brake fluid cable now you can just break the JTAH update a new firmware and then make the car to collide or to crash when it's 120 kilometers per hour so this is a possible scenario and nobody will find any sabotage evidence because it's in the firmware so what can we do there are some things we can do the first and most obvious is to add countermeasures there is things you can do at hardware level and software level so even in the system that are already deployed using the current chips you can use software to minimize the risk or to mitigate a little bit the risk but the most important thing is maybe that you don't have to reinvent the wheel so there is already a lot of solutions out there smart cars manufacturers have been dealing with this problem for many years so if you go to internet and you search you google you will find a lot of papers a lot of papers talking about different countermeasures against phone injection so you don't need to do nothing fancy you can just only see what is people doing already there and a specific recommendation is that we found that many times we were trying to inject a glitch and the glitch was successful meaning that we were able to bypass the security mechanics we were trying to bypass but the chip detected that something was wrong so there is some register that indicates if the chip detects some kind of glitch or something that is wrong so it's very tempting it has a programmer to just ignore this so there is the chip says that there is something wrong and you don't process this interruption to I don't know to stop the chip it's very tempting to do that but if you do that maybe somebody is trying to do phone injection and disabling one of the safety mechanism yeah now we are doing more research continuing this this line of this topic we are trying to find of all the safety mechanics in these chips which ones are better to prevent glitches and we are trying to apply this attacks on real ECUs and real cars because all this we were doing in a development board for these chips so we were not really attacking a real ECU we were just buying these development boards and then trying because it was easy for us so now we are trying with real ECUs and finally we have a specific obsession let's call it with UDS which is a protocol in the car we are trying to break this protocol using phone injection thanks God there is now some standards they are being defined right now the 3061 J3061 and 3101 these standards will address this problem actually the 3061 the first part of this standard is already there and they talk about side channel and they talk about phone injection but they talk about this in a very superficial way in theory or I expect when they elaborate the next parts of this standard the part 2, part 3 they will talk with more detail about what do you have to protect against phone injection side channel A-C-S-I-E L like the ACL levels but for cyber security and this 30101 will also address this problem but this one is still working in so we don't know what is in there so maybe in the future there will be some standards and some protecting against this phone injection techniques oh no sorry this one if you want to know more details about this research we will publish a full paper in the VTC 2017 this is next month in September you will be able to download the paper with more details I know that this phone injection side channel is very confusing very abstract so you are interested in knowing more details tomorrow our colleagues will talk about how to use against phone injection to bypass secure boot and I think it's a phone I don't know tomorrow and we have in our billets we have some demos and workshops about phone injection side channel so you can come and visit us at 5 we will have a demo on side channel how to use open software tools for doing side channel if you are interested in that sorry it's in our tent it's called RISQ FEFE and it's next to the Spanish Spanish hacker space it's in the hopper field that's you can try to find us in the weekend so any question sorry I forgot something actually I forgot something I guess I forgot something sorry yeah you forgot something so I demonstrated this this fault injection on this small Arduino which was part of a capture the flag challenge we were running last year which is called the RISQ HACME and we are now in our third edition which goes lives on Monday so if you are interested in doing more hardware oriented capture the flag style challenges you should definitely register and we also added some automotive components and we are working with the company Argus cybersecurity to make automotive specific capture the flag challenges as well so if you are interested in hardware security for an injection side channel and automotive hacking then you should sign up for this we will send you a board if you qualify by passing some challenges we will send you a board with some challenges you have to hack and that's it any question thank you very much very interesting talk about something that I need to try out the next weekend so we now have about 12 minutes left for Q&A session please line up on the microphones in the middle and I see there is one question already hey there thanks for this great introduction to the topic and the demos I have a question about the ASL standard why did you choose the colors I wondered that you gave for the best class the red color I would give the green one but why give it a red one I don't know do you have an excuse I'm sorry the development board is red thank you hi how likely do you think it is that the development board doesn't have any protection against stopping this kind of injections because in the end it's only that whereas when they actually deploy it they will detect intrusions and say okay after three intrusions yeah we tested the safety mechanism or the security mechanism in the chip, within the chip because it's in the chip, this development board yeah have those of course manufacturers can put more detection mechanism in the entire system in the PCB they can put more but the thing is that you can always remove from the board and test it in your development board so you remove any of these mechanisms in our experience we normally have to modify a little bit these PCB boards because the capacitors in the VCC line in the power line filter the glitches so we always have to do small modifications in the boards so we will have to do the same for this real ECUs but I don't expect any kind of safety mechanism in the ECU hardware that we cannot bypass by just removing the chip and putting in a different development board any more questions please line up yeah one more did you kill some of your devices while testing I think one died because of the EM but that's it and we put one in the acid to see the how it was inside that definitely didn't work anymore thanks yes please how much of a problem is it actually to access the memory via JTAG because usually I think in my experience in larger boards the memory is usually externally so what can you actually do with a JTAG that you can just do by desoldering the flash whatever this is a microcontroller so normally when you have a microprocessor the memory is outside the microcontroller normally the memory is inside so of course if this is a microprocessor you can just tap directly the lines that go out of the tip and then you don't need to do all this you don't need to open the JTAG to get the firmware but in this case in microcontroller the firmware is inside the chip you need to open the JTAG in order to read it I believe that normally when they have external memory they encrypt it and they only decrypted once it's back into the controller yeah that's true some security features are quite common in some microcontrollers or microprocessors sorry those that implement secure boot normally they have encrypted flash sometimes encrypted DDR that's absolutely true and then in that case you can also use the JTAG to open it and then get the decrypted firmware one more question ok this way a lot of microcontrollers now come with encryption engines to make things possible quite quickly on the chip have you tried to focus attacks on that area of the dye using EM or maybe laser or other techniques to see if you could do something with that of course this is actually part of our work there is a specific technique called differential fall analysis where you use a glitz to affect the stages of the crypto engine and then by injecting different errors you get different outputs with the same key and then you can by comparing them you can extract the key without knowing which one is the key so if you are interested in that maybe the guy in front of me can give you a lot of explanation about this thank you very much if there are no more questions if there are more please line up I have one question so lots of microcontrollers almost all of them come with multiple supply pins have you tried how much different it makes if you just glitch one or a few of these supply pins to affect special areas of the chip sometimes these different pins are power and different internal power planes so one is for the analog electronics the other is for the maybe the CPU a different one is for the cantron sear so the first thing we have to figure out is which one is the one the CPU is running from and then we only inject the glitch in that but many times in the documentation you don't know because the documentation only say BCC so then we don't care we just try all so it will be less specialized or less specific glitch because might affect many things that we are not interested but at some point this is a game of of a statistic let's say we try one medium time for full injection attacks and then maybe one will work because you have one single one single glitch will be enough to unlock the JTAG and extract the pure war so cool so I see one more question when you do such an injection how long does one injection take is it milliseconds one second no it depends from target to target so normally it's often it's related with the speed of the CPU so if the speed is very fast and you do one microsecond you are affecting many clock cycles and then yeah probably you will kill the chip or crush the chip so normally it's related with the CPU speed but it's more in the range of nanoseconds like 60 nanoseconds to I think the longest I have seen is one microsecond I have okay I actually wonder how long you need to do the experiment glitching it many times in a row before you actually have a success are we talking half a minute or a day so the experiments that I showed you these percentages they are obtained after running a few days typically you turn it on before you go home you leave it running over the night you come back, you see your results and then based on your results you change your parameters and you iterate this process like three or four times and then you are successful so you need five days to find the real parameters so how much time you need to glitch where and what is the voltage and then when you repeat these parameters you have a high successful rate so then you can glitch it maybe in less than one minute so you have to try less than 100 times and then you will have a glitch so less than one minute or two minutes do I understand correctly that you reset the system between these attempts yes useful because sometimes the glitch affects some modules that you are not aware of so do you think that the CPU is working properly after glitch but some hardware model has been affected and then it's better to have a full glitch sorry a full reset before continuing glitching but it depends sometimes we do sometimes not but it is useful for example in this demo it takes about three seconds to completely boot the device so then I only reset when I stop getting responses or I was successful and every attempt if nothing seems to happen I just keep shooting and not resetting but next time the next boot everything might change quite a bit right in timing or different things happen it's still not you have to find a trigger point which is close to where you actually want to do your footage action you can't just start counting from boot time so yeah before you said there was only one glitch and not two in those two processors the lockstep how can you be sure of that or how can you count how many glitches there were we inject a glitch with our tools we say to our tools inject a glitch and we were expecting because there is two CPUs we were expecting to have to inject two glitches separated by two clock cycles but we found out that one single glitch is enough I don't know if this answered your question ok ok one more could it be that you actually glitched the comparator which that actually give you the result it could be but I don't think so the reason is because the comparation is combinational logic so you can affect it but immediately we'll get the previous value it could be but I think it's not very likely but it could be we don't know because we don't have the internal I don't know we don't know how it works internally if there are no more questions now you have the village you have the talk tomorrow yes maybe I can mention that if you want to see the demo more closely you can also come down to the village and it will be running there ok and then please give one more thanks to this awesome talk and to our speakers