Tirer parti du premier microcontrôleur basé sur Arm® Cortex®-M33 du marché – 2e partie : gestion de la sécurité du cycle de vie

Note de l'éditeur : la 1re partie de cet article en deux parties explique comment optimiser le microcontrôleur à usage général LPC55S6x de NXP Semiconductors pour de hautes performances à basse consommation. Cette 2e partie montre comment optimiser ce même microcontrôleur pour la gestion de la sécurité du cycle de vie.

Pour les développeurs de systèmes basés sur microcontrôleurs, l'étendue des exigences de conception pour les applications à croissance rapide telles que l'Internet des objets (IoT), l'automatisation industrielle ou l'électronique personnelle, implique trop souvent un compromis entre les fonctionnalités du système, les performances et la consommation énergétique. Face aux menaces de sécurité croissantes, la nécessité de renforcer la sécurité dans ces conceptions constitue un défi supplémentaire qui peut laisser les développeurs avec encore moins de solutions de microcontrôleurs viables. Les développeurs ont besoin d'un microcontrôleur capable de prendre en charge les exigences plus familières de hautes performances et de réduction de la consommation, mais également les demandes croissantes pour une sécurité dans toutes les phases du cycle de vie de conception, y compris le provisionnement, les communications, l'amorçage sécurisé, les mises à jour micrologicielles sécurisées, et plus.

La 1re partie a présenté les microcontrôleurs LPC55S6x de NXP et montré comment leurs fonctionnalités répondent aux exigences de performances et de basse consommation. Cette 2e partie explique comment les fonctionnalités de sécurité étendue intégrées dans les microcontrôleurs LPC55S6x prennent en charge la sécurité tout au long du cycle de vie, du provisionnement et des communications au démarrage sécurisé et aux mises à jour micrologicielles sécurisées.

Comme décrit dans la 1re partie, le microcontrôleur à un cœur LPC55S66 et le microcontrôleur à deux cœurs LPC55S69 de NXP combinent un cœur de processeur à usage général Arm® Cortex®-M33 avec des capacités matérielles conçues pour répondre à des exigences d'applications plus spécialisées. Parmi ces capacités, les accélérateurs matériels pour la cryptographie symétrique et asymétrique fournissent les mécanismes fondamentaux requis pour des communications sécurisées. Auparavant, les accélérateurs cryptographiques étaient considérés comme suffisants pour les fonctions de sécurité de base comme la protection des données. Aujourd'hui cependant, les attentes des utilisateurs en matière de fonctionnalités de sécurité plus exhaustives ont généré des exigences plus complexes pour la sécurité du cycle de vie, du provisionnement en fabrication à la mise en service sur le terrain, en passant par l'amorçage sécurisé et les mises à jour micrologicielles sécurisées.

La réalisation de cette protection étendue requiert un ensemble complet de protocoles et de politiques de sécurité qui dépassent le niveau matériel. Néanmoins, l'efficacité des protocoles de sécurité dépend essentiellement de la disponibilité des mécanismes matériels adaptés, qui servent à accélérer l'exécution et à éliminer ou réduire les zones d'exposition aux menaces inévitables dans les dispositifs connectés.

L'architecture du LPC55S6x fournit ce type de support matériel pour la sécurité du cycle de vie avec ses nombreuses capacités, notamment la prise en charge de la technologie Arm TrustZone® et les multiples couches de protection requises pour atteindre un niveau de sécurité efficace.

Prise en charge de TrustZone

TrustZone fournit les bases pour la sécurité grâce à sa capacité à isoler l'exécution du code et les données dans des domaines sécurisés et non sécurisés spécifiques. Durant l'exécution du programme, le cœur Cortex-M33 primaire passe par plusieurs états d'exécution associés à différents modes d'exécution du code. Ces états de processeur et ces modes d'exécution du code incluent :

