 So that was for the background knowledge reminder. Now we will have a look at the XCube AWS 2.0 package. So the overview. So first, let's start with the multi-account registration. This is a key concept that's really important. So the multi-account registration is only one of the possible options to connect to AWS. You can have just-in-time registration, just-in-time provisioning, one-click X519 certificate. All these methods I won't describe today because they are not supported in our package. In our package, the novelty we bring is the support of a multi-account registration. So it introduces an optional simplified registration step where customers can register their device certificate without requiring a certificate authority to be registered with AWS IoT. So this is really important. It means that you don't need to have your device certificate signed by a certification authority. You can sign it by yourself and it will be fine. But the drawback is that each device must be individually registered in the AWS backend. So the benefit is that you have no CA to maintain with a private key or get your certificate signed by a CA. But the drawback is that you need to register your devices one by one. Each certificate must be known by the AWS backend. So the component device manufacturers will be able to offer components pre-provisioned with a digital identity, a certificate, without having to maintain a unique customer-specific CA. So by without having to maintain a unique customer-specific CA, we mean that there is no need for a single CA certificate for all devices. So this helps simplifying and accelerating the device registration process. So it fits quite well with our STSA110 SPL02 profile. It's the generic sample personalization profile where we have a device certificate signed by ST certificate. So ST certificate is not a CA, but it's not a problem with multi-account registration. So what do we gain with that? Initially, you had to manage different certificates for a single device to connect to multiple accounts. With different CA, because each account had a CA. So each time a device was moving from one account to the other, you had to update its device certificate to sign it with the appropriate CA. Now you can easily move devices from one account to the other by simply changing the AWS IoT Core endpoint the device connects to. So this simplifies the device registration process and it helps rapidly moving from testing to production. So for instance, you can register, test and configure a device in a pre-production account, and then you can register and use the same device on device certificate. You don't need to change the device certificate in a production account. So when opting to use this feature, you will also use what we call SNI server name and indication. It will be a string sent by your device and part of the TLS session to route the correct IoT endpoint. So again, what we gain with multi-account registration is an easy way to move the device from one account to the other. You keep the same device identity, the same device certificate. You don't need to have a CA signing your certificate. So I said that it was matching quite well the SPL02 personalization of the STsafe A100 tell. So let's have a look at this personalization. So in the SPL02 personalization, we create a standard profile. It's quite permissive. It's not the more restrictive one because it's made for evaluation purpose. And what is interesting for us is that it's a complete secure production flow. You will create a key pair for your device, a private key and a public key. And this will be securely inserted, injected into the STsafe. So your customer don't need to care for that. This is done by ST in a secure production flow. And in the case of SPL02 personalization, the device certificate is signed by ST's self-signed certificate. ST plays the role of a certification authority. So usually this is not great, but thanks to multi-account registration, the new thing in AWS 2.0, we can register this way because this device certificate will be known by the AWS backend. So how does it work? So let's have a look at the concept of AWS connectivity with multi-account registration. The first thing you do is to receive your STsafe pre-provision. So it's pre-provision thanks to the personalization, the SPL02 personalization. Then on the Amazon Web Services site, thanks to the CLI, the command line interface, or thanks to the web dashboard, it depends on what you prefer, you will create a policy, create a thing. Now that you have created a thing, if you turn on your STM32, it will communicate with the STsafe, which is embedded on the IoT Kit, and it will print the device certificate in a terminal, in a console. You will copy-paste this device certificate in a .pem file, and you will register this certificate on Amazon site. So this is the drawback. You need to do this for each and every device. But the benefit is that you will be able to move from one account to the other. Then you attach a policy, the policy that you created initially to the certificate, you attach the certificate to the thing, you get your endpoint description. So in our solution, but it's not only our solution, that's the way it's working for Amazon FreeRTOS, it's the same for all silicon vendors. You need to update an header file at wsclientcredential.h, and this will give the endpoint to the STM32. You recompile your software, and now you are ready to connect to Amazon Web Services with a multi-account registration feature. So, XCube at ws2.0 security. So SBSFU is the secure bootloader. So it will provide a security architecture, and it will provide a route of trust to boot the AWS 2.0 IoT application. It will authenticate the application before running it. So this is based on the certificates. It will provide secure services at runtime. This is what we call KMS. It's exposed through a standard interface called pkcs11. And it will rely on STSF-A110 as a secure hardware crypto token for elliptic curve cryptography and as a secure key storage. So we get the benefits from the STSF-A110 secure element. It's used by SBSFU as a route of trust for the AWS 2.0 firmware image authentication. We will extract the certificate from a store inside the STSF. And it's used by XCube at ws2.0 application to connect to a AWS server with multi-account registration technology. So in the STSF, we have a device identity, and we have assets we need for the TLS connection. So the Amazon embed TLS layer is not fully ported on top of pkcs11. So it means that server authentication, for instance, will still be performed on NCM32 side. We will come to this in the next diagrams. So secure IoT device via architecture. So this slide, this is something we have already seen. Well, we have seen almost the same picture at slide number seven. The difference here is the addition of a secure element, the STSF-A110. This brings a better security level as this component is designed to twirl even silicone-invasive attacks. With this element, we have a secure safe to store our secrets, the device private key, and ensure the integrity of key elements, the device certificate. So the private key is really a secret. It will be stored in the STSF-A110 and will never go out of it. The device certificate is a public element, something we need to send to the server, so it will be extracted from the STSF, but the STSF ensures the integrity of it. So in addition to this, the STSF-A110 also acts as a secure hardware crypto element providing electrical cryptography. So STSF-A, the deliverable is a pre-provision STSF-A110. So it's pre-provision with the device private key and the device certificate. In our package, it's integrated with SBSF-U via KMS, so it can be used seamlessly by the application. You do not even notice that you use a secure element. Your application relies on Amazon Freer Tos. Amazon Freer Tos uses Embed TLS for its cryptography. Embed TLS is supported on top of PICACI S11, and PICACI S11 is provided by KMS, and KMS then is doing the routing, either to STSF-A110 or to STSF-A110. We will come back to that in the next slide. So we can highlight that the pre-provisioning in the STSF-A110 is the first valuable asset of our solution. We provide a device that is pre-provisioned securely. The customer doesn't need to care for the private key and its protection. So now let's have a look at the package architecture. So we have our IoT application. So this application can do several things. First, it can print the device certificate. This is a very basic service we need to be able to register to AWS because we need to register this certificate in the AWS backend, as we saw earlier. It can do the TLS uncheck to enable the TLS communication, and it can also do overviewer update. It's relying on Amazon Freer Tos. So that's the new thing with this package 2.0. We have Amazon Freer Tos instead of the Amazon CSDK. And all this is relying on a secure framework brought by Xcube SBSFU. So we have a secure bootloader. We will ensure the authenticity of this application before running it. We have a secure firmware update, allowing us to implement over-the-air update. And we have the QMS, Key Management Services, to expose our cryptographic services to Amazon Freer Tos. So services like HASH, like SHA256, will stay on the STM32 side, but the electric curve cryptography will be offloaded to the STSafe. So it will be ported through the STSafe A110 middleware. And then we also need cryptography in SBSFU. This is brought by Embed TLS. So that's the thing you need to keep in mind. We have one instance of Embed TLS embedded in the application. This is the first binary. And in our bootloader binary, we also use Embed TLS for cryptography. This allows us to avoid using the ST Cryptolib. And this way, we don't need to sign extra documents to be allowed to get this crypto library. And at the very bottom, we have STM32 with all its security features like the firewall, the MPU, the WRP and RDP to bring security at the STM32 level. And we have the STSafe A110, which will embed our SBSFU certificates, the device certificate. It will do the job for the electric curve cryptography. So creating, generating signature or checking signatures. We also have the possibility of using a TRNG and TLSFAMeral key. In the version 2.0 of the package, this is not used. So handling the TLS assets. So looking back to TLS example, we have an architecture that allows us to use the silicone security features to build a trusted environment to protect access to critical keys and credentials. So on the MCU side, STM32, we have less critical information like the endpoint credentials to which server we must connect. We have the server CIS certificate. This will be used to authenticate the server. And the critical element, the critical TLS assets are stored in the STSafe A. This is our device certificate. It's not a secret, but its integrity is important. And our secret, the device private key. And in addition to this, all the cryptography operations will be run on the STSafe A side. So it means that the key will never be exposed out of the secure element. That's really a valuable asset because it gives a much better security than a solution with only the microcontroller. But on an MCU like the STM32, we have some security in here because we can use the firewall and we can separate secure enclave from the normal code to reduce the risk of malicious application accessing the keys directly. So KMS will run in the secure enclave. It won't be mixed up with the application. So it's some trusted code. It's not as good as STSafe A, but it's a good level of security for a general purpose microcontroller. But of course, the STSafe A110 can twirl silicone invasive attacks and it allows to offload the electric curve cryptography. That's the benefits we have. So TLS communication. Oh, I put it the other way around compared to the other slide. So this time, the device is on the left-hand side and the server is on the right-hand side. So what will happen? Our device will send client Hello to the server. The server will send the server Hello with its certificate. It will send the client certificate request and all the elements we need to do the key exchange. So this server certificate, we need to verify. So STM32 will verify the server certificate. It will verify the certificate chain because the server certificate is signed by root CA and this root CA is embedded in the STM32. Then as the server asks for our client certificate, we will retrieve this client certificate from STSafe A. So it's okay because it's a public information and this certificate we will send to the server. But we need to prove that we own the private key corresponding matching this public key. So what we do is that we ask STSafe A to sign a hash proving that the device has a private key and this certificate verify we will send to the server as well. So as you can see, we have IP communication between STM32 and the server and we have a nice QRC secure channel between the STSafe A and the STM32. Then we move into encrypted mode and we exchange encrypted messages as we saw earlier.