Boot Security in the MCU

uh right now we have a great talk uh this was the highest ranked uh talk in our uh review process uh it is boot security in the MCU by zton matashi and Daniel let's welcome them to the [Applause] stage thank you um yeah let's just jump straight in so who are we uh this is my colleague and friend Dan also known as the bald one and uh he's a co-founder at Alam and also a principal consultant there um he's been auditing um code for over two decades and just loves reading uh like anything related to like systems and firmware uh in the systems and firware space uh and I am Zan um I'm also a principal consultant at Alam and

I've always struggled with keeping my toys and gadgets function functioning because of just the strong urge to understand how things work um and what we are going to talk about today is boot security in the MCU as the title also said um if you came in expecting uh us to talk about like the suit of Iron Man um or anything like how it works I will have to disappoint you um but we are going to talk about uh microcontrollers the other MCU uh the OG MCU um especially esp32 and SDM 32 as the two biggest vendors that we've looked at and um and their secure boot reference implementations basically and we are going to do this talk uh also

highlighting some of the collaboration um things we've done to coordinate our research uh hoping that it will be useful for anyone who wants to do any sort of similar things um so yeah what are microcontrollers I guess if you're here you already have an idea but just in case um essentially there are like computers um with in uh yeah that has like a processor uh could have built-in memory peripherals IO um the combination of all of these can be like you know so vast depending on what the use case is for that particular microcontroller and um you can find them basically anywhere like in your badges um well I guess not necessarily this year unless you sold it someone but um

that last year's badges or your watch if you have a smartwatch or even your airpods have pretty uh powerful microcontrollers in them um yeah anywhere really so it's pretty uh pretty widespread nowadays um so it is important to focus on these kinds of topics we believe um and following this what is secure boot um well secure boot is what we're going to talk about today um but in a nutshell it's basically uh aimed to protect the MCU uh from uh against running uh unverified codes uh it has basically three major strategies that secure boots implementations we want to sort of adhere to and Achieve um one is protection so protecting the code itself that's running on the MCU against

malicious uh inputs and like malicious code uh um also protecting the data that's on the device so it has a privacy uh implication as well uh uh and also like an intellectual property kind of um uh yeah side as well so that the vendors who put these devices out on the market in the hands of their uh consumers uh can rest assured like yeah can sleep safely knowing that their code is safe and no one's going to steal them ideally um and it also has a detection kind of capability so secure boot should also uh be used or like should be able to detect if a malicious activity is being performed against the device so it

can shut down or reset or things like that uh and also recovery so you know in case there's some compromise or just not necessarily even like intentional but something happens uh the device can reset to a known secure and safe State um so these are all covered under secure boot um there's no real um industry standard that everyone has to follow if they want to implement secure boot but there's been some uh yeah work in this area so there are some nist um recommendations there are some guidelines out there that try to sort of un um yeah have some Universal guidelines on how to implement secure boot but there's nothing like um a widely accepted standard just at the

moment um so how does secure boot work um it starts with what is uh called a root of trust so this is a piece of immutable secret that um the whole process relies on to verify each next step in the boot chain so this route of trust is usually uh just burns into a device potentially in the bootrom which is unchangeable most of the time um or some other secure area which is immutable and secured against malicious readouts or um you know compromise uh and the process works in a way that this Ru of trust is used by the bootron which is the first step of the boot chain um so as I mentioned the bootum is usually

fixed in Hardware cannot be changed so if there are bugs in here then they are there um and the bootrom will use this root of trust to verify the second stage boot loader um which is also immutable code but can be updated um using the same secure boot process uh and then the second stage boot loader using the same uh certificate chain usually um will verify the application firmware um which is going to put be performing what the device is supposed to be doing at the end of the day um and our focus when it comes to secure boot was not on the first stage boot loader because there's been a lot of really good research out

there people just so boot Trum code is not really public um vendors uh try to keep that a bit of a secret obviously because if there's bugs in it or anything like that they cannot update it unless in the next generation of the firmware uh sorry the hardware um so there's been a lot of really good uh research published on reversing boot ROM code and and things like that but we are not really focusing on that uh at this point we are focusing on the second stage bootloader uh because um at Alon we do a lot of code reviews and and things like that so um we are we have a good like good amount of experience um

