 Hello everyone and welcome. Thank you for coming to this talk and today I will talk about WolfBoot and how we do secure boot and remote firmware updates and especially in the context of safety critical embedded systems. Obligatory company introduction for those of us, for those of you who don't know us, we've been on the market for about 19 years now, being founded in 2004. Last change name of 2014 when some of you might remember us with one of our older names, EISSL or CYSSL. And of course our main area focuses security and all our products are available as open source under the GPL license and of course commercial license which is a proprietary license for those who comply with the GPL terms. And of course we provide professional support from the same people who alter the code. Our main areas of focus are data addressed, so cryptography, encryption, authentication and data in transit, TLS, SSH and other secure protocols and this is done in a transport agnostic way so we are able to run those protocols not only as recommended on top of a TCP-IP stack but often in embedded environment means also running over custom transport. And more recently like six years ago we started researching on secure boot and firmware updates and now we have part of our products addressing these kind of challenges on the market. And the third part is the main topic we'll be talking about today. This is a bit another view of our product line. Of course Wolf SSL is what we are most known for and that's a lightweight SSL TLS library which is 20 times smaller in size than open SSL and it relies on WolfCrypt which is our crypto engine which has been certified for different scenarios both in security so for work concerns FIPS 140-2 and the ongoing FIPS 140-3 certification and of course in safety critical applications up to life critical scenarios so up to the 0178C.a which means that our crypto algorithms are allowed to run on airborne software as we were discussing about this in the previous talk. So where safety critical restrictions are very strict up down to the single line of codes and coverage and documentation of the specifics etc. We won't go into many details there but this is a core component that we will consider today. On top of that we distribute other application layer libraries such as Wolf MQTT which is a lightweight MQTT client which is of course by default secured with TLS. Wolf SSH which is a client server implementation of SSH that can run on very small microcontrollers including SFTP so you can transfer files on a device without a file system even by providing your virtual implementation of sending and receiving files through simple callbacks. Then we have a TPM library that's allowing simple communication with the TPM devices which become more and more popular as a HSM in the embedded market. And then Wolf Boot which is a main topic today and Wolf IDPS which is our IDPS which is our newest product. We do provide many language wrappers because many people like to use us on both sides so Cloud Endpoints can also implement Wolf SSL on different programming languages like C-Sharp, Python of course, Java. We have a JCC that's used in Android devices and the last line there is a series of open source, common line tools or other libraries that we support which Curl is worth mentioning because the author and maintainer of Curl in Istanbul is part of our team so we can also provide professional support on Curl which is non-GPA as you might know. So let's talk about secure boot. What we mean with secure boot in simple terms is we want to be sure that the software that's running on our target is what we expect it to be and especially that it's coming from a trusted source. We will see how this is possible with the means of cryptography, of standard cryptography and how we avoid any adversary to run malicious code or rock code on our target devices which is important. So a secure bootloader is a component that sits in our device. Most of the time it's immutable, sometimes it can also be upgraded through secure means and that's exactly this. This is the main task so ensures that no one runs code that's not authorized. So how do you write a secure bootloader nowadays? Writing it from scratch that's still our biggest competitor on the market. So companies that start their own secure bootloader as a component and they say yeah it's just secure boot. How hard can it be? And the thing that is always a hidden cost there is testing all the corner cases. It's what can go wrong in cases that you haven't foreseen during your design. Which means that it adds a lot of effort to your engineering team to start a project like this on your own. It might seem simple because it's not a large project. It's a few thousand signs of code. By definition it must be as small as possible. And there are also a few other things you have to consider. Key management, key deploy and how you sign your firmware before sending it to your target. And so it's a set of tools that are needed by the secure boot in general but are often not taken into account enough. So the same way you shouldn't write your own TLS library or your own TCP and P stack probably if you have already options for that unless of course you have good reasons for that. Why would you write your secure bootloader especially for a safety critical environment. So we came up with a more genetic solution at least. A consideration on safety versus security. Safety does not imply security by default. And this is a hard lesson that some verticals have learned pretty recently for instance a space agency that among the top class safety scenarios for the quality of the software that they deliver don't take enough into account the risks of cyber security. You say cyber security in space but okay Russia is stolen a satellite from the day before they started the war. So this is a real life scenario. And your adversaries can be very powerful. But this is also true in both directions. So safety does not imply security but also security does not by default imply safety. You can have a very secure TLS stack or a very secure crypto implementation that takes into account all the attack models but that is not taken into account safety. So there are actually examples where secure code must be following the guidelines and the certifications for the specific vertical. For instance the O178C which means also dynamic allocations are not allowed. The execution for must be predictable. And the ancient mentality is if then broken don't fix it but we should start thinking in terms of when something breaks we should have been already prepared to fix and patch it even if it's running on the field. So for this we provide the secure boot loader in a way that he can support your firmware updates. And for this there has been for many years a draft in the IETF that's called SUIT. So software updates for the internet things which targets many small devices and say how to protect the secure boot process. And the guidelines there are very clear. And this has been turned into RFC 1919 in April 2021 so pretty recently. So way after we started this project. So those are guidelines that are officially part of the IETF recommendation. And these requirements of course are clear especially in the small parts that are keeping your attack surface very small. And especially dealing with public key infrastructure when authenticating your firmware. And that's where Watford was born and it was written in C for bare metal use. It has small footprint so it can run on any embedded devices. Smallest one it's about 10 kilobytes you know. It has to be memory safe. So malloc and free don't exist in our boot loader space. We have simple partitioning scheme and we have structured the HAL so we made it very portable just six functions to port to your favorite target and we already support tens of those. And we have different booting strategies and partition selection strategy or firmware selection strategies that depend on the architecture of your target of course. We do also provide key tools for generating keys and signing the firmware and encrypting the firmware when needed on the host side. And of course the design is still based on the RFC 1919. This is also because at Watford's cell we don't invent anything. We don't write our own specification. We just implement what's specified in the standards and this is valid also for TLS and all the cryptography modules. The main features of Watford of course it relies on Wolfcrypt so our crypto engine that's FIPS 140-2 certified so it does exactly what FIPS specifies for cryptography and it has a version that's DO178C.A certified of all the crypto algorithms that we use in Wolfwood so it's easy to have a Wolfwood that's DO178C up to DALE A on airborne devices for instance. We have a public key based route of trust which is not really a route of trust it's what the RFC is called a trust anchor because it's just a public key. And we support multiple keys with multiple associations two different partitions or firmwares. Double loaders can handle updates of course and that it has a fallback mechanism so even if your firmware has been authenticated but it contains a bug it's able to revert it to the previous version so your device not rigged forever. And it has also power fail protection so if the most critical operations for instance swapping two partitions is interrupted to power loss for instance you are sure that the update will be completed at the next startup because there's always two copies of the same sector that's been moved at that point and the flags keep track in a redundant way of the update process. We support external fresh memories, SPIs on small microcontrollers up to any kind of nonvolatile memory even SATA drives. And we do support bootloader self update it's a unique feature so we can upload the bootloader while it's running this is not very fail safe so it's considered more an emergency situation so you should consider the implications when using this because of course that's a bootloader updating itself while it's running. But it works pretty well. We do support encrypted updates this is mostly to ensure that the firmware that's stored on an external device cannot be intercepted if it's encrypted for instance wiretapping SPI device or other physical attacks. And we do support delta updates also in combination with the above which allows for instance on a thin network protocols with low bandwidth to just transfer the necessary amount of bytes to switch from one version to the next for instance you're just publishing a bug fix and you don't want to spend a lot of time and bandwidth to update your target. So you just send the binary difference between the two and this of course supported also by the tools that sign and create the manifestator. What put as I said is very portable and supports multiple targets the project has started originally on ARM Cortex-M and was mostly oriented to microcontrollers but then we saw that the parting was also of course applicable to richer targets like ARM Cortex-A or Intel x86 32-bit and 64 where we currently have the possibility to replace Intel Slimboot with a much thinner implementation that can be certified because as you might know the 178 for instance but other other safety regulations have a cost of certification which is directly related to that to the numbers of lines of code and the complexity of the project itself. So we keeping it simple and small and of course risk 5 RV32 with a 64-bit risk 5 port coming up and PowerPC 32 and 64 bit which is mostly oriented to the automotive market. We don't have yet the MIPS port but that's also in our roadmap. The way we do key management is pretty simple. We generate the key pair once you are the owner of your own private key which stays in your premises on your cloud server or whatever build system you're using to distribute your firmware updates and as soon as this private key is safe you don't have to worry about the security of the entire secure boot process. So even if your fleet your devices have a public key stored in a trash tank or leaking that key by definition it's a public key so it won't impact on the security of the secure boot process for the fleet. The public key is as I said stored in the target it can be stored in different ways it must be accessible by the boot loader. We don't provide by default revocation mechanism of those keys but of course if you're storing them in a dedicated partition that's also upgradeable you can do that. By default the wolf boot includes the key store in its own binary so it can revoke the key just by using the key the last time to do a boot loader update for instance that's a scenario that we've seen among our customers. And the same tool what it basically does is attaches a manifestator to the image and this manifestator contains metadata and all the information about the firmware including the signature and the hash verification of the firmware itself. And yeah as we said it's a trust anchor rather than a root of trust and the difference is that the trust anchor according to RFC 6024 is a presentation of a public key so the only requirement there is that it's not writable by an attacker because of course this means that an attacker can put his own public key which in turn means that the attacker could load the ROG firmware there. So the way you store the trust anchor in your device is very important for this we usually rely on manufacturers storage one time writable storage or specific hardware security modules or even the TPM itself with the locking mechanism which is based on measure boots. And yeah that's exactly what I'm saying so sometimes we use flash readout protection from manufacturers which is sufficiently secure for most use cases but we must know that this kind of trust anchor are often subject to hardware attacks like glitch and so it's sometimes not sufficient depending on your risk analysis of course. And if you implement that through secure elements of course the security of your trust anchor increases there and we do provide support also for third party provisioning which means that if you have a contract with a company that's managing your private keys our tools can offload the operation of signing when signing the firmware and on the other hand the manufacturer of your hardware security module can install trust anchor that are specific per device and can be done in factory and that's usually that's usually one of the most secure trust anchor solutions there. So as we said we generated the key ones and key is of course a key pair can be CC, RSA, ED25519, ED448 and then the private key the public key is embedded in your target and the private key is used to sign the firmware on a server and then the authenticated firmware is sent to the device and authenticated by Wolfboot. So we do offer two possible boot strategies of course the A-B approach is when two partitions have the same value so you can boot your kernel from either of them and one of them is always available for receiving updates and that's only feasible on richer devices where you have an MMU for instance and you can run your kernel as a position independent like for instance on embedded Linux devices but of course for my controller due to executing place restrictions this is not possible so we do have a boot update approach which is based on a swap partition which is exactly as large as the one sector of your non-volatile memory and every time you receive an update that can be verified there will be a swap between the boot and update partition so at that point the new firmware becomes the booting firmware and the old firmware is stored in the update partition temporarily until we can confirm that the new firmware is working from the application side and yeah and of course this is also needed because we can store updates as I previously mentioned encrypted and in an external SPI device also microcontrollers and we can't really execute in place from there and executing in place from a different partition on the internal flash will mean that we need to know at compile time what is the booting address so on an embedded microcontroller what normally we do is dedicate a small partition at the beginning which contains a bootloader and we have a boot partition an update partition which might leave on the same internal flash or the update partition can be also moved to that to an external NVM and a swap partition that can be as small as the flash physical sector size which is used for redundancy during the swap operations to guarantee the the power failsafe feature on richer systems like embedded linux or position independent kernels we do use the ab election so if firmware exists in both partitions we're going to select the one with the latest version of course as long as both can be verified and then prepare the execution for the specific machine so we're talking about un64 or x86 where there's has to be some preparation done also for instance for the execution level the ring level and the interrupt routing for more complex systems and of course the update strategy is not always the same it's very simple it's about 100 lines of code there are more variants and we keep adding those and it is really a birth view of the the the wafboot components that can be recombined according to the specific use case so in the simple use case on a microcontroller at first we flash wafboot in the on its own partition and then we deploy the factory firmware that's signed as version one and this is the like normal first boot where wafboot will authenticate so at this point we don't need the jtag because we can disable that and wafboot authenticate the current firmware and boot into boots into that and that's normal operating condition but then you can transfer an update there and sign and transmit the firmware update which is received with any protocol because really this depends on the application also according to rfc and the the firmware that's uploaded there will be then verified and if it's valid and it has version number that's bigger than the current one the two images will be swapped so the previous firmware sits there in the update partition as I was previously mentioning so that if something goes wrong we can always swap it again and return the target to the initial situation before the update started the next boot of course we are back to the situation with with the newer firmware so the firmware will still be authenticated before booting all the time let's talk about the failsafe countermeasures as how we call it the million dollar brick avoidance we have a very predictable flow there is no dynamic dynamic memory heap is banned of course that prevents the the common silly error in embedded like it so historically silly error like heaps stack collisions our interrupts are all off and that's that has to do again with the predictable flow so we don't want surprises if we are not using devices we keep if not using peripherals we keep them off and if we have to use them we do prefer a slower polling approach rather than IQ where interrupts can happen at any point in the code and would also imply more non-predictable flows and so we have a compile time defined behavior for both the flows possible and the memory allocation and this is of course possible because wolf crypt can be compiled without any memory okay with any dynamic memory allocation and we can measure the stack space used at compile time the power failure save swap means that the power as I was saying can be interrupted and microcontroller can be reset at worst possible moment during the swap operation and the swap would be resumed from the point and yeah confirming the update or rolling back to previous version is something that you have to integrate in your application or operating system so for instance when the device is available again to be reachable through the network you can call the wolf boot success function which sets a flag in the flash or in the NVM device that you're using saying that that firmware is actually booting it's not just verified it's also working which is usually important and at that point we can discard the old firmware that was stored in temporarily in the update partition we of course have more unique features we talk about that update that reduce the update size reduce the transfer size it has two levels of authentication because first we identify authenticate the patch and then we apply the patch and we authenticate again the resulting image and the revert is always possible without any overhead from the storage point of view because we do have two ways patch so we have the patch is actually twice as big as the difference because it contains the differences between one and two and two and one and we do have actual side channel glitch attacks mitigation this has been a very long research and a very difficult set of patches adding quite a big amount of volatile architecture specific assembly but it has been tested on Cortex ham against voltage clock fault injections electromagnetic fault injections actual attacks that we have seen happening to one of our partners UAE in Canada which is specializing on this while other similar products in the open source world claim to have this but we have proven that those counter measures are absolutely ineffective on mc bootference even if mc boot claims to have those and of course a boot loader self-update we haven't seen this feature on any other boot loader we can authenticate multiple images so it's not just the booting firmware but you can have for instance a configuration partition that has a different set of keys we work on Cortex arm v8 to have a separation so you can update secure and unsecure domains and and we have a simple key store that has flags that it's a mask of permission that says which key can be used to authenticate which partition so this is extremely flexible if you have a model with multiple parties involved distributing software for for the same target in a secure way and of course once you sign a firmware with one of the available private keys the boot loader will automatically select the associated public key because in the manifest we do have a hint now just briefly before concluding let's see what kind of challenges the boot loader alone solves it's the tasks accomplished that you hear as providing a secure and reliable update mechanism key management tools to detect and discard the potential attacks of forged non-authentic firmware and managing interaction with the hardware and manage the storage where the updates are stored etc what we don't do at the boot loader level is preventing firmware updates to be intercepted for instance or ensure that only authorized device get the firmware that we're sending over because of course it's not authenticating itself so these are the challenges that are left to the secure transfer part and of course this can be done we suggest to be done on with standard secure protocol so anything that that you do should be always covered by secure protocols DTLS TLS and you know any components that we provide as I said are not related to a specific transport so they can be used in in peculiar and niche protocols as well we have customers updating firmware through canvas in a car still using TLS over as if it was TCP so you can see here we have an entire ecosystem of components we just seen Wolfput and the secure boot and firmware updates part in this talk but of course we can integrate all those components to provide a complete firmware update with those additional security requirements where they're available and this concludes my talk but gladly answer some questions. Thank you for a great talk I have a couple of questions just let me get my notes here. Sure. First of all the encryption and signature algorithms you employ are do you offer any quantum resilient versions of them yes we do we haven't integrated yet in Wolfput but Wolfcrypt already has a few of those algorithms that were finalists in the in the next selection some of them are only available through Libo QS so they're implied that you need the POSIX system for it but we do have initial implementation of deletion I think our Falcon that's running on a embedded device so it is in our 2023 roadmap to integrate those to have an example of post quantum safe security cryptography for the authentication part for the encryption we are less worried okay because we believe ES is still okay and how flexible is Wolfput for custom signatures and or crypto algorithms how easy is it to extend if one would need their own if you have requirements and other the manifest error is documented and it's basically a TLV so you can add your own tag and there is a tag for the authentication algorithm right so you just extend the value for those and that's how we have built up so the initial version that only ED25519 that we expanded to ACC with different key sizes and same for RSA and we recently added ED448 all right all right and another question about the delta updates how do you solve that when you have encrypted flash storage yes that's a so basically works like this the delta is built on the clear text images and then it's afterward is signed and then it's encrypted right so it's the crypt verify reassemble and verify okay I had a question about physical attacks but saw you mentioned it in the slides about the glitch attacks and clock skew and stuff yes and final comment was a third way of doing software update where you have a single partition which is your main partition and the only one that is supposed to be running and then you have a rescue partition or a disaster recovery partition is that something you would support as well or is it in the roadmap yes no that's that's that's something that customers asked as a customization which we haven't published just because they were doing it on two different microcontrollers at the same time so it was quite peculiar but as I said the main update function is just 100 lines of code and you can write your own just by assembling the various pieces as if they were LEGOs so it's like you can decide when to do integrity check verification check and where to copy what or the crypt to RAM and we do have internal APIs and what would that can be used for that and actually you could also not use what would as bootloader and use what put as a library because of this because I think you have the possibility to use the verification function which gives you the opportunity to use our host tools and you still have a bootloader run architecture we don't yet support okay and one final question how you done any research in the systems which employ red black separation yes we do have a good track record on Xilin's zinc plus platform where we do integrate with with their first stage bootloader and what is employed as a second stage bootloader on the application processor and in that case the provisioning is left to the FSBL and there the red black keys strategy of the manufacturer is respected and we're working with similar approaches using the the cam driver from nxp devices like a mx6 and mx8 yeah thank you is opti supported out of the box or is that up to the user opti yeah it's a it's a sequence stage for us right so it's we are not yet managing any trust on a functionality so we just authenticate opti as if it was a normal operating system or any other hypervisor there and and keep control to that what we can do to assist there is selecting the execution level that's that's needed by by your configuration which in case of opti i guess it would be the highest one so you can run it as an hypervisor so there's no built-in way to use it as hardware key management not not at the moment we haven't had requests from the market on this we are a question called company so as soon as the use case comes up lots of questions you mentioned about the about the incremental updates that you have a two-way patch so you have the patch forward and also the patch backwards to correct but in a case in case of a security update you really don't want to be able to roll back because you will roll back to an unsecured system correct so there is a way to disable it just say that this is a security update either you apply it and it works or just stop because maybe there is an attack in place and the system is not secure anymore yeah I understand what you're saying but the actual rollback it's a controlled rollback so in normal use case we never allow rolling back to a previous version that's coming from an update but when we roll back that delta or not is because we were not able to confirm that the firmware is actually working so you you don't want to break so if you were able to send a valid firmware image that can be validated or authenticated but maybe one of your engineers has introduced a critical bug into that and your device is not reachable anymore hopefully you put your waftput success point in your code where the device can be reachable so if that function is not called and you reboot again for instance to a watchdog the bootloader will have to have a way to roll back to to the previous version but that's the only case when this is allowed and it's clear in the code when this operation is allowed or not and this is also glitch protected okay thank you and is this supposed to be complementary with arm trusted firmware or is it like a replacement for arm trusted firmware we aim to be a replacement for arm trusted firmware at certain point there is a branch already doing that and the the reason for it is that we want to provide wolfcrypt as a crypto module so we're still deciding how many apis to support for now we support our own callback mechanism with our own api function names and pkcs11 and thinking about PSA as well but we don't have enough attention from the market to implement PSA at this time and but yeah eventually we do have a branch that's public and you can see it on our github where we are heavily working on this and we think that by the end of the year we'll have uh i provide a version that can can be a replacement for tfm and a safety critical one great thank you as in time is up and we need to switch to the next session so stay for the next session our team linux in safety critical applications thank you everyone thanks