 Nick and Albert from the Netherlands will talk about embedded systems and especially on the topic of the secure boot sequence of embedded systems and What to do to come around this? Okay, give a warm applause to Nick and Albert Thank you. Thanks for joining on this early morning. If you will be standing here I probably wouldn't be in the room because it's very early So we are Albert and Nick and we're here to present bypassing secure boot using fault injection So this talk is consisting of a few Subparts so we will introduce fault injection first and then we'll give an introduction to what secure boot is and then Albert will take the word and I'll actually detail various ways how you can use fault injection to bypass secure boot we will also touch briefly on the Practicalities of an attacker. So when you are actually doing secure boot What are the things you have to overcome and also what can you do as an implementer to minimize the risk for these type of attacks? One disclaimer. We're not really talking about you fee Secure boot here really talking about proprietary secure boot implementations that are implemented on embedded systems So these are typically very different from each other because defenders are free to implement whatever they want So we are hackers at the riskier where we test the security of different types of devices riskier both makes and uses tools to perform side channel analyzing fault injection and besides that we also do all sorts of projects in order to test the security of software and hardware and This talk is actually a little bit of both So we'll be using the tools we create and also the tools will be using and they're actually laying here in front of those And they will be used during the demo So first of all, I would like to start with a definition about fault injection when we talk about full injection So when we talk about full injection is really changing the intended behavior of a target by introducing a glitch To give an example what you can do for example, if you look at this Very simple code that is used to open the door based on the validity of a key using fault injection We can inject the fault at the if statement and that allows us to change its intended behavior And this results in us opening the door without actually having the correct key But of course how can these faults be introduced? For the people that were yesterday at the talk of Ramiro and Niels, they introduced fault injection Already a little bit so we're not going to too much detail But typically there's multiple techniques in order to change the environmental conditions of a target And this allows you to inject the glitch and this actually results in a fault that will create these changes in the intended behavior And one thing to realize is that these changes can be both in software and in hardware and another Characteristic of fault injection that it's you really have to be External to the chip so you cannot do it from internal so you cannot have software running on the device that generates this environmental change Or it's not likely that it's possible. They really have to do it externally So to give one brief example what the basic idea is of a glitch For example, if you look at the voltage that's provided to for example an arm core if we make a fast dip in this voltage It will actually cause a glitch inside the chip which will result in this change in behavior And it's important to do this not too soft because then no change will occur and not too hard because then likely the target will not continue anymore So we're doing it not to soft enough to heart We will affect only the intended behavior at that moment in time and we do not affect the continuation of the target So when you do fault injection There's different things that can go wrong in the target and this is just Some examples and typically we like to group the faults in two groups one that affect hardware that does software So you can think of processing core For example an arm core and the falls that affect hardware that is not directly involved in the execution of software So for the first group, you can think of changing instructions not executing instructions When data is being handled it is changed For the second group, we really talk about Hardware that of which the intended behavior is changed. For example, there might be security registers that are somewhere Stored inside the chip and that can be affected using fault injection or when data is transferred from A to B on the chip using dedicated buses This might go wrong when you're injecting glitches at that moment in time One thing to realize is that the true fault model for a given target is very difficult to determine Especially if you want to do it exhaustively so In order To be able to say something when we're presented by with code we take a shortcut So what we typically do is we just assume the target is vulnerable to Instruction corruption, so we are able to arbitrarily change the instructions that are executed And typically what you can do then is for example this if you look at this MIPS instruction We see if we flip one bit in the instructions and coding We actually do not add eight to the particular register, but we add zero and also more complex variant Is possible while multiple bits are changed and this allows us for example to change the load instruction into a store instruction But one thing to realize here is that of course you likely have limited control over what bits are going to change So typically you you cannot know this upfront and also one thing to realize that even though that this is a nice fault model and it is likely applicable to many targets, it's likely not the only fault model, but the advantage of using this shortcut is the instruction corruption The behavioral changes that you can have by using this model actually also cover other types of fault models for example if Register is read out by software that is not Related to the execution of software. It will be the same if that resistor will be read using load instruction if we change the storage into a store instruction because then effectively the red will not happen But in practice it might even be that the only the register actually is Glitched and not so much the execution of the software So this is a shortcut we often use So how does this go in practice? Well in order to do voltage fault injection you need some tooling and there's open source tooling available that allows you to do this And since these type of tooling is out Fault injection really became available to the masses So you do not have to create your own tool anymore. You can use this tool off the shelf and you Leverage on the community in order to perform fault injection At the risk here we use our own tooling and typically a setup looks a little bit like this So we have a workstation that is able to communicate With the Glitcher, which is the yellow device and to the target and in this case the target is Disneyland cyber board this house is a zinc chip Which is a system on chip that includes arm cortex a9 core in order to execute the software The Glitcher has various inputs and outputs and this is the bare minimum of what we typically use So there's one output is just a trigger which will tell us when to inject the glitch There's the output the VCC so that is the power that is actually powering the power domain that powers the arm core That allows us to inject glitches there We have one GPO Routed into a relay and this allows us to actually switch the external power supply of the board So whenever we inject the glitch and the chip gets into an error in a state We can reset the target in order to get to a known working state In practice a setup looks a little bit more like this So logically it looks all fine But this whole bunch of cables connected together all having their little purpose and this is roughly what's laying in front of us We made it a little bit robust so it would actually Still be alive after traveling over the camping, but it's roughly what is laying here in front of us So what we're running on the target in order to determine if a target is Vulnerable to fault injection attacks is a very simple program So we see first a trigger up that tells us when to inject the glitch and then then GPO pin will be raised And then we just execute a stream of add instructions which at the end increase a counter which will be sent back to the To the workstation and then the hypothesis is if this counter changes then we affected the intended execution of this software Meaning that the chip is not robust against fault injection attacks So we expect some outputs of which these are three examples So whenever we inject the glitch and it's too soft the counter will not change the counter will be 10,000 If we glitch too hard then the counter cannot be sent back because then the target either resets or it mutes And then we only get the counter string back and whenever we are successful the actual counter value will change so Depending on what's happening inside the chip this counter can be higher lower. It can be a completely different value And one thing of course to realize is that if you glitch too hard too often The then the target might actually damage permanently and then you have to swap targets in order to continue so There's one little thing you have to do first. So I Told you about the trigger so that is that GPO signal what you see and that defines actually the attack window So we know for sure that within those two moments in time the actual add instructions are being executed So it does not matter to us When we exactly inject this glitch because there will be multiple points within this attack window That are that are good But we need to find out how hard to glitch so what is too soft and what is Too hard so typically what we do is we randomize the voltage provided to the target and the glitch length and How Deep the dip in the power signal will go so typically we try to go to zero but due to capacitance is not always possible But by randomizing this We actually can determine What good parameters are and typically what we do is we plot This so what's happening here is If I stop it from a brief moment here on the y-axis is the glitch length That is in orders of nanoseconds and on the bottom is the Glitch VCC, which is in VCC and By actually randomizing the parameters and injecting glitches at that moment in time We actually see that there's some sort of a relationship between these Two parameters being the glitch length and the Glitch VCC at the bottom right You see the area where it's all green so then the combination of these two parameters means that's too soft on the top Left you see that is yellow so combination of these two parameters It's too strong, but you see happening in between you see some sort of a sweet spot Occurring so you see a curve there between the yellow area and the green area and that's exactly Where the parameters form a combination that allows us to Affect the intended behavior of the software without affecting this continuation So after the Glitch the target works perfectly the only thing that happened is that the program executed differently So if you run this for a very long time you get very nice graphs and for some targets this Relationships is different and nice patterns come up, but typically you see something like this So this tells us two things our setup is working correctly So we hooked up all the wires fine We modify the target correctly and also the target is not robust against fault injection attacks. So this gives This is a requirement if you want to use fault injection for something else Let's stop this so most secure embedded Devices have something in order to Protect the external Contents in flash and this is typically referred to as secure boot So for example, if you look at this generic implementation, which will look very similar to most implementations You're going to find in the field After the device set on we see that the first stage bootloader is loaded into SRAM by the CPU And typically this is done by some software that is stored in the ROM Which is read-only memory that will be the first code that is executed after power on reset and Then the second stage bootloader is actually loaded into DDR because typically the first stage bootloader is used to Initialize the DDR. It cannot use directly after power reset. You need some software in order to do this and Of course already mentioned it the contents in external flash are not protected so something needs to be there in order to provide integrity or Confidentiality, otherwise the attacker can change it and then take control over the device So typically what they do so I mentioned already the rom code is there and this rom code has access to a key And it's important to realize that those two parts cannot change So either the key is somehow tied to the chip either by storing a hash and The initial stages stored in ROM, which is read-only memory and Effectively they create a chain of trust, which is very similar to the PKI find-to-your-browser The difference being that there's only one root of trust here typically And so this root of trust is used to load the first stage bootloader and this first stage bootloader is of course Appended with a signature which is then used to actually authenticate the first stage bootloader a More complex variant is possible that the rom code also has access to symmetric T Which actually allows you to decrypt the first stage bootloader in order to provide confidentiality So that prevents attackers from reverse engineering the software stored in external flash However in practice a secure boot implementation does not consist of two stages or three stages It's typically consists of multiple stages So for example if you look at this arm trusted firmware reference implementation We see that there's multiple stages which are executed consecutively which all have to authenticate each other in order to Be sure that all software executed by the system after power reset is actually authenticated and trusted But this makes you wonder if there's so many stages Involved why do you why don't you bypass secure boot logically and I mean that's very true because I mean throughout the last few years We see numerous examples where actually secure boot implementations are being bypassed in a logical manner These are of these are two examples of this however one thing to realize is that typically these Early boot stages which run under the highest privilege level they consist on the They have a small code base, which means that there's a small logical attack service So this likely especially when defenders take care and they make sure that they Develop secure boot stages. The chances are high Much higher than for example the Linux kernel, which is a much larger code base that there's no logical vulnerabilities present And you need to leverage another type of attack in order to bypass secure boot if you want to do this So in this type of attack, of course is fault injection and there's others But this only makes sense to do this which is a sophisticated attack If there's something to gain during boot, which you cannot gain during runtime so I will touch on that a little bit later So there's a few disadvantages to fault injection. It is actually invasive. So you need to make modifications to the target You also need physical access. It's very unlikely You can do this remotely because you need to really have a physical presence to the target and Also compared to logical fault injection. It's expensive. So you need to have extra tooling It's of course is more expensive than if you would just use a kernel exploit in order to Take control of the device There are some advantages though. There's no logical vulnerability required Which we will touch upon later. Albert will show you this and also the standard embedded technology of today So everything you find in iot or almost anything you find in iot But also in other markets is not well protected against fault injection And this typically is because there is no solution that you can just integrate into your chip easily to prevent all these attacks And especially if you consider multiple different type of fault injection, which all require a different type of countermeasure in order to counter the The fault injection technique itself and Likely and as I said, I mean you need to gain something So during boot there might be assets available that are very interesting to to gain which you cannot get after the system is fully initialized So typically things you can access during boot or the rom code And this is the payload that is executed directly after power and reset So it's smart to disable access to this rom code when the system is fully initialized and you typically see this There might be keys available or stored or the usage of these keys might be only possible during boot for example, the keys used to decrypt the The stages executed after boot and also some functionality might actually be only available during boot So you can think of the cryptographic engines that are used to decrypt the payload Originating from flash So there was the introduction I would like to give the word to my friend Albert and he will continue Okay Okay, so Nick just gave us an introduction or fault injection and he gave us also an introduction to secure boot and why we need to do it And why why it needs to be there? So what we're now going to show you is some ways some Classic ways in which you can inject faults into secure boots and basically execute your own code Okay So if you have a secure boot implementation at the end of the day You're going to have to compare a computed hash against either a stored hash or a decrypted hash So when this comparison happens That's probably nice place to inject some faults. So This bypass is applicable to pretty much all secure boot implementations And it allows you to bypass that authentication. It does not actually allow you to bypass the encryption Okay, so what does it look like so here we have a snippet of code from the embed TLS Project, and I'm not sure if everyone can read it But here we have basically a memory compare of a computed hash against a stored hash And if they're the same we continue booting and otherwise We stop we give an error So this if this looks like a wonderful place to inject the fault But what does this really look like if we just if we compile it and disassemble it? So this is the code Compiled and disassembled. I'm not sure if everyone can read it But here's a memory compare and then depending on the outcome of the memory compare. We either continue booting or fail So in the C code there was it looked like there was one place where we can inject defaults and Bypass secure boot, but if we start looking here, there might actually be multiple places where we can bypass secure boot So for instance, we could try skipping the memory compare so not executing the memory compare perhaps we could try not executing that branch instruction and There are actually a couple of more places where a single fault will allow us to completely bypass this check and This is important because there are multiple locations in which a single fault can completely bypass this check Okay. Now, let's take a step back and let's look at the caller calling function. So this is a piece of code Which sadly can't be that well read But this piece of code is actually directly calling the code. We just saw so here. We see embed TLS PK verify And in that function is actually the memory compare we saw and Also here we have an if instruction and if we if it correctly verifies we boot and otherwise we don't boot and this code is Quite similar to the code. We already saw So that probably means there are also going to be multiple locations here Where a single fault will allow us to bypass secure boot So these bypasses they can happen on all levels. They can happen inside functions Inside their calling functions and inside their calling functions. Okay So I said we'd like to target These things with false injection, but how do we actually find out during execution when these are? So, I hope you'll after these couple of days. No, well, this is this is a power trace Of our secure boot implementation. It's an example trace of our own implementation And we can actually see a number of things happening And because it's our own implementation, we know exactly what's happening. So the first spike here is The copying of data from external flash into the chip then the second part is the decryption of The decryption of that image and the authentication and finally we have serial outputs, which means the image has fully booted Okay, so we're looking for that moment in which this decision is made between Executing this image and not executing it between verify between having proved that all the code is there and valid and it's not valid So, how can we find this? Well, we just use the normal image take a power trace and Then we corrupt the image and then we take another power trace and Then when they start to differ after before that point we need to have injected our glitch So in this case we just need to inject our glitch Just before the serial output because that's very very close to where that decision is going to be made okay so if you're an implementer and you find out that the image in flash is Not correct. It's been corrupted perhaps an attack has placed something there. What do you do? What do you do when signature verification fails a? Classic answer is to just enter an infinite loop So we've updated our code from the previous example We tried to compute the The signature and verify it and then instead of not booting we just go into a while one just an infinite loop I mean the target won't boot so problem solved, but let's have a quick look at the way this This code is compiled So here we have our code to embed TSPK verify and if we if the signature is correct We continue booting and otherwise we enter this infinite loop But there is a problem this infinite loop is actually directly above the correct code path So if we manage to inject a fault into a single iteration of this infinite loop will actually skip out and Continue booting and this is very nice for the attacker because it means that timing is not an issue You only have to hit that one iteration of an infinite loop this is actually a classic smart card attack and You know in general when you when you find out you have an invalid signature It's probably better to reset the device or perhaps even to wipe keys So I hope now everyone can read these power traces and can answer for themselves Where we need to inject a fault to skip out of this infinite loop And that's of course somewhere there Okay, so this is our last normal bypass our last classic bypass and that secure boot enable So as Nick introduced during the introduction there is actually a piece of OTP in the chip one-time programmable memory and This typically contains quite a lot of security sensitive Settings One of those settings is typically secure boot enable And secure boots enable is used because when people develop on these boards, they don't want to be bothered with secure boots But once everything's developed and it needs to be deployed to the field, they will enable this they will enable secure boots So typically just after the CPU comes out of reset something like the following code will run basically Basically the processor will fetch a value from some piece of memory maps Memory map region of a peripheral and it will fetch basically the value do I enable secure boot or not? Am I going to bother with all these? Hashes all these hash checks all that encryption and if you look at it like this you have that nice if That's probably also a nice place to inject a fault Okay, so these were the classic bypasses or All the classic bypasses and these actually work on works on multiple vendors products But those vendors have not sat still and they've also come up with Mitigations and typically these mitigations classically come from the smart card world and they can be divided into two groups the hardware countermeasures where the goal is to actually detect a for a glitch as it's being injected into the chip or As of all that a fault has occurred Now if your hardware doesn't support these countermeasures, you can also do a number of things in software however Countermeasures in software only lower the probability of a successful fault But they can't completely rule it out and they can't completely rule it out because they don't address the root cause Basically they can only detect that a fault has occurred and at that point, you know, you're already running on a stable hardware Yes, so with these software countermeasures, you can only lower the probability of a successful fault, but you cannot completely rule it out so while these Secure boot vendors and are building all these countermeasures They also use compilers and they turn on compiler optimizations and they do so because ROM memory size is limited in the end the ROM will directly go into the chip and This costs real estate this cost. This is wafer size and this directly translates to the production costs of the device and These compiler optimizations decrease the code size So that sounds like a nice trade-off however The compiler can actually optimize out intended code So I have some examples now Some classic examples So here we have a double check. We've implemented our mem. We've implemented two memory compares because It might be possible to actually skip out of one of them We might actually bypass one memory compare, but then we check again and you know, hopefully we'll actually find out That there was an issue that there was a fault So if we compare this with GCC without optimizations We see actually that there are two memory compares no problem and then we compile it with optimization level one. Oh, no Oh No are carefully constructed are carefully constructed fault injection countermeasure has been removed Yeah, so the compiler is of course allowed to do this because functionally nothing changes However, since we're in the domain of side-channel attacks suddenly this This behavior suddenly starts to matter a lot So we have some best practices for you the compiler is smarter than you and It really can optimize quite nicely But we can use volatile to prevent some of these optimizations We can force it to actually perform these comparisons twice or multiple times using volatile and Therefore we actually recommend that you actually read the output of your compiler at some of these critical places okay, so I said you should use volatile so I did here. I use volatile So here I have a volatile in pointer to some secure OTP value and then we read it out twice Now Something slightly unexpected happens when we compile it Perhaps not that unexpected we do actually get two loads from the same pointer So at least the memory access is there. It's there twice However, there is actually only one setup of the pointer So this means it might still actually be possible to actually bypass secure boot turn it on With a single fault because that pointer setup is only done once So actually the solution there is just to use the keyword volatile just a bunch of more times Okay So these are some Classic attacks some classic attacks. We've also discussed their mitigations and These mitigations have already been implemented in practice However, the attack surface for secure boot is a lot larger So let's move on There's some advanced attacks So our first advanced attack is called a combined attack It's the category of combined attacks and the combined attack is when you take one category of attack and Use and combine it with another so classically this is using fault injection together with side channel analysis But in our case we'll be using logical exploitation together with fault injection And we're going to take the easy approach here and this we're going to change the mem copy size arguments And we're basically going to build our own buffer overflow So you can imagine before the corruption we have a mem copy which copies a thousand hex for from source to destination And after the corruption we'll hopefully copy more data and we'll hopefully overwrite some critical variables And the nice thing about this attack is that it actually works even when dedicated hardware is used to perform this copy Because we're targeting the parameters of the copy So let's have a look at how that would work out So here is our embedded system as described by my colleague Nick So we have the bootloader 1.1 in flash Which will be copied to SRAM and then the bootloader 1.2 will end up in DDR However, there is something we failed to mention It's that the SRAM probably also contains the stack for this entire secure boot procedure So I think everyone can already see where this is going Okay, so here we have our code as it's running on the CPU It's setting up the parameters and then it will call mem copy So our goal will be to corrupt that size arguments and start overwriting stuff Okay, so we've prepared our flash We have a payload in flash followed by a lot of pointers So the payload is what we want to execute and the pointers all points To that buffer in SRAM where our payload will be copied Then as the system boots up we introduce a fault and Hopefully that again this fault will corrupt that size variable and We'll copy more data and then hopefully what will happen is we'll copy in the code our code followed by all those pointers and When this function returns one of those pointers will be popped from the stack and we'll actually jump directly to our code So that all sounds nice But we know we know about all these exploitation countermeasures. We know about stack canaries We know about ASLR. We know about no executes But sadly these aren't really ever employed during early boot stages So we can actually use classic stack smashing attacks Without too much trouble so I want to go back to this power trace and Also here. I want to ask I want to want you to think where do we need to inject a fault? To actually get this behavior and of course it needs to corrupt those parameters so just before we actually see a flash access perhaps SPI perhaps Some NAND flash just before that happens. That's where we need to glitch Okay, so my neck the next Combine attack is controlling PC on arm It's one of my favorites and it exploits an arm 32 specific Characteristic and that characteristic is that the PC register is directly accessible by most instructions So my colleague nick already introduced these fault models and he said, you know It might be possible that when we inject the fault we don't skip an instruction, but we actually just corrupt it So let's try corrupting some instructions to see what can happen So on arm 32 if you want to copy memory from a to b and you want to do so quickly You use these two instructions and these are from the arm reference manual and that's load data multiple and store data multiple And what load what the load will do is it will load data from the pointer R1 And it will load them into the registers R3 through our 10 and Then the store instruction will stall to the point R0 and it will store registers 3 through our 10 again so if we want to actually Perhaps add the PC register to this instruction all we need to do is turn on a single bit So if we flip that single bit from a zero to one We will actually add the PC register to the upper-hand list And instead of loading data from into R3 through our 10 We now load data in R3 through our 10 and the PC register When this happens The processor will just directly go exactly to the attackers code Yeah, so this one's very architecture specific, but there are all these slight variations Available on different architectures, but they're heavily dependent on the surrounding code So let's have a look at at this attack in practice We've actually have exactly the same set up as before We have our code followed by pointers in in flash And they will be copied into the system, but this time Instead of injecting a fault when we're setting up the parameters we're going to inject the fault during the copy and hopefully During this copy one of these pointers, so yeah and Hopefully during this copy will actually have a fault Which will actually move one of these pointers directly into the PC register And this will actually cause the processor to jump directly to our code Okay, so what's nice to see here is that actually if there are any software countermeasures Implemented against this they will not work because once the fault is injected we will no longer the Boot rumble no longer be executing and you will directly be executing already the attackers code So actually in fact against this attack. It's not really possible to construct software Software only fault injection countermeasures, and I really like this power trace. So what we do What we do here is we look at when that copy is still occurring from flash and at the end And when our code is being copied in but the flash pointers are being copied. That's when we try to inject the fault and Then hope for the best Okay, so my final combined attack is the wild jungle jump and it's my personal favorite so The basic attack is like this You start glitching Basically any time after your data has been copied into the system But before it's been fully decrypted or fully authenticated And the idea is that there are lots of magic pointers around and these magic pointers They point quite close to your buffer to your code or somewhere around it And we can get these magic pointers from anywhere we can get them from the stack we can get them from registers We can get them from memory and the only thing we actually need to do is make sure one of those That magic pointers magically ends up in the in the PC register and we'll have bypass secure boot and The more magic points there are in the system the higher to the probability of this actually working So these are the combined attacks We want to talk about so let me summarize these combined attacks allow us to actually bypass both the authentication of an image but also the decryption and Typically, there's little software exploitation mitigation during these early bootstations stages So there's no ASL are there are no stack cookies. There is there are no no execute bits and You know these fault injection mitigations which are implemented in software might not actually be that effective So this all sounds like we have, you know, a tremendous amount of power tremendous Tremendous amount of opportunities, but there are some practicalities which we must overcome So I'm now going to allow Nick to discuss these practicalities. Thank you So I would like to address these practicalities according to demonstration implementation Which is described here. So there's one big thing missing here There's no root of trust. So it's not really a real secure boot implementation, but there's one Authentication states in there. So stage one as access to an RSA key public key. It will load and authenticate stage two And we actually invalidate stage two by printing a different string different strings so we can identify it So originally there was something about blackhead written there, but of course, we're not a blackhead today So in order to invalidate this image, we changed it to something else, which will hopefully be shown on screen So again We have the similar setup as here one thing we failed to mention Explicitly is that we actually take power measurements of this board using an EM probe So that's the little probe you see denoted with the arrow and this allows us to look into the chip what's going on And these are actually real traces from this target So we actually see that there's a there's a small difference between the valid image and the invalid image and you see that There at the end There's a small spike missing and this indicates to us where we want to glitch. However to make this Easier we actually do The classic fail of entering an infinite loop. So for us It does not really matter if you look at these zoomed-in traces. We see that the Difference that we saw before is now much more clear because in time we see less of what's going on and And that's actually the moment in time where you would want to glitch if you want to bypass the Authentication, so if you want to write the signatures being verified There will be a path somewhere either signal is valid a signature is not valid. That will be that moment in time However, because we are entering an infinite loop we can glitch basically anywhere after that moment because the infinite loop is constantly running So that's exactly what we will be doing for the second demo which will be done live here on stage We will actually target this infinite loop So basically what we do we power on the target we wait long enough so that we're for sure in the infinite loop So in this case we wait around 500 or 600 milliseconds. I think For the glitch parameters because we know this target already a little bit. We know that there is This relationship between the glitch length and the glitch voltage So in order to minimize the search space of these parameters, we actually fixed the glitch voltage And we only randomized with the length And in order to do it here on stage the range of where we randomized is actually quite narrow typically you would take maybe a bigger range in order to Figure out what this parameter would be But also one thing to realize is that even though you do characterization using a test application If you X if you target a chip at a different point in time, there will be more hardware initialized and that means That there the pattern you need in order to inject the glitch successfully will be different So every time you have to redo this characterization in order to find these values So this is really the setup that's laying here in front of us and I'll switch the screen to the setup So So basically we talk to the glitcher Using a Python wrapper that allows us to set the signals that are incoming and out coming of this glitcher great So what you see happening now is that every time it will reset and it will give a response So what you see is that you actually we do not get the black hat string anymore It's only the string from you boot. So you boot is authentic authenticating the next stage and we're now trying to find the right parameters in order to actually Go out of the infinite loop because you boot detected that there's something going on that is fishy and it enters this infinite loop So if you're a little bit lucky, this will not take too long But also one funny thing is always that we also have that actually in our lab Is that if the temperature changes then environmental conditions of the target changes and also the glitch parameters change So we prepared this demo yesterday night when it was very chilly This morning it still worked, but I think now the tent is warming up with all the people in the Sun So this might become a problem so let's try to increase the length a little bit if this is not working now, we will just continue with the presentation and see if something happened Once we're done with that Typically it would glitch once every ten tries. Ah, there we go. So we've finally by we successfully bypassed So it's maybe a bit early for beer, but I think we'll drink a beer anyway, okay, so Albert introduced various ways to actually bypass the script boot implementations and better devices but there's certainly things Venice can do in order to make this much more difficult and Typically that is what you want to go for to make the to prevent them as a whole is very difficult Typically you can only lower the probability for successful ticks, but you can certainly make it more difficult So one of the things you want to do as a implementer of secure boot is you want to minimize the attack surface so for example You can authenticate all code and data and that is logical, right? Because that's the prime feature of secure boot anyway But also you want to limit the functionality in Rome was the the more functionality that is present there or executed during boot the more Opportunity or code constructions there potentially are that allow you to do some of the attacks Albert actually introduced and Also, you want to limit from the locations where you want to execute from for example You don't want to be able to execute from everywhere You will somehow want to restrict that even during boot and as Albert said this is typically not done during boot But it's really required if you want to prevent these type of attacks and Then already Albert of course touched upon it You can lower the probability even further by implementing specific countermeasures And it means that you can implement Countermeasures for fault injection so in hardware or software, but you can also Reuse all the knowledge there's from the software exploitation part because some of the attacks that Albert touched upon they actually leverage Software exploitation so if you make that part more difficult than also using these fault injection attacks to combine them with software Exploitation it will be much more difficult and Typically determining how good Your designers is very difficult to do From a paper study so you can look you can say something about it But in order to really figure out what's going on you really need to do testing Because typically what we state is that you really have to expect you expect the unexpected and sometimes it's very difficult to do up front This was it. Thank you very much. I hope you liked it and we're going for a beer Before we answer some questions Feel free to come to the states to look at this also Combine to our village. It's on the hopper field. It's over the Dike to the left there will be a big white tent and you will see this type of heart we're laying around because colleagues of us are also busy with it and Yeah, if you have any questions, please let us know We have a microphone in the middle of the tent or If you're far away, I can bring you this one too Yeah, we want to drink beer too. No question impossible What what voltage supply do you actually inject volts because these FPGA is typically have three four five power supplies Yeah, our rails When the schematics of the device are public you can read it from the schematic in order Which power supply actually need to use to affect the arm core Once it's if it's not public you need to figure this out by well I would call it PCB reverse engineering and making some educated guesses what goes where so you're Fault injecting the internal power supply not IO Yeah, so it's really the power rail that provides direct power to the arm core. Yeah, thanks Another question anyone no really not Thanks a lot, okay