auditing code so second stage bootloaders tend to be open source um from some vendors and like um they are what they are calling reference implementations so they are they should not be used one to one in a production environment but uh developers can use the reference implementation of the second stage bootloader to implement what they need uh to secure their devices so we are focusing on this the reason we are doing this is uh so we can uh demonstrate practical test cases against why uh these recommendations are out there uh we can find bugs submit them Upstream so they get fixed even in like current live production devices um and also as a business we can provide

tailored guidance to our customers using these sort of um secure boot uh boot loaders um and also uh we are not doing this because it's easy but because we thought it would be easy um so that's a bit of a warmup and I will just pass it to that who will talk about the sp32 now okay uh so yeah uh the esp32 was the first microcontroller we chose to look at um for several reasons we'll get into in a sec uh but it turned out to be a great choice uh the thing with the espressive is uh it's a huge family of microcontrollers there's a bunch of different series within each series a whole lot of um different micr

controller implementations uh have to just pick one and use that as what you're going to look at uh so in our case uh we just chose uh one of the the oldest um versions of the ESP uh which is most commonly deployed and has a lot of great research um out there already uh the sp32 uh is essentially running uh the extensor lx6 architecture which was sort of new for us uh there are some documentation out there that can read uh but fortunately uh focusing on the second stage boot loader we get to focus mostly on source code don't necessarily have to go too in depth on the architecture uh the security features that it offers is essentially a kilobyte

of onetime programable memory and a uh Hardware secure Boot and Flash encryption uh essentially it's the the thing in the picture there with the the green um square around it the ESP IDF uh framework is basically the reference implementation that expressive ships uh that developers can use to program these microcontrollers uh it provides all sorts of components and uh different things that you would want to use and just saves development time um and the the reference implementation in that is what we're focusing on uh we also chose uh many different versions or major versions of uh the framework just to get an understanding of how secure boot has evolved uh within that codebase over time so that we could develop different

test cases depending on which version of the framework somebody's using uh to basically get started in this we need to do dock review and fortunately for us espressive is fantastic in their documentation and their uh their code uh they're basically open source everything they've got um really in-depth uh data sheets technical reference manuals uh guides on their website as well as a really uh inclusive community with uh lots of fantastic Forum posts um this was a fantastic place to start since you know if you're getting into microcontrollers having all this information readily accessible just gets you up to speed nice and quick one of the things uh that we saw in there is uh especially if do recommend that if

you're um running a production device that you should uh enable secure boot so seems like a greater attack surface and uh something that we should focus on the uh a lot of the documentation uh indicated uh that security is more or less controlled via these one-time programmable fuses uh if you're not familiar with uh what these are it's essentially a um an image on the screen here the one on the the left uh is a fuse that has not been burnt and uh it presents the value zero um fuses can be programmed via software uh meaning that you can essentially issue instruction to the fuse controller and the fuse controller will physically uh essentially damage uh

the fuse so burn it uh and as a result of that the value of that fuse will um will change it'll go from a zero to a one uh and you can see on the the right that's an example of a a physically burnt fuse uh because it's physically burnt it's it's not possible to roll back that operation so once a fuse is set it can never be unset uh this is obviously a desirable property for uh for security so you know once you lock down a a system uh it's not like somebody can go in and reverse those operations so the the one kilobyte of onetime programmable memory uh is split into four blocks uh block zero is What's

called the system parameter block and uh this block is really for um locking down the microcontroller setting features that should be enabled or disabled depending on um a vendor's need uh block one is pretty much reserved uh to hold the flash encryption key uh so if you're using flash encryption this is where the the secrets get stored and uh block two is where the secure boot keys are burnt into memory as well uh block three is kind of for just application purposes anything that um you might need to do uh and make use of as onetime operation uh is available for you to use in block three uh one of the the properties that you find uh with um eusers is it's not

sufficient to Simply um burn them or not burn them uh you also want to have the ability to um to protect reading those fuses or writing to those fuses uh in certain cases so a clear and easy to understand example would be the The Flash encryption key that's a secret material that should never be exposed to anybody since if you can access a flash encryption key you can obviously decrypt The Flash as well so by read protecting uh that block um say block one uh it's possible to to burn the uh the key and software cannot access it but Hardware can uh the other operation get that can occur is also right protection so you