• Mode privilégié sécurisé, pour l'exécution du code au niveau du noyau ou des gestionnaires de périphériques
• Mode non privilégié sécurisé, pour l'exécution du code utilisateur sécurisé
• Mode privilégié non sécurisé, pour l'exécution des appels système typiques
• Mode non privilégié non sécurisé, pour l'exécution des applications utilisateur typiques

La différence entre l'exécution privilégiée et non privilégiée est extrêmement importante pour la robustesse du système d'exploitation global. Pour les besoins de cet article, cependant, nous pouvons regrouper ces modes d'exécution pour ne considérer que la différence entre le fonctionnement sécurisé et non sécurisé. Dans l'architecture TrustZone, le passage de l'état de processeur sécurisé à l'état non sécurisé invoque des limitations matérielles sur le cœur pour accéder à la mémoire programme ou aux données.

À l'état sécurisé, le cœur peut accéder aux données des régions sécurisées et non sécurisées de la mémoire, mais non au code stocké dans une région non sécurisée de la mémoire (Figure 1, gauche). À l'état non sécurisé, il peut uniquement accéder au code et aux données des régions non sécurisées de la mémoire (Figure 1, droite).

Figure 1 : Grâce à la prise en charge de la technologie Arm TrustZone, les microcontrôleurs LPC55S6x de NXP garantissent qu'un cœur fonctionnant à l'état sécurisé (S, à gauche) collecte uniquement les instructions pour la mémoire programme d'état-S, tandis qu'un cœur fonctionnant à l'état non sécurisé (NS, à droite) ne peut pas accéder au code ou aux données stockés dans la mémoire d'état-S. (Source de l'image : NXP Semiconductors)

L'architecture du microcontrôleur LPC55S6x exerce ce contrôle au niveau le plus bas de l'accès au bus, limitant les zones d'exposition aux menaces courantes, telles que les dépassements de la mémoire tampon que les pirates informatiques utilisent pour permettre à un code non privilégié non sécurisé d'accéder aux régions « protégées » par une porte dérobée. Dans le cas présent, NXP utilise une unité SAU (Security Attribution Unit) Arm TrustZone avec sa propre unité IDAU (Implementation Defined Attribution Unit) conçue pour isoler complètement le code noyau sécurisé du code d'application. L'unité SAU fournit l'état de sécurité (sécurisé ou non sécurisé) et identifie si l'instruction provient d'une région de la mémoire autorisée ou non. L'unité IDAU interface avec l'unité DAU (Device Attribution Unit) pour fournir une granularité accrue, en travaillant avec l'unité SAU pour déterminer l'attribut de sécurité d'une adresse spécifique. Il en résulte une requête de bus délivrée aux niveaux de sécurité et de privilège appropriés (Figure 2).

Figure 2 : Les microcontrôleurs LPC55S6x de NXP protègent l'accès au niveau de la transaction de bus, en utilisant l'unité SAU Arm TrustZone avec sa propre unité IDAU pour garantir que les requêtes de bus système fonctionnent aux niveaux de sécurité et de privilège appropriés. (Source de l'image : NXP Semiconductors)

Stockage et périphériques sécurisés

Les mécanismes de protection TrustZone isolent le code d'application et les données lors de l'exécution, en traitant les données utilisées (l'un des principes courants de sécurité des données), qui incluent également les données au repos et les données en transit. Bien que généralement associés aux problèmes de données de niveau entreprise, ces principes s'appliquent également au code et aux données d'un système embarqué. Ici, l'utilisation par un système embarqué typique de la mémoire Flash intégrée d'un microcontrôleur pour stocker les images des micrologiciels, le code et les données peut constituer un important vecteur d'attaque. Le dispositif LPC55S6x limite cette menace grâce à un algorithme de cryptage/décryptage appelé PRINCE. [Note pour les lecteurs : PRINCE n'est pas un acronyme.]

L'algorithme PRINCE est bien adapté aux implémentations de sécurité dans les systèmes embarquées grâce à sa vitesse et à ses exigences de ressources minimales. Implémenté dans le matériel des dispositifs LPC55S6x, l'algorithme PRINCE fonctionne en temps réel pour décrypter ou crypter des données à la volée à mesure de leur lecture ou écriture. Contrairement à de nombreux autres algorithmes cryptographiques, PRINCE ne nécessite pas de mémoire RAM pour conserver les données originales ou les résultats intermédiaires, ce qui élimine une autre vulnérabilité de sécurité. Par conséquent, les développeurs peuvent stocker en toute sécurité le code d'application, les images des micrologiciels et même les clés sécurisées dans la mémoire Flash interne du microcontrôleur.

Bien que les moteurs cryptographiques et le stockage Flash sécurisé verrouillent l'échange et le stockage des données, un système embarqué sécurisé nécessite le même niveau de sécurité pour ses interactions avec les capteurs et les transducteurs. En plus de ses capacités DMA sécurisées, l'architecture du microcontrôleur LPC55S6x fournit les mécanismes permettant de sécuriser davantage les échanges entre le cœur ou les autres maîtres de bus et les périphériques intégrés, la mémoire ou les GPIO (Figure 3).

Figure 3 : Les microcontrôleurs LPC55S6x de NXP combinent leur matrice de bus multicouche à des MSW, MPC et PPC pour isoler et sécuriser les transactions entre les différents maîtres de bus des dispositifs, les périphériques et la mémoire. (Source de l'image : NXP Semiconductors)

Dans ce schéma de protection, les contrôleurs de protection de mémoire (MPC) limitent l'accès à la mémoire par des applications moins sécurisées. Les contrôleurs de protection des périphériques (PPC) fournissent le même type de contrôle d'accès aux périphériques, ce qui permet aux développeurs de définir des règles d'accès différentes pour différents périphériques. Comme le mécanisme SAU/IDU est uniquement disponible pour le cœur Cortex-M33 primaire, les wrappers de sécurité maîtres (MSW) sont utilisés pour fournir une protection d'accès similaire aux autres maîtres de bus. Étant donné que la matrice AHB multicouche crée un chemin dédié entre les maîtres de bus et les périphériques ou la mémoire, il en résulte une connexion de bus interne sécurisée qui est isolée des autres transactions de bus pouvant se produire dans le dispositif.

L'architecture du microcontrôleur LPC55S6x permet de mieux isoler les accès sécurisés et non sécurisés aux dispositifs externes via son système GPIO sécurisé. Ce système étend le même type d'isolement aux broches GPIO que les mécanismes TrustZone créent entre les états de processeur sécurisés et non sécurisés et les modes d'exécution du code. Ainsi, seul le cœur Cortex-M33 primaire fonctionnant à l'état sécurisé peut accéder aux broches GPIO sécurisées, ce qui permet aux développeurs de sécuriser les signaux provenant de dispositifs externes critiques.

Gestion des clés sécurisée

Les différents mécanismes de protection décrits dans cet article fournissent les bases d'un système embarqué sécurisé. Cependant, pour connecter en toute sécurité ce système à un réseau, à un smartphone ou à un autre type d'hôte, les développeurs doivent pouvoir authentifier la cible de la connexion pendant la mise en service initiale et les transactions en cours, et maintenir un canal de communication crypté. La sécurité des algorithmes de cryptographie asymétriques et symétriques au cœur des protocoles d'authentification et des mécanismes de cryptage dépend en fin de compte de la sécurité des clés privées utilisées dans ces protocoles et mécanismes.

Grâce à leur fonction physique inclonable (PUF) intégrée, les microcontrôleurs LPC55S6x fournissent un mécanisme hautement sécurisé pour stocker les clés existantes et générer de nouvelles clés en toute sécurité. Cette approche dépend de la capacité du matériel PUF à créer une clé racine PUF unique servant à crypter les autres clés utilisateur. La singularité de la clé racine PUF découle de l'utilisation des fonctions internes du dispositif, ainsi que des données de démarrage SRAM, dérivées des contenus 0 et 1 aléatoires des cellules SRAM au démarrage). Pendant la phase d'enregistrement PUF, le dispositif utilise ces deux sources de données aléatoires pour créer une empreinte numérique et un code d'activation associé de 1192 octets (Figure 4).

Figure 4 : La fonction PUF intégrée des microcontrôleurs LPC55S6x de NXP utilise l'état aléatoire des SRAM au démarrage et d'autres fonctions internes afin de générer une empreinte numérique et un code d'activation utilisés pour les opérations ultérieures de génération et de stockage de clés. (Source de l'image : NXP Semiconductors)

Pendant le provisionnement du dispositif en usine ou plus tard sur le terrain, ce code d'activation est stocké dans la zone programmable sur le terrain par le client (CFPA) figurant dans la région Flash protégée du dispositif. Chaque fois que le microcontrôleur est mis sous tension et que la fonction PUF est activée avec la commande PUF Start, la fonction PUF combine le code d'activation existant avec les données de démarrage SRAM pour reconstituer l'empreinte numérique.

Après cette procédure PUF Start, la commande PUF SetKey entraîne le codage des clés utilisateur par la fonction PUF, notamment les clés maîtres partagées provisionnées en usine ou les clés privées fournies par les développeurs pour leurs applications. Dans le cas présent, la fonction PUF génère un code de clé pour la clé utilisateur correspondante en fonction de la taille de la clé, un index de clé et la clé utilisateur elle-même (Figure 5).

Figure 5 : La fonction PUF du LPC55S6x de NXP fournit une fonction SetKey qui permet de coder une clé utilisateur et un index de clé à l'aide de son empreinte numérique, fournissant un code de clé utilisé ultérieurement pour accéder à la clé utilisateur d'origine. (Source de l'image : NXP Semiconductors)

Les développeurs peuvent également générer de nouvelles clés à l'aide de la commande PUF GenerateKey, qui utilise le même processus de génération que la commande SetKey, mais avec des données uniques générées en interne remplaçant la fonction KEYIN illustrée à la Figure 5. Les clés définies ou générées avec un index de clé = 0 bénéficient d'une protection supplémentaire comme indiqué ci-dessous.

Pour utiliser les clés, les développeurs invoquent la commande PUF GetKey pour récupérer la clé utilisateur originale avec deux chemins de sortie différents en fonction de la valeur de l'index de clé utilisé lors de la définition ou la génération de la clé. Si l'index de clé est supérieur à zéro, la clé utilisateur est disponible via le registre PUF CODEOUTPUT. S'il est égal à zéro, la clé utilisateur est directement transmise au moteur AES ou dans les trois régions de mémoire Flash prises en charge du moteur PRINCE, comme spécifié par la valeur de KEYENABLE (Figure 6). Même si le registre KEYMASK 4 bits de la fonction PUF n'est pas directement impliqué dans la récupération de la clé, il prend en charge un mécanisme interne conçu pour limiter les attaques par canal auxiliaire.

Figure 6 : Pour accéder aux clés, les développeurs utilisent la commande PUF GetKey du LPC55S6x de NXP. Cette dernière utilise l'index et le code de clé générés pendant les opérations SetKey (ou GenerateKey) pour produire la clé utilisateur originale ou pour la transmettre via un bus privé aux accélérateurs cryptographiques du microcontrôleur. (Source de l'image : NXP Semiconductors)

Les clés à index zéro permettent de renforcer la sécurité du cycle de vie, dès la phase initiale du provisionnement en usine. Une fois provisionnée via PUF SetKey, la clé maître partagée (pour la cryptographie symétrique) ou la clé privée (pour la cryptographie asymétrique) ne peut quitter le dispositif ni même entrer dans le bus système. En revanche, le transfert de clés vers les moteurs AES ou PRINCE s'effectue en interne via une interface câblée dédiée non accessible par le logiciel.

Le mécanisme de gestion des clés PUF et les autres fonctionnalités de sécurité du microcontrôleur se combinent pour les autres phases de sécurité du cycle de vie, y compris l'amorçage sécurisé et les mises à jour micrologicielles sécurisées. Pour l'amorçage sécurisé, le LPC55S6x prend en charge de nombreuses méthodes de protection, y compris l'authentification des images signées RSA2048 à l'aide de certificats X.509 validés ou le décryptage des images stockées dans la région Flash PRINCE. Dans les deux cas, le chargeur d'amorçage récupère en toute sécurité les clés requises pour la validation du certificat ou le décryptage des images à partir du stockage de clés PUF en utilisant des hachages de clés générés par la fonction PUF, stockés avec les images dans la région Flash protégée.

La mise à jour micrologicielle utilise des mécanismes similaires pour authentifier une image de mise à jour micrologicielle sans fil, la décrypter et la préparer pour l'amorçage.

Au-delà des besoins immédiats de démarrage et de mise à jour micrologicielle sécurisés, les nombreux emplacements de stockage de clés et les capacités de génération de clés du dispositif prennent en charge les exigences de sécurité continue du cycle de vie pour la révocation des clés et des certificats. La capacité de gestion des clés prend en charge à son tour les politiques de sécurité de niveau supérieur telles que la révocation d'images de micrologiciels.

Les développeurs peuvent rapidement explorer les capacités des microcontrôleurs LPC55S6x à l'aide de la carte de développement LPCXpresso55S69 de NXP en combinaison avec l'environnement de développement intégré (IDE) MCUXpresso de NXP ou les IDE IAR ou Keil. Les outils de configuration MCUXpresso intégrés dans l'IDE MCUXpresso permettent aux développeurs de configurer le matériel du microcontrôleur et de générer le code d'initialisation. L'outil d'environnement d'exécution sécurisé TEE figurant dans ce jeu d'outils de configuration permet aux développeurs de configurer plus facilement l'accès de sécurité multi-niveaux du microcontrôleur LPC55S6x. À l'aide de l'interface graphique de l'outil TEE, les développeurs peuvent ajuster les privilèges d'accès à la mémoire, aux maîtres de bus et aux périphériques pour les quatre modes d'exécution et états du processeur décrits précédemment (Figure 7).

Figure 7 : L'interface graphique de l'outil d'environnement d'exécution sécurisé figurant dans le jeu d'outils de configuration MCUXpresso de NXP permet aux développeurs de définir des privilèges d'accès à la mémoire, aux maîtres de bus et aux périphériques pour un code s'exécutant dans les quatre modes d'exécution et états du processeur (source de l'image : NXP Semiconductors)

Pour le développement de code, NXP offre également quelques exemples de code simples qui fournissent des modèles de conception de base pour l'utilisation des fonctionnalités de sécurité du microcontrôleur (GPIO sécurisées, gestion de clés PUF) et des autres capacités du dispositif. Cependant, même durant la phase de développement, le microcontrôleur LPC55S6x contribue à maintenir la sécurité du cycle de vie grâce à sa capacité d'authentification de débogage à un fil

(SWD). Cette capacité permet aux développeurs autorisés de déboguer leur code sécurisé et de désactiver tout autre accès SWD afin de sécuriser les ressources avant de confier le développement à des développeurs de logiciels non sécurisés. Après avoir débogué à leur tour leur code, ces développeurs peuvent désactiver tous les accès au débogage via le port SWD.

Conclusion

Les développeurs font face à une demande croissante en matière de conceptions hautes performances, basse consommation capables de maintenir la sécurité durant le cycle de vie complet, du provisionnement en usine au fonctionnement sécurisé sur le terrain. La gamme de microcontrôleurs LPC55S6x de NXP, présentée dans cet article, offre une solution efficace qui combine des capacités de traitement à usage général avec un jeu étendu de fonctionnalités matérielles spécialisées, requises pour prendre en charge la sécurité du cycle de vie.