 Hi, and welcome! This session is about secure your IoT devices with IR systems and STM32 secure firmware install technology. The presenters for today's session are Clive Watts, Director, Product Management, and SecureFins. Andy Bison, Senior Product Manager at SecureFins. And Larone Hanous, Ecosystem Marketing Manager at STM32. Notice that you all are in mute at this point, and in case you have questions, you can make use of the question panel. If you are having any trouble, you can also use the chat panel. We will have at the end a dedicated session for Q&A. And now I'm giving over the session to Larone. Thanks Raphael. Good afternoon everybody. My name is Larone Hanous and I'm an Ecosystem Marketing Manager at ST in charge of STM32 development platforms and programming tools. The goal of today is to give you an insight into the programming solution to secure your application software assets using the STM32 secure firmware installation. Moving on, the STM32 secure firmware installation, also called SFI, is a root secure service for software IP protection in entrusted environments, typically at contract manufacturers. This secure installer has been firstly embedded into the STM32 H7 MCUs to protect against counterfeit or clone products and also to avoid overproduction. In order to deliver protection in entrusted environments, this robust STM32 secure solution ensures firmware confidentiality, firmware integrity, firmware authenticity, as well as make sure that the end device is a genuine STM32. In addition, to deliver protection against overproduction, the STM32 SFI also manages programming licenses. So how does the STM32 SFI operate? Well, by creating an end-to-end secure programming flow, this flow starts with the encryption of the firmware by a trusted authoring tool, continues with the authentication of the STM32 by the licensed server, and then the verification of firmware integrity and authenticity before proceeding with the firmware programming by the STM32 itself. Here is a global view of the end-to-end secure programming flow. On this view, you can see that the flow goes from the OEM desk directly to the STM32 MCU. The SFI service ensures firmware confidentiality when transferring data from the OEM to the flash of the STM32 target and prevents copy and overproduction in insecure environments. To achieve a high level of protection, the STM32 SFI solution relies on asymmetric cryptography with a private and unique key for each STM32 H7 device. This means that the device private key is embedded into the system flash and only the SFI service can access it. Now, moving on, let's look at the STM32 SFI crypto flow. So, the firmware is encrypted by the AES GCM algorithm with the firmware owner key, and at that stage, the firmware is ready for transfer. In parallel, the OEM key is stored in the licensed server or the HSM, which is a nickname for the hardware circuit module. On the production site, the firmware license for the device is generated from the OEM key and the device public key. The license can only be used by the targeted device. The firmware key is decrypted inside the device with its private key. The encrypted firmware is transferred in the device and decrypted before being stored in user flash memory. To be able to handle all this crypto flow, several tools are required. Typically, you need three of them. For the authoring, you need a firmware encryption tool and for the production, you need a licensed server and a flasher tool. The licensed server will generate the license associated to the SM32 SFI device, while the flasher tool will execute the SFI sequence by using the SM32 bootloader. So, a description of all those tools will be delivered later on by Clive. Let's see. Okay, it works. So, in a nutshell, the SM32 secure firmware installation really gives you a way to prevent firmware cloning and overproduction in unsecured environment with a very, let's say, integrated way. The secure loader is already embedded and provisioned by ST into the SM32 device and works together with ecosystem tools for encryption, license server, and programmation. The firmware cloning protection on the first installation can be done using any of the bootloader channel. Could be UART, could be SPI, could be USB. And last but not least, I mean, this end-to-end secure programming feature is available on SM32 H7 first historically, but also on the L4, L5, U5, WL, and more MCU configurations soon to be announced. For more information, feel free to go to the ST website at this link. And now is the time for me to hand over to Clive. Thanks very much, Moran. Great introduction of the ST technology. Okay, I just wanted to recap some of the business motivations for looking at this process transferring intellectual property from the OEM through to the factory. Security is often seen as a cost and overhead that should be avoided, but actually there are multiple benefits for OEMs and for production facilities. Most of these have traditionally been driven by standards and certification, which of course are not required. There are guidelines, there are standards that you should strive to meet, but increasingly we're seeing legislation coming in across Europe, in the US, and in Asia that will motivate companies to take security seriously. And at the end of the day, at the end of the day, the business motivators for taking security seriously, Laura has hinted at these already, are primarily production control, preventing people from making too many of your product, IP protection, preventing your valuable intellectual property from being misused, preventing people from injecting malware into your products, even before they go out into the field. And then really giving your device a unique identity so that it can be rapidly onboarded into a network and put into service. The way we think about this at secure things is to consider the process of transferring from the OEM on the left-hand side here, to the shop floor on the right-hand side. And we think about the need for a production planner role. So this is the person who is at the very end of the OEM process. The engineering guys are all done, everything's been tested and it's ready to go. And someone here is responsible for moving all that intellectual property out of the OEM and across to production. And then of course on the right-hand side here we have the production facility itself. And one of our challenges is this can be located pretty much anywhere geographically. It's likely to be a subcontracting company and most certainly the staff that are working there will be unknown to us as the OEM. And ideally what we'd like to be able to do here is to create a tunnel straight away from the production planner, all the way down to the production facility. If we can create such a tunnel then we can keep out all of the bad actors, those people who want to steal or change our intellectual property, they will be prevented from interfering with that transfer process. And most of us are working from home these days and we're familiar with the concept of the VPN that we use to tunnel into our business systems from our home office. And really what we want for this process is a kind of VPN that we can connect directly from that production planner role all the way down to the production facility. In fact thinking about this a little bit more in order to reduce the risk further it would probably be a great idea to be able to tunnel all the way down to an individual production machine so that we are clear where our intellectual property is going to and it's just not just going to somewhere in the factory or some person somewhere in that factory. We might need to consider a group of production machines for this concept if volumes are high or to provide some kind of redundancy. But definitely we want to try and restrict where our intellectual property is going to some known machines within that production facility. And how do we achieve this? Well the philosophy that we at SecureThings have is that the production planner should be able to take all of the intellectual property that's coming out from the development process and build that inside if you like a virtual vault where we put everything inside close the door and then we know at that point it is secure. So what would we put inside that vault? Well we would put certainly the application firmware, the software that's going to run what they use to seize but also a secure boot manager that will manage the security of the system when it first comes up and on an ongoing basis while it's executing. And we will have other configuration data particularly security assets that we would want to transfer over to the the shop floor. And there may be other data to do with the set up and configuration of the application itself. Essentially what we're trying to do here is to bundle all of that stuff together put it inside the vault which we would call a production package and then send that through an encrypted transfer down to the shop floor. And because everything is encrypted we can stand that by whatever mechanism we like we can send it by email by ftp and what we would like to do is encrypt that so that it can only be decrypted on that production machine. So essentially we're transferring that vault of information down to the production machine and holding it there securely until the time it's required which means that there is no possibility at any time for someone to steal our intellectual property or to modify it by introducing malware. It's available at that production machine still in an encrypted transfer form and held securely for that reason. The way that we're doing taking the approach to doing this is to create a hardware security module that is highly specialized for this task. There are many organizations that supply hardware security modules but we've created one that is particularly suited for this requirement because it is designed to work standalone and not to reference any other servers or outside systems that may themselves affect the security of that production machine. And what this hardware security module does is to dynamically manage the process of creating and generating and installing all the information inside the MCU to be programmed. So not only is it storing the keys that have come down from the OEM but it's also generating dynamically keys that are required to create a unique identity to that particular device and creating a certificate that represents that device that can be shared with the outside world as part of an authentication attestation process. So of course as part of that we're providing encryption and decryption services as well to enable the exported package to be managed once it gets to the MCU. And very importantly in order to continue that security all the way through to the MCU itself our system will connect directly to the MCU transfer from the hardware security module. Again in an encrypted format everything that's been sent from the OEM application firmware, boot manager, configuration data all the way through inside the MCU as Laurent has earlier indicated. And this means that we can protect all of the information that is inside that MCU at the point where it is loaded and again we prevent any opportunity for intellectual property to be stolen or modified during that transfer process. We'll come back to a look at this in a moment but we're also considering two different scenarios here. The first is the volume provisioning that I've introduced. The second is also the requirement for a smaller-scale desktop provisioning system that can be used for prototyping in first articles as well. So let's just have a look at that requirement. So no product goes to volume production immediately the engineering teams are done with the development. Typically there'll be a volume curve and we need to follow that volume curve in order to get to production, get to that high volume that we'd all like to see at the end of the day. So what we've created is a desktop deployment which we call secure desktop provisioner which mimics exactly the environment of that production machine and this can be used by the engineers using during development. It can be used by quality controls to produce first articles. That can be used by a range of functions within the OEM to generate prototypes in first articles that behave exactly as the finished product will do in volume production. And you can see at the bottom here the process is exactly the same. All of the intellectual property that is required is assembled together and held securely and then this is encrypted and then transferred as a production package down to a hardware security module, the blue box on the right hand side, which is part of the secure desktop provisioner setup. And instead of the programming and provisioning of the part being controlled by an automated machine, in this case it's controlled by an individual who has a user interface running on a desktop or a laptop that mimics the functions that the automatic machine would carry out in a volume production environment. And we'll have a look at this in a demo later on and see how this actually works in practice. So just a quick recap, Laura mentioned very well the overall system here that SFI is attempting to achieve. The whole purpose again is to make sure that we move from the customer premises, all of the information, particularly the firmware or the bulk of the intellectual property lies over an encrypted transfer to an untrusted environment such as the shop floor and also to ensure that we transfer that IP directly into the MCU where it can be stored and locked away inside the device. And that at no point do we have access, does anyone have access to that intellectual property? As secure things here working with IAR, our parent company, what we've tried to do is to think about how we might simplify this process from the point of view of the end user. We know that one of the major blocks to adopting security is OEMs really not knowing exactly how to implement security, what processes they need to go through, how they will deliver security to shop floor, how they will implement this in their devices. And what we're trying to think about here at secure things is how we can simplify this process using SD's SFI technology to enable faster adoption and the rollout of security in more and more devices. I read somewhere recently that the adoption of good levels of security last year in 2020 was around 4% of products. And we need to be able to support industry to be able to do better than that in 2021. So I've redrawn the diagram here to show how we are adopting SFI making this process more simple. You can see on the left hand side here we've got the developers and the production planner that I've talked about earlier in the customer premises. And the development environment here that we are proposing is a combination of two products called embedded trust and C trust which integrate with the development environment that IAR systems presents. And we'll show you that as part of the demo later on how that development environment looks and how it flows. And out of that environment we will produce an export package which then is taken by the production planner and sent across by file transfer to the untrusted environment. Again this is an encrypted production package so we don't need to do anything special about that transfer process. Information is held securely within the hardware security module which we call a security appliance until the time at which production is needed. And then as each individual SFI capable part is presented for programming our security appliance will then carry out a real-time dialogue with the programmer and have that program our transfer information securely still in an encrypted form across to the software running inside the in this case in STA32H7 using the SFI protocol. And this means that across all of that process all the transfers are secure all the IP is held securely and all the way to the point where it's locked down inside the device there is no access to that information. One of the nice things about this solution is that everything is transmitted by file transfer to the untrusted environment and there's no requirement for a physical transfer of any kind of key or coded information separately from that file transfer. And we do this by giving that security appliance a unique identity and manufacture and that unique identity is supplied to the production programmer and built into that encrypted production package so that only that security appliance can decrypt that package and there's no need for any other additional security checking on that file transfer. So talked about trying to make this simple for the OEM. What we're going to try and demonstrate to you today is how simple we've been able to make this process. Essentially we have four steps that we're going to show you today. In the embedded trust tool that SecureThing sells alongside IAR we have created the concept of a security environment which we call a security context and this contains all of the information about how security is going to be created inside the end product. It includes information about how the memory is going to be used, what certificates are going to be generated and particularly relevance for us today. One of the options inside the security context is the use of what we would call a secure install feature. So we can very simply go in there enable secure install while we are creating our security context and then this security context is then used as part of the development process. You can see here in step two once the development's completed we can activate the use of the secure install feature by a simple checkbox true or false and then that propagates down through the system to require the use of SFI all the way down through into the programming of the original device and having set up with the environment in steps one and two we can then generate the secure production package in step three and my colleague Andy will show you this in real time then that production package obviously goes down to the production environment whether this be our secure desktop provisioner for prototyping or the high volume environment at a separate facility it's the same process and then the software running on those systems will show you the desktop version automatically programs the device using SFI as the protocol and the technology to do that. One of the critical things here is that the operator of that system whether it be no volume or high volume needs to know nothing about the use of SFI in fact they don't know anything about it there are no options here at all relating to the use of SFI the requirement to use it comes down in that production package and everything is handled by our security appliance at the point where it connects to the device and programs and provisions it so the production facility is completely unaware of this and again that helps with the raising the security bar for the end-to-end system. So I mentioned the software tools a little bit earlier on so we have two flavors of product here for the developers both of these products are built on top of the basic integrated development environment that IAR sell many many people are aware of this I think we have 40 000 users worldwide about 40 percent of the the market and these look into in the embedded workbench product and just to be clear what the two different products are for the C trust product really is for learning about how security works how to go through this flow and enables OEMs to trial the process of building security into their products and the embedded trust is the full version which allows OEMs to go to production and to build quality security solution into their own product. One of the key things I'd like you to take away from this session is that with a single development environment on the left hand side here whether you're using C trust or embedded trust on the design side the process of going to production is identical whether you're going for small volume through the secure desktop provisioner or whether you're going for high volume production with a fully automated machine the process is the same the security solution is identical and the secure production package that goes across is identical in both cases clearly the identity of the target machine will change but the end-to-end flow of the process is exactly the same and this helps to build confidence that we have the same security solution all the way across the volume curve. What we're going to show you today is a demonstration using the secure desktop provisioner version for low volume and prototyping and today Andy will be going through the flow and using an SDM32 H753 device on a standard nuclear board to demonstrate the end-to-end flow and how simple and straightforward it is to take your IP all the way through from development through to secure provisioning in a production environment. So I'd like to hand over to Andy now who will try to take you through the live demonstration of this technology. Thank you Andy. Andy sorry for interrupting you it seems that your audio is not working could you just double check? Can you hear me? Andy it seems that it's gone again the audio perfect Andy now we can hear you perfect. Right okay so this is a different mic so fingers crossed it might work so sorry about that. So I'm sat here at the moment inside the embedded workbench and installed inside this I have got a copy of the embedded trust security development tools which extend the standard development environment to allow us to add security features and build those easily within our software system so you can see here that we've got this new security menu being added and what I'm going to demonstrate in this session is the go to production side of the tools workflow so basically the sort of how we actually get our software into our target system. So what I've got inside my workspace is two projects first of all I've got this SPM or secure manager project and it's this project along with the wider security context that Chloe've mentioned which is going to provide our immutable route of trust which is sort of the key to the protection of our system. The second project I've got is the getting started project and this is a standard example application which we provide that if you like stands in for the main application code of your final IOT product. So one of the things that getting started is providing is an example of how a user application can call into the secure API is provided by the SPM which allow us to leverage the route of trust keys and certificates within the system. So what I'm going to do now is switch to the getting started project and I'm going to look at the options in particular so within the security menu which you'll get displayed now I'm just going to confirm before we go any further exactly what version of my application I've got so we can see the application version here currently set to version one two three and it's this version number that is going to be used as part of any update mechanism so this allows us to prevent the rolling back of our software in the field so we can basically prevent older versions of the application being installed. So we've checked that version number we'll come back and see that again in a minute and what I'm going to do now is just trigger a hold of the getting started project. So this will just take a few seconds and one thing to note is the time that I'm building this for me here in the UK is about 2.33 p.m. again we'll come back and see that in a minute. So the application has now basically built and one of the things to note at the bottom of the build log here is the mastering message. So this basically indicates that the application has been encrypted using the keys from the associated security context and it's this that allows it to be installed and executed by a matching SPM as the microcontroller comes out of reset and we can also see that version number has been embedded into this at the same time. So if we assume that at this point we've finished the development process of our main application what I can do now is generate a version of the application that it can be used of part of the production process. So I'm going to go to the security menu select the export application option select directly to place that in and give ourselves an application name so let's just call this app and export it. So that's just confirms that the application's been exported so at this point what we're going to do is switch to the secure boot manager project. So what we're going to do now inside the secure manager project is check that that setting that Clive mentioned to enable the use of SFI has actually been set in my security context. So I'm going to go into the options and just click on edit the security context and there's two things I want to actually check. First of all I'm checking that the debug port has been selected to be disabled after we've actually programmed flash so this is basically to try and prevent anybody getting into our device after it's left the factory. Now if we were going to a full production situation we'd also want to permanently lock down the SBM so basically lock it into flash. I'm not going to do that now because I want to be able to recover my boards after we've done this demonstration for future use but that's something that you would do in a real production system. I'll then switch to the secure provisioning tab and ensure that the use secure install option is set true so that means that we are in a position to actually generate a secure boot manager that can be used as part of our production package. So we'll update that and okay that and when the menu closes I'll then again use to rebuild the application for the SBM and again just note the time this time is about here in the UK 237 p.m. So once this has actually finished building which it will do any second now we'll be in a position to actually go away and generate our production package. So I'm again going to go to the security option and this time select the export erect production so we're going to follow through this wizard to actually generate the encrypted production package which we're then going to be able to send to over to the factory or in my case to my secure desktop provisioner that I've got sat here with me as well. So I'm going to become export. First of all it gives me the option of rebuilding the SBM. I don't need to do that because it's just been unknown in this case and the next warning I get is just letting me know that some of the options are not optimal in my security context for production. So I mentioned for example that I've not enabled full SBM lockdown and this is just a warning that you know are you really sure you want to be doing this. In my case it's valid to go through this in a real production system you'd probably want to go and correct the settings and the IDE will actually give us some information as what we might want to go and fit before we carry on any further. Anyway, we're going to production. We are first of all going to pick the components that we're going to use within our production package. So the secure boot manager has already been auto selected. I'm now going to pick my application that's going to form part of my package. So that's the app file that we just generated. I also just need to confirm the security context that that was built against so that the tools can check that everything is valid between the application and the SBM. At this point I can click next. I now need to select an OEM identity. Now the OEM ID is basically an identification key that can be used by the HSM to actually identify the source of a production package. And I've got an ID for that here. So I'll go in and select that. And I just need to enter the password to allow the tools to recover the ID from my key. And click next. The next thing I need to do is target the actual production package at the HSM that's actually going to do the programming in the factory or on my desk. So as Clive said, we effectively want to know the exact machine we're going to be using in order to actually keep security as tight as possible. So in this case, I've got an ID for that, which is certificates from my HSM. And the final thing I need to do is select a production count. So this is how many units of this particular package do we want the factory to be allowed to produce. So this is the thing that can stop overproduction and gray market versions of my product being sold. So in this case, enter five and click next. And then we need to select the actual name of the package I'm going to generate. Let's call it SFI Moe and also the output folder. At the point I can click export. And in a few seconds, we should get confirmation that the package has been generated. So this is a fully encrypted package. In a real system, we'd be able to take that package, send it across to the factory using FTP or whatever, safe in the knowledge that nobody else can get access to it. At this point, what I'm going to do is switch to the secure desktop visioner product. So what I've actually got on my desk is one of those blue HSMs that Clive showed a picture of in his presentation. And connected to that, I have got two programming heads, which in this case are two IAR systems, IJETs and debug probes, which we repurposed and connected to each of those. I've got an STM32 H753 Nucleo board. So SDP is actually capable at the moment of programming up to four heads in parallel. In my particular situation working at home, I've actually only got access to two probes today. But the principle of programming four would follow exactly what we're going to see over the next few minutes. So the first thing I'm just going to quickly show you is inside SDP, you can actually go into the administration tab, look at the certificates and down here we've actually got the ability to export certificate for this particular appliance. And it was that certificate that I imported into the embedded trust product as we were going through the export process. So that's what ties the HSM up to the generation of the production package. So if we go back into the operation modes, I can now go and find my package. So I'll click on there and there's SFI demo that I've generated a few minutes ago. I'm going to open that. And what you can see now is that the screen is populated with details of the package that I've just imported. So for example, we can see that the OEM is IAR systems. So that was the OEM ID that I added to the package as we created it. We can also actually see that we're going to program this using SFI. So the next thing I actually need to do obviously is start the programming. So I'm going to do a production run. We can do a production run to a maximum of five. In this case, I've only got two boards. So I'll just enter two for this particular session. And what's going to happen at this point is I just need to trigger the fact I want to stop this particular package. And the SDP software will go off and process the package and put us in a tour position where we can actually go and program boards. So we're effectively parsing the contents of the package so that we know what to program to what locations using what mechanisms. So all of the details the SDP needs are being extracted at the moment. And there we go. We're now ready to program. And you can see that we've got this particular production run. We've got two remaining. And what I can do at this point now is press the program connected devices button. What this will do is start programming both of those two boards that I've got connected in parallel. And this is going to take a few moments. Basically what is going on to start with is the device is just being checked and erased, making sure the flash is empty. And we're then going to communicate over the SFI protocol with the STM32 bootloader to carry out the programming of the device over the SFI channel. So you can see the secure install process in progress down at the bottom of the log. So as I said, we've programmed two boards. We could have equally programmed three or four boards at the same time, all in parallel. There is a very small time overhead as we process each of the heads. But we're talking a couple of seconds extra for each actual one. So the basic speed would be pretty much as you saw there. So what we can see now in the details pane, it's the fact that of the authorised counter five, we've now produced a total of two, which means for a future production run, we could only carry out three more programings. So at this point, what I'm going to do is move out from secure desktop visioner and switch to the terminal view I've got here. And I'm just going to disconnect one of my boards from my IJET. So just give me a moment. And then I'm going to press the reset button. And what we've got now appearing in the terminal view is the first of all, the SBM starting up and then the getting started application in invo once the SBM has processed it. So one of the things that we can actually see up here is the full time of the SBM. So if you remember 237 and the installing the updates are the actual application that we've actually got. So we can see the version of the code did 123 in the hex update has been taken from the update slot where we programmed it and installed into the execution slots. And then we started to execute it down at the line here. And at this point the SBM has concluded and we've jumped into the getting started application. And here we can see that the getting started application is the one that we built a few minutes ago at 233. So within the application, if I just type H for help shows us a list of the commands that are available. And these are basically some of the SBMs API secure API commands that we can access from our application. So we've given us an example I've had to call those. So for example, we can look at some details of the application. We can look at the SBM status. So we can see not only the SBMs built time in here, we can also see the time visioning started as well. And then finally, for example, we can see a device ID tests. So as the actual programming was taking place, the UID from the MCU that was being programmed was read and encrypted into the device certificate and this command within the SBM basically goes and reads the UID and then gets the device ID from the certificate and does a comparison. And we can see here that that comparison has completed successfully. And that brings me to the end of the demonstration for today. So I'll hand back over to Raphael. Perfect. Thank you, Andy, for your fantastic demonstration. And now it's also the time where we can actually go over the questions we have. And also, if you still have questions, you can always send it in for sure. So we got a few questions here that I can probably read. Maybe I can start with the unanswered ones. So just a second, I will just double check that everything is fine here. So there is one question that is probably best for Andy. Andy, is the source code for the secure boot available in case I want to do adjustments for the process, the boot process? So the answer to that is basically yes. So what actually happens is that the portion of the process that we didn't show today, so the creation of the secure boot manager, the source code is actually added into that project as you create your SBM project. So all of the sources are provided there for you. You can modify them if you like. We wouldn't necessarily recommend that you do much in the way of modification. But if you have a requirement to do so, the sources are all provided. Perfect. Thank you, Andy. Okay. Let me see. Let me scroll over here. We got some good questions here. Can I use the secure things tools for my Sdm32F407 device without SFI, the secure firmer install? Sorry, I didn't get your part. Shall I do that question? Yes, please. Yes, so obviously there are many different Sdm32 parts with different levels of security in them. And SFI is an advanced security feature of devices like 753 that we've looked at today. We do support devices that don't feature SFI and we offer the same flow, exactly the same processes being demonstrated today for that. Obviously, you miss out then on the security of that final transfer into the device, in that case. But if that's a decision that's made and yet sufficiently secure for your product and your environment, then that's perfectly possible with the tool chain that we have demonstrated today. Perfect. Thank you, Clive. And maybe I have another question that you can also answer here, Clive. It was already answered on the chat, the question panel. What about firmer updates in the field? If it's supported, yeah? Yes, so one thing I hope that you've realized, audience, is that the secure boot manager that we've installed in this device actually stays running once the system has been booted up. Some secure boot managers will disappear at that point, but that stays running. And the purpose of that is to provide services to the application software. Andy, my colleague hinted at a few of those just now. But one of the primary services that's very critical is to be involved in the process of updating in the field. So the assumption has to be that products will be updated in the field. They will need to be updated if only for security patches and not just functionality, but there must be an update mechanism. So our secure boot manager can take the same production package that's come from a new build of the OEMs and validate that, make sure it's come from a genuine, excuse me, from a genuine supplier, make sure that it's not been modified, make sure that it's not been injected with malware. And if all those validations pass, it will install that software and then, of course, update the current version number to that version, preventing any rollback to the previous version. So absolutely, we support that. That's a very critical part of security of devices in the field. And our secure boot manager provides that functionality so that the application software doesn't need to. Good. Wonderful. Thank you, Clive. I'm afraid we are starting to run out of time here from our side. So please, if you have any additional questions, you're always welcome to reach out to us. And I would all like to thank you for the time you spent with us. And I hope you enjoyed this session. Thank you so much.