don't necessarily have to burn a fuse you can also leave it as the value zero and right protect it meaning that it's not allowed to be burnt uh so a basic example would be um when you uh receive an ESP microcontroller uh generally comes with a a MAC address since they have like a a Wi-Fi and a BL stack uh and the MAC address um comes from the factory it's often used as a way of uniquely identifying which chip you have so your Salan sp32 um connects to the internet his Mac address would be different to my Mac address uh the interesting thing is that there's no right protection on this memory so uh we can obviously change uh

the the bits of that and change the the factory Mac address which is maybe not ideal so obviously if we're shipping a product that relies on Mac addresses we need to right protect that uh that memory uh the real reason why we care about looking at these eusers to begin with with that uh documentation review is we need to understand a little bit about the platform since um if we look at the uh the reference implementation for secure bo uh it's no good just focusing on that if the rest of the microcontroller remains in a insecure State um so spending a little bit of time learning about the different fuse configurations uh lets you determine um

what the the recommended values should be as a a basic example uh there's a fuse in the system uh parameter block called uh JTAG disable and this might be used to disable JTAG uh in production so that users can't simply attach uh their JTAG probes and Peak and poke memory and do debug operations uh you'd want to do this in the case of secure boot because if it's not done uh then obviously somebody could just inject their own code into the memory and bypass any um guarantees that might otherwise provide so with that out of the way uh that was kind of like the the dock review and initial experimentation um just learning enough about the microcontroller to know what

needs to be locked down uh but really since our focus is on the the code auditing uh let's assume that the microcontroller is configured according to best practices again um expressive is great they've got documentation on what those best practices are and we also have a tool that will release at the end that you can use to verify um that your code might be conformant so our approach was basically audit all of the things uh really what that means is uh we pull down the ESP IDF codebase uh there's two folders in there one called bootloader the other bootloader support these are obviously related to bootloaders and so our goal is just to read every bit of

code that uh that lives in that folder and try and find bugs so uh what that kind of means is we started at the the first entry point which is called call start cpu0 and you just read it line by line try and build an understanding of what's Happening uh why certain operations might take place and try and figure out uh different attack scenarios and so this is literally only a few uh this uh code block on the screen is only a few lines into that function and what I've um indicated here is there's a function called to something called select partition number so this means that we need to Now understand a little bit

about what a partition is and why it's selecting a petition number so a few slides back you saw the you know what a micr controller is and so it's obviously the ESP on the left um but the chip to the right of it is spy flash it's external memory it's physically a chip that lives separate to the ESP but can hold data you can think of it as like a hard dis or something in a in a traditional computer uh so this uh this flash memory um just do data and it can be anything the only constraints are that the first few kilobytes of that memory hold um the second stage boot loader and a digest of

it which is used by the the boot ROM to verify the boot loader so from an attacker point of view we can't re or for our point of view we can't really modify these things so we just leave it as is but the rest of that uh spy flash is um for the taking so the partition table is at some offset within um this FL FL memory and the petition table basically points to different sectors of the flash memory um and says you know maybe this petition is reserved for data another one might hold an application code another one might uh contain um I don't know like parameters for configuring hardware and so on so okay uh we sort of understand that

there's this external device now contains data that we can modify um we then get a few lines lower and see core to bootload our utility load boot image okay so we jump into that function and again it's only a few lines in um and you you hit something which says check anti roll back so the next thing to do is okay what's anti roll back uh you know why do we care that it's actually making this function call again go back to the documentation learn a little bit about it uh essentially an roll back uh is used in situations where the microcontroller receives a firmware update over the Internet it'll receive that update it'll write it to another

petition an unused petition uh and the requirement would be that the the application uh so the version of that firmware update needs to be higher than the currently running version um and it's basically the reason for anti-rollback is that you should be able to download an update uh that fixes a vulnerability and the system should never be able to go back in time and run a a known vulnerable version of the firmware that might still be signed so uh the basic approach to it is let's say that the current um so the the code that's running in otaa Z is the thing that's actually going out and speaking to the internet to get a firmware update um it downloads it it

then writes it to ota1 and then the next operation it does is it changes the active petition in this otaa data um petition then on the next boot uh rather than booting into the otaa Z the microcontroller will boot into otaa 1 and then when ota1 successfully boots up it'll blow an euse and that euse is essentially a an um an increment uh counter that represents the currently allowed version of the firmware to run and because it's blowing an euse it means you can never roll back in time um and run an older version so um the question then becomes how do we um know what version a uh essentially a firmware is and that basically comes

