Concevoir un système de gestion du cycle de vie des certificats PKI pour les périphériques IoT

Les certificats PKI (Public Key Infrastructure), permettant de sécuriser les communications, le contrôle des accès et la signature du code, sont très simples à utiliser dans les périphériques IoT (Internet of Things) ; mais les processus de gestion du cycle de vie des certificats nécessitent une attention particulière. Dans cet article, l’expert en PKI Tamás Horváth explique comment élaborer vos processus de gestion, pour une sécurité et des performances optimales.

PKI est actuellement la meilleure technologie disponible pour sécuriser les communications via l’internet et les mises à jour logicielles dans les applications de l’IoT, et pour contrôler les accès aux services et périphériques IoT.

PKI supprime l’échange préalable de clés

La technologie PKI permet, en s’appuyant sur des certificats, d’attribuer des identités de confiance aux périphériques et services IoT. Il est ainsi possible de sécuriser les communications point-à-point de N-vers-N, par l’authentification et le chiffrement, sans échange préalable de clés.

PKI permet également l’exploitation de certificats d’accréditation, autorisant le porteur du certificat (qu’il s’agisse d’un objet physique ou d’un service) à accéder à certaines ressources ou à rejoindre un domaine d’infrastructure spécifique (par exemple un bâtiment). Les certificats d’accréditation peuvent ainsi remplacer les autres types de services d’autorisation centralisés, tels qu’OAuth ou OpenIDConnect, tout en permettant de garantir l’anonymat.

Une grande diversité de cycles de vie possibles

Il est aisé d’exploiter les certificats PKI dans les applications de l’IoT, dans la mesure où ces certificats sont pris en charge par la plupart des protocoles de communication, des produits d’authentification et d’accès, et des services électroniques.

Cependant, l’élaboration de processus de gestion du cycle de vie des certificats requiert une attention particulière. Cela est dû à la grande diversité des cycles de vie possibles des périphériques IoT, dépendant des facteurs suivants :

  • La chaîne d’approvisionnement de production pour les périphériques IoT peut comprendre un certain nombre d’étapes distinctes (telles que la fabrication des puces et des circuits électroniques, l’assemblage du produit, l’association du produit à un opérateur réseau, l’installation du produit dans un domaine d’infrastructure, ainsi que la remise du produit du fournisseur à l’opérateur), et impliquer différents acteurs.
  • Le contexte opérationnel des périphériques IoT – par exemple leur utilisation dans un contexte particulier par un utilisateur spécifique, leur installation au sein d’un domaine d’infrastructure spécifique (un bâtiment, une organisation ou encore une ville), ou leur affectation à un rôle spécifique au sein d’un service –, peut varier énormément. Dans certains cas, le produit devra être activé par une personne autorisée dans un environnement sécurisé ; dans d’autres cas, cette activation devra s’effectuer via l’internet, à l’aide de services de contrôle à distance.
  • Le cycle de vie post production des périphériques IoT peut également varier énormément. Certains produits peuvent changer de propriétaire ou de contexte opérationnel. Certains sont exploités dans des lieux publics, d’autres doivent être rigoureusement protégés et surveillés. D’autres encore peuvent nécessiter une maintenance régulière et/ou spécifique, sur le terrain ou dans un environnement sécurisé.

Maintenir la confiance tout au long du cycle de vie est essentiel

En élaborant vos processus de gestion du cycle de vie des certificats PKI, vous devez vous assurer d’établir et de maintenir la confiance pour les périphériques IoT d’un bout à l’autre de la chaîne d’approvisionnement et tout au long du cycle de vie des produits. Cela est essentiel pour se prémunir contre les risques associés à :

  • Des produits de contrefaçon s’introduisant dans la chaîne d’approvisionnement ou un environnement opérationnel sensible.
  • Des produits non déclarés ou trafiqués insérés à des fins malveillantes dans la chaîne d’approvisionnement ou un environnement sensible (par exemple, un produit prêt à l’emploi contrôlé par un tiers qui le connecterait à votre insu à votre réseau domestique).
  • Des accès non autorisés à des équipements ou des services connectés, par exemple la prise de contrôle malveillante de robots dans une usine de production.
  • Un équipement qui tomberait sous le contrôle d’un autre équipement ou serait redirigé vers un service piraté, dans le but de capturer des données.

Les identités de confiance doivent être attribuées aussi tôt que possible

Afin d’établir et de maintenir la confiance pour les périphériques IoT tout au long de leur cycle de vie, leur identité doit pouvoir être aisément contrôlée. Pour cela, il est important qu’une identité soit attribuée aux produits ou à ses composants aussi tôt que possible dans leur cycle de vie. Par la suite, la validation de cette identité devra être requise lors de toute nouvelle attribution d’identité à l’objet ou au composant dans l’étape suivante de fabrication, ou lorsque le produit entrera dans son environnement opérationnel (i.e. personnalisé pour un utilisateur ou installé dans un domaine d’infrastructure).

