DigiNotar: l'échec d'une autorité de certification comme test de contrôle du préjudice opérationnel

Résumé

• La violation de 2011 de DigiNotar a produit des certificats frauduleux, y compris un certificat utilisé dans des tentatives d'attaques de l'homme du milieu contre des utilisateurs de Google principalement situés en Iran, et a forcé les fournisseurs de navigateurs et de systèmes d'exploitation à supprimer ou à ne plus faire confiance aux certificats DigiNotar.
• Mozilla a publiquement critiqué DigiNotar pour avoir détecté et révoqué certains certificats frauduleux des semaines plus tôt sans en informer Mozilla. Microsoft a par la suite jugé tous les certificats DigiNotar non fiables. L'ENISA a décrit l'événement comme une attaque contre les fondements des communications électroniques sécurisées.
• La dépendance du secteur public néerlandais a fait de l'événement plus qu'un simple nettoyage par les fournisseurs de navigateurs. DigiNotar a émis des certificats liés aux services d'ICP gouvernementaux, et la perte de confiance a créé un problème de continuité pour les sites web et services gouvernementaux qui ont dû migrer sous une pression d'urgence.
• Le dossier étaye une conclusion de responsabilité à haute confiance concernant le contrôle opérationnel de l'AC, la notification tardive et la gouvernance des programmes racines. Il n'étaye pas l'affirmation selon laquelle chaque certificat a été utilisé de manière abusive, que chaque service gouvernemental a échoué ou que les pratiques actuelles en matière d'ICP sont inchangées depuis 2011.

Registre des preuves et son utilisation

Cet article utilise les sources Fox-IT, ENISA, Mozilla, Google, Microsoft, VASCO, HKCERT, CCDCOE, universitaires, CA/Browser Forum, programmes racines, RFC, Certificate Transparency, NIST et ENISA DNS pour séparer les faits de l'incident, la gouvernance de la confiance publique et les leçons de continuité opérationnelle.

Une compromission d'AC modifie la réalité de l'utilisateur avant que celui-ci ne le sache

L'événement DigiNotar a été grave parce que les autorités de certification se trouvent sur le chemin de la confiance invisible. Un utilisateur qui visite un site familier ne choisit généralement pas une AC. Le navigateur ou le système d'exploitation fait déjà confiance à un ensemble de racines. Si une AC peut émettre un certificat frauduleux pour un domaine qu'elle ne contrôle pas, un attaquant peut être en mesure d'usurper ce domaine auprès des clients qui font confiance à l'AC. L'utilisateur voit une connexion cryptée valide alors que l'affirmation de confiance est fausse.

Le billet de blog de sécurité de Google d'août 2011 décrit des signalements de tentatives d'attaques SSL de l'homme du milieu contre des utilisateurs de Google, principalement en Iran, utilisant un certificat frauduleux émis par DigiNotar. L'avis de Mozilla a également décrit une attaque MITM active sur les connexions SSL sécurisées aux serveurs de Google et a noté que le certificat frauduleux avait été émis à tort par DigiNotar. Il ne s'agit pas de risques PKI abstraits. Ce sont des conséquences visibles pour les utilisateurs d'une défaillance de contrôle de l'AC.

Le rapport intermédiaire Fox-IT, publié par le biais d'un dépôt auprès de la SEC de VASCO, a défini son objectif comme étant de donner aux parties prenantes suffisamment d'informations pour effectuer leur propre analyse des risques tout en retenant certains détails sensibles. C'est exactement la tension dans un incident d'AC. Le public a besoin de suffisamment d'informations pour décider si la confiance reste sûre. L'enquêteur ne peut pas publier toutes les techniques qui aideraient les attaquants. L'AC est incitée à préserver la confiance. Les fournisseurs de navigateurs doivent agir rapidement car leurs utilisateurs sont exposés.

Le contrôle de DigiNotar sur le préjudice existait donc avant que le public ne connaisse le préjudice. L'AC contrôlait les systèmes d'émission, la segmentation réseau, la journalisation, la révocation, la détection d'incident, la notification et l'intégrité des intermédiaires liés au gouvernement. Une fois les certificats frauduleux créés, les fournisseurs de navigateurs et les gouvernements contrôlaient la méfiance d'urgence et la migration. Les utilisateurs ne contrôlaient presque rien, sauf de mettre à jour leur logiciel ou d'arrêter d'utiliser les services concernés après avoir été prévenus par quelqu'un d'autre.

Le retard de notification n'était pas un défaut de relations publiques