down to the the image format the application image format uh which sort of lives in one of those partitions so in our case this image header and segment array and so on we live in otaa 1 um we don't really need to care too much about all the different um structures in a um in an application image format uh for our purposes we just care about this uh one structure which is called ESP app desk um it's the very first segment um in the uh the update image and this uh contains a value called secure version which is essentially that firmware um uh version that would be running so okay uh that makes sense we

know uh what anti-roll back is uh but then we see uh the next core which is Trad partition and we won't go through the code and the implementation of that but essentially um loads um the application and and runs it um but we've already just learned enough about this Behavior to realize that there's an issue here if spy flash is under the control of an attacker you know it's an external device we could desolder it we could solder on our own emulator we have full control over it uh we've seen that there's a moment in time in which the versioning information is checked and then a moment in time in which the firmware is actually loaded and executed uh this is

essentially indicative of an issue called timer check timer use uh where if we replace the data that's being used at these two different times then um we'll end up being able to potentially uh changing a secure version from some higher value to a lower value and running that so we've got a theory of uh where an issue kind of exists um how would we test this on you know in practice uh fortunately ESP uh has qmu support and uh so you can emulate the the microcontroller itself and one of the nice things with this is um that spy flash memory uh can be pointed to a fake block device and in our case we used

something called NBD kit which lets you essentially um turn a file from your file system or some program into a fake block device and our goal here is our NBD kit is just a program and when a fetch occurs to say otaa 1 we'll return the valid firmware update but then the very next time uh we see an access to that ota1 petition we'll return uh some older version of the firmware that has a vulnerability in it and turns out that that theory uh was a great success and uh got the first cve from our work so shout outs to Joseph for uh the the initial finding and what you see in the screenshot up the top is

a secure boot version saying that in the eusers the firmware update must be version 10 you're not allowed to run any version less than that but then down below you see that the actual running version um of this uh firmware is actually version zero might have a vulnerability in it that we can now exploit get control over the device so that was pretty nice um and this whole idea of accesses to flash and you know the time in which something's loaded the time in which it might be used uh it seems pretty interesting and uh the MBD kit integration is kind of powerful enough that we can actually start logging uh which sector of uh flash is being accessed at what time

whether it's a reader or wrer operation and then you can plot that over time and so we wrote a little bit of tooling uh just to sort of see how common uh this sort of double fetch uh case is and as you can see in the uh the GIF on the screen seems to be pretty common there's a lot of cases in which um you know the same uh region of uh flash memory is accessed over and over again um we this tooling has also been uh extended to support uh logic analyzer plugins so you can do this on physical Hardware not just in an emulated environment and uh see what's actually happening in practice so um that tooling kind of um

helped us a lot uh and uh continuing on with this time check timer use issue um we kept auditing the code just as you saw before line by line you know see a feature go research it in the docs come back and think about if there's an attack scenario and we end up in this uh this function called process segment data this is probably like the Holy Grail of uh issues if you find a avability in this uh function it's actually responsible for loading the data um like an application from flash into RAM and at the same time Computing um the uh the hash of it for secure boot verification so the idea being all the data get that

gets loaded into RAM at the very end of that load it'll then compare the the check sums and uh if it's allowed to execute then it will uh if not then it'll bail out but you see this sort of primitive um the two lines with the arrows the very first one you see this access to the variable SRC uh at index wi and then that's actually the first operation where it fetches the data and loads it into RAM uh the second time you see it with the second arrow down below it's accessing SRC wi again but this time for the purpose of figuring out or or essentially using it in the the hash calculation so this is pretty nasty uh

knowing already that we can just toggle between which data is being received from uh from flash we now have a case where the data that's loaded into RAM can be different to the data which is um having the secur boot verification done on it uh that seemed pretty awesome except uh it turns out that caching is a thing on the the ESP and um the the access granularity um was or or um the locality of the accesses um was too close and as a result uh those two Fetchers it would not always go back out to uh the Spy flash it would actually just use whatever was left over in cash and as a result even though technically

