Validation des certificats des périphériques IoT

Les certificats PKI (Public Key Infrastructure) constituent la meilleure technologie disponible pour la protection des communications, le contrôle des accès, ainsi que la sécurisation du code dans le cadre de l’IoT (Internet of Things). Les processus de gestion des certificats nécessitent cependant une attention particulière. Dans cet article, l’expert en PKI Tamás Horváth explique comment s’assurer de la bonne validation des certificats des périphériques IoT.

PKI est la meilleure technologie disponible pour la protection des communications, le contrôle des accès, ainsi que la sécurisation du code dans le cadre des applications de l’IoT. Dans un récent article de blog, j’ai abordé la question spécifique de la gestion du cycle de vie des certificats, en tenant compte de la grande diversité des scénarios possible en termes de chaînes d’approvisionnement et d’exploitation des produits IoT. Dans cet article, j’aborderai un aspect moins souvent évoqué des infrastructures PKI dédiées à l’IoT : la validation des certificats des périphériques IoT.

La révocation est une fonction intégrée à PKI

Les standards PKI – à commencer par la norme X.509 dans les années 1990 – définissent une infrastructure de révocation pour les certificats : dès lors que la clé privée du détenteur du certificat est compromise, est soupçonnée de l’avoir été, ou n’est simplement plus requise, le certificat concerné peut être révoqué à l’aide de la fonction de révocation de l’autorité de certification (AC) qui l’a généré. L’AC déclare alors publiquement la révocation aux autres parties de la PKI. Pour cela, il existe deux procédures standardisées :

  • Les listes de révocation de certificats (CRLs), téléchargeables depuis un service CDP (CRL Distribution Point) centralisé. Une CRL répertorie tous les certificats révoqués dans le contexte de l’AC.
  • Un service OCSP (Online Certificate Status Protocol) permettant d’obtenir le statut de révocation (révoqué ou non révoqué) d’un certificat en particulier.

Ces services permettent à toute partie concernée, souhaitant vérifier le certificat d’une autre partie, de contrôler le statut de révocation. Même si ce sont typiquement des services centralisés, ceux-ci peuvent être mis à disposition à différents points du réseau pour améliorer leur disponibilité et accessibilité. Les réponses des CRLs et des services OCSP ont une durée de validité spécifique et intègrent pour l’essentiel le même contenu. Par conséquent, ces services sont considérés comme offrant le même niveau de validation. Les réponses des CRLs et des services OCSP peuvent également être placées en cache afin d’en améliorer l’accessibilité.

Processus de révocation dans l’IoT

La procédure classique de validation de certificat (voir la RFC 5280) comprend la vérification du statut de révocation du certificat, basée sur une réponse de type CRL ou OCSP récemment demandée ou mise en cache. Dans le cadre d’une application de l’IoT, cela signifie que :

  • les machines chargées de la validation ont accès à un service CDP ou OCSP, ou encore à un composant stockant en mémoire cache les réponses de ces services.
  • le service CDP ou OCSP doit pouvoir satisfaire de gros volumes de requêtes.

Dans une infrastructure PKI classique, la révocation est déclenchée par des utilisateurs humains, typiquement après avoir constaté et signalé la compromission d’un hôte. Dans le cadre d’une application de l’IoT, un utilisateur ou un système de gestion des périphériques (par ex. une plateforme IoT) doit demander à l’AC la révocation du certificat concerné. Cela s’effectue généralement via l’interface de gestion des certificats de l’AC, et non via le service de support de l’AC.

Dans le cas d’une application IoT, il est utile de se demander :

  • Est-il réellement pertinent de révoquer le certificat des périphériques IoT ?

Si, par exemple, aucun risque matériel ou financier n’est lié à la perte d’un périphérique IoT, l’infrastructure de révocation est facultative. Malheureusement, il n’existe pas de façon standard de signaler dans un certificat qu’aucun service de révocation n’est disponible. Il sera nécessaire d’examiner le comportement du programme de validation dès lors que le certificat à valider ne présente aucune URL de service CDP ou OCSP. Dans ce cas, le programme de validation DEVRA supposer qu’aucune vérification du statut de révocation n’est requise.

  • Est-ce qu’un utilisateur humain a la possibilité de signaler la compromission d’un périphérique via un système de support, et existe-t-il un système de gestion capable de déclencher la révocation de certificats pour des périphériques ou des identités qui ne doivent plus être utilisés ?

S’il n’existe aucun moyen de signaler un cas de révocation, l’infrastructure de révocation est facultative.


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


Renouvellement des certificats dans l’IoT