Le suivi de la suppression par Mozilla est l'un des documents de responsabilité les plus clairs du dossier. Il indique que DigiNotar a détecté et révoqué certains certificats frauduleux six semaines plus tôt sans en informer Mozilla, et que certains de ces certificats concernaient les propres domaines de Mozilla. Le problème n'est pas l'étiquette. Les programmes racines reposent sur une notification rapide des incidents, car les fournisseurs de navigateurs sont les parties qui peuvent protéger les utilisateurs à grande échelle en mettant à jour les décisions de confiance.

Une AC peut penser qu'elle a révoqué les certificats malveillants connus et contenu une intrusion. Cette croyance ne suffit pas lorsque l'AC ne peut pas prouver l'étendue complète de la compromission. L'avis de Mozilla indiquait que DigiNotar avait signalé des preuves que d'autres certificats frauduleux avaient été émis et étaient activement utilisés, mais que l'étendue complète n'était pas connue. Microsoft a d'abord retiré deux racines DigiNotar des listes de confiance, puis a mis à jour sa réponse pour déplacer tous les certificats DigiNotar dans le magasin de certificats non fiables. L'incertitude a entraîné une escalade.

Le retard de notification modifie la courbe des préjudices. Pendant ce délai, les parties utilisatrices continuent de faire confiance à des certificats qui peuvent ne pas être dignes de confiance. Les fournisseurs de navigateurs ne peuvent pas déployer de mises à jour de méfiance. Les propriétaires de domaine ne savent pas qu'ils doivent rechercher des certificats frauduleux. Les services gouvernementaux peuvent continuer à planifier comme si l'AC était intacte. Les utilisateurs peuvent être ciblés par des attaques MITM sans avoir de réelle chance de détecter la défaillance de l'AC.

C'est pourquoi la divulgation d'incident pour une AC doit être plus rapide et plus complète que la divulgation ordinaire des fournisseurs. L'AC ne protège pas seulement ses propres clients. Elle protège toutes les personnes dont le logiciel fait confiance à sa racine. Un retard de notification transforme l'ensemble de l'écosystème des parties utilisatrices en une population à risque non avertie.

La dépendance du gouvernement néerlandais a changé le rayon d'explosion

DigiNotar n'était pas seulement une AC commerciale. Les sources publiques décrivent son rôle dans l'infrastructure de certificats du gouvernement néerlandais. Ce rôle a rendu la méfiance opérationnellement difficile. Si un fournisseur de navigateur supprimait simplement toute confiance à DigiNotar immédiatement, les services gouvernementaux utilisant des certificats liés à DigiNotar pourraient devenir difficiles ou impossibles d'accès. Si la confiance était maintenue temporairement, les utilisateurs pourraient être exposés à des certificats frauduleux. C'est le piège de la dépendance de l'ICP du secteur public.

Le résumé de l'ENISA sur l'opération Black Tulip indique que de faux certificats ont été créés pour des centaines de sites web, y compris Google et Skype, et que le gouvernement néerlandais et les fournisseurs de navigateurs ont pris des mesures une fois l'incident devenu public. L'analyse du Journal of Strategic Security traite l'événement comme le premier désastre numérique néerlandais, car il a relié la défaillance d'une AC privée à la dépendance nationale des services publics.

L'annonce de faillite de VASCO montre le point final de l'entreprise: DigiNotar a déposé une demande de faillite volontaire et a été déclarée en faillite en septembre 2011.

Le problème de continuité n'était pas théorique. Les services gouvernementaux s'appuient sur les certificats TLS pour l'identité, la confidentialité et la confiance. Le remplacement des certificats dans les agences et les systèmes nécessite une coordination: nouveaux fournisseurs, validation, déploiement, tests, conseils aux utilisateurs et compatibilité avec les navigateurs. Si l'AC a perdu la confiance, chaque jour de transition comporte des risques. Si la transition est accélérée, les services peuvent tomber en panne.

Cela fait de DigiNotar un cas de continuité du secteur public. Un gouvernement peut externaliser l'émission de certificats, mais il ne peut pas externaliser la conséquence publique d'un effondrement de la confiance. Les achats doivent se demander si une AC dispose de contrôles opérationnels solides, d'audits indépendants, d'obligations de notification d'incident, de plans de migration d'urgence et d'une position dans les programmes racines. Il doit également se demander à quelle vitesse les certificats peuvent être remplacés si la confiance est retirée soudainement.

Les fournisseurs de navigateurs ont agi en tant que gouverneurs d'urgence

Lorsque le système de confiance publique échoue, les fournisseurs de navigateurs et de systèmes d'exploitation deviennent des gouverneurs d'urgence. Mozilla a retiré sa confiance. Microsoft a déplacé les certificats DigiNotar dans le magasin de certificats non fiables. Google a averti les utilisateurs et utilisé les mécanismes de sécurité du navigateur pour répondre. HKCERT a publié des conseils publics. Ces actions ont protégé les utilisateurs, mais elles ont également interrompu ou menacé l'accès aux services qui dépendaient de DigiNotar.