there's a time of time of use issue in code in practice um the behavior of the hardware in this caching mechanism means that uh it turned out that it wasn't exploitable uh one of my ideas at the moment though is uh espressive are not just running on the extensor lx6 there's also an lx7 architecture there's a risk five architecture um I don't know if there's even more than that uh but I wouldn't be surprised if there's situations in which um this caching mechanism Works different and therefore um because it's the one code base that's used for all these devices all of a sudden that vulnerability might become exploitable in practice so fingers crossed that that leads to something

interesting soon um but yeah so I could basically talk all day on you know ASP issues and all the different things that you can do um our research is far from complete with it um but the too long uh didn't read is basically timer check timer use uh seems like a very powerful primitive and juicy attack surface um otherwise the the rest of the boot flow that we were looking at in terms of attack surface and ways in which we could um uh tamper with the system to potentially uh get a bypass actually seemed pretty good uh on first pass um again you know there seems to be uh an opportunity for esoteric issues uh

since it's one code base running on many different architectures maybe there's different quirks that happen there this is an area that I'm still exploring um but overall I think uh if you're interested in the topic of secure boot uh esp32 seems like a great choice microcontroller um thanks to the documentation the forums and the code is quite clean and the ability to emulate it so I think I'll pass over to Zan for the STM site thanks so yeah uh um jumping like Switching gears a little bit here we are going to switch over to another vendor uh that is similarly pretty WID spread in the embedded space St micro Electronics is stm32 family of MCU um so it as I said uh like similar

to esp32 um there's a lot of different versions of their chips out there so just if you go on their website they have uh this nice little diagram which is the main family of their mcus so as you can see there's the F series there's the H series g l etc etc um uh but if you go to your uh to their module selction uh selector table thingy um you can see that they actually have about 2,000 different mcus um that support secure Boot and secure install and update um functionality and they all of these will belong to these larger families but in different configurations with different peripherals different like CPU speeds energy consumption Etc uh whatever you

need to fit your purposes you will find it with stm32 if you can find it um because when we started doing the documentation review uh compared to esp32 which then was really enjoying and just had a really good time reading through ESP docs and just Forum posts and stuff like that when I I was doing stm32 I felt like I was in Dante's Nine Circles of hell um especially somewhere between Circle 5 and seven which is like anger heresy and violence um because stm's documentation is all over the place their websites are just uh contradicting sometimes it's really hard to find um actual uh usable technical documentations um hidden inside their training and and things like that they

do have really good data sheets I will have to give it to them um memory layouts are easy to find in those like 1,00 pages of PDFs um uh but overall it's it's kind of hard to figure out the stdm ecosystem uh and on top of this their source versioning is not versioning uh they bundle different Source bases together so it's it's really hard to find what you want um like consistently um but for our purposes we focused on The stm32 L4 S5 it's a really catchy name um and specifically the discovery kit that is B- L4 S5 iot 01a again great naming um so the reason we chose this is because this is a pretty

cheap uh MCU uh pretty widespread it's a low powered uh MCU it doesn't necessarily have the highest security sort of features or the highest power that STM offers uh but it is very accessible and and used in a lot of places um so it has yeah like a bit of Ram uh a bit of uh flash support and all the communication interfaces and peripherals that you would need uh to interact with the device um and when it comes to their firmware supports just just how ESP has the IDF framework um stdm at the time um had mainly support for what they call xcube ssfu sbfu stands for secure Boot and secure firmware update um but as I was putting together

these slides uh like the research we I think we did it like last year basically um so there's been a bit of a gap in time between the actual research and the slides and I was uh just working on the slides when I saw that the actually support two new things um or like at at least they are more pronounced now they might have supported it but I just couldn't find it in documentation um so they also support uh sbfu by MCU boot uh which was not available during our research uh but it this seems to be the main thing that they will be supporting from now on on the screenshot you can see that it's coming soon so great um

but yeah we were focusing on sbfu um at at the time um so ssfu documentation again um when you're jumping into uh auditing something that is so complex and big you start with Doc reviews um they had a nice little like strategy uh outline for how they do secure Boot and firmware updates so um these are the strategies that they will adhere to single code of Entry uh single code entry is the ssfu binary itself uh so this is the immutable code that will um be used throughout the whole secure boot process um they rely on um arm features um uh security features uh so arm is the architecture that they're using for their mcus um mainly they're relying on