Dans une infrastructure PKI classique, la validité des certificats est typiquement alignée sur la durée de vie garantie du périphérique concerné (par exemple une carte à puce ou un équipement IT) ou sur la validité de l’AC générant les certificats (laquelle peut être limitée afin d’éviter que les CRLs ne grossissent trop). Cette durée de validité peut être également limitée selon d’autres critères, par exemple dans le cadre du contrôle de l’identité des personnes ou de l’accréditation des détenteurs de certificat. Je recommande la lecture de cet article pour mieux cerner les raisons pour lesquelles les certificats ont une durée de validité : https://security.stackexchange.com/questions/58025/why-are-certificates-limited-in-time

Le renouvellement de certificats (renouvellement des clés ou recertification) nécessite l’accès à l’infrastructure d’AC centralisée, et par conséquent présente les mêmes contraintes en termes de fiabilité des communications au sein de l’IoT.

Dans le cadre d’une application IoT, il est utile de se demander :

  • Quelle est la durée de vie attendue du périphérique ? Y a-t-il des raisons, d’ordre organisationnel ou technique, de limiter la validité des certificats ?

Si ce n’est pas le cas, la durée de validité du certificat peut être définie de façon à couvrir la durée de vie attendue, être pratiquement infinie (par ex. l’an 9000) ou encore indéfinie (représentée par 99991231235959Z, conformément à la RFC 5280). L’algorithme de validation DOIT être capable d’interpréter correctement ces données de validité. Dans ce cas, le processus de renouvellement et l’interface correspondante sont facultatifs.

  • Sera-t-il nécessaire de changer l’identité du périphérique ?

Si ce n’est pas le cas, et que la durée de validité du certificat couvre la durée de vie du périphérique, le processus de renouvellement ainsi que l’interface correspondante sont facultatifs.

Validation en cas de connectivité internet peu fiable

Dans une infrastructure PKI classique, la partie en charge de la validation dispose d’un accès fiable au service CDP ou OCSP. Il est aisé de distribuer ces services vers différents nœuds en parallèle afin d’en améliorer la disponibilité et l’accessibilité. Dans un algorithme de validation standard, si aucune donnée de révocation n’est disponible, la requête de validation renverra un résultat négatif, avec pour conséquence l’impossibilité, par exemple, d’accéder à un service. Ce mécanisme est conçu pour éviter les « faux positifs », à savoir qu’un certificat révoqué soit validé avec succès. Le principe est d’accorder la priorité à la sécurité, au risque de perdre en disponibilité de service.

Toutefois, dans certains scénarios de l’IoT, l’accès à l’internet peut se trouver temporairement perturbé. Cela peut être le cas, par exemple, des périphériques qui se connectent à internet via une passerelle (un smartphone, par exemple) ou via un autre périphérique (un chargeur pour véhicule, par exemple). Cela peut également concerner les périphériques conçus pour se connecter à d’autres uniquement de façon ponctuelle, sans bénéficier d’une connexion stable à internet (les applications Car2Car, par exemple). Dans de tels cas, il convient de se demander :

  • Que se passe-t-il si le périphérique IoT en charge de la validation n’est pas en mesure de valider le certificat d’un service ou d’un autre périphérique ? Cela se traduira-t-il par l’impossibilité d’accéder à un service, ou par des problèmes d’exploitabilité ou de sécurité ?

Si les risques associés à la validation de faux positifs sont faibles, en termes de probabilité et/ou de dommages matériels ou financiers, il peut être décidé d’appliquer une tolérance pour ces faux positifs, au profit d’une meilleure disponibilité des services. Si les risques sont élevés, une approche plus stricte devra être adoptée.

  • Est-il possible de mettre les données de révocation en cache dans le périphérique en charge de la validation ou dans un autre équipement accessible (la passerelle, par exemple) ?

À titre d’exemple, un chargeur électrique de véhicules peut maintenir en cache les CRLs pour les certificats de tous les véhicules susceptibles de se connecter pour leur rechargement. Cela pourrait constituer une solution très efficace. Cependant, si l’AC couvre un parc automobile important, le téléchargement et le stockage des CRLs nécessiteront des taux de transfert et des capacités de stockage non négligeables. Dans de tels cas, le recours à un service OCSP pour la validation peut constituer une alternative intéressante.

  • La responsabilité d’obtenir les données de révocation peut-elle être transférée vers la partie en charge de l’authentification, connectée de façon fiable à l’internet ?

Cette approche est appelée « OCSP stapling », ou « agrafage OCSP » (RFC 6066). Dans l’exemple du chargeur ci-dessus, l’appareil peut fournir une réponse OCSP lors de l’authentification d’un véhicule électrique connecté. L’agrafage OCSP est pris en charge dans le cadre de l’authentification TLS côté serveur, mais n’est malheureusement pas pris en charge dans le cadre de l’authentification TLS côté client. Il est cependant possible d’implémenter cette fonctionnalité au niveau communication de l’application.

  • Le processus de révocation peut-il être remplacé par le renouvellement fréquent de certificats à durée de vie courte ?