Ce double rôle est inconfortable mais nécessaire. Un programme racine n'est pas une liste passive. C'est un système de gouvernance. La politique actuelle du magasin racine de Mozilla et les exigences du programme Microsoft Trusted Root rendent explicite ce que le cas DigiNotar a démontré: l'inclusion est conditionnelle à la conformité continue, à la divulgation, aux audits et aux contrôles de sécurité. Une racine de confiance est un privilège de sécurité publique, pas un droit de propriété permanent.

La méfiance d'urgence est un contrôle brutal. Elle peut protéger les utilisateurs contre les certificats frauduleux, mais elle ne peut pas distinguer chaque certificat légitime hérité de chaque certificat malveillant de manière à préserver toute la continuité du service. C'est pourquoi les contrôles des AC et la divulgation rapide sont si importants en amont. Si les fournisseurs de navigateurs doivent choisir entre une méfiance globale et une exposition continue, l'AC a déjà échoué à un niveau que les acteurs en aval ne peuvent pas réparer gracieusement.

L'événement a également contribué à motiver des mécanismes d'écosystème plus solides. Certificate Transparency, désormais un élément central de l'ICP publique du web, rend les certificats visibles publiquement afin que les propriétaires de domaine, les navigateurs et les surveillants puissent détecter plus tôt les émissions frauduleuses. Le CT ne remplace pas totalement la sécurité des AC, mais il réduit la probabilité qu'un certificat frauduleux reste caché pendant des semaines. DigiNotar fait partie de l'histoire qui a rendu le comportement silencieux des AC moins acceptable.

Le contrôle opérationnel suit la capacité à limiter le préjudice

L'expression contrôle opérationnel du préjudice est délibérée. DigiNotar ne contrôlait pas l'attaquant. Elle contrôlait si ses systèmes d'AC étaient segmentés, mis à jour, surveillés, journalisés et gérés avec une protection appropriée des clés. Elle contrôlait si l'émission anormale était détectée et escaladée. Elle contrôlait si les fournisseurs de navigateurs étaient informés lorsque des certificats frauduleux étaient trouvés. Elle contrôlait la quantité de preuves que les enquêteurs pouvaient récupérer.

Les documents de Fox-IT et de l'ENISA pointent des défaillances de mesures de sécurité de base et des préoccupations de compromission généralisée. Les détails techniques exacts doivent être traités avec soin, mais le dossier public est suffisamment solide pour montrer que les pratiques de contrôle étaient inadéquates pour une AC de confiance publique. Les systèmes d'une AC ne sont pas une informatique d'entreprise ordinaire. Ce sont des machines à produire des assertions que les navigateurs et les systèmes d'exploitation acceptent globalement. Une défaillance de contrôle de base à ce niveau devient un préjudice public.

Les exigences de base du CA/B Forum et les directives de gestion des clés du NIST fournissent un vocabulaire moderne pour ce devoir: gestion du cycle de vie, preuve d'identité, audit, protection des clés, révocation et sécurité des systèmes. Ces normes ne doivent pas être lues comme si chaque contrôle de 2026 existait à l'identique en 2011. Elles sont utiles car elles montrent ce que l'écosystème a appris à formaliser. Une AC doit être capable de prouver non seulement que les certificats sont émis, mais que l'autorité d'émission ne peut pas être capturée silencieusement.

Le contrôle opérationnel inclut également la communication sur le préjudice. Une AC qui ne peut pas délimiter l'ensemble des certificats frauduleux ne peut pas demander de manière responsable au monde de continuer à lui faire confiance. Une AC qui connaît des certificats frauduleux et retarde la notification contrôle une fenêtre pendant laquelle d'autres sont exposés à leur insu. Une AC qui dessert des fonctions gouvernementales contrôle le calendrier selon lequel les agences doivent migrer. Dans chaque cas, le contrôle des preuves est un contrôle du préjudice.

La révocation était insuffisante car la confiance s'était déjà effondrée

Dans les opérations de certificats ordinaires, la révocation est le mécanisme permettant de dire qu'un certificat spécifique ne doit plus être approuvé. L'événement DigiNotar est allé au-delà de la révocation ordinaire. Si l'émetteur lui-même est compromis et ne peut pas prouver l'ensemble complet des certificats frauduleux, les parties utilisatrices ne peuvent pas supposer en toute sécurité que seuls les certificats connus sont mauvais. C'est pourquoi les fournisseurs de navigateurs sont passés de la révocation ou de la méfiance de racines spécifiques à une méfiance plus large.

