WEBVTT 00:00.000 --> 00:13.760 OK, welcome. Thanks for coming to this talk. We are getting a little bit closer to the 00:13.760 --> 00:20.240 hardware in this talk. Compared to what we've seen so far, and we're talking about 00:20.240 --> 00:27.240 wolf boots, resilient quantum resistance equipment for all architectures. I am Daniel 00:27.240 --> 00:33.960 like I'm out of from wolf as a cell. Wolf as a cell is a company that develops 00:33.960 --> 00:41.560 a maintain a number of softer products. The main one being wolf as a cell itself, which 00:41.560 --> 00:49.800 is lightweight, TLS and crypto implementation for mostly oriented to embedded devices. 00:49.800 --> 00:55.160 We are 20 times smaller than open itself so we can scale down to micro controllers and 00:55.480 --> 01:02.200 smaller embedded systems which scale much better. We are open ahead on specifications. We were 01:02.200 --> 01:08.280 ahead on the TLS 1.3 for instance, lately, we support all operating systems 01:09.160 --> 01:14.360 for more or less that we know of, and we have certifications for FIPS 140-3, 01:15.160 --> 01:22.520 and we can be the best asset crypto and we invite you to challenge us on this. 01:23.480 --> 01:29.160 And we are all the things that we do are dual items. Some are GPL-3, some are GPL-2, 01:29.960 --> 01:37.880 two plus, and we offer commercial items for those folks that cannot use the GPL version, 01:38.840 --> 01:44.520 which is most of our customers and this allows us to maintain our products with a professional team 01:44.520 --> 01:53.560 of developers. And of course besides Wolf as a cell and TLS, we have three main focus points. 01:55.000 --> 02:01.240 We focus on data or securing data addressed to cryptography. So we are our crypto engine 02:01.240 --> 02:06.440 used as a standalone project that's called Wolfcript. We've secured data in transit with 02:06.440 --> 02:11.960 Wolf as a cell and also with SSH, Wolf as a SAGE. We have the Wolf and QTT client. 02:12.600 --> 02:17.560 We have a number of products, but here today, to talk about secure boot and firmware updates. 02:17.560 --> 02:23.960 So that's a third area there. And of course, if you're here, you probably know what secure boot is 02:23.960 --> 02:31.960 and what it's go. And so the goal is basically to prevent anyone to load a firmware that's not 02:31.960 --> 02:38.840 authorized on your in this case embedded system. So that's where we focus on today. So we're not talking 02:38.920 --> 02:45.640 about generic computers as the previous speaker, but you have to know how this project has 02:45.640 --> 02:54.760 started in 2018. And our first target was a code exam. So there is more microcontrollers in this 02:54.760 --> 03:00.600 case. We want to implement firmware updates over the air because many of our customers and users 03:00.600 --> 03:08.760 were already doing this themselves using our Wolfcript engine. So basically, they were all the 03:08.760 --> 03:14.600 time to invent in the same wheel. So we decided to give this wheel a shape. And since we don't 03:14.600 --> 03:19.480 do anything, we don't invent anything. We are company that's based only on specifications are 03:19.480 --> 03:24.520 come from standards. The first thing we did is looking for a standard. And there was none at the 03:24.520 --> 03:30.120 time. But there was this group within the APF. There was working on a draft. There was called suit 03:30.120 --> 03:36.040 at the time. There's a software update for the Internet of Things. Later, you name to something else, 03:36.040 --> 03:45.880 but still this document became an informational RFC. I think in 2021, it's called RFC1919. 03:46.760 --> 03:52.760 So you understand this was initially just an IoT product. So for this reason, 03:53.720 --> 03:58.680 I made a talk at the beginning. Well, after a couple of years, the projects started here at 03:58.680 --> 04:07.880 Fossilum, but he wasn't the IoT that room. So you can see that we grew a little bit past that. 04:07.880 --> 04:12.200 And we started porting to different architectures. We started with this five, 32 bit. 04:13.320 --> 04:19.000 We also added the Renes' architecture, which is a proprietary architecture. And then during the 04:19.880 --> 04:26.120 years, we also supported to actual applications, CPUs. We did a porting refee, which is mostly, 04:26.840 --> 04:33.320 let's say, the mostration for us because refee is a very complex chain. It's too complex to fit 04:33.320 --> 04:39.800 in embedded Linux systems for us. And especially in those scenarios where safety is also important, 04:39.800 --> 04:48.360 not just security. Then we scaled up, we ported to PowerPC. We ported to Oric Cycure. That's very 04:48.440 --> 04:55.880 popular targeting, automotive, and also on the cortic save family. So that's why you see 04:55.880 --> 05:03.800 R and twice there. Nowadays, we support all these architectures. We have 35 plus targets, probably more. 05:03.800 --> 05:10.120 Most of the time you can do that in C, if you know what you're doing. And one specific thing I'll 05:10.120 --> 05:17.480 talk about a bit more is a protection against glitch attacks, default injection. Because after 05:17.560 --> 05:22.200 while we start to this project, this company, UAE, that makes this fantastic device, 05:22.200 --> 05:27.720 the ship shelter. I don't know if you know this one. Basically, you can inject electromagnetic 05:28.440 --> 05:34.120 fault injections and then you can make your secure bootloader skip a specific instruction. 05:34.120 --> 05:40.440 And that's a common attack on if you can afford one of these on secure bootloader, especially in 05:40.440 --> 05:46.760 IoT devices. So that was a major concern for us. So we went through, let's say, 05:48.200 --> 05:55.000 face where we managed to add some architecture-specific mitigations. Because most of those are 05:55.640 --> 05:59.640 volatile assembly, because we need to trick the compiler not to discard our redundant checks there. 06:00.760 --> 06:07.960 So here, here, adversely, is the compiler itself. And we managed to, the mitigations were verified 06:08.280 --> 06:14.760 by the folks that reported this in the first place. We do have certified security, because 06:14.760 --> 06:22.040 our crypto engineers, FIPS 140, the streets cryptographic certification. And we also have several 06:22.040 --> 06:29.560 safety certification. In particular, DO178C, that's for airborne devices. So all embedded devices 06:29.560 --> 06:35.800 that are on board on airplanes need to respect this and it's a very strict requirement on safety. 06:38.120 --> 06:44.520 We have flexibility. We do distribute with Wofboot also this portable key tools that allow you to 06:44.520 --> 06:51.240 sign and the key keys and manage the keys inside the firmware. We support multiple 06:51.240 --> 06:57.240 petitions, multiple keys. We do have encryption even then to end from the sign to the verify 06:57.240 --> 07:05.240 there is an encryption that's optional to AAS or Chacha. And we can support a floating 07:05.240 --> 07:11.000 sign-in to AAS app, which is later, because it becomes relevant in the post-quantum features. 07:12.440 --> 07:17.560 The RFC-1919 is information out, but indicates that the boot law needs to be 07:17.560 --> 07:23.720 very small, because large parsers, apparently, are important attacks are face. 07:25.400 --> 07:31.960 In need to use a manifesto for metadata, that's what we use to carry the signature and 07:32.280 --> 07:40.600 the shot I just to authenticate and verify the integrity of the image. The authentication should 07:40.600 --> 07:45.960 be based on a trust anchor. That's also a term that's defined by RFCs. We go a little bit further 07:45.960 --> 07:51.400 into that. We do have based the integrity verification. And the app transfers are no managed 07:51.400 --> 07:55.080 directly by the boot law there, but they need to be managed by the application. The boot law 07:55.080 --> 08:00.840 they find the image there and verify it. And this, of course, prevents the boot law to have to carry 08:00.840 --> 08:09.880 something like a TCP-HP stack or any radio drivers that are a significant amount of attacks 08:09.880 --> 08:14.760 or face that you add to a very critical part that's your first stage boot law during most cases. 08:14.760 --> 08:19.560 So the key pair, you generate it once, you keep it yourself. In most cases, of course, you can 08:19.560 --> 08:30.600 use a rack HSM or even HSM as a service in combination with our key tools. So you can have a cloud-based 08:30.600 --> 08:37.480 HSM which manages your signing part process and we split the process so that this is possible. 08:38.360 --> 08:43.560 The sign tool does just attach this manifesto to the image and the manifesto of course contains 08:43.560 --> 08:49.400 the signature to verify the authenticity of the image. And since the firmware version is also part 08:49.400 --> 08:56.680 of the signed payloads, it's impossible for an attacker to try and fall back to a previous version, 08:56.680 --> 09:02.760 knowing for instance a vulnerability in your previous version. So that's how it works. There's 09:02.760 --> 09:09.080 just a firmware manufacturer, you add the priority key, LFC, 19 mandates that you have a public key, 09:09.080 --> 09:14.520 only embedded system somewhere and then you verify your embedded firmware before starting. 09:15.320 --> 09:18.600 The trust on code basically is a public key that cannot be 09:19.000 --> 09:26.600 changed, altered by an attacker. So it needs to be stored somewhere where it's impossible 09:26.600 --> 09:33.160 for an attacker to modify it. And there's several ways to do this. The common way we use is 09:33.160 --> 09:38.200 if your book loader is already in a partition that's not modified, but for instance, it's just 09:38.200 --> 09:43.720 programmed once. You can embed the key store in the bootloader itself. Otherwise, you can use a 09:43.720 --> 09:48.760 neighbor embedded system and write it back to flash, OTP, we do have OTP drivers for instance for 09:48.760 --> 09:55.160 a CM32. You can use an HSM or a secure vault in the surrounding area, so in the machine itself, 09:55.160 --> 10:03.240 and even the TPM. We support interaction with the TPM. Of course, you know, in a microcontroller, 10:03.240 --> 10:07.960 you're supposed to execute in place. So what we do is a swapping mechanism that involves a 10:07.960 --> 10:13.000 swap partition, more details about this. Also in the previous talk, because this mechanism 10:13.080 --> 10:18.680 is still the same. So if you check the archive for the 2020 talk, you'll see that more in details. 10:19.720 --> 10:26.440 On TPU-based system, we added an AB election at boot, so basically bootloader chooses between 10:26.440 --> 10:31.480 images that can be verified. And just the last one, and there is of course a mechanism, 10:31.480 --> 10:40.440 if you want to confirm that firmware version. And we integrate with the TPM in several ways, 10:40.440 --> 10:46.120 TPM 2.0, we do measure boot to PCR extend, similar to what was presented earlier. 10:48.120 --> 10:55.000 Yeah, we also support parametric encryption on the TPM, so no one can wipe out your TPM while 10:55.000 --> 11:01.080 the bootloader is communicating with it. Some features we have that recently, we can do 11:01.800 --> 11:07.960 trust-on management on code XM devices, so it's a full replacement for TSM, that he moves a lot 11:08.040 --> 11:14.280 of bloating from it, and that's specifically useful in those use cases where you need to reduce 11:14.280 --> 11:19.880 the complexity to reduce the attack surface for the reasons I already said. But you still want to 11:19.880 --> 11:26.360 use the trust-on-am 2 separate secure and secure area. In this case, both boot is not just a bootloader, 11:26.360 --> 11:31.800 but it adds the both-cript functionalities in the secure part that can be access to a PCS 11 11:31.880 --> 11:39.560 interface from the non-secure application. One very big port that we did was the X86 port 11:41.400 --> 11:48.200 on specifically on the 11th generation Intel Core 7. Of course, this is not for generic PC, 11:48.200 --> 11:53.000 and you understand this is a very advanced and better device, it's usually used with the 11:53.000 --> 11:58.680 media or something like this, so the green part there is secured by the Intel provided 11:59.640 --> 12:04.600 Intel bootload, and then you have two stages of soft boot to the first one, 12:05.880 --> 12:10.280 verifies the second, and then the second stage verifies the kernel image. 12:11.800 --> 12:16.440 The important thing to note here is that Intel provides something that's called FSP, 12:16.440 --> 12:22.120 firm support package, and a demonstrator bootloader is called Slim boot, which is probably 12:22.120 --> 12:28.600 10 times in size of what soft boot looks like here, and in the same setup. So Intel is starting 12:28.600 --> 12:35.320 to suggest safety oriented customers to adopt soft boot indoor scenarios, for instance, in 12:35.320 --> 12:41.800 aerospace or in medical devices. And now we talk about post-quantum secure boot, because this is 12:41.800 --> 12:48.680 very important. We started developing post-quantum solutions in-war physics hell very long ago, 12:50.120 --> 12:57.240 but we started to introduce our own specific implementation for embedded devices, and the 12:57.240 --> 13:02.920 worst boot, of course, was one of the early adopters of this, and the first thing we added was 13:02.920 --> 13:10.760 hash-based signatures, so LMSHsets, XMSS, and then after a while we switched to our native 13:10.760 --> 13:16.920 implementation, before we were using the PQC lib with the reference implementation. And then we 13:16.920 --> 13:26.920 added recently towards Q3 last year, MLDSI and hybrid solutions that are very important to 13:27.080 --> 13:35.320 prepare to secure boot against both types of attack. So attacks on classic cryptography and post-quantum, 13:35.320 --> 13:42.120 we'll see that in a minute. So quickly, the status of standardizations of these algorithms, 13:42.120 --> 13:45.480 because of course at some point we need to choose those algorithms. We already support 13:46.120 --> 13:55.400 classic algorithms, all of them, RSA, ECC, ED24519, ED448. But of course we had to add some more 13:56.200 --> 14:06.440 of those, and we had to understand which ones, so already in 2016, let's say, a contest for 14:06.440 --> 14:16.360 including this quantum safe algorithms. And of course, the thing we care about the most is public key 14:16.360 --> 14:25.960 verification, so we had to choose algorithms in that area. These are excluded from the algorithms, 14:25.960 --> 14:30.440 because they were stateful. Stateful means that every time you generate the signature, 14:30.440 --> 14:39.320 you need to keep the state. And this otherwise introduced a very catastrophic type of vulnerability. 14:39.400 --> 14:47.960 So for this reason, these algorithms, as they are standardized by ITF, in these RFCs, 14:49.320 --> 14:55.400 mandate that this is the classic scenario from before, and that works also with MLDSI as we will see. 14:55.960 --> 15:03.320 But with the stateful algorithms like LMSXMSS, you can't manage your key yourself. So you need 15:03.880 --> 15:08.600 a separate HSM that keeps the state, every time you sign a new key, and we of course support this, 15:08.600 --> 15:15.480 because we cannot flow that to a third party sign. And the verification is in fact the same. 15:17.480 --> 15:24.520 But they actually algorithms that needs to be approved where this so far, what's important for us, 15:24.520 --> 15:31.160 we just disregard the first and the third, and we checked the MLDSI, because this is a replacement 15:31.160 --> 15:39.160 for RSI and CCM, in signatures, and it's based on the lithium. And the important also that 15:39.160 --> 15:46.680 NSI is mandating to start migration to post quantum cryptography, secure boots, starting from this 15:46.680 --> 15:53.800 year. And this will be completely replaced in the classic algorithms in a few years. 15:54.360 --> 15:59.960 And this document was already released in September 2022. So this is basically the timeline 16:00.920 --> 16:06.040 the yellow line is what concerns us, and it's actually starting now at the beginning of this year. 16:06.040 --> 16:10.840 So people should be already switching to post quantum for new, secure boot devices. 16:11.560 --> 16:18.920 What's happening in Europe is slightly different, kind of slower. This document was released in April 16:18.920 --> 16:27.480 last year, and started the task force that needs to decide which algorithms will be standardized 16:27.560 --> 16:32.680 for using the European Union. And this document from the European Commission actually defines 16:32.680 --> 16:39.400 the shoes. Should define a roadmap by April 26, but there is no yet mentioned of algorithms. 16:39.400 --> 16:43.320 On the other hand, Germany fans and the Netherlands are leading the effort and they are working 16:43.320 --> 16:50.680 on a common document where they are looking to standardizing the same algorithmist nest with the 16:50.760 --> 16:58.840 addition probably of something, but we know let's say the application of any algorithm 16:58.840 --> 17:03.480 started being proposed so far. So the addition would be flood or cam that's being proposed by the 17:03.480 --> 17:09.720 Germans. So what we have just to wait to see what happens over here. We're lagging behind a few 17:09.720 --> 17:17.160 years now, I think, about six. What are the concerns actually? So there is not a harvesting, 17:17.240 --> 17:25.640 you probably know, long-lived device, and the migration path cannot be that easy. There is 17:25.640 --> 17:31.320 one thing to keep in mind that these new implementations and designs that have been 17:31.320 --> 17:38.040 standardized, I cannot knew. So they don't have the same maturity as classic algorithms. 17:38.040 --> 17:44.520 And you could say ECC has no known attackers nowadays as we know it. So why should we replace it? 17:44.520 --> 17:52.040 So the actual strategy should be hybrid and that's what we introduced last. So we can do hybrid 17:52.040 --> 17:59.400 signature schemes. So it has two signatures. One is a classic, for instance, ECC and the other 17:59.400 --> 18:07.000 one is post-quantum and the bot signatures need to be verified. And this of course natively supported 18:07.000 --> 18:11.400 by Wofboot. So instead of having one private key, you get two private key, one is classic ECC, 18:11.400 --> 18:18.360 the other one is PQC. Of course the classic can be RSA or anything else. And we have a best-in-class 18:18.360 --> 18:26.040 solution that's a MLDSA 87 plus ECDSA51, which is in line with the current recommendation from 18:26.040 --> 18:32.440 Nissan and CNSA. And that's what our customers have been advised to adopt for especially 18:32.680 --> 18:40.520 long-lived device. So we keep working on a post-quantum algorithms. And of course 18:40.520 --> 18:46.280 you will see more of this coming soon. But this concludes my presentation. So take some questions now. 18:46.360 --> 18:55.080 Now I have questions. Oh, yeah, thank you. 19:07.080 --> 19:10.840 What happens if you have Wofboot as bootloader and you flash a firmware over it? 19:10.840 --> 19:20.600 Yeah. Oh, all right, okay. We normally have two partitions there, right? Even in micro-controllers. 19:20.600 --> 19:26.840 So if you send an update that's not valid, that simply gets discarded and you keep putting the 19:26.840 --> 19:32.680 same one. Even if the firmware is valid, but it has a bug. So you stage it. And at some point 19:33.960 --> 19:38.280 it's been signed. But one of your engineers is put a bug in there. So the device is not reachable anymore. 19:39.240 --> 19:43.800 We have a mechanism where we call a success function that sets a flag in the flash and says, 19:43.800 --> 19:49.320 this is good. So I just did it actually replace MCU bootloader with Wofboot on my watch. So 19:49.320 --> 19:54.920 and there is a success button that says, okay, I can see time and, you know. 19:57.960 --> 20:01.960 Fantastic. Thank you.