Principes de base de la sécurité IoT — 3e partie : garantir la sécurité du démarrage et des mises à jour des micrologiciels

Note de l'éditeur : Malgré la prolifération des dispositifs IoT, la sécurisation de ces dispositifs reste une préoccupation constante, dans la mesure où les problèmes de sécurité peuvent constituer un obstacle à l'adoption des dispositifs connectés dans les applications Internet industriel des objets (IIoT) et les applications stratégiques où les données d'entreprise et personnelles peuvent être compromises en cas d'attaque réussie. Sécuriser les applications IoT peut être intimidant, mais en réalité la sécurité des dispositifs IoT peut reposer sur quelques principes relativement simples qui sont pris en charge par les dispositifs de sécurité matériels. En suivant des pratiques de sécurité bien établies, il est possible de répondre à ces préoccupations. Cette série en plusieurs parties fournit des conseils pratiques pour aider les développeurs à s'assurer que les meilleures pratiques sont suivies dès le départ. La 1re partie traite des algorithmes de cryptographie sous-jacents aux conceptions sécurisées. La 2e partie traite du rôle des clés privées, de la gestion des clés et du stockage sécurisé dans les conceptions IoT sécurisées. Ici, la 3e partie étudie les mécanismes intégrés dans les processeurs sécurisés pour atténuer les autres types de menaces sur les dispositifs IoT. La 4e partie identifie des mécanismes de sécurité et montre comment les appliquer dans les processeurs avancés pour contribuer à assurer l'isolement requis pour atténuer les attaques sur l'environnement d'exécution des dispositifs IoT. La 5e partie décrit comment la sécurité IoT continue à s'étendre depuis les dispositifs IoT par le biais de mesures de sécurité de niveau supérieur utilisées pour connecter ces dispositifs aux ressources cloud IoT.

Utilisés conjointement, la cryptographie matérielle et le stockage sécurisé fournissent les capacités essentielles requises pour mettre en œuvre des conceptions Internet des objets (IoT) sécurisées. Une fois déployés, cependant, les dispositifs IoT sont confrontés à de multiples menaces visant à corrompre ces dispositifs et lancer des attaques immédiates, ou à des menaces persistantes plus subtiles et plus avancées.

Cet article décrit comment les développeurs peuvent améliorer la sécurité des dispositifs IoT en utilisant une racine de confiance qui s'appuie sur des mécanismes de sécurité sous-jacents afin de fournir un environnement de confiance pour l'exécution de logiciels sur des processeurs sécurisés de Maxim Integrated, Microchip Technology, NXP Semiconductors et Silicon Labs, entre autres.

Présentation et rôle de la racine de confiance

Les méthodes cryptographiques et les clés sécurisées sont des outils essentiels pour assurer la sécurité de tout dispositif connecté. Comme indiqué dans les deux premières parties de cette série, elles fournissent des mécanismes fondamentaux utilisés par les protocoles de niveau supérieur pour protéger les données et les communications. Pour protéger le système lui-même, les développeurs doivent tenir compte des vulnérabilités qui peuvent affecter le fonctionnement du système et l'exécution des logiciels dans les systèmes embarqués.

Dans un système embarqué typique, une réinitialisation du système suite à une panne de courant ou à une exception logicielle critique finit par engager le processus de démarrage du logiciel pour recharger une image de micrologiciel depuis la mémoire non volatile. Normalement, le redémarrage du logiciel est un mécanisme de sécurité important utilisé pour rétablir le fonctionnement d'un système qui a été déstabilisé accidentellement ou intentionnellement. Dans les systèmes connectés, où les pirates informatiques utilisent divers outils « chapeau noir » pour compromettre les logiciels, les experts en sécurité recommandent souvent le redémarrage pour contrer les intrusions affectant l'exécution des logiciels. Par exemple, en 2018, le FBI a recommandé aux consommateurs et aux entreprises de redémarrer leurs routeurs pour contrecarrer une campagne de piratage massive alors en cours.

En pratique, le redémarrage n'est pas une garantie d'intégrité du système. Après un redémarrage avec une image de micrologiciel compromise, le système reste sous le contrôle du pirate. Pour atténuer ce type de menaces, les développeurs doivent s'assurer que leurs logiciels fonctionnent sur une chaîne de confiance qui s'appuie sur une racine de confiance établie au moment du démarrage et qui s'étend à toutes les couches de l'environnement d'exécution du logiciel. La capacité à atteindre ce niveau de sécurité dépend essentiellement de la garantie que le processus de démarrage débute avec un micrologiciel fiable.

Vérification des images de micrologiciels pour un démarrage sécurisé

Dans un système embarqué, le processeur hôte charge une image de micrologiciel de la mémoire Flash vers la mémoire principale et commence à l'exécuter (ou commence à l'exécuter directement depuis la mémoire Flash avec la capacité Execute-in-Place (XIP)). Si les pirates ont compromis l'image du micrologiciel, le processus de démarrage aboutit à un système compromis.