Cette distinction est centrale. La révocation traite les feuilles connues comme mauvaises. La méfiance de la racine traite du manque de fiabilité de l'émetteur. La première est chirurgicale. La seconde est systémique. L'échec de DigiNotar est devenu systémique parce que le dossier public ne pouvait pas soutenir la confiance que l'environnement de l'AC était fiable et que tous les certificats frauduleux étaient connus et révoqués.

Les utilisateurs comprennent rarement cette distinction. Ils la ressentent comme des mises à jour logicielles, des pages d'avertissement ou des services bloqués. Les exploitants de services la ressentent comme un remplacement d'urgence des certificats. Les gouvernements la ressentent comme une planification de la continuité. Les fournisseurs de navigateurs la ressentent comme une décision de risque dans l'incertitude. L'incapacité de l'AC à prouver l'étendue oblige tout le monde à une réponse coûteuse.

La journalisation moderne de CT, des audits plus stricts et des processus d'incident des programmes racines sont conçus pour réduire cette incertitude. Ils ne l'éliminent pas. Une AC qui perd le contrôle de l'émission crée toujours une crise. La question opérationnelle reste de savoir si l'étendue peut être mesurée assez rapidement pour éviter une méfiance au niveau racine.

Les acheteurs de services publics ne devraient pas traiter le choix de l'AC comme une commodité

Les certificats TLS sont souvent bon marché, automatisés et routiniers. Cela rend tentant de traiter le choix de l'AC comme une note de bas de page d'achat. DigiNotar montre pourquoi cela est dangereux pour les services publics. Le statut de confiance de l'AC peut déterminer si les citoyens peuvent atteindre en toute sécurité les sites gouvernementaux. La gestion des incidents par l'AC peut déterminer si les fournisseurs de navigateurs maintiennent leur confiance. La qualité de l'audit de l'AC peut déterminer si la compromission est détectée avant que les certificats frauduleux ne soient utilisés de manière abusive.

Les acheteurs de services publics devraient demander des preuves. Quels programmes racines incluent l'AC? Quels audits sont publics? Comment les systèmes d'émission sont-ils segmentés? Comment les clés privées sont-elles protégées? Comment l'émission anormale est-elle détectée? À quelle vitesse les incidents sont-ils signalés aux programmes racines, aux régulateurs, aux abonnés et aux propriétaires de domaine concernés? Combien d'AC alternatives peuvent émettre des remplacements d'urgence? Comment les certificats sont-ils inventoriés dans les agences? À quelle vitesse une migration complète peut-elle être exécutée?

Ils devraient également éviter la concentration. Une seule AC ou un fournisseur de certificats géré peut être efficace, mais peut devenir une dépendance en mode commun. Un gouvernement qui s'appuie sur une seule AC pour de nombreuses agences devrait maintenir un chemin d'urgence vers d'autres fournisseurs, y compris les enregistrements de validation, l'automatisation et les procédures de déploiement testées. Sinon, la méfiance envers un seul fournisseur devient une interruption de service public.

Le pouvoir de délégation DNS importe ici car les certificats lient les noms de domaine aux clés publiques. Le contrôle de domaine, la validation d'AC, les enregistrements DNS et la confiance publique sont liés. Si les processus d'identité de domaine sont faibles, l'émission de certificats peut être abusive. Si les certificats ne sont pas approuvés, les noms de domaine peuvent se résoudre correctement mais échouer de manière sécurisée au niveau du navigateur. La continuité publique dépend à la fois du contrôle DNS et de l'ICP.

Ce que le dossier ne prouve pas

Le dossier public ne prouve pas que chaque certificat frauduleux a été utilisé dans une attaque active. Il ne prouve pas que tous les services gouvernementaux néerlandais étaient indisponibles pendant la même durée ou pour la même raison. Il ne prouve pas que chaque employé de DigiNotar connaissait ou a causé la défaillance. Il ne prouve pas une attribution finale complète pour l'attaquant. Il ne prouve pas non plus que la gouvernance actuelle des AC est identique à celle de 2011.

Ces limites n'affaiblissent pas la conclusion de responsabilité. Elles l'affinent. Un incident d'AC est dangereux précisément lorsque l'ensemble complet des mauvais certificats, des utilisations et des parties affectées est incertain. Le manque de connaissances complètes n'est pas une raison pour préserver la confiance. C'est une raison pour laquelle les programmes racines peuvent devoir retirer la confiance.

Le dossier ne doit pas non plus être utilisé pour affirmer que toute externalisation des services d'AC est dangereuse. L'ICP de confiance publique est un écosystème parce qu'aucun site web ou agence ne peut maintenir seul la confiance globale des navigateurs. La leçon n'est pas l'isolement auto-émis. La leçon est une externalisation disciplinée avec des preuves publiques, une migration d'urgence et une responsabilité claire en matière de notification.

