 Maintenant que vous avez eu une belle overview de ce qui est un manager de sécurité et ce que vous pouvez faire avec ça, nous allons aller à un autre très important et fort feature de la STM32 H5, que nous appelons « Debug Authentication ». Alors, commençons. Le propos ici est de clarifier ce que est l'authentication de Debug dans des détails. Et montrer comment l'AIS peut aider le client dans l'analysation du fil de retour. Alors, allons-y dans les détails. Nous avons maintenant construit notre produit. C'est sur le fil, c'est bien travaillé, mais pour quelques raisons, certains détails sont revenus, parce que quelque chose ne marche pas bien. Le client a retourné le produit à la team de soutien. Donc, le soutien doit analyser cet ordinateur. Qu'est-ce qu'il peut faire ? D'abord, pour commencer, nous allons revenir sur ce que l'a été la provision dans le produit. Vous êtes maintenant utilisé pour cette pièce. Et ces secrets OM, sur les secrets autres que nous avons ici, nous avons la provision de route publique dans le format électrique et la masque de permission. Cela a été fait par défaut. Et cette pièce de route publique est située dans la direction de l'authentication de débug. Maintenant, qu'est-ce que nous pouvons faire ? Nous pouvons réopérer le debug. Pour réopérer le debug, c'est vraiment d'un close-device, pour pouvoir réopérer le debug, pour pouvoir analyser le device. C'est une nouvelle feature de STM32. Pour faire cela, évidemment, nous avons besoin d'authentiquer nous-mêmes, pour que le device soit réopéré. Et pour cela, nous avons besoin de deux choses. Nous avons besoin d'une chaine de certificat et de l'association privée de l'ECCI, pour prouver votre identité. Alors, nous allons le faire, et nous expliquerons un peu plus en détail plus tard. Nous avons notre device qui est close, et nous voulons réopérer le debug. Nous allons le faire directement de l'interface STM32 Q by D. Alors, nous allons simplement dans la configuration de debug, comme ça. Debug As, et l'opening de la configuration de debug. Ici, vous avez votre configuration de debug pour l'ECCI. La première chose à faire, c'est d'aller au tab de debugger. Juste un petit peu en bas. Et ce que nous voulons faire, c'est d'attacher à un target de roulage pour voir ce qui se passe. Donc, nous ne voulons pas performer d'une récente, juste comprendre où l'issue s'occupe. Donc, essayez de comprendre où le compteur de programme est roulant. Et nous avons besoin aussi d'enlever l'authentication de debug, ici, à l'aide de la clé, donc la clé de route et un certificat. Donc, s'il vous plait, choisissez l'application et allez à votre projet. Donc, encore une fois, avec votre shortcut, allez au projet de roulage, et allez à la clé de route, et ensuite, vous pouvez sélectionner la clé privée. Donc, la clé de route et pour le certificat, vous avez besoin d'appliquer. Juste aller au projet, aller au certificat et sélectionner la clé privée. Et la dernière partie est de aller à la clé de roulage et éditer la configuration, juste pour éviter d'enlever l'authentication de l'authentication de la clé. Nous voulons juste voir et ne modifier rien. Ensuite, vous pouvez lancer le debug. Et vous verrez que le STM32 QBID va réopérer l'application grâce à la clé de route qu'on a offert. Donc, pour prouver que nous sommes autorisés à ouvrir l'application. Et nous devons juste être dans un état de roulage. Donc, ici, nous sommes attachés à l'application, mais vous pouvez voir que nous ne sommes pas arrêtés. Donc, nous pouvons suspendre. Et nous savons que, où l'application était en train, et nous pouvons analyser ce qui s'est passé. Donc, vous pouvez voir que, à partir d'un état de roulage, nous pouvons réopérer l'application, voir où nous sommes et analyser sur l'application. C'est l'advantage principale de l'application de l'application de debug. On va retourner au slide. Nous avons fait tout ça. Nous avons vu que nous pouvons réopérer l'application de la clé de route qu'on a offert grâce à l'application de debug. Donc, nous allons voir maintenant dans les détails comment cela fonctionne. Juste un souvenir de l'application du product. Nous avons déjà vu l'application de l'application de l'application de la clé de route qu'on a offert. Donc, ce sont les deux que vous savez. Et ici, vous pouvez voir que nous avons deux autres détails. Et le principal qu'on est adressant ici est le état de provision. Donc, c'est un état pour provisioner les clés d'OB. C'est l'option de clés d'OB, je dirais. C'est un état de provision secure à l'intérieur de la STM32 H5. Ce n'a rien à faire avec le manager secure. C'est indépendant de le manager secure. Nous avons vu le état de provision entré dans le manager secure. Ici, l'option de clés d'OB est un état de provision secure attaché à la STM32 H5. Et pour l'application de l'application d'OB, nous ne allons pas parler de ça aujourd'hui. C'est un autre état, un autre état de product. La façon dont vous pouvez voir que, d'un état ouvert, nous avons besoin d'aller dans l'application d'OB ou de l'application d'OB avant d'aller directement dans l'application d'OB ou de l'application d'OB. C'est une chose importante, c'est que, pour éviter l'application de l'application d'OB, nous avons besoin de provisioner les informations nécessaires pour réopérer l'application de l'application d'OB. C'est l'un des propositions de cet état de provision, d'un état de provision secure dans l'application d'OB. Et l'authentification de l'application d'OB est un mécanisme qui permet de réopérer le dévice. C'est donc l'intention de l'application d'OB que nous avons juste vu avant. Et ça peut aussi donner l'objet de faire une régression non-secure, de revenir dans l'intention de l'application d'OB ou de la régression de l'application d'OB. C'est donc l'application de l'application de l'application d'OB ou de l'intention de l'application d'OB. Donc, comme nous l'avons dit, nous avons besoin de provisioner l'application d'application d'OB avec un outil public et d'application de l'application d'OB. Et ensuite, nous avons besoin de créer un certificat pour pouvoir l'authentifier et réopérer. Donc, juste pour vous donner ce que veut dire une régression, c'est tout de suite de l'authentication de l'application de l'application d'OB. Si vous vous autorisez à le faire, vous arrêtez tout. Donc, la régression est une façon de revenir à un ordinateur virgin sans rien dans l'application d'OB. La régression parciale ou la régression non-sacredite est en train d'arriver seulement sur le côté non-sacredite et de garder tout sur le côté non-sacredite. Donc, vous pouvez downloader l'application non-sacredite et faire des tests. La provisioning doit être faite dans les états de provisioning, et c'est comme ça que ça fonctionne. Nous avons un file XML qui contient le lien à la clé de route que nous voulons provisioner et la masque de permission. Nous avons ce créateur de l'application entrée qui est construit dans un file binary avec un format spécifique qui est recognisé par le programmeur et qui est recognisé spécialement par le target pour être provisioné dans le storage secure, dans le storage obéquis. Une fois la provisioning, vous pouvez ouvrir le device et réutiliser ça pour réopérer et nous verrons comment ça fonctionne. La masque de permission de stock, c'est un masque un peu à propos de la capacité de l'application. Vous pouvez donc garantir une capacité de réagression, un mode secure, un mode non-sacredite avec différents niveaux. Donc, ce qu'il faut faire, c'est de faire une authentification de débug. Comme vous pouvez le voir, nous avons besoin d'un clé de la masque privé et d'un certificat d'application qui s'embête du clé public correspondant à ce clé privé et d'un masque de permission associé à ce certificat. Donc, par exemple, ce certificat permet seulement de réagir non-sacré, de réagir partial parce que tous les bêtes sont prêts à 0. Cela signifie que si vous avez ce certificat, vous pouvez seulement faire cela, vous ne pouvez rien faire. Pour générer un certificat, donc, nous allons aller plus en détail. C'est un principe générique du certificat qui contient un clé public et qui est signé avec un clé privé. Le format de ce certificat, ici, n'est pas un format standard, c'est un format défini par l'accessibilité d'armes à dac. Et ce certificat est beaucoup plus simple et nous avons utilisé un créateur d'armes à générer ce certificat. Vous pouvez voir que nous pouvons avoir un type certificat. Ici, nous voulons générer un certificat de route. Nous devons donner un masque de permission pour ce certificat, donc les capacités de ce certificat. Et, à l'input, nous devons aussi donner un clé public. Le clé public ici est le clé public de route parce que nous voulons générer le certificat de route. Et comme c'est le certificat de route, c'est autosigné. C'est-à-dire que nous avons utilisé le clé privé associé correspondant au clé public pour signer le certificat. Donc, la signature est générée par cette clé. Et cela signifie aussi que, pour pouvoir vérifier que la signature est correcte, nous pouvons utiliser ce clé public ici. Donc, c'est le principe du certificat autosigné. Et pour faire notre authentification de débug pour la régression partielle, comme l'exemple que nous avons juste présenté, nous avons besoin d'un PC avec un programmeur qui a le clé privé et le certificat de route. Nous avons un premier secteur qui est le step d'authentification. Si cela passe, nous pouvons demander l'action. Donc, la seule action possible ici est la régression partielle. Et donc, nous venons de retourner aux clés, en gardant toutes les parties sécurisées. Donc, ici, nous n'avons pas de restriction sur les capacités. Cela signifie que, comme nous avons le clé privé, nous venons de retourner aux clés précédents. Comme nous avons le clé de route, nous pouvons générer un certificat avec un masque de permission. Donc, cela signifie que nous n'avons pas de restriction sur les capacités. Nous pouvons maintenant contrôler les capacités d'authentification de débug en utilisant un certificat de route. Donc, le certificat de route signifie que c'est la chaine de route de route. Et nous verrons juste après cela comment nous pouvons générer un certificat de route. Et puis, avec un certificat de route, nous limiterons les capacités parce que vous avez un clé privé ici, mais vous ne pouvez pas générer ce certificat avec ce clé privé. C'est la différence principale. Donc, ici, ce que nous avons dans nos firmes cubes, nous avons, vous pouvez voir dans l'exemple de la DA. Donc, quand nous avons regardé les clés, nous avons trois clés qui sont offerts par défaut. Donc, ce sont le clé 1, le clé 2 et le clé 3. Et le clé 1 est le clé de route. Le clé 2 est pour un step intermédiaire et le clé 3 est pour le plafond. Donc, un moyen de voir c'est d'avoir un équipe de sécurité qui a les clés de route. Donc, ils peuvent faire tout. Vous avez un équipe de projet qui a le clé 2. Donc, le clé 2, ce projet a la capacité de générer un clé certificat pour différents équipes avec des possibles capacités différentes. Et aujourd'hui, ce qui est offert par défaut est que les capacités sont les mêmes pour tout le monde. Donc, la capacité totale. Nous pouvons faire une régression, une régression partieale et une réopené de débug authentication. Donc, pour générer une chaine de certificat, nous avons déjà vu comment générer notre certificat de route qui est signé par notre clé de route et qui est offert par le clé de route publique. Donc, nous avons notre certificat et nous avons notre équipe de sécurité et nous avons notre équipe de projet. Le clé de route publique a besoin de générer un clé de route publique, donc clé publique, clé privé et a besoin de donner ce clé publique à la équipe de sécurité pour générer un certificat d'intermédiaire. Donc, ici, le clé de route publique, qui est sélecté dans le certificat d'intermédiaire, nous avons décidé quelles sont les permissions pour les équipes de projet. Nous utilisons leur certificat de route pour la chaine et nous utilisons la clé de route publique pour signer ce certificat. Donc, ici, le clé d'intermédiaire de second niveau de certificat qui contient le clé publique et la permission offerte ici est signée par la clé de route publique. Donc, les certificats d'intermédiaire dans la chaine sont maintenant signés avec ce clé de route privé, le certificat d'intermédiaire et le clé d'intermédiaire. Ensuite, dans le troisième niveau, le clé de projet est maintenant capable de créer un certificat pour l'équipe de développement. Et ici, vous pouvez voir, nous avons un type de certificat d'intermédiaire. Cela signifie que c'est un certificat qui peut être utilisé pour réopérer un dispositif. Préviément, le certificat d'intermédiaire donc ceci ne permet pas de réopérer un dispositif. Vous avez besoin d'un certificat d'intermédiaire pour le faire. Mais maintenant, avec le même mécanisme, le équipe de développement doit créer leur propre clé d'intermédiaire à propos de la clé publique à l'équipe de projet. Le clé de projet va générer un certificat, un certificat d'intermédiaire avec un certificat d'intermédiaire associé à cet équipe. Ils utilisent la clé d'intermédiaire pour mettre dans la chaine finale. Et ils utilisent leur propre clé privée pour signer le certificat d'intermédiaire. Donc maintenant, vous avez un certificat d'intermédiaire contenant le certificat d'intermédiaire, le certificat d'intermédiaire de l'équipe de projet et le certificat d'intermédiaire dedicé à l'équipe senior. Donc, c'est l'overview de comment tous les certificats sont générés. Ensuite, quand nous utilisons l'authentication de débug, l'équipe senior va présenter leur clé privée et le certificat d'intermédiaire pour pouvoir débugger l'authentication de débug sur le target. Donc aujourd'hui, ce que nous avons est exactement ceci. La clé d'intermédiaire, le clé d'intermédiaire et le clé d'intermédiaire avec un certificat d'intermédiaire et un certificat d'intermédiaire et un certificat d'intermédiaire. Donc, c'est ce que nous avons par défaut dans notre projet. Donc, ici sont les clés et le certificat. Donc, le certificat d'authentication de la chaine d'intermédiaire et de la chaine de débug. Vous pouvez voir qu'il y a d'autres ici, mais ils ne sont pas utilisés et ne sont pas utilisés. Régardant le masque d'intermédiaire, vous pouvez voir que vous pouvez provider le masque d'intermédiaire à chaque niveau de certificat. Donc, à niveau 0 pour la route, à niveau 1 pour l'intermédiaire, à niveau 2 pour le certificat d'authentication de débug. Et donc, on est capable de restreiter progressivement les capacités de la certificat. Donc, par défaut ici, tout est possible. Vous pouvez faire la régression et ouvrir le débug. Donc, avec le clé 3 et le certificat, nous pouvons faire chaque régression, débug secure et débug non-secure. En détail, comment ça fonctionne ? Vous êtes le team de développement et vous voulez performer l'authentication de débug. Vous utilisez votre propre clé privée et le certificat, le chaine de certificat de débug qui est donné par votre team de projet. Le programme cube commence par découvrir ce qu'il y a sur le dispositif et obtenir des informations sur le dispositif pour pouvoir performer le next step. Donc, le next step est de provider le chaine, le chaine de certificat de débug. Et le dispositif avec ce chaine de certificat est, premièrement, capable de checker la route publique parce que nous avons donné la hache de la route publique quand nous avons prévenu le dispositif dans le premier endroit avec aussi un target SOCMASK. Donc, ici, la firmoire de débug authentication qui est dans le système flash commence à vérifier si la route publique certifiée match la route publique qui a déjà été prévenu. Cela permet de croire cette clé et parce qu'avec cette clé nous pouvons checker la signature du premier niveau. Donc, nous pouvons checker le premier niveau de le certificat. Quand le premier niveau est checké, nous pouvons croire la clé publique et aussi la clé certifiée niveau 0. Et nous pouvons utiliser ensuite cette route publique pour vérifier le second niveau de la clé certifiée parce que la clé intermédiaire était aussi signée avec la clé private. Donc, nous pouvons utiliser la clé publique pour vérifier cette signature. Et ensuite, nous pouvons croire la clé intermédiaire publique parce que la signature du second niveau est ok. Et ensuite, comme nous croisons la clé publique 2, comme nous pouvons checker la signature du certificat de la clé certifiée qui était signé avec la clé route 2. Sorry, la clé privée 2. Donc, ici nous pouvons vérifier la signature et croire le contenu de la clé certifiée. À ce point, nous avons fait l'authentification process et nous pouvons croire que cette clé certifiée est authentique. Mais nous avons besoin une autre étape parce qu'une clé certifiée est quelque chose qui est publique. Nous avons besoin d'assurer que la clé certifiée ait aussi la clé privée qui correspond à la clé publique 3. Et pour faire ça, la clé embédée de software génère une valeur normale retourner au programmeur et le programmeur signifie cette valeur en utilisant cette clé privée et renverser à l'application et la clé qui croit la clé publique 3 peut vérifier la signature de la valeur normale. Et si la signature est correcte, cela signifie que l'auteure de la clé certifiée est l'auteure est le bon auteur donc l'un qui a la clé privée et maintenant que la procédure d'authentification est faite, vous pouvez réquester une action et le software va vérifier que la action est consistante avec ce qu'il y a dans les masques de la permission et on va performer la action et envoyer le status. Et donc la masque de la permission nous avons besoin d'une action réquestée à l'une. C'est tout le même le même position dans chaque certificat de la masque de la permission est aussi l'une. Si c'est le cas, donc la action réquestée est performée. Donc donc on va essayer d'y mettre en pratique et on va dire que nous avons une nouvelle équipe junior nous voulons présenter des capacités sur le produit. Donc la équipe junior doit créer une équipe junior pour exemple doit créer une compagnie pour présenter à l'équipe junior la clé publique pour obtenir un certificat. Pour exemple, l'équipe junior ne veut pas remettre le manager de sécurité sur la plate-forme et ne permet de débarter dans un état clos. Donc nous voulons juste remettre ces capacités juste pour pouvoir faire une régression non-sécure. Donc nous voulons donner un certificat qui limite l'équipe junior pour la sécurité. La régression. Donc pour faire ça le même processus la équipe junior génère leur équipe. La clé publique est donnée à l'équipe junior pour être incorporée dans le chaine certificat. Donc ensemble avec la masque de permissé donc nous avons notre génération de certificat livre la masque de permissé pour l'équipe junior le certificat intermédiaire et tout ça sera signé avec la clé privée de l'équipe junior. Et sera envoyé à l'équipe junior donc l'équipe junior retient ce certificat qui est signé par les clés privés de l'équipe junior. Donc pour mettre ça en pratique nous avons créé la clé pour vous donc la clé 4 et s'il vous plait juste copier ça de votre de l'équipe junior à votre projet. Donc je vais le faire. Donc je reviens à l'équipe junior ici timestampévent détection route provisionie DA et ici sont les deux clés. Donc je copie les clés et reviens à mon projet hands on timestampévent détection route provisionie DA clés et je peste les clés ici. Ok et maintenant nous allons utiliser créateur de l'équipe junior STM32 créateur de l'équipe junior créateur ici c'est donc premièrement aller à h5 et vous verrez beaucoup de choses que h5 est capable de faire ici nous sommes intéressés dans une authentification de débug certifié génération nous sélectionnons aujourd'hui seulement h5 supporte cette feature et nous voulons générer le certificat de vie donc ici nous sommes le projet team j'ai sélectionné l'issueur est intermédiaire donc clé pour clé privé nous devons donner la clé publique donc ici clé publique juste pour reminder ce que nous voulons faire ici c'est le ce qui s'appelle la clé privé issueur et c'est ici la clé publique ok et nous devons aussi mettre le certificat pour la chaine donc c'est le certificat intermédiaire que nous allons mettre dans le certificat final donc ici j'ai ouvert revenu prévu le directeur et donner la chaine intermédiaire puis ici si je le mets la chaine intermédiaire vous pouvez voir par défaut nous avons des zeroes ici quelqu'un ici et nous voulons seulement donc je presse ici pour changer au zéro nous voulons ici le certificat pour seulement autoriser la régression partielle donc c'est ce que c'est fait ici et puis nous devons donner l'outil de la certificat donc ce que je vais faire c'est de copier le pass ici que nous avons ok copier et paste donc nous sommes dans le certificat et je vais le dire junior team certificat dot b64 et je génère le certificat ok leave certificate successfully chaine si je reviens au directeur dans le certificat vous pouvez voir maintenant junior team certificate chaine ce qui a été généré donc si je reviens au slide ici vous avez les détails pour le faire par vous-même c'est juste ce que nous avons juste fait ok donc maintenant junior team peut faire une régression partielle donc faisons-le avec le manuel avec le STM32 code programmer donc je vais utiliser le code programmer donc précédemment nous avons utilisé pour ouvrir l'application maintenant nous devons aller à ce schild menu donc je vais le mettre dans la full screen et cliquer sur DA pour l'authentication débug et discover donc ceci est le premier step et ici on peut voir que nous ne pouvons pas communiquer avec le dispositif parce que nous sommes toujours connectés avec le Q by D donc je termine ici donc nous avons élevé le link débug et je reviens au code programmer et je peux lancer le discover et vous pouvez voir que durant le discover nous pouvons lire des informations et une très intéressante information est le device unique ID des versions et des states ici et aussi un statut de provision que c'est important et ici vous pouvez voir que nous sommes dans le lifecycle de PSA ça veut dire que nous n'avons pas dans un state clos nous avons laissé notre device dans un state débug et nous pouvons nous avons cette spécifique bouton pour ouvrir le débug donc ce qui veut dire que nous sommes dans une sorte d'intermedié state où le débug est ouvert mais si vous switch off le device donc si vous retirez le pouvoir et portez le ton alors il sera clos de nouveau mais dans un certain défi vous ne pouvez pas switch off par exemple un défi pour la batterie vous ne pouvez pas remettre facilement la batterie parce que c'est soldé ensuite nous avons ce bouton qui fait la même chose que si vous faites un poursage sur le reset donc j'ai pressé ici un débug fermé le target est successement locké si je découvre vous pouvez voir que nous sommes maintenant dans le lifecycle de la device fermé donc nous sommes back dans un state clos et ensuite ce qu'on veut faire c'est d'utiliser le certificat que nous avons juste créé donc en revanche ici nous sélectionnons le pass de clé donc le clé que nous avons besoin d'utiliser pour l'authentification débug est le clé privé donc nous allons ouvrir le clé privé donc revenons à notre projet hands-on et route provisione d'a clé et nous avons besoin ici k4leaf.bem ce qui est notre clé privé et pour le certificat encore sélectionnons votre hands-on route provisione d'a et certificat et ici nous utilisons le certificat junior team ce qu'on a juste utilisé donc maintenant nous avons notre clé privé et certificat nous pouvons l'interface nous demande de continuer à sélectionner une action pour faire donc nous préparons ce qu'on veut faire avant de faire quelque chose et ici nous allons essayer de faire une pleine régression et normalement nous avons si je reviens pour l'authentification débug créateur ici pleine régression n'est pas autorisé pour ce certificat donc nous allons essayer de le faire exécuter donc j'ai pressé j'ai déjà pressé ici l'interface ne montre pas que c'était pressé mais vous pouvez voir que il a failé donc l'authentification débug a fail parce que ce certificat n'a pas le droit de réopérer le dispositif donc nous allons le faire encore donc nous avons déjà notre certificat de leave notre certificat de team junior notre certificat de team junior donc ceci est déjà fait puis essayez de faire une pleine régression donc ici nous sommes maintenant autorisés pour faire ça si vous exécutez la pleine régression devrait travailler le succès de l'authentification débug ok vous pouvez vérifier avec les options ici le state nous sommes maintenant dans la pleine régression débug donc nous venons de la pleine régression débug nous avons fait une partie de la régression donc nous avons évoqué tout ce qui est non sécurisé et nous sommes revenus dans la pleine réunion débug donc vous pouvez voir que automatiquement un programmer est connecté donc nous pouvons déconnecter et vérifier avec le découvert aussi le state et nous sommes dans la pleine réunion débug la pleine débug donc la même information nous allons retourner aux slides donc nous devons voir exactement ce que nous avons fait ne devons pas retourner trop vite donc nous avons eu ce cycle de vie inconnu et donc nous nous avons fermé le débug jusqu'à la pleine réunion débug et ensuite nous avons utilisé notre quai pour la pleine réunion et la pleine réunion débug que nous avons créée et nous essayons d'abord de faire la pleine réunion débug mais ici nous pouvons faire la pleine réunion débug qui fonctionne et nous pouvons vérifier et nous avons essayé de l'autoriser aucune action de l'autorisation sera résultée dans cette authentification faible donc maintenant nous avons fait ceci juste avec l'autorisation débug que pour cette pleine débug nous devons faire seulement ceci donc maintenant pour finir cette pleine réunion débug nous allons faire une pleine réunion débug donc nous devons retourner au programme cube et faire la même chose mais avec la pleine réunion débug et le certificat le certificat défaut qui permet de faire tout donc ici donc nous utilisons k3 en case en lieu d'un k4 et pour le certificat nous avons utilisé le certificat la pleine réunion débug continue et fait une pleine réunion débug exécutée et après cette exécuté l'autorisation débug est faite nous pouvons vérifier donc nous sommes connectés donc nous pouvons vérifier ici dans le state de produit que nous sommes dans un state ouvert et ici que si nous readons le contenu de la pleine la pleine est arrêtée et la même chose avec l'autorisation débug nous pouvons découvrir dans un state ouvert et voir la pleine réunion débug ici c'est et donc ici nous nous avons arrêté tout donc dans la conclusion nous vous pouvez avoir ici un overview de ce très fort nouveau feature de STM32 H5 avec l'utilisation de certificats qui permettent de trouver le contrôle sur ce que l'utilisateur peut faire et grâce à la re-opening débug de l'autorisation débug de l'autorisation débug de l'autorisation débug permet de faire un filéreté de l'analysie dans un moyen sécuritaire merci pour votre attention