Idéalement, les composants des périphériques IoT (tels que les cartes SIM, les puces eSIM, les microcontrôleurs ou encore les cartes embarquées à bord des véhicules) se voient attribuer leur première identité, basée sur certificat, par leur fabricant lors de leur production dans un environnement sécurisé.


Télécharger le guide: ”Bâtir une infrastructure IoT sécurisée.”


De nouveaux certificats pour chaque étape du cycle de vie

Lorsqu’un fabricant livre des composants de périphériques IoT au fabricant suivant dans la chaîne de production, il est également censé fournir, de façon sécurisée, la liste des identités des composants. Ainsi, le fabricant suivant sera en mesure d’écarter les composants non approuvés, et de produire en toute sécurité de nouveaux certificats, spécifiques au fabricant ou au contexte, pour les produits.

Ce processus devra être réitéré à chaque étape de la chaîne de production des périphériques IoT. Lors de l’acquisition du produit par un usager ou une organisation, l’opérateur devra lui attribuer un nouveau certificat pour le contexte opérationnel (après avoir contrôlé l’identité qui lui avait été attribuée précédemment).

Des certificats pour simplifier le contrôle des accès

Il existe plusieurs moyens d’inclure des identifiants tels que le nom du fournisseur, celui du domaine opérationnel ou encore l’ID du compte client, dans les requêtes d’enregistrement, les demandes de certificats ou les certificats eux-mêmes. Le moyen le plus courant est de s’appuyer sur les URIs (Uniform Resource Identifiers), les noms de domaine DNS (Domain Name System) ou encore les adresses IP (Internet Protocol).

Le principal avantage de mentionner le contexte opérationnel dans le certificat est que cette mention peut directement constituer une accréditation pour le produit ou le service, l’autorisant à opérer dans le contexte spécifique. Ainsi, les parties communicantes peuvent se valider mutuellement, sans recourir à un système tiers d’accréditation ou de gestion des accès. Par exemple, les capteurs ou les caméras délivreront leurs données uniquement au service de contrôle dont ils dépendent, dans la mesure où le nom de domaine opérationnel figurant dans leurs certificats correspondra.

Le produit peut être contrôlé uniquement par son propriétaire légal

Typiquement, le certificat attribué pour le contexte opérationnel garantit que :

  • Le produit peut être contrôlé uniquement par son propriétaire légal.
  • Seul un produit appartenant à telle entité peut accéder au compte de service de cette entité.
  • Le produit peut être exploité uniquement au sein du contexte opérationnel.
  • Le produit ne peut fournir par erreur des données à d’autres parties ou à d’autres contextes opérationnels.

En principe, les certificats peuvent être génériques (certificats dits « wildcards »), ce qui implique que tous les produits d’un même domaine partagent la même clé et le même certificat. Je recommande de ne pas utiliser de tels certificats génériques dans les applications de l’IoT, car dans ce cas les cycles de vie des produits ne pourront être contrôlés individuellement.

Les quatre étapes de l’attribution d’une nouvelle identité

Sur le plan technique, l’attribution d’une nouvelle identité à un périphérique IoT se déroule selon les quatre étapes suivantes :

  • Enregistrement (enrôlement) du produit au niveau du fabricant, du fournisseur ou de l’opérateur.
  • Génération d’une nouvelle paire de clés de chiffrement, soit sur le produit lui-même soit par l’intermédiaire d’un service sécurisé (étape facultative).
  • Demande et publication de certificat PKI pour le produit concerné.
  • Attribution d’un certificat (et le cas échéant d’une clé privée) au produit concerné.

Lors de chacune de ces étapes, les procédures de sécurité doivent être strictement respectées, de façon à ce que seules les parties autorisées puissent intervenir dans le processus, et garantir que la clé de chiffrement et le certificat PKI sont bien associés à l’objet concerné.

Autorités d’enregistrement et de certification

À ce stade, une autorité d’enregistrement (AE) et une autorité de certification (AC) sont requises.

  • Le rôle de l’AE est de contrôler l’accréditation des produits en vue de leur enregistrement, de façon à ce que seuls les périphériques IoT concernés puissent obtenir un certificat pour l’étape suivante de leur cycle de vie. Les données d’enregistrement font apparaître le lien entre l’identité existante du produit et l’identité demandée.
  • Le rôle de l’AC est de produire des certificats, et de garantir que seuls les périphériques IoT enregistrés (accrédités) obtiennent un certificat pour la prochaine étape de leur cycle de vie. L’AC garantit également que les clés publiques et les certificats sont associés aux produits concernés, en possession des clés privées correspondantes. Les certificats existants des périphériques IoT peuvent être exploités comme preuve d’identité par l’AC.

