 Maintenant, je vous présente un démon d'exploitation en utilisant notre exemple de code à l'aide de la ferme STM32WL-Cube. ST delivers un exemple de code à l'aide d'un SBS, en incluant le KMS. L'objectif de ce démon est de vous montrer les bricks de sécurité basiques qui sont à l'aide de la ferme STM32WL. Dans ce démon, nous allons utiliser un de l'exploitation de code à l'aide de la ferme STM32WL-Cube. Ce exemple est capable d'améliorer un single ou un dual-core. Ici, nous utilisons un target dual-core, mais l'on n'utilise qu'un M4 de ce dual-core. Il y a un exemple d'exploitation de code à l'aide de la ferme STM32WL-Cube, qui est une implémentation de standard SBSFU. Il est installé dans un mode image. Ce SBSFU est capable d'améliorer le download de la ferme STM32WL-Cube en utilisant le protocole Y-MODEM. Les principales features qui sont demonstrées ici sont la KMS. La KMS est le système de management de la ferme STM32WL-Cube. Le code de ce système de management de la ferme STM32WL-Cube est installé dans le sceau SBSFU. Il est installé dans deux différents types de clés dans ce démon. Il y a des clés d'ambiance qui sont situées à l'intérieur de l'engin de la ferme STM32WL-Cube et des clés statiques qui sont dynamiquement provisées. Ils sont situés dans des zones réservées dans la ferme STM32WL-Cube, qui s'appelle KMS Data Storage. Pour pouvoir contrôler la ferme STM32WL-Cube, une ferme STM32WL-Cube, une ferme STM32WL-Cube, qui est à l'intérieur de la ferme STM32WL-Cube. Le BLOB est un set de données qui contient les clés pour être importés. La data est encryptée et signée, la même façon que la ferme STM32WL-Cube est faite pour un file de ferme STM32WL-Cube. Donc, les nouveaux clés sont aussi importés avec le même mécanisme que l'on utilise pour un file de ferme STM32WL-Cube. Dans ce démon, nous allons utiliser des clés d'ambiance différentes. Le premier, les clés utilisent d'écrire et d'authentiquer la ferme STM32WL-Cube. Les clés utilisent d'authentifier et d'écrire le BLOB, qui sont différents. Et aussi, les deux clés utilisent pour tester les propositions. Et ensuite, nous allons avoir deux clés statiques, qui seront provisionnées. L'une est une clé RSA, et l'autre est une clé AES. Juste avant d'entraîner le démon, nous allons vous montrer l'application flash de ce démon. Les clés de l'adresse de l'application sont sur le top des figures, donc nous pouvons voir les clés d'ambiance, les clés d'ambiance et les clés MS-Code. Et ensuite, la ferme secure, la ferme secure boot, la ferme secure update, qui est capable d'écrire la nouvelle ferme. Et ensuite, les clés de l'adresse de l'adresse de l'application sont utilisées pour tester les clés statiques, qui seront provisionnées. Et les clés de l'adresse BLOB, qui recevront le BLOB avant l'installation. Et ensuite, la ferme active d'adresse d'adresse pour l'identifier l'application et l'application, qui est en fait un exemple qui est présenté dans le projet. Les deux principales protéctions utilisées dans le démon sont la protection RDP, qui assure la entrée unique pour la ferme secure et la possibilité d'accéder à l'application en utilisant le debugger. Et la deuxième protection, c'est la protection RDP, qui assure l'immutabilité de la ferme secure et les clés d'ambiance. Nous allons maintenant switcher au démon. Donc, notre démon est basé sur la ferme secure pour WLV.1.0.0 où vous avez l'application standard d'adresse d'adresse d'adresse d'adresse. Alors, nous allons voir l'exemple dans les applications du projet Nucléo. Et le démon va utiliser cette BFU-1 image. Nous avons 4 projets dans cette application la ferme secure et la BFU c'est un BFU standard pour les projets et l'application d'adresse. Et sur cette ferme, nous avons un blob KMS qui est utilisé pour générer un blob. Nous allons aller au STM32 Q by D où j'ai déjà lavé ces projets et nous allons les compilier. Donc, nous allons maintenant l'AC Corbin, et vous pouvez voir qu'il y a une pré-builde, et le propos de cette pré-builde est d'injecter toutes les clés d'embaîtage qui sont nécessaires, donc pour l'authentication et l'authentication de bloc, et aussi les deux clés utilisées pour le test, ce que l'on verra plus tard. Donc ici, dans l'AC Corbin, nous avons le framework Secure Engine, including the KMS Core, and also the embedded keys. Then we build the SPSFU, which is the code that manages the Secure Boot, Secure Firmware Update, so the authentication of the application, and also it manages the installation of the new application and the installation of the blocs. Then we build the user application, which is the demo application, and at the end of this build, we will have a post-build that will generate in the user application binary some binaries, so here you can see it is generating intermediate files, and then we have our two files, the one binary containing the SPSFU and the user application that will download on the target, and a user app.sfb, which is an update file that is encrypted and signed. So let's open the Q programmer and connect to the target. So we have here a target STM32WL, you can see it here, and we will download this file to the target, so here it is already prepared, so I select this file and it just before I launch the Terra Term, so I have the Terra Term that is outputting the traces of the SPSFU. So I start programming and at the end of the programming, the SPSFU is launched automatically. So we have here the traces of the secure boot, we can see that it is checking for a new firmware to download and also checking for a new blob to install. And if nothing is needed for installation, then it is checking the active firmware authentication, so it authenticates the firmware. The firmware is OK, then it is launched by the secure boot. Then from here we have the example firmware, the user application with a kind of a menu, and we will use this test KMS, so I press A. And you can see that we have two first tests using embedded keys and two next tests using static keys. I press 1 to launch the first test, you can see that it is running successfully because the key is already there and we can use it. The user application is actually using KMS services to be able to perform this encryption and decryption without having access to the key itself, just service providing a key index that you want to use. And same for the second, so I press 2. I have also this second test with ASCBC, with encryption and decryption. Next, if I want to launch the test number 4 using it. So I press 4, you can see that the test is failing and the reason is that the key is not imported yet, so the key is not available on the target. So here we need to import dynamically using this import blob, the keys necessary to the two last tests. So to achieve this, let's go back to our project and select the KMS blob. This KMS blob is a project containing only one C file and this C file is containing a blob structure with all the keys that you want to import. So here we import a RSA key and we also import an AS key and you can see that there is a parameter that tells that you can derive the key. So this means that KMS associates to each key, the actions that are authorized and here we can use derivation for this key for instance. So here are the keys you want, the static keys you want to import to your target. To do that, just launch the build and this build will generate here in the blob project in binary, it is generating this file. So this file is the blob which contains the two keys that are defined here. The two keys are encrypted using this CBC key and they are signed using this ECC key. Then on the target we have already embedded the associated public key of this ECC key and also this symmetric key so that the SBSFU will be able to decrypt and authenticate the content of the blob. So let's see how we can do that. We go back to our Terra term and import the blob. I press 3 and here we have the Y modem interface to import the blob. We use the Y modem interface and I am already here in the good directory because I prepared this demo before. So I press the blob, KMS blob and it is transferring the blob. You remember in the flash area dedicated to this transfer after this transfer made by the application itself, the application is rebooting, giving back the hand to the secure boot. And secure boot, one of the steps is checking if there is a blob to install and here it has detected this blob that is still encrypted. So it is decrypting it and checking the authentication. Once this authentication is ok, it installs the keys in the key store of the KMS. So it calls the SBSFU, calls the secure engine to it and the KMS service needed to install the keys. Once this installation is done, the process goes on to launch the firmware that is still check authentication of the firmware and we can check what we can do now that we have made the import. We can use this key, so I press 4 and you can see that we can use the RSA key to generate a signature because RSA here is a private key and the second test also we can derive, make a derivation using this AES key. In conclusion, let me come back to a slide presented previously where we could see on the left side the device with its secure boot, secure firmware update and embedded keys that is able to run but has not been provisioned yet and then the blob that is used to provision the keys dynamically where you want on the field even in interested areas so that you have a device that is fully functional. So the solution we propose using this KMS allows this dynamic provisioning. Thank you for your attention.