 Ok, maintenant, on a vu que l'AOVWS package est designée. Maintenant, on peut ouvrir et voir que l'AOVSTsafe A110 a été intégrée, grâce à l'ex-cube SBSFU. Donc, peut-être que je dois expliquer la chaine de certifications de SBSFU que nous avons sélectionnées. Donc, c'est l'exemple rationnel. Donc, il est important de le rappeler et de savoir qu'on a deux sets de certifications. Le certificat utilisé par SBSFU pour authentiquer l'application de la ferme et le certificat privé de l'application privé. Ceci est donné par l'AOVSTsafe A, et cette certificat est utilisée pour connecter à l'AOVWS. Donc, ce que je vous montre dans cette slide est la chaine de certifications qu'on a besoin sur le site de SBSFU pour authentiquer l'application de la ferme. Donc, nous avons décidé de faire une chaine avec 4 certifications pour avoir quelque chose de réaliste et pour démonstrer la flexibilité que la chaine de certifications de SBSFU peut ajouter sur le transfert de responsabilité. C'est important. C'est flexible parce que vous pouvez revocuer les CAs intermédiaires sans affecter d'autres éléments. Il y a un transfert de responsabilité parce que par suivre la chaine de certifications, vous savez où c'est et où c'est. Donc, vous pouvez mettre votre ordinateur. Donc, nous commençons avec la route CA. Ça pourrait être un DGCERT, pour exemple, qui est une certification de certifications de certifications de route CA. Dans notre cas, nous allons utiliser OpenSSL pour générer les certifications. Donc, ce sera un fake, ce n'est pas un DGCERT. Ensuite, ceci signifie un certificate OEM. Donc, ce certificate OEM est l'honneur de l'application, l'un qui produise l'AOT node. Donc, nous pensons que c'est bien de l'avoir parce que si vous n'avez pas ça, une autre compagnie utilisant un DGCERT comme un CAs pourrait installer la ferme sur votre ordinateur. Donc, nous avons vraiment besoin de ça pour dire, OK, je suis signé par DGCERT, mais je suis compagnie A. Ensuite, nous pouvons avoir un CAs intermédiaire qui peut représenter une facteurie. Donc, une compagnie peut avoir plusieurs factures, donc vous pouvez signer plusieurs certifications, un par facteurie. Et vous savez, quand vous vérifiez le certificat, la chaine des factures est arrivée. Et finalement, nous avons le certificate de l'application, ce qui est signé par la ferme, et ce qui est utilisé pour vérifier la ferme de la fente. Et ceci peut aussi être multiplié. Dans la facteurie, vous pouvez signer plusieurs certifications, un par facteur. Et de cette façon, vous savez de quelle ligne de production votre ordinateur est arrivée. C'est le transfert de responsabilité. Donc, c'est le rationale de l'exemple qu'on a choisi. Maintenant, nous allons voir comment ça fonctionne sur le côté de l'SBSF. Donc, premièrement, un cas de utilisation sécuritaire. Donc, nous avons notre STSA sur le côté gauche, notre STM32 sur le côté droite. Nous sommes en train de tourner l'OTN, l'SBSF prend la fin. Il déploie des STSAs par la chaîne de l'AISQC de la route CA et de l'OMCA. Donc, ces certifications ne sont pas secrets, mais elles sont restées en STSA pour assurer leur intégrité. Nous combinons cela avec l'intermediate CA et la certification de l'AISQC qui a été installée dans l'actif firmware. Donc, dans le STM32 flash. Donc, quand nous avons fait ça, nous avons une chaîne de certifications. Nous vérifions cette chaîne de certifications. Donc, pour vérifier la chaîne, nous utilisons l'AMBED TLS sur le site STM32. Mais chaque fois, nous avons besoin de vérifier une signature, une signature élyptique de cryptographie. Nous l'offlions au STSA. Finalement, nous décidons que nous pouvons entrer cette certification de firmware. Donc, nous utilisons la clé publique qui est offerte par cette certification pour vérifier l'image de la firmoire. Donc, encore une fois, nous faisons une check de signature. Nous vérifions la signature de la firmoire grâce au STSA. La utilisation de la utilisation de la firmoire sécuritaire sera très similaire. Donc, quand nous recevons une nouvelle firmoire pour installer, ce que nous faisons c'est que nous récupérons le STSA, la route CA et l'OMCA. Cette fois, l'intermédiaire de CA et la certification de l'AMBED TLS qui signifie que la firmoire image est venu de l'image, de la firmoire élector. Nous faisons la vérification de la signature pour chaque élément de la chaîne avec STSA. Une fois que nous avons vérifié la chaine de certification, nous savons qu'on peut entrer la firmoire publique. Et nous utilisons cette firmoire publique pour vérifier l'authenticité de l'image que nous recevons. Et encore une fois, la vérification de la signature est performée par STSA. Donc, nous convaincons seulement les publics. Nous n'en faisons aucun secret. Donc, cela relaxe les constraints sur le côté de la devise sur le STM32. Maintenant, nous allons avoir un look sur le STM32 et le STSA110 de l'intégration. Donc, c'est le top-view. SBSFU contient une clave sécuritaire. Cela se débrouille dans la pièce de la firmoire de l'STM32. Donc, cela est segregé du reste de la softwares. L'envers de la softwares se débrouille dans l'envers de la firmoire. Dans cette firmoire, nous allons débrouiller la clave osmale et la clave osmale qui sera utilisée pour communiquer par la channe de l'A2C avec le STSA110. Et dans l'envers de la firmoire, nous allons avoir le KMS débrouillant. Et ce KMS sera considéré comme un token externe. Donc, le STSA110 et le STM32 sont considérés comme un seul token. Cela signifie que, typiquement, avec une initialisation, vous initialisez les deux STM32 KMS et le STSA110. L'application n'est qu'une seule token. Vous n'avez pas de carence pour les routiers. Nous routierons au STM32 ou nous routierons au STSA, basé sur les demandes et les capacités du token. Mais tout ce logique est implémenté dans le KMS. Vous n'avez pas de carence pour vous. Vous avez un token, vous n'avez pas de carence si le STM32 fait le travail ou le STSA fait le travail. Le KMS sera considéré comme un seul token. Donc, le KMS routier. Donc, comme je l'ai dit, le STM32 et le STSA110 sont considérés comme un seul token. Il est possible de combiner les opérations offertes par le STSA, typiquement l'éleptique de la cryptographie et les opérations offertes par le STM32, typiquement le H, le SHA256. Donc, le STSA110 est un élément sur le hardware certifié. Donc, le STSA signifie la check en génération et le STM32 pour l'opération H. Le routier est statique. Il n'y a rien de très complexe. Il est basé sur un switch en compiler. Donc, si vous avez un look à l'advocat, vous trouverez dans le KMS un switch appelant KMS X Token Enable. Donc, vous savez que quand ce switch est présent sur Enable, vous pouvez faire le routier pour le STSAF quand il est nécessaire. Pour chaque opération, il y a un défi acheté et si il y a un défi acheté, ça signifie que le STSAF peut être utilisé. Ensuite, le routier sera basé sur le object Enable qui est donné au KMS. Donc, selon le object que vous utilisez pour votre opération, il va aller sur le STM32 ou il va aller sur le STSAF. Et le routier est par service. Donc, vous pouvez trouver ce routier sur le KMS entry.C level. Donc, vous n'avez pas besoin de digérer très profondément sur le KMS intrin 6. Juste le KMS entry.C vous donne l'information est-ce routier sur le STM32 ou est-ce routier sur le STSAF. Donc, c'est bon d'avoir un élément sécurisé mais c'est plus important d'avoir une communication sécurisée entre le STM32 et le élément sécurisé. Pour faire ça, nous utilisons une chaîne sécurisée sur l'AIS2C.C. Donc, pour cette chaîne sécurisée sur l'AIS2C, nous avons besoin une maquille pour authentiquer la communication et une maquille de hausse. Donc, ces maquilles sont portées dans le hall de feu sur le STM32 et sont aussi présentes dans le STSAF.C. Merci à cette maquille, nous pouvons avoir une communication sécurisée. Donc, comment ça fonctionne ? C'est basicement un set de messages TLV. Nous avons un code command, un type de maquillage. Nous avons la maquille de la maquille et la valeur de la maquille sentée par le STM32 sur le STSAF. Ensuite, nous avons un MAC pour authentiquer le message. Et enfin, un CRC pour assurer l'intégrité. Bien sûr, certains commandes ne sont pas nécessaires pour la sécurité et, en ce cas, ils ne sont pas encryptés et vous n'avez pas le CMAC. Donc, chaque fois vous builde un commande, vous indiquez si vous voulez être encryptés ou si vous voulez être authentiqués. Comment fonctionne le code ? Vous recevez un request KMS dans le projet SECorbin, ce qui est le code en train dans le hall de feu. Vous allez au KMSxTokenSTSAF.C, chaque fois que vous communiquez avec STSAF. Vous utilisez le STSAF middleware, STSAFACore.C. Dans le STSAFACore.C, vous vous indiquez la communication. Donc, vous utilisez STSAFACrypto.C, qui relient aux services offerts par SECorbin. Ces services vous permettront de encrypter le message et de calculer pour compter le CMAC. C'est basé sur le STCryptoMiddleware, mais dans notre cas, nous avons implémenté des rappeurs et tous les calls sont redirectés à MBTLS. C'est pour éviter l'embaiement de l'institut STCryptoLibrary parce qu'on aurait besoin de signer des contrôles exportaux et nous ne voulons pas avoir des contrôles exportaux dans notre package IoT Cloud. Quand ceci est terminé, vous utilisez STSAFACervice.C, qui utilise un interface offert par SECorbin pour utiliser l'I2C. C'est très simple et nous utilisons les clés pour communiquer. Donc, en passant par KMSXtock et STSAF.C, en passant sur le STSAF Middleware, en passant sur le cryptopart pour encrypter tout et en passant sur le service part pour l'I2C en ligne. Donc, certifications sur le storage. Donc, comme je vous l'ai dit, nous avons une chaine de certifications pour le SBSFU pour garantir l'image de la ferme, l'application. Donc, nous avons un set de batchscript qui nous permet de créer cette certification. Donc, ce n'est pas une vraie route CA. C'est une faite one créée par cette scripte. C'est la même chose pour le SBSFU, le SBSFU et le SBSFU. Mais ils sont valides. C'est juste que ce n'est pas une vraie route CA. Le SBSFU et le SBSFU sont en passant sur le STSAF.C, dans ce qu'on appelle les zones CA.C. Vous pouvez le voir ce genre de file storage, un file secure storage. Et la clé osmice et la clé cipher sont allés à l'application du slot STSAF. Tout ceci est implémenté grâce à un projet appelé STSAF Provisionning. Ce projet STSAF Provisionning est utilisé des clés de code d'art. Donc, pour une vraie implémentation, pour une vraie déploiement sur le fil, vous devez diversifier ces clés. Le projet est capable de diversifier les clés. Mais le problème est que nous avons un file STSAF qui est statique, STSAF PairingKiss.bin qui est utilisé par le SBSFU pour placer ces clés dans le sceau secure dans le fil. Donc, parce que ce n'est pas si facile de faire la diversification. C'est quelque chose que vous devez garder en compte. Ensuite, notre OEM Intermediate Certificate et le Live Certificate sont un package avec la ferme dans le bundle que nous appelons le file STSAF. Tout ceci est fait par le SBSFU projet. Nous reviendrons de suite. Donc, si nous voulons avoir une overview de la vérification de la ferme avec le SSAF A110 pour avoir notre bout secure ou notre update ferme de sécurité, c'est nous qui travaillons. Nous loadons la route CA et l'OEM Certificate du SSAF A à notre 32 ram. Ensuite, nous prenons l'OEM Intermediate et le Live Certificate et l'OEM Le Live Certificate de l'activité active et de l'aide de la ferme et nous vérifiquons la chaine certificante avec MBET TLS. Mais, le SSAF A110 est offloadé sur le SSAF A. Et enfin, nous vérifiquons le SSAF A110 sur le software et l'application et les SSAF A110 sont routés sur le SSAF A. Ceci est utilisé par le SSAF A110 et un élément C'est important de savoir que pour la région de performance l'aide de la chaine certificante et l'aide de l'aide sont compétuites et ne sont qu'une. Cela signifie que quand nous voulons vérifier et vérifier l'authenticité de la ferme, nous n'avons pas besoin d'aller sur l'éleptique cryptographique, parce que c'est assez costel, donc nous comparons la geste avec l'une qu'on a installée. Alors, j'ai dit que nous avons un SSAF A provisioning project. Vous devez être aware que ce projet contient par défaut des clés d'art-coded qui ne sont pas diversifiées. Donc, ce besoin doit être diversifié par l'application pour la production, parce que vous devez couper un SSAF A avec un STM32. Si vous utilisez toujours la même clé, vous arrêtez la sécurité. Le projet permet de l'indomisation d'utiliser les clés. Donc, c'est bien, mais malheureusement, nous avons des clés d'art-coded qui sont statiques. Donc, c'est un travail que vous devez faire quand vous voulez faire le déploiement. Ce n'est pas donné par le package. Nous utilisons le certificate d'art-coded, le SSAF A et l'OMCA, qui sont les mêmes pour tous les modèles. Mais cela peut être très acceptable parce que le SSAF A est toujours le même. Le SSAF A est l'auteur de tous les modèles. Donc, nous pouvons avoir toujours les mêmes modèles. Donc, vous pouvez le garder. Vous devez juste mettre le SSAF A et le SSAF A et le SSAF A de votre customeur. Le projet doit être mis en place pour réunir le SSAF A. Donc, souvenez-vous, le SSAF A vient de réunir avec les assets TLS qu'on doit connecter à l'USA. Toutes les assets de la SSAF A qu'on doit authentiquer dans l'image pour avoir un bout sécurisé, sont réunis grâce à ce projet de réunir le SSAF A. Donc, cela va tourner les certifications de SSAF A. Seuls les certifications de l'adresse et de l'adresse privée sont pré-provisionnées. Donc, si nous avons un look sur le système de construction des SSAF A, c'est pas très différent de l'un que nous avons dans le package de la SSAF A. C'est le même principalement. Il n'y a seulement deux spécificités concernant l'artif de sécurité. Les quies ne sont pas la même. Les quies que nous provisions à la stage pré-build et la clé MacCypherKey pour communiquer avec STSF-A. La compilation de l'SBSFU est la même, et à la post-processing, nous utilisons les certificats injectés dans l'aider de la firmoire pour être updates. Donc, les certificats intermédiaires, les certificats lieux, ils sont injectés à la stage post-bill et nous créons le userapp.sfb avec ces certificats qui nous permettent de authentiquer la firmoire.