[TRIBUNE de Guillaume Crinon, KEYFACTOR] La mise en œuvre de bonnes pratiques de cybersécurité dans les dispositifs IoT est beaucoup moins complexe que ce que l’on entend fréquemment. Les difficultés surviennent lorsque les équipes produit envisagent la sécurité a posteriori au lieu de la mettre en œuvre dès la conception du produit. Précisions de Guillaume Crinon, directeur IoT Business Strategy de la société Keyfactor.

En matière de cybersécurité, les fabricants d'appareils doivent comprendre trois concepts importants. D’abord, la "sécurité parfaite" n'existe pas et les normes, tactiques et exigences sont amenées à évoluer. Ensuite, chaque projet est différent et comporte des restrictions (consommation d'énergie, puissance du processeur, nomenclature, budget...) qu’il faut prendre en compte pour adapter la stratégie de cybersécurité du produit concerné en un compromis acceptable. Enfin, une planification précoce est essentielle pour sélectionner le matériel et les équipements afin de concevoir un produit suffisamment souple pour assurer la sécurité actuelle mais aussi future.

Cette planification s’articule autour de huit étapes successives que l’on peut mettre en œuvre à son rythme par mises à jour logicielles, pourvu que le matériel ait été correctement dimensionné au départ. Également, l’ordre dans lequel parcourir ces étapes peut être ajusté en fonction du niveau de maturité de l’entreprise en matière de cybersécurité.

- Étape 1 : Identifier les normes et réglementations auxquelles le produit doit se conformer, aujourd'hui et à l'avenir

Les normes et réglementations varient en fonction des secteurs d'activité et de la situation géographique de l’entreprise et de ses clients. Qu'elles soient imposées par un gouvernement ou suggérées pour l'interopérabilité par un consortium industriel, le produit final doit être conforme à ces normes ou si la norme n'est pas complète, ce même produit doit être capable d'accepter une mise à jour pour s’y conformer.

- Étape 2 : Choisir la racine de confiance matérielle ou logicielle de l’appareil

Une racine de confiance (RoT) est un élément sécurisé (SE) dans lequel les secrets de l'appareil et les algorithmes cryptographiques de bas niveau peuvent être exécutés en toute sécurité. Elle peut prendre la forme d'une puce sécurisée ou d'un logiciel sécurisé sur un matériel non sécurisé. Le choix de la solution dépend du coût du produit et des exigences en matière de sécurité du système global. De nombreux types de secrets – certificats X.509, clés symétriques – peuvent nécessiter cette protection supplémentaire. Le nombre de secrets et de processus déterminera le choix de la RoT à utiliser.

- Étape 3 : Sélectionner un microcontrôleur avec suffisamment de mémoire pour des mises à jour over-the-air (OTA) sécurisées

Le logiciel d’un appareil étant amené à évoluer et se développer au fil du temps, il est indispensable d’anticiper ces besoins et de dimensionner dès le départ les tailles de mémoires flash et RAM dont cet appareil aura besoin tout au long de sa vie. Les OEM doivent donc trouver un équilibre pour s’assurer de ne pas manquer de mémoire durant la vie du produit ou même avant l’expiration de sa garantie, tout en évitant le surcoût d’une mémoire surdimensionnée.

Il est fortement recommandé de choisir un mécanisme sécurisé de mise à jour du firmware à distance et d’intégrer l’agent embarqué de ce mécanisme au firmware du produit. De même, il est recommandé de prévoir un mécanisme permettant de mettre à jour la racine de confiance avec de nouvelles clés et de nouveaux certificats X.509 au cours de la vie du produit.

- Étape 4 : Mettre en place une infrastructure à clé publique (PKI) pour les certificats initiaux des appareils

Chaque produit IoT est amené à interagir avec d'autres machines. Il a donc besoin d'un document numérique pour s'identifier et prouver son authenticité en cas de besoin : c’est le certificat initial de l’appareil. Pour émettre ces certificats, il est recommandé de mettre en place et configurer une PKI. Elle se compose d'une autorité de certification (AC) racine, qui est maintenue hors ligne en toute sécurité, et d'une AC subordonnée, dédiée à chaque ligne de produits. L'autorité de certification subordonnée génère un certificat initial unique pour chaque appareil fabriqué.

La durée de vie du certificat de l'appareil initial correspond généralement à la durée de vie prévue de l'appareil. Cependant, pour protéger le certificat sur cette durée, il doit être stocké en toute sécurité dans la RoT de l'appareil et son utilisation doit être strictement limitée à l’enrôlement de l’appareil dans son environnement d’utilisation.

Le marché actuel offre de multiples options d’hébergement d’une PKI en fonction des préférences et des ressources disponibles de l’OEM : via un modèle SaaS (Software-as-a-Service) avec un fournisseur ; hébergé dans ses propres installations, sur site ou dans son cloud ; ou un modèle hybride avec des composants locaux et dans le cloud.

- Étape 5 : Décider comment la PKI sera intégrée dans le processus de production

En fonction des préférences, des processus et des capacités de l’entreprise, il existe trois options principales pour le provisionnement des identités initiales :

- Le pré-provisionnement par le fournisseur ou distributeur de puces silicium en amont de la fabrication de l’appareil. La plupart des fournisseurs et distributeurs de puces offrent ce service de personnalisation pour les Secure Elements. Plus rarement, ils peuvent également l'offrir pour les microcontrôleurs. Cette option est pratique lorsque l'on sait quelle puce va être intégrée dans quel appareil final,

- Le provisionnement pendant la fabrication à l'usine. Cette option est la plus souple pour un fabricant, car il garde le contrôle total de sa PKI et de ses processus tout en ne dépendant d'aucun fournisseur externe. Mais elle requiert d’intégrer le processus de fabrication,

- Le post-provisionnement in-situ chez le client final en aval de la fabrication. Dans ce scénario, les appareils sont fabriqués avec des puces pré-provisionnées avec un certificat de naissance provenant de la PKI du fournisseur de silicium ou d'un TPM (Trusted Platform Module). Cette identité de naissance provisoire est ensuite utilisée par l'appareil lors de son premier démarrage pour contacter un service d’enrôlement. Ce service vérifie l'identité de naissance de l'appareil et, en cas d'autorisation, collecte le certificat initial de l'appareil auprès de la PKI et le transfère automatiquement à l'appareil, ce qui clôt le processus de fabrication. Cette option permet en outre l'ajout de certificats spécifiques à des régions géographiques ou clients finaux tout en fabriquant un produit générique.

- Étape 6 : Mettre en place une procédure de signature de firmware intégrée au pipeline de développement

Chaque équipementier a la responsabilité de développer les firmwares qui vont donner vie aux appareils qu’il produit, mais il doit également assurer la maintenance de ce code pendant toute la durée de vie de ces appareils. Quelle que soit la manière dont le code est mis en œuvre et déployé, il doit être signé cryptographiquement avant d'être installé sur sa cible de façon à ce que l’appareil puisse en vérifier l’authenticité et se prémunir contre des malwares.

- Étape 7 : Intégrer un bootloader sécurisé à l’appareil

Pour garantir que les secrets soient bien conservés dans la racine de confiance de l'appareil et que le logiciel de démarrage ne soit réécrit pour contourner les contrôles de sécurité, il est indispensable de mettre en place un bootloader sécurisé. Ce code spécifique, dont le premier étage est stocké en ROM, est construit de façon à démarrer des services par étapes, chacune d’elles vérifiant la signature de la suivante avant son exécution, jusqu’à l’application. Les signatures sont vérifiées en utilisant la racine de confiance de l'appareil.

Un bon bootloader assure que le code ne peut pas être modifié, corrigé ou mis à jour de façon frauduleuse. Pour minimiser les risques d'erreur, il doit être petit, simple et limité à sa fonction principale.

- Étape 8 : Ajouter les clés et les certificats de vérification de la signature du code à l’appareil lors de la fabrication

Les clés et certificats de vérification du firmware doivent être présents sur chaque appareil pour lui permettre de vérifier l'authenticité d'une mise à jour logicielle avant de l'appliquer. Contrairement aux certificats initiaux des appareils, les clés et certificats de vérification sont identiques sur tous les appareils fabriqués. Ils doivent être hébergés en toute sécurité dans une mémoire protégée ou un Secure Element pour éviter qu’un hacker ne puisse les remplacer par ses propres clés et introduire un malware dans l'appareil.

Les hackers recherchent toujours le maillon le plus faible d'un réseau, pour en exploiter la faille et ainsi atteindre indirectement leur cible. La sécurité ne peut pas être simplement ajoutée une fois la conception du produit terminée, car elle nécessite une infrastructure, des considérations de conception, ainsi que des processus et des outils qui doivent être mis en place pendant les étapes de développement, de production et de maintenance.

Par ailleurs, il ne faut pas figer la sécurité d’un système en fonction du cahier des charges initial. Le firmware ne sera jamais parfait ; des bugs ou des vulnérabilités seront découverts. Des ajustements seront nécessaires pour répondre à des évolutions des spécifications opérationnelles de l'appareil. Les normes évolueront. Mais toutes ces mesures correctives ne pourront être déployées par des mises à jour logicielles sécurisées de l'appareil connecté qu’à la seule condition que l’appareil lui-même intègre une solide base de sécurité telle que celle décrite dans ce document.