 After your lunch break, let's check. OK. So my name is Jorge Ramirez, and I'm the bi-security lead at Fondres. Our main product is a cloud platform that simplifies development and helps secure maintenance of the IoT and Edge Linux devices that you have. So my role as a bi-security lead is to make sure that the root of trust is guaranteed in all the boot process for all the different platforms that we support, all the different architectures, ST, or NXP, silings from the boot ROM until the Linux kernel boots. So the main purpose of having this sort of task in a Linux conference is really to raise awareness about the security benefits of controlling keep cryptographic IP, not only from a global API, which is something that you already have with PAYK ACS-11, but from a trusted execution environment. As we will see, one of the main benefits is having access to a secure storage supported, as defined by the global platform specifications. And I think that's a big plus. I think this talk, I will be able to consider it as access if we start seeing more pull requests into the opti-crypto repository at the moment. Support for a big number of them, but we keep on getting more and more requests for us, for funders to do these sort of drivers, when in fact, I think it should be the industry pushing the support, because all the benefits that it implies. I've done these sort of drivers a few times for the virtual platform, for a secure element from NXP. And it's simpler than it looks. I mean, I'll show some of the tools that we have to be able to communicate between the rich OS and the trusted execution environment. And everything is in C, so it's pretty straightforward, I think. One thing that I want to mention, there are many implementations of PAYK ACS-11 out there, every SOC vendor. For some reason, every time they have a new IP, they come with the associated PAYK ACS-11 library. I think it would be great if we could stick to a single implementation, preferably the one supported by Opti, and then just plug the cryptographic IP and the interface, which is also a global platform interface. So that further view. The agenda, I don't think I mentioned. So yeah, I'm going to go through, I don't know, I suppose most of us are familiar with the trust zone, but I'll go through all of it a little bit, through the trust zone, what's the runtime resident firmware, how Opti works with the secure monitor. A little bit about persistent storage, trusted application, how PAYK ACS-11 benefits from everything that I'm going to describe. And then we'll go through a little bit of the internals, a couple of examples of drivers that have done at upstream. So the hardware trust zone, I mean, sorry, the ARM trust zone is a hardware security feature that I've been there for ages now, on Cortex-A profiles, and since the last couple of years, I think, in Cortex-A as well. It enforces hardware isolation, not only in the CPU, but also at the MMU level, so you have separate MMUs. And one nice thing is the cache and the TLB entries can coexist, so you don't need to flash when you transition from a trust secure environment into the normal world. Bass transactions and interrupts, peripherals can be partitioned, peripherals usually are under the silicon vendor decision, so each shock has its own GPIO only for secure storage, so for the secure world or shared or whatever. One thing about the trust zone, despite all the isolation, is that obviously, if you are careless, configuring it, you don't get any of the benefits that it has. This is one of the reasons why we believe that every time you set up the trust zone, you should do it under the root of trust, just to make sure that that firmware is always verified by the ROM. ROM verification is pretty standard these days, so most of the silicones are going to allow you to program the hash of a public key. Then later on, when you send your firmware to the ROM, you will attach to it the public key again, it will verify the hash and then you use the public key to verify the signature that you're trying to boot. One thing about the, I mean, when I was talking about handling this with care, there is a TrustedFilmware.org project which provides shock developers and OEMs with a reference trusted code that basically it complies with all the relevant ARM specification. So that is typically used as a reference, but in reality, everybody's using it upstream. So what's in the upstream is pretty good. And then with respect to the trust zone and other important bit, that somehow, I don't think not everyone knows yet, there's been key move support for 10 years now. So you can run the whole, I mean, your whole shock with the trust zone and the normal world and secure world and the key move, which is very good if you want to develop within the trusted security environment without hardware. If I'm going too fast or if you have questions, feel free to interrupt because I usually accelerate. So one key component of the trust zone architecture is the runtime resident firmware. So this is firmware that executes a new exception level, EL3, and is there forever from the moment you boot. It should be there. And it's going to allow you, it's going to allow the system to transition between what is understood as the normal world or the non-secured world where the nooks and user applications execute and the trust zone. As I said before, usually you really want the resident firmware, also known as secure monitor, which is maybe a more common termination, to always be installed under secure boot, so being its sign. Opti, also, which is one of the implementations of a trust execution environment, provides its own resident firmware, a secure monitor, for 32-bit platforms, I think, but it's not much use. Everybody tends to use the implementation from the upstream ATF. And the way that the normal world enters the secure world is through this firmware. But regularly, there is something called the secure monitor call, which is very well defined in specs. And what is important in this discussion that we're going to have is to identify that there are two main types. One that is fast and atomic, which is what most of us usually use, which is, I mean, it has different classes as well. So you've got ARM specific, CPU specific, OEM specific. And there's one call, one type of SNC calls, that allows them to be suspended. So you could execute the SNC call and expect the call to be suspended as something else, completely different happen. And then your threat comes back again. So that's what we're going to be discussing, the yielding one. One thing about the trusted firmware resident, sorry, the trusted firmware implementation of the secure monitor is quite nice in the sense that it provides additional services. So one of the services that it provides is support for a test execution environment, which is not always required, but it allows it to run as a service or PSCI for power management. So you can access the secure wall through the secure monitor using an SPD, which is a payload dispatcher. And this payload dispatcher in the trusted firmware is just going to switch between normal and secure wall. It's going to handle all the SNC functions targeting the secure yield one. Maybe I jump over this. Is everybody familiar with the exception levels in ARM architecture? Maybe I should have. So we have, I don't know if you can say it. So this is a very common description of the new exception levels since ARM64 came along. So the secure monitor or the run to monitor firmware runs an exception level EL3. And then we have an hypervisor. All this is the non-secure environment. This is the trust zone. And we have EL0 for apps and trusted app also a secure EL0. And we have EL1 for Linux or whatever OS runs and for the trusted user environment. So through the trusted firmware, we communicate this way in and out of the trust zone. If you go through the trusted firmware.org, these are the user denominations that they use for the different firmware involved in the bootchain. So you've got BL1, they call it ROM. BL2 is some Facebook loader that executes in RAM. CoolBSPL, which I use it a lot. Then you have the secure monitor, which people tend to call TFA but it's just a secure monitor. And then you can have a trust execution environment of T, which they call it BL31 and BL32, which is a normal bootloader like a U-boot. I'm going to talk a little bit about one implementation of a trust execution environment, which is of T. It's an open portable coming from SD years ago and then was adopted by Linaro. It runs in ARM and for the last year and a half or so, there's been support for Rift 5, which I think is quite handy. Actually, they've committed, they've pushed a lot of code already. It has an standardized API that follows the global platform spec. So that's good. And what it does is provides a run in OS. Did I go back? It's providing the run in OS with, well, actually, I should say the OS or the bootloader with access to a secure world. So it's not only Linux I'm talking about. The normal bootloader U-boot, you can access the T from there. Not many people use it, but it's quite handy if you want to have RP and B access to store secure data in an EMMC. So in the slide that follows, I mean this one and the coming one, I'm going to summarize some of the important aspects for some things that I think are important in Opti when you're doing crypto work. And I'm going to start with this one, because if you read the code, you say, well, it's just a hardware unique key. And it's much more than that. So the hardware unique key is actually the master key. Opti doesn't keep any secrets. Well, it keeps secrets inside the trash zone, but you typically don't build it with secrets inside. So all the secrets are derived from a master key, which I'll describe later. So when the search boots, you have to provide Opti with a value. And the value will be used as a master key. So one thing important is that it has to be unique. Well, it should be unique to avoid duplication. As I say, it's going to be used as a symmetric key to derive all the other keys that Opti is going to be using internally. So it's important that it's never exposed outside the trash zone. Tips of this kind, I mean keys of this type are going to be the one that are involved in secure storage. Actually, there is support now for sealing the keys in the Linux key ring. There is an interface. Actually, there is a Linux driver for it that we will access in Opti and securing, actually, wrapping the keys, so sealing the keys, using a key derived from this value. Another example is when accessing, which I will describe as well later, and a secure element over a shared bus, you want to encrypt all the data. Because you are going out of the trash zone into a public bus, so you don't want the data to be unencrypted. So that key is also derived from this seemingly innocent hardware unique key. It's more than that. And in the terms of architecture that I'm looking into, which is actually most of them, I quite like the implementation that there is in the IMX boards, because it's quite safe. What they do there is they provide a hardware unique key when the system boots in normal mode. But when the system boots in secure mode, meaning that the ROM is going to verify the first firmware, in that mode, under the hood, the identification changes. So that way is never exposed outside the trash zone, unless you do a printf, right? But nobody should be able to access it. And that's quite nice. So have a complete different value during development. And then a new one, when you say, OK, this board is trusted, I can enable the hardware unique key, which is going to persist for the duration. Most platforms, they don't provide that functionality, so the drivers should be taking care of that. And that means having one for development and then detecting that the board is transition into secure mode, into a secure state. And at that point, you generate a persistent hardware unique key. And it's important that the key doesn't change, particularly if you are accessing RP&B, because the RP&B key is always also derived from this key. So if your hardware unique key changes, the RP&B key changes, and you cannot longer access RP&B. And you have to take it out of the board. So yeah, it serves as a unique identifier. And ideally, it should only be available both in sign firmware. But as I said, it's useful for development. It depends on you. But when you launch a product, make sure that it doesn't change. Then one of the main benefits that I see for Opti is having access to the secure persistent storage. Global platform enforces the requirement given by the global platform, which are actually quite nice. Because one very important one is that you can have secure storage using no secure resources. So as I said, you can share the hard disk between the trash wall, or the trash zone, and Linux, if you wanted, or U-boot, and the trash zone. So that's what Opti defines as the richest secure environment file system, meaning Opti is going to always call back to Linux when it wants to access the file system. It also has another one, which is quite nice, the RP&B support, which is more secure, obviously, because the reply memory protection block is contained in the hardware. But it's less use. For some reason, it doesn't have so much space anyway. Another important requirement is that secure storage is bound to your device. So you cannot take your files and move it to another device. You won't be able to access them. And each trusted application is going to have access only to the storage that it creates. So there is no intercommunication between trusted applications. I don't know if you can see it, but when I was referring before about the hack, all these keys, all the keys that are involved in defining secure storage, which is one per device, there is one for trusted application, there is one for file, all of them are derived from the hardware unique key. So imagine that if you leak the hardware unique key, then all of this is at risk. So that's why I consider it important that everybody pays attention to the hack. Then a quick summary of what a trusted application is. So the execution of any software between the normal wall and the secure wall is split using just one bit. When you boot a trusted application, there is a companion site on the normal wall. It will call the secure monitor, and it will be executed. So everything that gets executed on the secure wall initiates in the normal wall. I mean, Opti or the secure wall is never going to start any tasks other than the initial boot without being asked to. We'll see there's no thread scheduling. There's not much there. So when you boot a TA in the trust, oops, not there. When you boot a TA in the secure wall, all of those trusted applications have been RSA signed. So what you're booting is always verified. They could be encrypted, but then you have to figure out how to pass the encryption key. It's a symmetric encryption into your binary. And the TAs can be stored in the RP&B or can be stored in the T image early as well. So you can access them during you boot if you need to. That means that you will build the trusted application inside your Opti binary. They can be versioned, and they have a number of configuration flags. So they can support multiple sessions. Then you can configure the stack sizes and so forth. So we'll get into the end of this. One very good example that encompasses all the benefits of the trust zone is the PKS-S11 TA. I like this slide because it kind of defines the architecture that I've been using for a while now in fondries. So with Opti, actually I shall start saying, but verify boot, remote attestation, description, all of them. They can be implemented using a PKS-S11-11 API. They support for all of them. So this is quite handy if you need to support different hardware or different devices. So it could be different cryptopripy, so it could be a TPM, or it could be you just want to simulate your system before going to production. So you can achieve all of this using PKS-S11. Just by configuring the request in the application, then you could be executing on a crypto IP, or you could be executing on a TPM. And I think that's quite important. When I started this talk, I was mentioning that what we need here is more. So basically we need more crypto devices in there. And then we have CAM, we have silent support, we have ST support. I think TI has started pushing supports for some crypto in the trust world. I think the more, the better, always. Now, so that was the history of what's the TGE, and why should we use it, and how we get security storage, and some of the issues when basically configuring OPTI in terms of the task sizes, hardware unique key, security storage. And now let's see how you can develop the software to integrate your crypto IP in this environment. So I said earlier as well that OPTI implemented its own secure monitor. But most of the people, most of the teams, they always use the one that comes from the Tractor firmware, which is a very good reference. The secure monitor is going to manage all the entries and exit in and out of the secure world. And that's a very important thing to remember. We had two types of SMC calls. One's the fast, with the RQ, the mask, and the yielding ones. At some point, you are a master RQs, and maybe you want to sleep, or maybe not. But you want to have the choice. One thing that I believe I also mentioned is the OPTI. Some people call it ANOES. I don't think it's not really ANOES. It's just an execution environment, so it's not going to do any scheduling. It's a way of task. What they call as a trusted task is only a rich execution environment threat that's being shadowed into another threat in the transport. But all the threat belongs to Linux. But because of that, it has to implement some synchronization primitives. So you have some spinlocks, which they just love the CPU. But also you can use semaphores, sorry, mutexes to schedule different. And the way they implement mutex, which I think is interesting, mutex is a service that is used in the case of Linux. And Windows, I don't know how they do it. But in case of Linux, it's a callback from the trust zone to Linux. And that will be the typical completion structure taking care of sleeping that task. And then it will reenter when it's done. So there are a number of tasks, sorry, stacks involving in OPTI. They have different sizes. The thing is that they are configurable because sometimes you have a demand for more stack, depending on where you're locating your internal functions for your crypto stuff. So how do we exit? I mean, entering the T is used from user land. Just using the OPTI client libraries. I don't know if you have time to have a look at it. It's just a normal C library that you link to it. And then you execute the calls and somehow you land in your trusted application or your trusted service. These libraries, this library can be extended to support for secure elements or for secure, for trusted applications, for anything that you want. So you can push code upstream. I think the way in is easy. People usually don't have a clear picture of how do you get out and if you need more resources. So OPTI implements two types of exits, synchronous and the synchronous one. The synchronous, because OPTI can handle interrupts, right? You could define a secure interrupt and the secure interrupt will be handled in the trust execution environment. But what happens if there is an interrupt happening, there's an interrupt occurring where you're executing your code in the trust zone. Then you need to go back. So that will be an asynchronous exit for a foreign interrupt going back to the normal wall. I think the ones I wanted to talk about were these synchronous exits. So this one, to call back to the monitor software and EL3, which is good. And there is another one, which I think is more useful generally, which allows you to call back to Linux or UBUT to the normal wall for services. What the code does is going to, so once you are in the trust zone, it's going to suspend the threat and it's going to SMC back to the monitor. And then the monitor will call back into Linux and proceed from there. So this is very handy and this is used, for instance, when Linux, sorry, when the trust zone, let's say that Linux want to store, let's say that a trusted application wants to use secure storage. So the data path will go into the trust wall. The trust wall will be calling back into Linux. Linux will access RPNB and then will come back into the trust zone. So that's a route that is used a lot. There are some more cavities in the sense that there's also something called a supplicant driver. So when you call back to Linux, sometimes the kernel can do it and sometimes the kernel cannot do it. If the kernel cannot do it, when you come back on your RPC call, you need to release the supplicant that is waiting on a notify and the supplicant will take care of handling your request, which is the case of RPNB. It's nicer when the kernel can do it because then, for instance, if the secure wall wants to access an SQLC bus, it could just call Linux and Linux will access the bus and come back. So I think I explained a little bit about the T-supplicant. If you have any questions, feel free to interrupt me. I can see that maybe I'm going too fast or maybe I'm losing. So yielding the SMC, these are two examples which I mentioned very quickly before. One is right to RPNB and the other one is accessing the secure element. Accessing RPNB uses the supplicant because the kernel cannot access it directly. It needs to, it cannot access it yet. I'll precise that in a minute. So at the moment, the way it currently works is Opti is going to call back to Linux. Linux will release the supplicant, the supplicant will perform the right and then it will go back. There is some work going on in the kernel to enable direct access from Linux to RPNB without having to go to the supplicant because sometimes the T boots before Linux. So you want the T to be able to access RPNB without having to wait for usage space. So this work going on, and I think it's going to be merged, I don't know when, it could be a couple of months. So that's one case with it be a supplicant and the other case is accessing without requiring the supplicant which is the case of a SQC support. In this example, let me check. Yeah, it thinks that the resolution is not great but I'll put links there as well if you want to poke around. The second example is a simple app that I wrote to access an HSM via the Trason and the HSM is controlling SQC. So this is a Linux application that is going to send the APD use to the Trason. The Trason is going to call back Linux which is going to call back to the SQC driver. You're going to send the data to the HSM and you're going to send it back to the Trason for operation and then the call returns. And this driver is actually quite interesting because as I said, we need to encrypt everything that goes in the public bus. Everything that gets out of the Trason is not considered secure anymore. So when you're accessing an HSM through a non-secure method or mechanism which is like a high-scruby or a spy or one of those, unless you lock it for yourself, you want to encrypt all the communication. So that's the case of a ELC-serial Linux. You can do the same thing from U-boot and I upstream all this code. So U-boot has a command called SCP-03 that allows the user to rotate the keys in the HSM. As I said, it's very similar in the path. With the difference is that instead of going to Linux, you go to U-boot. Going to U-boot is actually easier to work with. The driver is simpler. You don't have multi-thread there, it's just a single thread. So there is a supplicant also in U-boot but the supplicant is just part of the whole operation. So now I'm just going to describe these two cases which are representative of the work that I've done over the past couple of years. One is the first one is this device, the NSP-SF50 HSM. It's a hardware security model that is accessible from my square C. It gives a bit of thrust at the IC level. I mean, you can read from the slide but one important feature that the NSP offers with this silicon is that you can pre-provision keys directly on the device. So when you system boot, you can use those keys for whatever thing you want. And that's quite handy. I think that's one of the biggest assets of these two. It has RSA, it has CCC, it has RNG, I mean it's a very, very full feature device. The only thing is that it sits on the square C. So when you talk to it, you need to make sure that everything is encrypted. Global platform for that defines another specification called the secure channel protocol O3. I didn't read, I actually didn't see an O2 but this is the O3. It's a standard, it defines how securely agree on the keys. So these devices, they are shipped with an initial key and they're in the persistent storage but you can rotate it. So you should be doing that during early, early in your boot process. So another thing about Opti, I mean this is important because early in the boot, let's say that you want to provision the device. Without the normal world, you cannot use the RPC call in there. So if you need your cryptographic IP to be accessed early in the boot sequence before Linux is up or before UBT is up, then you might have to write one driver or two driver. In this case, I have to write one SQLC driver to access the secure element but SQLC is not complex. And the important thing is as soon as Opti initializes, they have this macro, a boot final. At that point, you can switch your driver. You say, okay, from now on, any further request that anybody makes to the secure element instead of routing it to the normal native trust on driver, I'm going to route it to the RPC drivers. So in your boot sequence, you can use different drivers for the same features, which are quite nice, I think. So early in the boot, you can do the device provisioning, you can identify the hack and you can do the first rotation of the keys. So initially, the system boots with predefined keys, right? Everybody knows that key, those are public. So you want to rotate them as soon as possible. And that's something that you can do before Linux is up. Then through the boot loaders, if for whatever reason, you still don't want to do it at that point, you can wait for UBOOT as well. So UBOOT also provide the same command that is going to allow you to rotate those keys. Functionality-wise, we implemented this feature because not everybody wants to rotate these keys so early. Some people have different provisioning strategies, different factory requirements, so sometimes they want to postpone rotating these keys a bit later. And then when the normal wall is up, yeah, then you can use any, actually you can use PKS CS11 to secure a store into the HSM, all the crypto operations, RSA, RSA, Renonoma Generator, and AAS, all of them can be executed if the user wants to in our security model. One thing as well is Opti provides its own cryptographic libraries, based on Liptone Crypt and Liptem embed TLS as well. So if you decide to implement support for a cryptographic IP, that only has a subset of the operations that you need. You can say that you don't have an RSA 2048, you don't have to implement that, but you want it, you can fall back, you can request Opti to say, okay, in my cryptographic driver, if this operation, I don't support RSA 2048, please give me a software implementation on it. And the good thing is that it will be executing in the trust zone, so that's a plus. A different matter is if you want the HSM to delegate into the library, how do you get the private keys? Because you can't. So in some cases it's not possible because the private keys are always inside the device. So this is the case where we use threat RPC to call back into the kernel. The kernel is then giving us access to a SQLC bus. The reason why we use the kernel as an SQLC bus provider is because we don't have any issues with runtime PM, which is my power of the bus in the middle of a transfer. We don't have any issues with bus contention as well. Opti can go anytime he wants, Linux will do the scheduling. So this is why that path was put in there. Obviously, we initially tried to follow only this path, but as soon as Linux is up and he doesn't see any body using the controller, he will shut it down. So yeah, RPC came along and it's quite handy. I mean, all the code I'm talking about is upstream. So in case you want to have a look. The second case is a bigger platform. I mean, this is an expensive development board. It's like 15,000 euros. This is AMD SILINX, VersaL Adaptive Platform Device. And here, the way the AMD SILINX architecture works, everything is routed through the PLM firmware. So this is running a microblaze processor. They change the firmware with every BSP release, but everything is controlled through this software. All the implementation of the most of the cryptography that it offers is uses, as I said, adding the embedded software by SILINX. And there is an authenticated encryption. There is RSA, ECC. There is SHA-3 as well, 384. Not to use yet, but it's there. There's access to a physical and cloneable device. And then if you want to use fuses, you have to go as well through this processor. So in order to access this thing, it's quite handy that the secure monitor patches that they have in there, they have support for a mailbox. So one very straightforward way of communicating between Opti and the PLM is through calling to the secure monitor. As you can open a mailbox, inform the secure monitor that you want a mailbox with the device, and from then on, just do these threat MCC calls. That way you can instruct the PLM to do all of these operations from within the trash zone. This code, it took a while to upstream because it's a lot of code. Opti has support for fuses and all the cryptographic tools that I described. One important caveat of the architecture is any critical service that Opti wants to use, which is the random number generator, for instance, or the AGCM engine, it should be reserved. I didn't mention this. Did I mention? I can't see very well. I don't think I mentioned. Well, let me check. So when the hack gets defined for this, the input can come from an ASGCM engine controlled by the PLM. And you can fit a private key from there. If for whatever reason that gets exposed as well, you may be given away your hardware unique key. So Opti gives you the opportunity to reserve devices exclusively for the trash zone. That's done by a device tree. Another option will be the hardware-supported reservation. But device tree already allows you to reserve devices. Can't see very well what says in that. Yeah, so this is just an example of how everything is sorted. In this case for Bersal, the number of keys that it supports in an elliptic car from an RSA is not as big and an HSM. It's only 2048 and I think it's 256. Everything else will fall back to Tom Crypt. And that seems to be working quite well. So as a summary, getting out of the trash zone is easy. Requesting support from the normal wall through threat RPC is easy. I mean, it's totally transparent to you. You just call the function and everything is executed in the kernel or in the supplicant if you need support from the normal wall at user space level. You can also call easily to the secure monitor. And the secure monitor can delegate your call wherever it needs to go. So it's a bit different to maybe secure enclaves where everything is constrained into the environment you chose. With a T, you can get out. You can get your stuff from the normal wall and then come back again and continue with your processing. Which I think is a very interesting feature that makes it very easy platform to work with. There's some of the reference if you want to have a look. I presented the Bersal, all the upstream that I did at EmbeddedWall early this year and the year before the next PEC 50 driver. They were big deliverables. There was a lot of code upstream, but I think it gives a good reference of how theory is simple is to upstream a cryptographic IP into Opti. For me, the important bit, it gives you the benefit of accessing it through PKCS 11, which I think is a great advantage. If there are no questions, have some backup slides that I can go through or I can clarify. I can talk a little bit about secure boot if you want. I don't know how long we're going in time. You still have five minutes. OK. So yeah, put it aside because I heard about secure boots sometimes. And a few times it's not described the way I think it could be described. Secure boots relies on the capability of the ROM to verify your favor through a polycryptography. For that, you need to fuse because there's no work around it. You have to fuse a key into the platform. But that doesn't mean that all your route of thrust have to use the same key because then your security is as good as the single key. So the way we tend to use it mostly is, sure, you fuse your first key for the first boot loader, but the subsequent one, which was already verified by the ROM, contains a number of binaries signed with a different set of keys. And those are the ones that the first loader will verify. That way, basically, you can rotate those keys whenever you want. You are not tied to what's in the fuses. Sure, you are tied for the fuses but only for the first boot loader. I think that sometimes this goes unnoticed. Many platforms have the capability of having a persistent route of thrust, including the kernel, like the VersaLaCup. You can fuse your keys, and then they will verify everything from the first film with their boots until the Linux kernel all the way to applications. It's just brutal. But as I said, you need to protect that key with your life. The other way, sure, you protect the first key, but all the other ones you can rotate. There is a process. There will be a process involved, but I think it's totally worth it. And that's important, but of course, as long as the first boot loader can be upgraded. If there is a vulnerability of some kind and you need to reprogram your device, you always want to be able to go to the first loader and say, OK, remove everything. We have an issue here. And that's why the first key is important. And another important thing about Opti. For me, Opti has value when it boots early. Over the last three or four months, Chrome guys have changed all the load architecture. And now you can load Opti through an SMC call. So you can boot to use the space and say, OK, now I want to load the key. Maybe for them, I'm sure there are no security implications, but if Linux vendors start doing it because it's easier to upgrade your system, because it's easier to upgrade an application that firmware. So if you start receiving T upgrades from user space, I will be a bit concerned. I mean, that path is mostly set for Chrome OS, because they don't have an issue in the boot chain. But with a normal desktop, you don't want to load your T from user land. You want to load it through the boot chain. What else? It is a code dive, but I don't think we can see anything, right? It's not working. Well, I think that's it, because OpenSSL integration. So that's all I have. Any questions? No? I think there's a lot of value. I'll repeat myself there. But having the cryptographic drivers in the Trason, this value is not that much effort, and you open it to everybody. I mean, once you have it in OPTI, then they have a PKS CS11, and you can access it, you have security storage, you have the whole thing. And you'll need to worry again about getting a vendor, PKS CS11 implementation, and rebuilding your product, and all that pain. So just stick to one. Regarding the trust store during Uboot, is it available immediately? Can we access the area that we set up in the trust zone for the secure keys via Uboot directly? And there is already support in the mainline for doing this? Not really, right? I don't think they support upstream. I mean, we have support in one of our repos. You have to write a little trusted application and then just to route it. But yeah, I mean, you can use what we have as a reference. I can give you a link. Yeah, because my idea was to, for example, store the Uboot variables, for example, the environment inside of maybe the secure store in the trust zone to make the entire boot safer and encrypted. So with respect to the boot sequence and to simplify, actually, to secure server upgrades, we use the RP&B to make sure we don't have rollbacks or to make sure that we know the version that we're installing at any time. And that's controlled always from the trust zone and readable as well by Opti. So yeah, sorry, but by Uboot, but yeah. That's one of the benefits as well. And I'll say again, because it's important. I've seen many boards being bricked. The RP&B key, if you use Opti, is generated from your hardware unique key. If that changes, you don't. And you don't remember what it was, then Uboot will be able to access it again. That's not going back. Do the trusted application authors need to worry about speculative code execution? Or is that handled for them by the trusted environment? I'm sorry, I couldn't. I couldn't hear. Do trusted application authors need to worry about speculative execution problems? Or is that handled for them by the environment? They are, yeah, they are affected. And in Opti, there has been changes to cover for that. I don't remember the names of the fixes, but there is a number of them and they're looking into it. But yes, it is affected as well. You can also open CBEs on Opti and you'll see there is a list. Some of them can be fixed, some of them can't. But there is work on the sense that you're describing. So the trust zone is as secure as you make it. And you can make it secure or if you're a bit careless with a few components and it's not a trust zone anymore. It's like a dumping ground of stuff. Any other questions? All right, thank you.