La faillite de DigiNotar est pertinente mais n'est pas la mesure du préjudice. Une entreprise peut échouer commercialement après avoir perdu la confiance, mais le préjudice public plus large est la période pendant laquelle les utilisateurs, les gouvernements et les navigateurs ont dû fonctionner dans l'incertitude. C'est la surface de responsabilité.

Tests pratiques de responsabilité

Une autorité de certification devrait pouvoir répondre à plusieurs questions avant un incident. Peut-elle prouver que les systèmes d'émission sont isolés d'une compromission d'entreprise ordinaire? Peut-elle détecter rapidement la génération non autorisée de certificats? Peut-elle produire un inventaire complet des certificats? Peut-elle révoquer à grande échelle? Peut-elle informer immédiatement les programmes racines et les abonnés? Peut-elle préserver les journaux contre la suppression par un attaquant? Peut-elle démontrer que les intermédiaires gouvernementaux ou à haut risque sont protégés séparément?

Les programmes racines devraient se demander si les rapports d'incident sont rapides, spécifiques et vérifiables indépendamment. Ils devraient exiger suffisamment d'informations publiques pour que les propriétaires de domaine et les parties utilisatrices puissent agir. Ils devraient garder les mécanismes de méfiance d'urgence prêts, car la protection des utilisateurs ne peut pas attendre un dossier juridique parfait.

Les acheteurs gouvernementaux devraient maintenir des inventaires de certificats et des manuels de remplacement d'urgence. Ils devraient savoir quels services publics dépendent de quelle AC, quelle AC alternative peut émettre des remplacements, quelles étapes de validation DNS sont nécessaires et quelle agence a l'autorité pour pousser les changements pendant une crise. Ils devraient tester les messages destinés aux utilisateurs qui expliquent l'échec de confiance sans encourager un comportement dangereux de clic.

Les propriétaires de domaine devraient surveiller l'émission de certificats pour leurs domaines via les journaux CT et les services associés. Ils ne devraient pas supposer que l'absence de nouvelles signifie l'absence d'émission frauduleuse. Le dossier DigiNotar montre comment un certificat frauduleux peut être découvert en dehors de l'AC et en dehors des opérations normales du propriétaire du domaine victime.

Le contrôle du préjudice appartient à la première heure de l'incident

La première heure d'un incident d'AC n'est pas seulement pour le confinement. C'est pour décider qui d'autre doit pouvoir contenir. Le retard de DigiNotar montre pourquoi. Si l'AC garde l'incident à l'intérieur de ses murs jusqu'à ce qu'elle comprenne tout, elle peut préserver sa propre option tout en refusant l'option aux navigateurs, aux systèmes d'exploitation, aux propriétaires de domaine, aux gouvernements et aux utilisateurs. Ces acteurs en aval peuvent détenir les seuls contrôles qui peuvent protéger les parties utilisatrices à grande échelle.

Un plan d'incident d'AC moderne devrait donc contenir deux pistes. La piste forensique préserve les preuves, identifie les mouvements de l'attaquant, énumère les certificats et détermine l'exposition de la racine ou de l'intermédiaire. La piste de l'écosystème notifie les programmes racines, les abonnés, les propriétaires de domaine concernés, les fournisseurs de navigateurs, les régulateurs et les partenaires de services publics avec des faits délimités. La piste de l'écosystème ne devrait pas attendre la clôture forensique parfaite.

Elle devrait dire ce qui est connu, ce qui est suspecté, ce qui a été révoqué, ce qui ne peut pas encore être exclu et quand la prochaine mise à jour arrivera.

Pour les services gouvernementaux, le contrôle du préjudice nécessite également une autorité de migration. Si une AC n'est plus approuvée, quelqu'un doit pouvoir ordonner le remplacement des certificats dans les agences, valider les nouveaux certificats, coordonner les modifications DNS ou ACME, mettre à jour la documentation, informer les citoyens et mesurer la restauration du service. Un inventaire de certificats du secteur public qui n'existe que sous forme de feuilles de calcul dispersées ne suffit pas.

La migration d'urgence doit être répétée car la méfiance de la racine comprime les fenêtres normales d'approvisionnement et de changement en heures ou en jours.

Le dossier DigiNotar est donc un avertissement sur la latence des preuves. Plus il faut de temps pour connaître l'ensemble des certificats concernés, plus les navigateurs doivent choisir entre la confiance et la méfiance générale. Plus il faut de temps pour informer les exploitants gouvernementaux, moins ils ont de temps pour migrer en douceur. Plus les utilisateurs sont laissés sans mises à jour, plus ils sont susceptibles de continuer à faire confiance à une assurance invalide. Le contrôle du préjudice opérationnel commence lorsque l'AC informe suffisamment l'écosystème pour agir.

Le problème des services gouvernementaux était la migration sous méfiance