Une telle approche permet de retirer à la partie responsable de la validation la charge d’accéder au service CDP ou OCSP. Au lieu de cela, la partie responsable de l’authentification, connectée de façon fiable, renouvelle son certificat à une fréquence similaire à celle à laquelle les CRLs seraient publiés. Le résultat obtenu est proche de celui de l’agrafage OCSP. L’avantage est que les services CDP et OCSP deviennent facultatifs, ce qui se traduit par une simplification de l’infrastructure PKI. L’AC doit néanmoins maintenir un liste noire (ou blanche) en interne, et refuser le renouvellement de certificat aux périphériques signalés comme compromis ou désactivés. Le renouvellement est pris en charge par les protocoles courants de gestion des certificats tels que SCEP, CMP ou EST. D’un autre côté, la distribution du service de renouvellement vers différents nœuds peut s’avérer plus complexe qu’avec un service CDP ou OCSP. Je pense que cette approche est intéressante dans certains cas, par exemple lorsque les certificats doivent de toute façon être renouvelés fréquemment, pour des raisons de confidentialité ou de non-traçabilité, ou lorsqu’il est nécessaire de minimiser la taille du code dans le périphérique responsable de la validation.

Révocation d’une AC racine

Dans une infrastructure PKI classique, la révocation d’une AC racine est déclarée via un mécanisme « out-of-band », par exemple via une page web dédiée, une publication officielle, ou d’autres moyens de diffusion de confiance. Les fournisseurs concernés et les administrateurs IT sont ensuite priés de retirer le certificat de l’AC racine des listes de certificats de confiance.

Typiquement, une fois installé sur site, un périphérique IoT ne dispose pas d’un second mécanisme de vérification du statut de révocation des certificats racines. Dans ce cas, il convient de se demander :

  • Existe-t-il un service de maintenance au sein de l’infrastructure, en mesure de retirer les certificats racines révoqués des listes de certificats de confiance auxquelles accèdent les périphériques ?

Cela est fréquemment le cas des véhicules communiquant via un service télématique avec les systèmes de gestion du fabricant. La maintenance des listes de confiance peut également être associée aux processus de mises à jour logicielles des périphériques. Afin de sécuriser ce type de communication, il est recommandé de disposer d’un système PKI indépendant, en mesure de valider les listes de certificats de confiance. Dans le cas contraire, une AC racine compromise serait susceptible de désactiver la validation de ces listes.

  • L’auto-déclaration de la révocation de l’AC racine dans sa propre CRL est une pratique inhabituelle, mais efficace. Cette approche est-elle envisageable pour votre application IoT ?

Le principe consiste à déclarer la compromission de l’AC racine via sa propre liste CRL, signée par la clé compromise. L’avantage est qu’aucun second canal ou mécanisme de maintenance n’est requis, dans la mesure où le périphérique est lui-même capable de détecter la compromission de l’AC racine. Cette approche nécessite cependant de s’assurer que le CDP n’est pas lui-même compromis. Notez également que ce type de procédure n’est pas supporté par l’algorithme de validation standard (RFC 5280), et que par conséquent une implémentation spécifique sera nécessaire. En revanche, l’algorithme de validation standard produira des retours négatifs sans l’aide d’un canal supplémentaire ou de code additionnel.

Conclusion

L’algorithme de validation standard, tel que défini dans la RFC 5280, présuppose une connexion fiable à une infrastructure centralisée de validation/révocation, i.e. un service CDP et/ou OCSP. Dans l’internet des objets, la connectivité à de tels services centralisés peut ne pas être aussi fiable que souhaité pour une exploitation à haute disponibilité. Ainsi, cette connexion aux services centralisés passe-t-elle fréquemment par une passerelle ou un périphérique tiers. La stricte application du processus de validation standard peut entraîner des pertes de disponibilité ou d’exploitabilité.

Dans cet article, nous avons évoqué un certain nombre de scénarios possibles, susceptibles d’améliorer la disponibilité et l’exploitabilité des services IoT. Ces améliorations peuvent être obtenues par des changements mineurs dans l’exploitation de la validité des certificats ou des algorithmes de validation, ainsi qu’à des approches impliquant la mise en cache des données de révocation, l’agrafage OCSP, la fréquence de renouvellement des certificats, ou encore l’auto-déclaration de la compromission d’une AC racine. Notre conclusion est que l’architecte logiciel doit tenir prioritairement compte de la nature de l’application, et choisir en conséquence parmi les différentes options permettant d’optimiser les performances globales du système PKI IoT. Le présent recensement de recommandations et d’approches ne saurait être exhaustif, et se propose essentiellement d’ouvrir à des développements ultérieurs.

Bâtir une infrastructure IoT sécurisée

Published 5/10 2018

News and Blog