Automatisation des processus d’attribution de certificats

À cause du nombre potentiellement très élevé d’objets concernés par les applications de l’IoT, il est fortement recommandé d’automatiser les processus d’enregistrement et d’attribution de certificats. L’automatisation permettra de rendre ces processus à la fois plus sûrs et plus économiques.

Les demandes d’enregistrement et de certificat peuvent être générées par un système de gestion de la relation client (CRM), par l’équipement du fabricant, ou encore par un système de gestion des périphériques tel qu’une plateforme IoT. Les demandes de certificat peuvent également émaner du périphérique connecté lui-même ; on parle alors d’auto-enrôlement. Le fait d’attribuer des clés et des certificats aux objets directement depuis l’AC simplifie énormément l’infrastructure de sécurité.

Il n’existe pas de protocoles standardisés pour l’enregistrement, mais cela n’est pas vraiment un problème dans la mesure où le transfert des données d’enregistrement vers un service est une opération basique. En revanche, et c’est le plus important, il existe plusieurs protocoles standardisés de gestion des certificats, couvrant à la fois les demandes et les attributions, tels que SCEP, CMC, CMP, EST ou encore ACME. CMP et EST sont les plus aboutis pour ce qui concerne la gestion des certificats tout au long de la durée de vie des produits, notamment du fait qu’ils autorisent l’auto-enrôlement des certificats basé sur l’authentification de l’objet demandeur via son certificat existant.

Événements survenant au cours du cycle de vie opérationnel

Une fois installé dans son contexte opérationnel, un périphérique IoT peut être endommagé, volé, compromis, ou simplement retiré de l’exploitation. Il peut également changer de propriétaire ou de contexte opérationnel. Il arrive également que la validité du certificat obtenu de l’opérateur soit limitée, et qu’il soit nécessaire de la renouveler.

Le remplacement ou le renouvellement des certificats est pris en charge par les protocoles CMP et EST. Le système de gestion des périphériques IoT, voire les périphériques IoT eux-mêmes, peuvent superviser la validité des certificats, et si nécessaire effectuer automatiquement la demande de nouveaux certificats.

Les certificats révoqués sont rejetés

Toute perte, compromission ou retrait d’un périphérique IoT doit naturellement faire l’objet d’une procédure. Les infrastructures PKI standard intègrent un service de révocation, chargé d’invalider les certificats. Dans le cadre d’une validation standard, la partie validant extrait le statut de révocation du certificat soit d’un référentiel CRL (Certificate Revocation List), soit d’un serveur OCSP (Online Certificate Status Protocol).

Un objet porteur d’un certificat révoqué ne pourra plus accéder aux services demandés, ni recevoir de message chiffré. Les réponses des référentiels CRL et des serveurs OCSP peuvent être placées en cache pour améliorer les temps de réponse et la disponibilité. (Dans un prochain article de blog, j’évoquerai les inconvénients potentiels de ces infrastructures de validation de certificats, et suggèrerai des approches alternatives.)

Toute perte ou compromission nécessite un reporting dans un système de gestion des périphériques IoT, qui à son tour peut révoquer le certificat affecté, via une interface appropriée, auprès de l’autorité de certification. L’AC publie les révocations par l’intermédiaire des services CRL et OCSP susmentionnés. Le changement de propriétaire ou d’opérateur, ou encore le retrait de périphériques pour des causes ordinaires, telles que la terminaison d’un contrat, peuvent être supervisés par un système CRM, qui pourra déclencher la révocation. Parmi les protocoles standards de gestion des certificats, seul CMP prend en charge la révocation.

Élaboration des processus : synthèse

En résumé, une saine élaboration des processus de gestion des certificats PKI pour les périphériques IoT comprend les étapes suivantes :

  • Analyser le cycle de vie des produits.
  • Identifier le moment opportun ainsi que le mécanisme approprié pour l’attribution au produit ou à ses composants de leur premier certificat (idéalement dans un site de production sécurisé).
  • Concevoir une chaîne ininterrompue d’identités de confiance d’un bout à l’autre de la chaîne d’approvisionnement et tout au long du cycle de vie du produit.
  • Automatiser la production de certificats, spécifiques au fabricant ou au contexte, ainsi que les processus de renouvellement, de révocation, de retrait ou de remplacement des certificats ; l’automatisation de ces différents processus est essentielle à la sécurisation et à la minimisation des coûts de la solution IoT.
  • Le cas échéant, s’appuyer sur les capacités d’auto-enrôlement des certificats par les AC. Cela permet de simplifier énormément l’infrastructure de sécurité.
  • Exploiter si possible la capacité des certificats PKI à constituer des données d’accréditation, car cela peut permettre de simplifier l’infrastructure de contrôle des accès.

Bâtir une infrastructure IoT sécurisée