Le problème opérationnel le plus difficile dans le dossier DigiNotar n'était pas simplement de décider que la confiance avait échoué. C'était de migrer les services légitimes loin d'une ancre de confiance après cette décision. Les services gouvernementaux ne peuvent normalement pas changer les certificats publics par improvisation. Ils ont besoin de validation, de fenêtres de déploiement, de tests, d'étapes DNS ou ACME, d'approbation du propriétaire du service, de conseils aux utilisateurs et d'un moyen de vérifier que les anciens certificats ne sont plus utilisés.

Lorsqu'une AC n'est plus approuvée, ces étapes ordinaires sont comprimées par l'urgence de la sécurité.

Cette compression crée deux risques. Agir trop lentement expose les utilisateurs à des certificats frauduleux ou à l'incertitude quant à l'authenticité du service. Agir trop rapidement peut interrompre l'accès public, en particulier pour les systèmes avec des clients fragiles, des intermédiaires codés en dur, des certificats épinglés ou des points de terminaison gérés par des fournisseurs.

L'acheteur gouvernemental responsable devrait donc savoir avant une crise quelles agences utilisent quelle AC, quels fournisseurs alternatifs peuvent émettre des remplacements, quels enregistrements de validation sont prêts et quels propriétaires techniques peuvent déployer des modifications. DigiNotar montre qu'un inventaire de certificats n'est pas un atout administratif. C'est un atout de continuité.

Le problème de la communication publique est tout aussi important. Si les citoyens voient des avertissements de certificat sur les sites gouvernementaux pendant une crise d'AC, les responsables doivent éviter deux mauvais messages. Le premier mauvais message est ignorez l'avertissement. Cela enseigne un comportement dangereux. Le second est cesser indéfiniment d'utiliser les services numériques. Cela peut interrompre les obligations légales, les prestations, les permis et les communications essentielles.

Une réponse mature indique aux citoyens quels domaines officiels sont concernés, quand le remplacement est prévu, quels canaux restent sûrs et comment vérifier les mises à jour.

C'est là que DigiNotar devient un cas de gouvernance plutôt qu'un simple cas de sécurité des AC. La défaillance d'une AC privée a forcé les autorités publiques à gérer le retrait de confiance pour les services publics. L'État a dû convertir une décision de sécurité du programme racine en continuité pour les citoyens. Cette conversion devrait être planifiée à l'avance pour tout service public numérique critique.

L'audit ne suffit pas si les preuves d'incident sont retardées

Les autorités de certification sont depuis longtemps associées aux audits, aux politiques et aux artefacts de conformité. Ces artefacts comptent, mais DigiNotar montre leurs limites lors d'une compromission active. Un audit peut décrire un environnement de contrôle à un moment donné. Un incident nécessite des preuves sur ce qui s'est passé, ce qui a été émis, ce qui a été révoqué, quels systèmes ont été touchés, quels journaux peuvent être approuvés et qui a été informé. Si ces preuves sont retardées ou incomplètes, les parties utilisatrices ne peuvent pas attendre le prochain cycle d'audit.

Les preuves d'incident d'une AC devraient être traitées comme une fonction de sécurité publique en direct. Les faits les plus importants ne sont pas seulement internes: noms et numéros de série des certificats concernés, heure d'émission, heure de révocation, étendue suspectée, exposition de la racine ou de l'intermédiaire, journaux préservés, abonnés contactés, programmes racines informés et action recommandée pour le client. Certains détails sensibles peuvent rester confidentiels, mais les faits d'action doivent circuler rapidement.

La critique de Mozilla concernant le retard de notification est puissante car elle identifie un échec du routage des preuves, et pas seulement un échec de la défense technique.

L'ICP publique moderne dispose de plus de mécanismes pour cela qu'en 2011. Les journaux de Certificate Transparency peuvent exposer les certificats émis. Le CCADB et les politiques des programmes racines peuvent structurer les rapports d'incident. Les fournisseurs de navigateurs peuvent coordonner les décisions de méfiance. Les exigences du CA/B Forum peuvent définir les attentes. Mais les mécanismes ne servent à rien si une AC hésite à les utiliser. La leçon de gouvernance de DigiNotar est que la confiance dépend du comportement lors d'un échec, pas seulement de la réussite des documents annuels.

Pour les clients et les gouvernements, cela signifie que la diligence raisonnable devrait interroger explicitement sur les preuves d'incident. À quelle vitesse l'AC informera-t-elle les programmes racines? Comment les propriétaires de domaine sont-ils alertés des émissions suspectes? Dans quelle mesure les journaux sont-ils complets? Que se passe-t-il si l'AC ne peut pas prouver l'étendue? Quel rapport public sera disponible? Un fournisseur qui ne peut pas répondre à ces questions n'est pas prêt à détenir la confiance publique pour des services critiques.