Pour vérifier l'intégrité du micrologiciel avant le démarrage, les développeurs utilisent un processus de signature de code qui intervient tôt dans la chaîne d'approvisionnement. Dans une structure sécurisée, l'image du micrologiciel système est signée avec une clé privée provenant d'une paire de clés privée-publique créée avec un algorithme cryptographiquement robuste tel que l'algorithme de signature numérique à courbe elliptique (ECDSA). Si la clé privée ne quitte jamais la structure, la clé publique du système est envoyée avec le système. Au démarrage, le processeur applique cette clé publique système pour vérifier la signature du micrologiciel avant d'utiliser l'image.

Bien entendu, le processus que nous venons de décrire laisse la clé publique elle-même vulnérable et, par extension, rend le micrologiciel système vulnérable à un remplacement non autorisé. Si la clé publique reste non protégée dans le système embarqué, les pirates peuvent éventuellement la remplacer par une clé publique provenant d'une paire de clés privée-publique qu'ils auraient eux-mêmes générée. S'ils remplacent l'image du micrologiciel du système par un micrologiciel malveillant signé avec la clé privée associée en leur possession, la signature du micrologiciel compromis réussit le processus de vérification et le processus de démarrage se poursuit, ce qui aboutit à un système compromis.

C'est pourquoi les systèmes sécurisés reposent sur une clé publique valide qui est provisionnée dans un élément sécurisé au sein de la structure de sécurité. Les circuits intégrés de sécurité tels que le DS28C36 de Maxim Integrated et l'ATECC608A de Microchip Technology fournissent à la fois le stockage sécurisé d'un élément sécurisé traditionnel et l'exécution sécurisée d'algorithmes d'authentification, comme ECDSA, pour la vérification de la signature du micrologiciel.

Avant le démarrage, le processeur hôte peut envoyer le micrologiciel via une interface série au DS28C36, par exemple. À son tour, le DS28C36 utilise la clé publique du système provisionnée plus tôt dans la structure sécurisée pour vérifier que la signature du micrologiciel a bien été créée avec la clé privée associée dans la même structure sécurisée. Enfin, le DS28C36 signale le résultat de la vérification au processeur hôte, qui procède au chargement de l'image du micrologiciel si la signature est valide (Figure 1).

Figure 1 : Les développeurs peuvent utiliser des circuits intégrés de sécurité tels que le DS28C36 de Maxim Integrated pour vérifier les signatures des micrologiciels afin d'empêcher le processeur hôte de lancer un micrologiciel compromis. (Source de l'image : Maxim Integrated)

Un processus de démarrage plus sécurisé protège l'image du micrologiciel afin d'éliminer toute crainte que les clés ou les images soient compromises. Grâce à un stockage sécurisé et à des accélérateurs de cryptographie, des capacités de démarrage sécurisé efficaces sont intégrées dans un nombre croissant de processeurs, notamment les processeurs Gecko série 2 de Silicon Laboratories, LPC55S69JBD100 de NXP, MAX32520 de Maxim Integrated et ATSAML11D16A de Microchip Technology. Grâce à ces capacités, cette catégorie de processeurs sécurisés peut fournir la racine de confiance requise afin de créer un environnement de confiance pour l'exécution des logiciels système et d'application.

Fournir une racine de confiance via le démarrage sécurisé

Les processeurs sécurisés de cette catégorie offrent des options de démarrage sécurisé conçues pour garantir l'intégrité de l'image du micrologiciel sous-jacente à la racine de confiance. Par exemple, les processeurs Gecko série 2 EFR32MG21A et EFR32BG22 de Silicon Laboratories développent cette racine de confiance grâce à un processus de démarrage en plusieurs étapes basé sur un élément de sécurité matériel et un élément de sécurité virtuel (VSE), respectivement (Figure 2).

Figure 2 : Le processeur Gecko série 2 EFR32MG21A de Silicon Laboratories utilise un élément de sécurité matériel intégré dans la première étape de son processus de démarrage en plusieurs étapes (illustré ici), tandis que l'EFR32BG22 initie son processus de démarrage en plusieurs étapes avec un élément de sécurité virtuel. (Source de l'image : Silicon Laboratories)

Dans l'EFR32MG21A, un cœur de processeur dédié fournit une fonctionnalité cryptographique ainsi qu'un élément matériel sécurisé pour le stockage sécurisé des clés. Grâce à cette capacité dédiée, le processeur initie le processus de démarrage en utilisant le code stocké en mémoire morte (ROM) pour vérifier le code du chargeur d'amorçage de premier niveau (FSB). Une fois vérifié, le code FSB s'exécute, ce qui permet de vérifier la signature du code du chargeur d'amorçage de deuxième niveau (SSB). La séquence de démarrage se poursuit avec l'exécution du SSB vérifié, qui à son tour vérifie la signature du code d'application, qui inclut typiquement à la fois le code de niveau système et le code d'application de niveau supérieur. Enfin, le code d'application vérifié est exécuté et les opérations du système se déroulent comme requis par l'application.