RDP which is called readout protection we will get that uh back to that in a second um and they also have this strategy to protect and isolate uh secrets in enclaves so this this can be either The Flash itself um in a protected region that's immutable and uh protected against like un um authorized access uh or it can be stored in an external secure element called the St safe um which is another family of like mcus that uh St has uh we'll get back to that in a second as well um and they also want to limit the sbsf attack surface so only support what they really need to support and of course disable all debok ports but mainly J tag um or s

swd or whatever um when RDP is enabled in order to limit access to uh to the runtime basically of the instructions that are running on the on the chip during secur boot uh and they also have this strategy of monitoring the system against like tempering so they have uh all sorts of security features that they use from arm um related to temperature control um and all sorts of like uh side channel uh monitoring capabilities uh but the col common element seems to be the RDP um security feature um so this comes from the arm architecture uh RDP has two levels uh 0 to2 uh sorry three levels 0 to two and they are uh it's just one of the security features

that arm support but it is the main one um so depending on how or depending on the use case that developers want to build their environment around uh they can use multiple other features as well such as the memory protection unit which can Mark memory Pages um with granular access controls so like you can Mark uh memory Pages as non-executable or just read only or read write etc etc um another common feature is uh right protection um wrp um which will protect the marked regions against uh eras erasing and reprogramming um in memory uh there's also PCR op uh which is proprietary code readout protection um which yeah protects uh again like you can Mark memory pages to

be execute only um and there's also a firewall um which is basically like basically an arm you can have multiple levels of code execution you can have unprivileged code and privileged code and the firewall is used basically to ensure that privileged code can uh only be called from privileged code um and yeah um protect against these sorts of attacks and there's a bunch more other security features that arm support these are just the main ones that are shared across the stdm family of chips uh most of the time uh but even then like some might have less support some might have more and is uh con contrary to espressive esp32 these features are uh encoded in

Flash in the option bite on the screenshot we can see the memory layout of The L4 um series of chips and those option bites are what um uh will dictate how these security features are used and whether they are enabled or not and these are immutable and are protected at the end of the day by RDP so RDP as I mentioned has uh three levels RDP level one is just no protection at all um Flash and the Ram uh or the yeah the memory of the chip can be read uh using a debugger there's nothing stopping anyone from messing with the boot flow or anything like that using a debugger uh level one is a bit more protection so

in the in case of a debugger uh being attached to the device um if RDP level one is set the device will Halt and um the reference implementation will also reset the device um so it's a bit more protection but uh because the device will halt when it detects a debugger uh the ram contents will still be accessible to the debugger so if there are secrets uh still in Ram when the debugger is attached during the boot flow those can be read so it's not great but it is a step up from no protection at all um and has it has to be noted that level one can be downgraded to level zero uh the ssfu code the reference

implementation by St uh at this point we'll reset the chip so delete single uh data that is stored there so there's a bit of roll back protection there um but um yeah still uh RDP level one can be downgraded to level zero uh programmatically uh that's like allowed in the documentation as well and then level two is the one that is truly unmut immutable uh once this is set um yeah um no access will be allowed to um to either Ram or The Flash and um this is the level of um lockdown that people should aim for if they are developing their own devices uh it is a bit of a so like some because STD offer is level one

uh some vendors tend to choose that because they think that they might want to do some like um yeah field debugging or whatever that they want to do um but it's usually not worth it for the risk of the lack security controls compared to level two um but yeah but if level two is said there is no debugging um basically on the chip um so in the flash that little table uh shows the option bytes that correspond to the level of protection of readout like RDP the readout protection uh bits so hex CC uh in the RDP option b part will mean that it's level two uh hex AA will mean it's no protection at

all and anything that's not either AA or CC will be level one so that's a bit of an interesting um adct surface there there's been some research published with related to using strong UV lights just shining on the MCU which can cause bit flips um where they can uh basically downgrade the level two uh to level one uh by flipping just one bit so that the the C hex CC becomes not hex CC but also not AA necessarily so it will just be a downgrade to level one however that sort of attack is unreliable because uh at the time um when I was putting together the research um there was no specific enough UV attack that didn't also

corrupt other parts of the chip so even data that you would be after with this attack would be corrupted so it kind of makes it unfeasible and then uh there's a lot of research out there using fault in uh to sort of just skip over these uh sort of checks and bypass uh read out protection uh but these are all Hardware related to text which is not our Focus um so we started looking at the sbsf code um um how it's organized is um it's organized uh so basically they always have two uh versions of the SBS Fu code broken down into different chips that they support or discovery kits that they support uh there's a KMS