DigiNotar explique pourquoi la méfiance de la racine peut être la moins mauvaise option

La méfiance de la racine est perturbatrice, il y a donc toujours une pression pour l'éviter. Les sites web peuvent casser. Les portails gouvernementaux peuvent échouer. Les anciens clients peuvent perdre l'accès. Les entreprises peuvent subir de graves conséquences commerciales. La faillite de DigiNotar montre que la méfiance peut être commercialement fatale. Ces coûts sont réels et ne doivent pas être balayés.

Pourtant, l'alternative peut être pire. Si une AC ne peut pas prouver quels certificats ont été émis frauduleusement, continuer à faire confiance signifie que chaque utilisateur qui s'appuie reste exposé à un ensemble inconnu d'usurpations possibles. Le fournisseur de navigateur devient alors responsable de la protection des utilisateurs avec des preuves incomplètes. Dans cette situation, la méfiance peut être la moins mauvaise option car elle échoue de manière fermée. Elle donne la priorité à la protection des utilisateurs plutôt qu'à la continuité d'une relation de confiance qui ne peut plus être vérifiée.

C'est pourquoi la responsabilité opérationnelle de l'AC est plus stricte que la responsabilité ordinaire d'un fournisseur. Une panne SaaS normale peut être atténuée en attendant la restauration. Un échec de confiance d'une AC peut nécessiter que l'écosystème cesse de faire confiance au fournisseur avant que celui-ci n'ait fini d'enquêter. L'incapacité de l'AC à prouver la sécurité devient une preuve contre le maintien de la confiance. C'est une norme sévère, mais elle découle du privilège de l'AC: elle peut émettre des assertions pour les domaines d'autres personnes que les navigateurs acceptent globalement.

La leçon pour la continuité du secteur public est que la méfiance d'urgence doit être incluse dans la planification. Un gouvernement ne peut pas supposer que chaque racine de confiance le restera. Il devrait savoir comment remplacer les certificats à grande échelle, comment communiquer un événement de méfiance et comment préserver l'accès aux services sans affaiblir la sécurité des utilisateurs. DigiNotar a rendu ce besoin visible.

Le prisme de la sécurité des utilisateurs devrait guider la remédiation

Une compromission d'AC peut facilement devenir un argument entre institutions: l'AC, sa société mère, les auditeurs, les fournisseurs de navigateurs, les gouvernements et les régulateurs. Le prisme de la sécurité des utilisateurs maintient l'argument au sol. De quoi l'utilisateur a-t-il besoin pour être protégé contre l'usurpation? De quoi le citoyen a-t-il besoin pour accéder à un service public légitime? De quoi le propriétaire de domaine a-t-il besoin pour savoir si son nom a été utilisé de manière abusive? De quoi le fournisseur de navigateur a-t-il besoin pour livrer une mise à jour sûre?

De quoi le gouvernement a-t-il besoin pour migrer sans dire aux gens d'ignorer les avertissements?

Lorsque ces questions guident la remédiation, la carte des responsabilités devient plus claire. DigiNotar devait fournir des preuves et arrêter l'émission dangereuse. Les fournisseurs de navigateurs devaient retirer leur confiance là où les preuves étaient insuffisantes. Les exploitants gouvernementaux devaient migrer et communiquer. Les propriétaires de domaine devaient surveiller et répondre. Les utilisateurs devaient recevoir des mises à jour, mais ils n'auraient pas dû être invités à résoudre le problème d'ICP eux-mêmes.

Ce prisme de la sécurité des utilisateurs limite également les affirmations excessives. Il n'exige pas la preuve que chaque certificat frauduleux a été exploité avant que des mesures ne soient prises. Il n'exige pas de blâmer chaque partie utilisatrice pour avoir fait confiance à une racine acceptée par l'écosystème. Il n'exige pas de prétendre que la méfiance d'urgence est indolore. Il demande quelle action limite le mieux le préjudice pour les personnes qui ne peuvent pas inspecter les rouages internes de l'AC.

La valeur durable de DigiNotar est qu'elle transforme la gouvernance cachée des AC en sécurité publique visible. La compromission a clairement montré que le tissu de confiance du web n'est aussi solide que son émetteur de confiance le plus faible et aussi responsable que ses preuves honnêtes les plus rapides. Cela reste une norme pertinente pour chaque AC de confiance publique.

La planification de la continuité doit inclure la propagation du magasin de confiance