Comme ce processus commence avec le code ROM et n'exécute que le code FSB, SSB et d'application vérifié, cette approche résulte en une chaîne de confiance vérifiée pour l'exécution du code. Étant donné que le premier maillon de cette chaîne de confiance repose sur un code ROM qui ne peut être modifié, chaque maillon suivant de la chaîne étend cet environnement de confiance. En même temps, cette approche permet aux développeurs de mettre à jour le code d'application en toute sécurité, et même le code du chargeur d'amorçage de premier niveau et de deuxième niveau. Tant que chaque paquet de code fournit une signature vérifiée, l'environnement de confiance reste intact.

Les processeurs qui fournissent ce type de démarrage sécurisé avec une racine de confiance prennent généralement en charge plusieurs modes et options. Par exemple, les processeurs Gecko série 2 de Silicon Laboratories offrent une capacité de démarrage sécurisé basée sur certificat renforcée.

Utilisés dans les transactions d'infrastructure à clé publique (PKI) de routine, les certificats contiennent la clé publique ainsi qu'une référence à un ou plusieurs certificats associés qui pointent à terme vers un certificat racine accordé par une autorité de certification (CA). Chaque certificat de cette chaîne sert à vérifier le(s) certificat(s) situé(s) au niveau inférieur, résultant en une chaîne de confiance basée sur une autorité de certification de confiance. Les navigateurs s'appuient sur cette chaîne de confiance pendant la phase d'authentification TLS (Transport Layer Security) pour confirmer l'identité des serveurs Web. De la même manière, les systèmes embarqués peuvent utiliser des certificats pour confirmer l'identité de la source du code d'application ou du chargeur d'amorçage. Ici, le processus de démarrage en plusieurs étapes se déroule comme décrit précédemment, mais avec une vérification supplémentaire du certificat associé avec chaque étape (Figure 3).

Figure 3 : Les processeurs Gecko série 2 de Silicon Laboratories renforcent la sécurité système en vérifiant les certificats pour les clés publiques utilisées lors de la vérification des signatures à chaque étape du processus de démarrage. (Source de l'image : Silicon Laboratories)

D'autres processeurs, tels que le LPC55S69JBD100 de NXP, prennent en charge un certain nombre d'options différentes pour l'image du micrologiciel. Outre les images de micrologiciels signées, ces processeurs prennent en charge les images de démarrage avec la norme industrielle DICE (Device Identifier Composition Engine) du Trusted Computing Group. Une troisième option permet aux développeurs de stocker les images dans des zones spéciales de la mémoire Flash du processeur prenant en charge le chiffrement PRINCE, un chiffrement par blocs à faible latence qui permet d'atteindre une sécurité comparable à celle des autres chiffrements, mais dans une zone de puce beaucoup plus petite. Implémenté dans le LPC55S69JBD100, le chiffrement PRINCE peut effectuer le décryptage à la volée du code crypté ou des données stockées dans les régions Flash dédiées PRINCE du processeur. Comme les clés secrètes utilisées pour le décryptage ne sont accessibles qu'au moteur de cryptographie PRINCE, ce processus de décryptage reste sécurisé. En fait, ces clés secrètes sont protégées par une clé primaire (KEK) générée par la fonction physique inclonable (PUF) du LPC55S69JBD100. (Pour plus d'informations sur l'utilisation des fonctions PUF et KEK, reportez-vous à la 2e partie.)

Cette approche permet aux développeurs de stocker des images de micrologiciels supplémentaires — une capacité requise pour fournir aux dispositifs IoT des méthodes de mise à jour en direct (FOTA) des micrologiciels sans risque de « plantage » des dispositifs. Si le processeur ne peut utiliser qu'un seul emplacement pour stocker les images de micrologiciels, une image de micrologiciel défectueuse peut placer le processeur dans un état indéterminé ou verrouillé qui bloque, ou « fait planter », le dispositif. En stockant les images des micrologiciels dans les régions Flash compatibles PRINCE du LPC55S69JBD100, les développeurs peuvent utiliser des stratégies de repli (back-off) qui permettent de restaurer une version précédente du micrologiciel si la nouvelle version démarre dans un état non fonctionnel.

Comme toutes ces nouvelles images de micrologiciels doivent passer les contrôles de vérification de signature requis dans le processus de démarrage sous-jacent, les développeurs peuvent pleinement tirer parti de l'option FOTA sécurisée pour ajouter de nouvelles fonctionnalités ou corriger des bogues sans impliquer le système ou sa chaîne de confiance.

Conclusion

La sécurité au niveau du système et des applications exige un environnement d'exécution qui ne permet qu'aux logiciels autorisés de fonctionner. Bien que la vérification des signatures de code soit une fonctionnalité essentielle pour permettre ce type d'environnement, les systèmes sécurisés doivent s'appuyer sur un ensemble plus complet de capacités pour établir la chaîne de confiance requise afin de garantir une exécution fiable des logiciels. Le fondement de ces environnements de confiance repose sur une racine de confiance fournie par des mécanismes de démarrage sécurisés soutenus par des processeurs sécurisés. Grâce à cette catégorie de processeurs, les développeurs peuvent mettre en œuvre des dispositifs IoT sécurisés capables de résister aux attaques visant à paralyser l'exécution des logiciels dans un système ou à détourner entièrement le système.