version which is as I mentioned uh relates to how the secrets are stored so the KMS will use like a local um Enclave uh inside the flash uh memory region to store the secrets and the St safe version of the code we use that external chip uh the St safe which is this external secure Enclave to store those chips off of The Flash or the MCU um and the high level boot flow when it comes to ssfu is that there's a board initialization happening so all the like Hardware uh layers are initialized and then the SD safe itself um will initialize STD uh terminology is a little bit confusing because they refer to St safe even in the KMS version when

the St safe chip is not even used um but it just means that the secure engine is going to be starting up um and then uh uh they apply all the protections or check their protections so all of those arm features can be basically categorized into two set of features one is static one that when it's set on the device it will stay there throughout power cycles and reboots so those would be RDP wrp and uh proprietary code r that protection and then uh there are all the runtime checks which have to be uh set by the boot process every time there's a power cycle happening on the chip so these will be the firm well uh

sorry the firewall um protection against like dma access and and a bunch of others all the anti-tampering um things would be have to set during runtime during Boot and then uh sbsf is a state machine um uh yeah uh uh initializes the state machine which will be responsible for checking for updates downloading verifying and then executing the user firmware so the SD safe in it bit um which was like the second step after the hardware has initialized uh in the uh reference implementation is kind of just already left to the to the reader to implement they have this like really rudimentary way of just putting the keys in the flash at a certain constant um address

and just loading it from there but as the comment also says in the source code um this is not really secure so it's already left to the developer to implement some Safe Way of storing the initial um or like loading the initial Secrets um which is interesting uh and then yeah the sbfu state machine uh will start um which has all these features um some are depending on uh whether St safe is used or the local KMS version of the code is used um and each of these uh State machine steps will check that the previous check has like the previous step has successfully um completed just so we avoid skipping over certain steps uh and also all those like runtime and

static checks that we talked about um checking like the RDP level stuff like that um will be checked at each of these um steps just to make sure that no like time of check time a few things have happened between uh these steps so like RDP hasn't been downgraded since like downloading the firmware and before executing the firmware and things like that and what's cool is that in the reference implementation they already do um like uh side Channel mitigations like fault injection uh mitigations so for example these static checks might be executed twice uh after one another uh just to ensure that a fault injection is not uh messing with these checks um and yeah so this is basically

the part of the code that shows that um um all the all the previous steps have been um completed before moving to the next one um so that was just a quick recap or like a quick summary of how STD approaches SECU Boot and now into the uh let's go into a little bit more detail of our specific approach so as I mention we use this discovery kit um which is this thing um it's super useful because it the MCU itself The L4 S5 is in the middle um but it already has on the PCB a bunch of peripherals that you might be um using so it has a Wi-Fi chip on the top left uh it has USB uh ports on the

board um it has flash memory everything uh that you would need to start working with uh this specific chip and it's it also has a lot of exposed headers which is very useful when you're like playing with something and just um yeah want to get something working quickly um and on the bottom of the board we can see that they also have an SD safe uh secure element um on this discovery kit as well which is great because we can then explore that uh part of the ecosystem as well but um we were a bit lazy so we got this nuclear based uh extension Shield basically uh which sort of just slaps on top of the discovery kit um and the

circle chip um or yeah the um thing is is the St safe that is also on the bottom of the discovery kit uh but why we did this is because then we can do this so we can just put the uh extension shield on top of the disc Discovery kit just uh using those headers and because the headers are also Exposed on top we can just use our logic analyzer with just simple wiring just plugging it into the right um slots for the I squared seab bus and ground uh so we have easy access to um to to the bus itself without having to like trying to find the solder joint solder points or just

having to mess with soldering at all um and the cool thing about the discovery kit is that it comes with the stlink uh debugger which is st's own sort of uh debugging protocol um and it supports Source level debugging using their own X Cube IDE environment um which is great so you just plug in a USB cable into the board the other into your laptop and you have Source level debugging using GDP which is just excellent um when we are exploring these sort of things um so um I keep talking about this STD safe thing uh the chip is it's just that it's a little uh little really low power chip uh the hardware configuration is pretty black box for

