 All right, let's get started. I've got too many slides and not enough time. Story of my life. Try to talk quick and leave some room for questions. But thanks for joining. As you can see, my talk is on boot to cloud security considerations with IoT. It's a bit of a big topic, so we're not going to dive into super deep details. It's really more just to lay down some signposts. If this is a problem space you're interested in, point you in the right direction and try to give you some help to dig into some of the specific details, just because there's too much to cover. Just to get started, about me, the least interesting slide in the presentation. But my name is Kevin Townsend. I'm a tech lead at Lenaro. I've been there for about four and a half years now. My main focus is generally on ARM, more on the MCU side. A little bit Cortex-A, Cortex-R, but mostly the Cortex-M side of things. RTOS-IS and IoT security. I've been working for about 15 years, full-time, just in open source software. It's always been my bread and butter. It's a conscious choice. I just love being able to contribute to both the open source hardware and the open source community in general. Much more of a firmware person today than my early career was, really, more on the hardware side, which is good, in a sense. In the embedded space, you really need to have a little bit of a foot in both of those camps sometimes. I'm the Zephyr maintainer for ARCH32, the trusted firmware and integration, and just a small little hobby personal project. Zephyr Scientific Computing Library. I just really enjoy working with sensor data. And to me, embedded devices, it's all about taking data, doing fun things with it, and having interesting outcomes. So just a small library I put together to sort of do linear algebra and things like that. And if you're interested, you can see some of my work on MicroBuilder. And that's the GitHub username, obviously, for Zephyr if you need to reach out to me for something. So in terms of agenda, again, these are just sort of high-level things, but we're going to look a little bit at secure boots, at device provisioning, and specifically a bit of a sidetrack on key derivation, which is one of the more important parts, I think, of the provisioning process. How do you secure data in transit? How do you secure data at rest? And we'll distinguish the difference between the two of those. A quick example of tying these things together, what an end-to-end solution for boot-to-cloud security might look like, called Confidential AI, which is just an open source proof of concept we put together in my team in Leonardo. And then a quick checklist wrap up. So let's get started, just in the interest of time. So generally, if you're thinking about a secure IoT system, it's probably going to look at a very high level something like this. You're going to have a couple key components here. You're going to have secure boot, which is generally referred to as your root of trust. You're going to have some sort of firmware component. And that firmware component may or may not be separated into two different execution environments. If you're using something like Trusted Firmware M, for example, you're going to end up with two firmware images where you'll have a secure or a trusted processing environment and an untrusted processing environment. And your sort of firmware decision-making choice is whether you have a single monolithic firmware image or a secure non-score image is going to be based on a variety of factors that only you know. So you'll have that secure root of trust, your firmware image, then on the far right side, you're going to have to have some sort of provisioning infrastructure for your solution and generally some sort of cloud connectivity that doesn't necessarily have to be AWS, Amazon, Google, whoever. Maybe that's behind a company firewall, but generally you're going to want to get that data off somehow for analysis and potentially get information from the cloud infrastructure onto your devices for more updates, sending commands, et cetera. So generally these at a very high level, these are kind of the key silos that you're going to need to look into on a secure IoT system. So let's start with secure boot at sort of the front end of that pipeline. And that's a really important one because secure boot is the one thing that you absolutely want to get right and you don't want that to be an afterthought. If you do not have a secure trusted boot process, you don't have a secure anything because you don't know what you're running. You have no way to verify that this is a trusted image that it hasn't been tampered with, et cetera. So you do not want to leave this to be an afterthought. You absolutely want from the very beginning to be thinking about what does my secure boot process work like, what features does it give me, what do I require for that? Don't leave that to the end. So test that early and test that often. In the case of Zephyr, this is most often an open source boot loader called MCU Boot. It's not always the case, but it's a good place to start and it's well supported. And there's very good documentation around it. And that gives you a fairly solid foundation. Something to keep in mind with the secure boot process though, which may or may not make you feel comfortable, is that generally secure means immutable, particularly for the boot loader. So again, this is why it's important to get this on the table and plan for this from very early days, because that boot loader as your root of trust is generally something that you do not and cannot be changing in the field. It's important to get it right. You've got your verification keys, public keys burnt into that boot loader, probably, to verify the rest of the chain of trust. So get this right, because it's extremely difficult to change that boot loader in the field if you're taking security seriously, which hopefully you are. That secure boot loader should only run valid signed and ideally versioned images. And again, that's part of the immutable process because that signature verification, the metadata for that exists inside generally, the secure boot loader. And I say ideally versioned as well, because one of the things you need to take into consideration is that if and your firmware probably will have a lifecycle and you're putting out incremental releases adding new features, but also hopefully introducing security fixes, and you generally want to certainly consider the idea of enabling rollback protection, which means let's say firmware 1.0.3 has a known security vulnerability, so I put out 1.0.4 and we ship that. I want to make sure that people with malicious intent cannot intentionally roll back to a version with a known vulnerability to take advantage of that. So that's why not just signing, but versioning is also important to plan into your development cycle from the very beginning. So in the case of MCU boot, the K-config flag you want to look at is MCU downgrade protection. And there's a very variety of ways to implement that in hardware and software. Using a hardware counter, there's a lot of knobs to turn there, but something you want to think about and keep into your mind during your planning stages. Image content and signature with whatever your secure boot letter is needs to be verified every single reset. That comes with the cost. It's going to slow down your boot time a little bit, but it's essential to know that every time I boot up my device, the firmware image has not been tampered with, that the signature is still valid. So again, security often, there's a price to pay for that in the case of secure boot that will add some overhead to your startup time. It's nothing ridiculous, but there is a cost to it. Generally, it's worth it. Something you probably want to look for, that MCU boot does support, but if you're not looking for MCU boot, using MCU boot, is you probably want to look for something that also supports image encryption. People are probably always going to find a way to get your binary image off a chip if they're really determined, but a boot loader that at least out of the box supports image encryption at least raises the bar a little bit if you're publishing firmware update images just on an open TCP server or HTTP, et cetera. So just a detail you might want to look for as a criteria is that you can encrypt image as it's in transit from whatever your cloud infrastructure is to your IoT device. And MCU boot does have support for this out of the box. Again, because that secure boot loader is immutable, you're probably going to want to look at what are the hardware recovery options for that, because you can't change the boot loader, but what happens if you flash a faulty image, because generally you're going to be locking down your device in other ways. And this is a bit of a trade-off, whether you want this or don't want this, but it's a good feature to at least a tool to have in your toolbox. So in the case of MCU boot, how that works is you can optionally enable a serial recovery mode that only relies on the boot loader image itself. You can set a specific GPIO pin and then use the standard MCU boot tooling to flash a new valid application image in the field. And the signature, et cetera, will still be verified on that image. The reason that's nice that that's encapsulated purely inside the boot loader is that MCU boot generally has a requirement also on a valid application image. So if I'm using, say, BLE as my transport mechanism to send firmware over MCU boot, that BLE stack actually exists in the application image. So if you get a device that's totally bricked and something happens with that application image that it's corrupted, it is nice in the field to have a potential path over serial to update your firmware image relying only on that 32 kilobyte boot loader. Again, there's pros and cons to that, but it's a nice feature, a nice tool to have in your toolbox. And tooling is going to be a very important requirement when you're looking at secure boot as a problem. We'll go into that in a couple of slides, though. So just to sum up, secure boots, you absolutely want to get this right. You want to do your homework and your due diligence and plan from this early on, but there are some requirements beyond just picking a secure boot loader. For example, secure boot absolutely requires that you are protecting the boot loader flash region from overwrites that nobody else can come in and maliciously replace your boot loader. And that's something that we can't really do at an MCU boot level, because that's going to vary significantly from one SOC to another. Nordic is going to have certain options in place to protect flash memory, NXP, ST are going to have different options. So you really need to be doing your homework to understand how do I lock down that 32, 64, whatever kilobytes of memory so that it can't be rewritten once the device is deployed. And that's just digging into the data sheet. But again, be aware of it. If I can easily overwrite my boot loader, I no longer have any semblance of security on my device. If I can just place a malicious chunk of code in there easily. That also means disabling generally some SOC device recovery options. So for example, if you've used NXP parts, some of the LPC family, it's a fairly popular set of mass market MCUs, there's something called ISP recovery mode where I can set a candidate specific state when I reboot the device in hardware and it overrides any sort of user firmware and gives me access to the debug interface, et cetera. So it's great as a developer because whatever I do to my device, I can always recover it and hook my J-Tag or whatever, my J-Link up and reflash firmware. You absolutely don't want to be exposing that kind of possibility to someone with malicious intent. So you wanna be looking again at the data sheets. How do I lock down that feature? It's usually just setting some fuse on the chip but making sure that you've defined a process to lock down those hardware recovery options that you may or may not be aware of, but you wanna be digging around to lock those down. Similarly, the debug interface. You're gonna wanna lock down the debug interface or I can just hook up my J-Link and be pulling data off getting the hardware unit key or whatever from a register. So plan early on for the sort of details of the risks to make sure that you have a reliable boot process. Again, we can't go into too much detail. I'm just trying to give some high-level pointers. These are the things, the most obvious areas to go wrong and if you wanna make a checklist, do this, this and this. And when you're evaluating your boot process and again, to reiterate, this is the one thing you absolutely wanna get right. So in terms of tooling, this is MCU boot specific but MCU boot actually comes with some really good tooling out of the box. So a boot loader is one thing but the ecosystem around it is also important. It's like a scheduler is kind of boring. Zephyr is a great system because it's an ecosystem. It's a bit similar. Your boot loader, you also want good tooling around that and there are some pretty good tools out of the box and there's some community efforts also to add more tooling. So in the case of MCU boot, you're today, there's a command line tool called MCU manager. I know there's some desire to introduce better tooling here. I think Nordic specifically, you guys were interested in replacing MCU manager with something a bit more flexible. It's still not a bad tool out of the box. So it's a CLI command line management tool and it works over a variety of transports. If yours isn't on this list, you can extend it. So it works out of the box with serial BLE and UDP meaning I can use my mobile phone to interact with my boot loader, send a firmware update, collect some data, et cetera, or UDP or something else. It is extensible and there's an extensible command set. It's not just restricted to firmware images so I can set the date time on the device. If there's an RTC, I can update the file system. I can get thread statistics, stack usage, et cetera and also device statistics. So if you have an iSquad C sensor from the command line I can see how many times was the iSquad C bus pulled, how many errors occurred in the sensor driver. That's extremely useful for debugging things in the field. So the MCU brings not just secure boot to the table. It actually brings you a lot of very useful field debugging analytics information and I find the statistics system in Zephyr it's not a subsystem people are aware of but it's extremely useful for field debugging. Things that are very difficult for a customer to give you insight to like how many bus faults have there been on the spy bus or whatever. And you can get that using MCU manager from the command line tool. You can reset the device. You can send shell commands, kind of scary. You might not want to enable that but it's there for development. You can, from my bash prompt, I can be sending shell commands and get the response back. Super useful, more on the development side though. Please don't enable that in your deployed devices. The option again, those optional commands are double-edged sort. So you want to be careful with that and you want to evaluate them. Some of them are good, some of them are bad and can be maliciously used. So evaluate that, but it's there. It's extensible and you can do some really interesting stuff out of the box. I think actually the tool that doesn't get a lot of love because it's written in go, I like Golang. I don't know what's wrong with all you Python people. Golang's a great language. Compiles to a binary. So I think that desires to move to Python but I don't know, I don't know. Anyway, opinions. Image tool is the other tool that you're gonna bump into with MCU Boot and this is, you might not need to use this directly. This is the tool that's used to sign your firmware images most of the time. But you can also use it to generate correctly formatted keys for the signing and that's problematic. When you're trying to generate your own private keys there's a lot of knobs to turn and there's a lot of things that can go wrong. So rather than just using open SSL or something like that it's nice to have a tool that just gives you a correctly formatted signing key. So you can do that out of the box with image tool that'll sign your images. You can also use it to verify firmware images, comparing it with the key to make sure this image is correctly signed and get very C-friendly public and private key snippets out of it. So it's a useful helper. You generally probably won't interact with it directly but it's there if you need to do something on your own. Always, always please for the love of all that is good in this world generate your own private keys from day one do not use default keys ever because someone will forget about them. Even in development generate your own signing key as soon as you start a new project and don't ever ship default keys. It takes you five minutes and just get in the habit of doing it. So in the case of Zephyr and MCU boot the KConfig flag you're gonna want is this boot signature key file that will point to a PEM file and then it will use that during the automatic signing process when you build your firmware images just get in the habit of generating your own keys. So provisioning, that's one of those other pillars on the going from secure boot all the way to the other side on provisioning but it's something that happens very early in the device life cycle. So you can see that one over here and whether that happens purely in a factory or the field depends on your use case. The problem is there is no one size fit all approach here. Provisioning is a hard problem. It's a domain specific problem. It's a company specific problem. It's really hard to prescribe what provisioning should, could, might, must look like for you. There's just so many variables. Can I use a public cloud provider? Is my company okay with pushing my data out to Google, AWS, Amazon, whoever? Does that data need to remain in the EU for legislative reasons? Where can I store that data? Does everything need to exist purely behind my company firewall on our own servers? What kind and how many keys and certificates are required on my device? How often will those certificates changed used for connecting to TLS servers, et cetera? What does the life cycle look like for that? Can those be provisioned purely in a factory once? Do they need to be regularly updated with three, nine, 12 month lifespans? There's a lot of knobs to turn there. What level of access control to the provisioning servers is required? Can that exist publicly? Can it just be some Amazon AWS server that anybody can talk to in the open? Does that need to exist behind layers of security so that things can only be provisioned by key people with access cards on a factory floor? Only you know that. So who can provision the devices when, where, et cetera? It's a complicated landscape and you're the only one who can really navigate what your requirements are there. But you want to, again, be thinking about that very early on because you don't want to be have to be integrating key management infrastructure late in the game into your firm. These are the kind of things you really want to get on the table from day one. So there are two common scenarios for provisioning devices, factory provisioning and this is generally the easier of the two. This is where devices are entirely provisioned in the factory during the hardware manufacturer maybe just before they go into packaging. You're burning your unique, some unique ID and some key access certificates to talk to your server and whatever that metadata might be to communicate with your data endpoints. That all happens in the factory. The user opens up the device and it just works. That's the easier solution. The other common scenario is something generally referred to as late binding. In this case, devices are provisioned in the field by the customers, generally using an intermediary tool. So this is where I get my wireless security camera or something, I plug it on the wall then I need to go through the application and I'm going to provision that device into a local network or some sort of cloud network. But that happens once the customer has the device in their hands. Late binding is definitely probably the more common scenario in shipping products. It's a harder one, but that's generally the one you're going to probably end up dealing in most non-industrial scenarios, I guess. So again, provisioning is just a hard problem. This is just kind of a signpost. If you're looking for some help and you're new to this provisioning space, here's at least one open standard. You can look at Fido device on board. It's relatively new. The adoption, I don't think hasn't been spectacular, but still it's a good standard to at least look at and see what can we learn from this. Maybe this works for you out of the box. Maybe it doesn't, but it'll at least give you some direction. These are the kinds of infrastructure problems you're going to have. These are the issues you need to be looking at. And so there aren't that many open standards out there. So just to sort of lay down a signpost, if this is a problem space that interests you, have a look at this. It's a good place to start. There are simpler solutions. This one's a bit complex in terms of infrastructure. There's a simpler solution we'll talk about a bit later. With a sample at the end. So there's a lot of ways to do this. One of the, just in terms of best practices, one of the key parts of provisioning though is key management. And usually one key is not enough. Generally you're going to, maybe I'll have a key for my TLS server and something for a cloud server and a key for encryption and a key maybe used for signing my sensitive data to ensure that the data traveling through my device to the cloud is intampered with. So that needs to be signed. And to verify that signature, I need the public key on the cloud endpoint to verify that my data, the data integrity and the provenance of the data. So that generally involves something called key derivation. And again, a multiple keys are often required on real world systems. The thing is key storage is a hard problem. And so the safest way to store a key is just never to store it, if you can get away with that. And so you can use something like a common standard key derivation function like HDDF in this case to generate something called a device-bound key, which you derive from the hardware unique key. Most MCUs today have a feature in them that they will ship with a hardware unique key or a unique identifier of some sort. Maybe it's just 16 bytes, but it's something that generally there's a unique number you can get out of a register that uniquely identifies that specific MCU. So when you use something like HDDF to derive a key based on that HUC, you get a very interesting feature called a device-bound key. What that means is that key is tied to a very specific instance of an MCU. And I'll go into a bit of details, but that gives you some interesting features. And there's also the benefit that because I'm deriving that as soon as the device comes out of reset, I never have to store that key anywhere. That solves a huge attack surface. Somebody can get access and dump the binary from my firmware and they're not gonna find that private key. Not having to store it solves an entire class of problems for you. The HUC then becomes the sensitive thing to protect. But so what happens in this process is if I'm using the HUC plus some sort of info label, so we take the HUC plus a string and those two together combine to give me a repeatable output that I can regenerate every time it boots. So what we do is every time the device boots, we regenerate these private keys. And those keys then are also another advantage is that they're persistent across firmware. I can unflash an entirely different firmware image. I don't have to worry about wiping out the user's private keys that were used to encrypt things because they were never stored. And it's based on hardware, not a software implementation. As long as you're using something standard like HKDF, the same inputs will always give you the same outputs. So it gives you key persistence as a potential benefit. It also ties encryption, authentication, et cetera to a specific MCU. You can imagine a PCB where I have a large external QSPI flash or an SPI device where I need to store device secrets. I want to encrypt that as it goes off my chip to that device. But what happens if somebody gets access to that board and maybe they pull the MCU off and they put another MCU on there with a malicious firmware. If I'm using a device bound key for the encryption, replacing that with another malicious MCU will not give them access to things that were encrypted because the key that's used for that encryption is tied to that specific physical instance of an MCU. That may or may not be useful to you, but there are a lot of benefits of not just of not storing the key, but having it bound to a very specific instance of a piece of hardware. It makes it much harder for me to pretend to be a device that I'm not because without that hook, I can't generate the same signing, encryption, whatever, authentication keys. So this approach absolutely requires one thing though that you do need to know how to protect that hardware unique key and that's again one of those things that's going to vary vendor to vendor. So this is a great approach with the caveat, figure out how do we lock down access to the hook that that hook never leaves the key. So for example, if I'm in a situation, if I'm using something like trusted firmware M on the secure side and Zephyr on the non-secure side, that's a common topology where you have distinct secure and secure firmware. Something you need to take into account here is if I have that kind of layout on the secure side and maybe I can do key derivation with the same approach on both sides, you make sure on the secure side that you are always appending something extra into that info label on the secure side. And the reason for that is, let's say my non-secure side is telling the secure side of my firmware, I need a new key and use the hook and use this string and maybe I know that info label which is the additional information that gives me a unique key out. If I know that string that the secure side is saying, I can just give it the same string and then I will get the secure key from my... I will get the private key from the secure side. I can derive that on non-secure. So taking the simple step of your secure key derivation function for keys that exist on the secure side, always ensure that you accept maybe that extra info label, but it's prepended with something else that only the secure side can prepend and obviously do some simple checks. So like if the non-secure side tries to be a little bit spart and also knows the prepended value and appends something else that you reject that key request. But you do need to make sure that you are not leaking keys from the secure side to the non-secure side. And the way to do that is to make sure that you are always on the secure side during key derivation, appending extra information into that info field. You don't need to do that on the non-secure side, just as something you may or may not be aware of as a pitfall to avoid. It's low-hanging fruit, but deal with it from early on. Another benefit of this kind of Huck-based key derivation is you don't have to generate private keys. You can actually use this to drive a unique device UUID. If a UUID is a useful identifier for your tens, hundreds, thousands, whatever of devices in the field, this also gives you a device-bound unique UUID, and you can generate multiple versions of those if you want. So there's some other free features of this. So if you're not familiar with key derivation, have a look at HKDF. It's sort of a well-supported modern standard. The standard's not that inaccessible. Links are, you've got the RFC here. Sorry, just a quick time check. So securing data in transit. And this is where you've got your firmware image talking to some sort of cloud infrastructure, public, private, whatever, maybe behind a company firewall, but there's still some kind of communication going on there. The too long didn't read is just use TLS. If you can establish a connection with a server, just use TLS. You want to talk to your MQTT broker, just use TLS. It's tried, it's true, it's universally adopted, it's reliable, it's based on modern encryption standards. To keep it up to date, just use TLS. Problem solved. If you can connect to something, do everything you have to to use TLS for that. And the only maybe caveat here is make sure, in Zephyr for example, when you're establishing that connection, make sure you're enforcing a recent version of TLS, which is TLS 1.2 is sort of a good minimum starting point today. So don't accept TLS 1.1, et cetera, connections. Just you'll avoid a certain class of problems that way. So just, again, best practices. If this is new to you, you haven't played around with TLS on an embedded device, here's a good example to look at, the HTTP get socket sample. You can see how to get the certificate authority on the Zephyr device, which will enable you to verify that you're actually talking to a server that you should be talking to and it's not pretending to be someone else. So there's just a good pointer if you're interested and new to communicating over TLS with a server. Have a look at that one, it's a good starting point. So basic TLS authentication validates the server identity. In a sense, it gives me as a client device a degree of confidence in who I'm talking to because that server has a certificate that is signed by a certificate authority and I trust that certificate authority that they're doing their homework to actually validate the server as who he says he is. So the way that that generally works is you've got your client device with your Zephyr firmware here and it wants to talk to a server. So it will send a client hello message, part of the standard TLS handshake and the server will respond, hey, how's it going? Sends a server hello over and part of that server hello includes the server's X509 certificate which is signed by a CA. I get that certificate on the client side. I have the CA's public key and I can say, okay, you look like who you say you are but I wanna check anyway. So it can check the signature on that certificate and if it matches the CA I have, I have a reasonable degree of confidence that I'm talking to someone that I can share information with and the TLS handshake goes on with a key derivation process and you eventually end up with symmetric encryption of data using AES or something else and depending on what the server supports. It's a fairly well understood process. It brings up an interesting question though. How does the server know that it's talking to a trusted client device? So the server, he's flashing his credentials but how does that server know who I am? Am I pretending to be someone else? That's an interesting problem that maybe you don't think about as much with TLS and TLS out of the box actually includes something called client authentication and this is where the server also asks the client device to prove its identity and what's important here is that we're not inventing anything. This is a standard part of TLS. Every TLS stack out there is going to support this so you don't have to invent some weird process to prove who you are. You can use this with any HTTP server, whatever the TCP server that you're talking to. So there are some, if you're using a cloud provider to push out your data to MQTT or whatever, some of the cloud providers have better or worse support for this client authentication. Azure IoT, I don't want to play favorites but for example, I think Azure IoT Hub, this is something they've done well and maybe a bit better than some of their competition because they have very good support out of the box for you upload your CA certificate to Azure IoT Hub and it can use that to validate any incoming client requests to know that they have a certificate that's been signed by that CA and then they accept or reject the connection. So you can do this on your own as well but the support for this, the use of this extra feature isn't a given but some cloud providers are making more progress in there. Something to look at though to establish trust in both directions. So how that works in practice is you start with the same process, I've got my client device talking to my server, hey, how is it going? The server says, hey, haven't seen you in a while, here's my certificate again just in case, should prove who I am but part of that server hello also includes now an extra step where the server says, hey, you know what, haven't seen you in a while, I just want to make sure everything's above board. So why don't you send me back your certificate as well and you can see that here on the bottom this client certificate request and that's going to prompt the client device to take its X509 certificate which was signed by a specific CA via the certificate signing request. It's going to send that certificate over to the server device and then the server device can just verify the signature and make sure it's signed by the CA that I trust and maybe that's enough maybe it actually wants to talk to that CA infrastructure and say, okay, you're signed but has this device been block listed? Is this certificate still valid? Is it, so that you can take more or less steps on the server side than to verify that device maybe this device has a UUID that I know the device has been stolen or compromised I can then reject that connection based on that extra data so that out of the box using entirely open standards that are well supported in everything you can add device authentication to your Zephyr device so this is where you can introduce like basic client authentication because inside that X509 device certificate you don't just need a key and a public key oh already five minutes, okay quicker you can stick fun data in there so if you're interested in some examples here's one, you click this link or look at this QR code here's an example of generating a mutual TLS TCP server it's in go, I'm sorry, for the Python people and there's a script, a bash script in there for generating certificates for the server and the public keys et cetera just to give you some pointers if you wanna go in details here's a talk from last year's ZDS specifically on X509 client authentication so securing data at rest what do we do when TLS isn't available and some use cases are like I need to place secure information into external flash I need to use an intermediary app to send data to the cloud so maybe I use BLE to talk to my phone or lays it to a cloud server how do we deal with those situations securing data at rest is unfortunately less of a solve problem today there's a lot more work needed here and it's not as easy as TLS just use TLS, solve your problems for data at rest, we don't have that option to my knowledge, COSE is the only open embedded appropriate standard I'm personally aware of for protecting data at rest and COSE is something that's built on top of CBOAR concise binary object, something which is basically binary JSON it's very tightly coupled to JSON and it's a nice standard because you can very richly express complex data and relationships between nested data so COSE is something that builds on top of CBOAR it allows you for signing an encryption of data at rest using modern ciphers and I really believe this is something that should be actively promoted as a solution for securing data at rest unfortunately COSE encryption the E in the COSE is less common than the signing part today, the S so there's very poor encrypt and encrypt zero library support today particularly in C so there are some C libraries like T-COSA that are making an effort to improve this but it's still an active work in progress and there's no profiles in COSE so you kind of need to know a little bit what you're doing to glue things together if you're interested in this we put together a Rust proof of concept for what COSE looks like encrypting data at rest so you can follow that first link to see some examples of this is what COSE encryption might should could look like for an embedded device with efficient throughput there's also there was a talk a couple of months ago from my colleague in the back David Brown discussing what is efficient COSE encryption look like watch that talk if you're interested in this problem I think it's a good standard that you should keep your eyes on in terms of example everybody loves examples you want to see an example of what end to end boot to cloud security looks like how this all glues together a good example we've done in Linaro something called confidential AI what is that very quickly it's an attempt to demonstrate end to end security best practices based on modern Cortex-M hardware V8M, ARM trust zone using entirely open source standards and open source software with AIML workloads as a case so we're doing inference on the secure side and demonstrating how do I secure the data pipeline from the secure to the non secure to the cloud signing and encrypting data et cetera nothing special about the AI it's just a use case because I think having a good use case leads to better engineering results so we picked AIML as the use case how do I secure my models and my data this is what it looks like here's the links if you want more details there's a sample bootstrap server in there if you don't want to use some complex provisioning thing here's a good starting point for what provisioning might look like we put together a bootstrap server to take in device UUIDs generate certificate signing parse certificate signing requests register those certificates in a database and then the top link here is the parent repository for confidential AI which is based on Zephyr and trusted firmware M you can run it in QEMU no hardware required totally emulation friendly including the cloud connectivity over TLS quickly checklist integrate your bootloader early on understand your provisioning requirements replace your default keys please in day one even during dev plan for key storage just use TLS 1.2 don't use it use if you're using TLS think about it for client auth data at rest is still a work in progress but COSA is the standard to watch please get involved thank you I'm sorry that was like 39 minutes no questions I guess but if you've got any questions just chase me down over here I'm happy to talk about this so sorry I don't have time for questions so hope that was useful anyway