DigiNotar expose également un problème de propagation facile à sous-estimer. Les fournisseurs de navigateurs et de systèmes d'exploitation peuvent décider rapidement de ne plus faire confiance à une AC, mais la protection n'atteint les utilisateurs que lorsque les mises à jour logicielles arrivent, que les entreprises gérées les approuvent, que les anciens appareils les reçoivent et que les applications utilisent réellement le magasin mis à jour. Certains clients peuvent utiliser des ensembles privés ou des appareils qui ne suivent pas le système d'exploitation.

D'autres peuvent se trouver derrière des proxys d'entreprise qui modifient le comportement de validation des certificats. Une décision de programme racine est donc un début de protection, pas la fin de la protection.

Pour les services gouvernementaux, cela signifie que la planification de la continuité doit suivre les deux côtés de la migration. Le service public doit remplacer ses propres certificats suspects, mais il doit également comprendre si les citoyens et les employés publics ont reçu la mise à jour de méfiance qui les protège de l'usurpation. Un centre d'appels peut avoir besoin d'expliquer pourquoi une mise à jour du navigateur est importante. Un administrateur système peut avoir besoin de vérifier que les postes de travail gérés, les kiosques et les appareils mobiles disposent de magasins racines à jour.

Une équipe de sécurité peut avoir besoin de surveiller si un trafic accepte encore la chaîne non approuvée.

Ce problème de propagation est une autre raison pour laquelle le retard de notification est si grave. Chaque jour perdu avant que les fournisseurs de navigateurs et les gouvernements n'apprennent suffisamment pour agir devient un jour ajouté à une chaîne de distribution déjà lente. L'AC peut révoquer un certificat rapidement après la découverte, mais la protection pratique des utilisateurs dépend toujours des chemins de mise à jour en aval.

Le dossier DigiNotar montre que le préjudice opérationnel n'est limité que lorsque les preuves, les décisions de méfiance, le remplacement des certificats et la propagation des mises à jour du client atteignent tous la population qui s'appuie.

Cette même chaîne de distribution devrait être testée avant une crise. Un ministère, un réseau hospitalier, une banque ou un système judiciaire qui dépend du TLS public devrait savoir si les postes de travail gérés utilisent le magasin du système d'exploitation, un magasin de navigateur, un magasin de proxy, un ensemble Java, un profil de gestion des appareils mobiles ou un ensemble de confiance d'appareil. Il devrait savoir qui peut mettre à jour chaque magasin et à quelle vitesse. Il devrait également savoir quels services publics accessibles peuvent remplacer les certificats sans temps d'arrêt.

DigiNotar a compté parce qu'elle a transformé ces questions d'inventaire tranquilles en questions de continuité urgentes. L'organisation qui peut y répondre avant la méfiance a une chance de protéger les utilisateurs sans leur apprendre à contourner les avertissements.

La norme de preuve devrait être tout aussi concrète. Un service public ne devrait pas simplement dire que les certificats ont été remplacés; il devrait conserver une liste des points de terminaison concernés, des heures de remplacement, des avis aux utilisateurs, des contacts fournisseurs et des populations de clients qui peuvent encore s'appuyer sur une confiance obsolète. Ce dossier aide les examinateurs ultérieurs à séparer la douleur de transition inévitable du retard évitable. Il protège également le public d'un faux choix entre l'accès et la sécurité.

L'objectif n'est pas de maintenir une ancre de confiance défaillante pour des raisons de commodité. L'objectif est de migrer les services légitimes assez rapidement pour que la méfiance puisse protéger les utilisateurs sans les laisser bloqués.

L'essentiel pour la responsabilité

L'échec de DigiNotar a changé la signification pratique de la confiance dans les AC. Il a montré que les contrôles internes d'une autorité de certification peuvent devenir un problème de sécurité des utilisateurs à l'échelle mondiale; que le retard de notification peut être aussi lourd de conséquences que l'intrusion initiale; que les dépendances des ICP gouvernementales créent un risque de continuité publique; et que les fournisseurs de navigateurs peuvent devoir opter pour une méfiance d'urgence lorsque l'AC ne peut pas prouver l'étendue.

La norme de responsabilité n'est pas la perfection contre tout attaquant. C'est la preuve. Une AC publique doit prouver que l'autorité d'émission est protégée, que les journaux et les inventaires peuvent révéler les abus, que les incidents sont divulgués rapidement, que la révocation et la migration sont opérationnellement possibles et que la confiance du programme racine est méritée en permanence. Si elle ne le peut pas, le préjudice ne se limite plus à la liste des clients de l'AC.

DigiNotar n'est donc pas seulement un récit édifiant historique. C'est une carte de contrôle pour chaque organisation qui dépend de l'ICP publique du web. La confiance est déléguée, mais le préjudice est ressenti localement par les utilisateurs, les agences, les banques, les hôpitaux, les tribunaux, les écoles et les entreprises. La partie qui contrôle la machinerie de confiance contrôle la première chance de limiter ce préjudice.