obvious reasons this is what is the safest part of their ecosystem uh all we know is that it has 6 kiloby of configurable nonvolatile memory it has um onetime fuse uh onetime programmable fuses as well to store Secrets uh and it communicates with the main MCU using the iatch C bus um which is great for us because it is addex surface um because a lot of the modern chips like your iPhone for example will have a simp similar secure Enclave but that's built into the main MCU as well inside that die so there's no easy way for you to intercept the communication between the CPU as it performs all these uh secure boot functions um using the secure element uh

but in this case it's an external chip um so it's great at ex surface for us um there are some commands don't really care about them um have support they support a bunch of things um it's a bit dry to go through them uh but we did find a bug which was great so the little um GIF here shows uh the code running and then when we put on a malicious Shield which was going to simulate um malicious access to the ice crat SE bus basically in a person in the middle style of attack uh the code there will execute and uh LEDs will start blinking uh showing that malicious code has been executed how that work works is

that when the MCU reads off the i c bus this is the main like utility function the uh Hardware context bus receive uh function that's read off the bus reads of the bus using um uh preset length of data to be red uh into a buffer that is held uh in the uh by by the CPU uh the main MCU um so uh this part is fine uh the length on the top is uh preet uh not user control nothing wrong there but uh once the read happens um the driver basically will reset the length of the buffer based on the code received of the bus um which is user controlled uh and then if that uh length

received uh from the bus is longer than the response length previously set as a static like to 523 bytes in case of the ssfu uh a second read will happen because that will basically mean SDC s safe will tell the MCU that we have more data to send so a second read will happen um on the on the bus using the same function but now uh the length of that read is going to be controlled by the attacker uh which means that uh we can right past the length of the previously set um buffer um so pretty straight up memory corruption vulnerability um so in order to do this uh we also wrote a little plugin used uh

that you can use with s logic 2 uh which is the software for uh the S logic analyzers so if you use this and you intercept I Square C communication you can um just get an idea of what kind of commands are being sent through this bus and what are the responses and things like that uh I have to note that this is only going to work in like non lockdown production devices because St safe will encrypt Communication in a properly controlled environment in like a production environment uh but during uh like just development this can be a really useful tool to just intercept the messages and see what's running through the i squ c

bus um and then that's just a quick recap of the St safe uh ecosystem there's still a lot to do uh we mainly focused on the St safe uh s the stdm ecosystem and we mainly focused on the STD safe uh um chips but yeah there's still a lot to do a lot to cover in the ssfu packages as well and then as an outroduction okay uh yeah so that's a overview of our work for ESP and STM uh there are many many other places where uh dragons be lurking for um for research topics uh they the SCP uh supports executed in place there's also um these co-processors which can run uh in deep Sleep that might have access to

memory that you can exploit dma padding essentially everything in the list here is a tax surface that we're currently exploring uh and you'd probably have some luck if you looked into these areas as well um our plans for the future uh include just a lot more auditing over these uh same devices as well as even more and uh some of the tooling that you saw uh in the talk today uh we'll also have um some improvements on uh made for them oh uh speaking of the tooling um the repo uh that's uh on the slide uh will host um links to a lot of the uh the tools that you saw so if you are

interested in using them uh feel free to check out the um repository it's not pushed just yet but uh today I'll make sure that we get something uh in there um one final thing uh since it was a collaboration project uh one of the uh things that we realized is it was important for everybody to have a a test environment that we could use to reproduce each other's work or just to uh get stuck back into auditing um when the time came back again uh so we created essentially a bunch of Docker containers as well as uh Dev containers uh that lets you um essentially spin up these ESP and STM environments uh for code oring and hacking uh just takes one

command and then you're ready to go uh so if uh you found anything in this talk interesting and uh you know you're inspired to um either replicate the work or go off and do it yourself um you'll find uh essentially some tooling that makes that very easy to do uh a lot of the work um uh that sort of got us started here um was sort of based on uh prior work people who have done a lot of research into fold injection attacks uh that first AG boot ROM attacks and so on and uh had a lot of really interesting information that we were able to Leverage um once we got into the second stage bootloader uh just

the the one thing that I'd love to point out here is uh Travis goodp speed is uh published this microcontroller exploits book uh just recently uh it's an absolutely uh phenomenal book very interesting read um so definitely check it out uh if you're interested in in this sort of topic uh with that being said I think uh we're done we might have time for questions uh but thank you [Applause]