 So we're checking out the MQ boot here a bootloader for IoT. Hello, who are you? My name is David Brown. I'm with Lenaro and what are you? What is this? So this is a NXP Freedom K64 board. This has a ARM Cortex M4 based CPU on it. We're gonna be showing the bootloader that we've come up with it works both with Zephyr and Minute currently. There's interest in other OSes as well for this. So it's a shared bootloader between... what is Minute? So Minute is another real-time operating system similar to Zephyr and they originally developed the bootloader and we worked with them to port it to Zephyr as well. How are you able to share a bootloader between different platforms? So there's a set of common code that is used by all of them and then a small amount of shims that interface directly to the underlying operating system. The bootloader doesn't have a large number of requirements. It basically needs to operate the flash driver and print some messages out. All right, so what are you showing here? So what we're showing here is we have the bootloader that I can use a JTag debugger to flash into the device and then looking at the serial port we can see that there is a small JavaScript interpreter running. It's called jerry script. And if we reset, you can see that we're still in that. So that's pretty quick or? Well, so the thing that we can do now is an over-the-air upgrade. So there's a new version of the firmware. So this firmware will be sent and placed in a second partition on the flash device and then the bootloader will look for that, detect that there is a new image there, verify its signature to make sure that this is supposed to be running and then we'll swap the two images so that the new version won't runs. And once that's done, we now have a small Python interpreter running on the target. And as a one particular use case, this could be a test build and if the test fails, the bootloader would then swap the old image back that the upgraded image didn't work and the device is not running a useless image. So is that a fully secure, stable way of updating IoT? That's the idea. Fully secures a pretty strong term to use. It does require some hardware support to protect the bootloader itself from being replaced. As I began, I wrote the bootloader with a JTAG debugger. So it will be better on the Cortex M33? Yeah, well what's really required is the ability to lock the flash and prevent it from being written to once the bootloader is placed into it. Lock the flash, prevent it to be written to. Correct. So that's not something in Cortex M4 and M3? It's generally a feature of a specific SOC and in this particular case, for kind of clear reasons, you don't want to do that during development because you go through a lot of boards if you lock it each time you change your software. And then so you're going to be able to verify signatures and safely upgrade from the verified image. Yes. So what does mean the signatures verified? I have another demo where we can load in an image where I've corrupted one byte of it and the upgrade is just rejected entirely. Is there any way that people will be able to fake that or trick that somehow? Depends on which people you refer to. I mean, this is the same kind of cryptography that's used to secure websites. There's a ECDSA signature over a SHA-256 sum. And as long as the public key is kept, or the private key is kept private, it shouldn't be available. And this whole Zephyr stuff is kind of new, no? Yes. And it's been moving very fast? Definitely, yes. So that means you have a lot of stuff to do? Is that the... Oh, there's definitely a lot to do, yes. This is what you work on? Yes. So I've been working on this bootloader for about six months now. All right. Is it fun? I enjoy it, yes. It's challenging. Because this is very important. There's all these lights and all these things and if they're connected, they're not secure, but you want to make them secure. And really the bootloader is kind of the first important stage to any kind of security you have. If you don't trust the image that you're running, then any security you have after that could be thwarted by simply loading rogue images. So it's kind of the underlying thing behind any of the security we have on these targets. Is there other parts of the security that's important, or is just security bootloader stuff? Oh, no, the other parts are definitely important. Well, you need ways of protecting memory, secure cryptography between the device and other things it may be communicating with. Goodness, there's all kinds of things. So everything has to go through the trust zone all the time? Yeah, and obviously there's different kinds of levels of security. These devices are very small. The ARM V8 M's aren't even yet available and people want to build devices. So there's different levels of security you get depending on the hardware. And the narrow has taken a big role in all this solving all these issues. We're trying to. Yeah. And the team is spread around the world? Yes. Yeah, I'm based in Denver. I'm the only one on my team there. And you're chatting with some people in Sweden? Yes, that's pretty regular, yes. Okay, cool.