OK, welcome. Thanks for coming to this talk. We are getting a little bit closer to the
hardware in this talk. Compared to what we've seen so far, and we're talking about
wolf boots, resilient quantum resistance equipment for all architectures. I am Daniel
like I'm out of from wolf as a cell. Wolf as a cell is a company that develops
a maintain a number of softer products. The main one being wolf as a cell itself, which
is lightweight, TLS and crypto implementation for mostly oriented to embedded devices.
We are 20 times smaller than open itself so we can scale down to micro controllers and
smaller embedded systems which scale much better. We are open ahead on specifications. We were
ahead on the TLS 1.3 for instance, lately, we support all operating systems
for more or less that we know of, and we have certifications for FIPS 140-3,
and we can be the best asset crypto and we invite you to challenge us on this.
And we are all the things that we do are dual items. Some are GPL-3, some are GPL-2,
two plus, and we offer commercial items for those folks that cannot use the GPL version,
which is most of our customers and this allows us to maintain our products with a professional team
of developers. And of course besides Wolf as a cell and TLS, we have three main focus points.
We focus on data or securing data addressed to cryptography. So we are our crypto engine
used as a standalone project that's called Wolfcript. We've secured data in transit with
Wolf as a cell and also with SSH, Wolf as a SAGE. We have the Wolf and QTT client.
We have a number of products, but here today, to talk about secure boot and firmware updates.
So that's a third area there. And of course, if you're here, you probably know what secure boot is
and what it's go. And so the goal is basically to prevent anyone to load a firmware that's not
authorized on your in this case embedded system. So that's where we focus on today. So we're not talking
about generic computers as the previous speaker, but you have to know how this project has
started in 2018. And our first target was a code exam. So there is more microcontrollers in this
case. We want to implement firmware updates over the air because many of our customers and users
were already doing this themselves using our Wolfcript engine. So basically, they were all the
time to invent in the same wheel. So we decided to give this wheel a shape. And since we don't
do anything, we don't invent anything. We are company that's based only on specifications are
come from standards. The first thing we did is looking for a standard. And there was none at the
time. But there was this group within the APF. There was working on a draft. There was called suit
at the time. There's a software update for the Internet of Things. Later, you name to something else,
but still this document became an informational RFC. I think in 2021, it's called RFC1919.
So you understand this was initially just an IoT product. So for this reason,
I made a talk at the beginning. Well, after a couple of years, the projects started here at
Fossilum, but he wasn't the IoT that room. So you can see that we grew a little bit past that.
And we started porting to different architectures. We started with this five, 32 bit.
We also added the Renes' architecture, which is a proprietary architecture. And then during the
years, we also supported to actual applications, CPUs. We did a porting refee, which is mostly,
let's say, the mostration for us because refee is a very complex chain. It's too complex to fit
in embedded Linux systems for us. And especially in those scenarios where safety is also important,
not just security. Then we scaled up, we ported to PowerPC. We ported to Oric Cycure. That's very
popular targeting, automotive, and also on the cortic save family. So that's why you see
R and twice there. Nowadays, we support all these architectures. We have 35 plus targets, probably more.
Most of the time you can do that in C, if you know what you're doing. And one specific thing I'll
talk about a bit more is a protection against glitch attacks, default injection. Because after
while we start to this project, this company, UAE, that makes this fantastic device,
the ship shelter. I don't know if you know this one. Basically, you can inject electromagnetic
fault injections and then you can make your secure bootloader skip a specific instruction.
And that's a common attack on if you can afford one of these on secure bootloader, especially in
IoT devices. So that was a major concern for us. So we went through, let's say,
face where we managed to add some architecture-specific mitigations. Because most of those are
volatile assembly, because we need to trick the compiler not to discard our redundant checks there.
So here, here, adversely, is the compiler itself. And we managed to, the mitigations were verified
by the folks that reported this in the first place. We do have certified security, because
our crypto engineers, FIPS 140, the streets cryptographic certification. And we also have several
safety certification. In particular, DO178C, that's for airborne devices. So all embedded devices
that are on board on airplanes need to respect this and it's a very strict requirement on safety.
We have flexibility. We do distribute with Wofboot also this portable key tools that allow you to
sign and the key keys and manage the keys inside the firmware. We support multiple
petitions, multiple keys. We do have encryption even then to end from the sign to the verify
there is an encryption that's optional to AAS or Chacha. And we can support a floating
sign-in to AAS app, which is later, because it becomes relevant in the post-quantum features.
The RFC-1919 is information out, but indicates that the boot law needs to be
very small, because large parsers, apparently, are important attacks are face.
In need to use a manifesto for metadata, that's what we use to carry the signature and
the shot I just to authenticate and verify the integrity of the image. The authentication should
be based on a trust anchor. That's also a term that's defined by RFCs. We go a little bit further
into that. We do have based the integrity verification. And the app transfers are no managed
directly by the boot law there, but they need to be managed by the application. The boot law
they find the image there and verify it. And this, of course, prevents the boot law to have to carry
something like a TCP-HP stack or any radio drivers that are a significant amount of attacks
or face that you add to a very critical part that's your first stage boot law during most cases.
So the key pair, you generate it once, you keep it yourself. In most cases, of course, you can
use a rack HSM or even HSM as a service in combination with our key tools. So you can have a cloud-based
HSM which manages your signing part process and we split the process so that this is possible.
The sign tool does just attach this manifesto to the image and the manifesto of course contains
the signature to verify the authenticity of the image. And since the firmware version is also part
of the signed payloads, it's impossible for an attacker to try and fall back to a previous version,
knowing for instance a vulnerability in your previous version. So that's how it works. There's
just a firmware manufacturer, you add the priority key, LFC, 19 mandates that you have a public key,
only embedded system somewhere and then you verify your embedded firmware before starting.
The trust on code basically is a public key that cannot be
changed, altered by an attacker. So it needs to be stored somewhere where it's impossible
for an attacker to modify it. And there's several ways to do this. The common way we use is
if your book loader is already in a partition that's not modified, but for instance, it's just
programmed once. You can embed the key store in the bootloader itself. Otherwise, you can use a
neighbor embedded system and write it back to flash, OTP, we do have OTP drivers for instance for
a CM32. You can use an HSM or a secure vault in the surrounding area, so in the machine itself,
and even the TPM. We support interaction with the TPM. Of course, you know, in a microcontroller,
you're supposed to execute in place. So what we do is a swapping mechanism that involves a
swap partition, more details about this. Also in the previous talk, because this mechanism
is still the same. So if you check the archive for the 2020 talk, you'll see that more in details.
On TPU-based system, we added an AB election at boot, so basically bootloader chooses between
images that can be verified. And just the last one, and there is of course a mechanism,
if you want to confirm that firmware version. And we integrate with the TPM in several ways,
TPM 2.0, we do measure boot to PCR extend, similar to what was presented earlier.
Yeah, we also support parametric encryption on the TPM, so no one can wipe out your TPM while
the bootloader is communicating with it. Some features we have that recently, we can do
trust-on management on code XM devices, so it's a full replacement for TSM, that he moves a lot
of bloating from it, and that's specifically useful in those use cases where you need to reduce
the complexity to reduce the attack surface for the reasons I already said. But you still want to
use the trust-on-am 2 separate secure and secure area. In this case, both boot is not just a bootloader,
but it adds the both-cript functionalities in the secure part that can be access to a PCS 11
interface from the non-secure application. One very big port that we did was the X86 port
on specifically on the 11th generation Intel Core 7. Of course, this is not for generic PC,
and you understand this is a very advanced and better device, it's usually used with the
media or something like this, so the green part there is secured by the Intel provided
Intel bootload, and then you have two stages of soft boot to the first one,
verifies the second, and then the second stage verifies the kernel image.
The important thing to note here is that Intel provides something that's called FSP,
firm support package, and a demonstrator bootloader is called Slim boot, which is probably
10 times in size of what soft boot looks like here, and in the same setup. So Intel is starting
to suggest safety oriented customers to adopt soft boot indoor scenarios, for instance, in
aerospace or in medical devices. And now we talk about post-quantum secure boot, because this is
very important. We started developing post-quantum solutions in-war physics hell very long ago,
but we started to introduce our own specific implementation for embedded devices, and the
worst boot, of course, was one of the early adopters of this, and the first thing we added was
hash-based signatures, so LMSHsets, XMSS, and then after a while we switched to our native
implementation, before we were using the PQC lib with the reference implementation. And then we
added recently towards Q3 last year, MLDSI and hybrid solutions that are very important to
prepare to secure boot against both types of attack. So attacks on classic cryptography and post-quantum,
we'll see that in a minute. So quickly, the status of standardizations of these algorithms,
because of course at some point we need to choose those algorithms. We already support
classic algorithms, all of them, RSA, ECC, ED24519, ED448. But of course we had to add some more
of those, and we had to understand which ones, so already in 2016, let's say, a contest for
including this quantum safe algorithms. And of course, the thing we care about the most is public key
verification, so we had to choose algorithms in that area. These are excluded from the algorithms,
because they were stateful. Stateful means that every time you generate the signature,
you need to keep the state. And this otherwise introduced a very catastrophic type of vulnerability.
So for this reason, these algorithms, as they are standardized by ITF, in these RFCs,
mandate that this is the classic scenario from before, and that works also with MLDSI as we will see.
But with the stateful algorithms like LMSXMSS, you can't manage your key yourself. So you need
a separate HSM that keeps the state, every time you sign a new key, and we of course support this,
because we cannot flow that to a third party sign. And the verification is in fact the same.
But they actually algorithms that needs to be approved where this so far, what's important for us,
we just disregard the first and the third, and we checked the MLDSI, because this is a replacement
for RSI and CCM, in signatures, and it's based on the lithium. And the important also that
NSI is mandating to start migration to post quantum cryptography, secure boots, starting from this
year. And this will be completely replaced in the classic algorithms in a few years.
And this document was already released in September 2022. So this is basically the timeline
the yellow line is what concerns us, and it's actually starting now at the beginning of this year.
So people should be already switching to post quantum for new, secure boot devices.
What's happening in Europe is slightly different, kind of slower. This document was released in April
last year, and started the task force that needs to decide which algorithms will be standardized
for using the European Union. And this document from the European Commission actually defines
the shoes. Should define a roadmap by April 26, but there is no yet mentioned of algorithms.
On the other hand, Germany fans and the Netherlands are leading the effort and they are working
on a common document where they are looking to standardizing the same algorithmist nest with the
addition probably of something, but we know let's say the application of any algorithm
started being proposed so far. So the addition would be flood or cam that's being proposed by the
Germans. So what we have just to wait to see what happens over here. We're lagging behind a few
years now, I think, about six. What are the concerns actually? So there is not a harvesting,
you probably know, long-lived device, and the migration path cannot be that easy. There is
one thing to keep in mind that these new implementations and designs that have been
standardized, I cannot knew. So they don't have the same maturity as classic algorithms.
And you could say ECC has no known attackers nowadays as we know it. So why should we replace it?
So the actual strategy should be hybrid and that's what we introduced last. So we can do hybrid
signature schemes. So it has two signatures. One is a classic, for instance, ECC and the other
one is post-quantum and the bot signatures need to be verified. And this of course natively supported
by Wofboot. So instead of having one private key, you get two private key, one is classic ECC,
the other one is PQC. Of course the classic can be RSA or anything else. And we have a best-in-class
solution that's a MLDSA 87 plus ECDSA51, which is in line with the current recommendation from
Nissan and CNSA. And that's what our customers have been advised to adopt for especially
long-lived device. So we keep working on a post-quantum algorithms. And of course
you will see more of this coming soon. But this concludes my presentation. So take some questions now.
Now I have questions. Oh, yeah, thank you.
What happens if you have Wofboot as bootloader and you flash a firmware over it?
Yeah. Oh, all right, okay. We normally have two partitions there, right? Even in micro-controllers.
So if you send an update that's not valid, that simply gets discarded and you keep putting the
same one. Even if the firmware is valid, but it has a bug. So you stage it. And at some point
it's been signed. But one of your engineers is put a bug in there. So the device is not reachable anymore.
We have a mechanism where we call a success function that sets a flag in the flash and says,
this is good. So I just did it actually replace MCU bootloader with Wofboot on my watch. So
and there is a success button that says, okay, I can see time and, you know.
Fantastic. Thank you.