TD 4 : Autorités de certification

François Lesueur (francois.lesueur@insa-lyon.fr)

Ce TD présente le modèle de PKI “Autorités de certification”, généralement noté CA (Certification Authority). Pour rappel, dans le cas du HTTPS par exemple, une CA doit permettre de valider la clé publique tierce obtenue pour la connexion au site demandé.

Dans le mode distanciel, réfléchissez en groupes de 4 dans des salons de discussion spécifiques. Des éléments de réponse sont accessibles pour chaque question (en cliquant sur les questions) : réfléchissez sans ces éléments, puis regardez et intégrez ces éléments. L’enseignant fera le tour des groupes pour échanger sur les points nécessaires.

Notations

Point de départ et objectif

Nos deux interlocuteurs sont Alice (client HTTPS, ie, un navigateur web) et Bob (serveur HTTPS, ie, un serveur web). Même si le protocole permet l’authentification mutuelle (chaque acteur authentifie cryptographiquement l’autre), nous allons étudier le cas le plus diffusé où seul le client HTTPS authentifie le serveur HTTPS. L’authentification permet d’établir un canal sécurisé en sachant que la bonne personne est de l’autre côté : il faut pour cela connaître la bonne clé publique de son interlocuteur.

Nous allons décrire au fur et à mesure la connaissance des différents acteurs. Au départ, Alice n’a pas de connaissance particulière, Bob connaît son couple de clés PubB/PrivB (c’est lui qui l’a généré).

L’objectif est qu’Alice obtienne la connaissance (B, PubB), ie, l’association valide de la clé publique de Bob à son identité.

Échange direct

Alice et Bob communiquent à travers un canal non sécurisé. La première façon pour Alice d’obtenir l’association attendue serait de la demander à Bob à travers ce canal. C’est ce qu’il se passe lorsque l’on parle, en HTTPS, de certificats auto-signés.

  1. Sans prendre en compte la sécurité, est-ce que cela peut fonctionner ?Oui, on obtient en général une clé fonctionnelle
  2. Si cela fonctionne, quel peut être le risque (en prenant maintenant en compte la sécurité) ? A-t-on gagné quelque chose par rapport à une communication en clair ?S'il y a un attaquant, il peut remplacer la clé sur le chemin. On a en fait rien gagné : soit il n'y a pas d'attaquant sur le chemin, on obtient la bonne clé mais la crypto ne sert pas à grand chose (vu qu'il n'y a pas d'attaquant) ; soit il y a un attaquant et on se fait MitM
  3. Décrivez une attaque possible par man-in-the-middle.L'idée est de modifier la clé en chemin et de s'interfacer dans la communication, il faut détailler.

Une PKI, et donc par exemple une CA, vise à sécuriser l’obtention de cette association (identité, clé publique).

Un premier type d’alerte de sécurité des navigateurs concerne ces certificats auto-signés.

Ajout d’un nouvel acteur : la CA

Nous intégrons un troisième acteur C (CA), qui va agir comme un tiers de confiance, et ajoutons les connaissances suivantes :

  1. À partir du cours, refaites la cinématique de CA/HTTPS dans ce modèle : les échanges entre B et C, puis entre B et A (A et C ne communiquent jamais directement !). Quel élément est le certificat ? Vous utiliserez les notations présentées en début de sujet.B fait une demande de certificat, il envoie pour cela (B, PubB) à C. C lui envoie en réponse le certificat (B, PubB).{h((B, PubB))}PrivC, qui est l'association signée par sa clé privée. Enfin, B envoie à A ce certificat (B, PubB).{h((B, PubB))}PrivC
  2. Comment C vérifie-t-elle l'association déclarée (B, PubB) ?Il n'y a pas de cryptographie possible à ce niveau, C ne connaît pas B initialement. Ce sont d'autres moyens : réception d'un mail (est-ce sécurisé ?), coup de téléphone, envoi d'un paquet par internet (mais sans authentifier B, donc). Pas de preuve de validité cryptographique ici, et c'est donc largement perfectible : pas de miracle !
  3. Comment A vérifie-t-elle l'association obtenue (B, PubB) ? Quelle est la chaîne de confiance ?En vérifiant la signature grâce à PubC. A fait confiance à C, qui a confiance en l'identité de B.
  4. Que déduire si le certificat reçu par A est bien signé mais pour une identité différente de B ? (en HTTPS, l'identité attendue, B par exemple, correspond au nom d'hôte de la requête, par exemple `www.insa-lyon.fr` pour une requête à `https://www.insa-lyon.fr/index.html`)On en déduit que la réponse ne vient (peut-être) pas du serveur attendu (n'importe qui peut avoir un certificat bien signé pour un autre nom), donc on est pas dans les conditions de sécurité. Le navigateur vérifie que le certificat est valide ET correspond bien à l'identité demandée.

Un second type d’alerte de sécurité des navigateurs concerne des certificats bien signés mais valides pour un autre site.

Un certificat est essentiellement cette association (identité, clé publique) assortie d’une durée de vie limitée, le tout signé par une autorité de certification. La norme X509v3 contient évidemment de nombreux autres champs.

L’écosystème HTTPS

Ce modèle est tout à fait possible avec une unique CA. Cependant, en pratique, il s’est développé avec une multitude de CA, notamment pour HTTPS. Chaque serveur a le choix de quelle CA il veut être certifié. Du coup, un navigateur reconnaît typiquement de l’ordre d’une petite centaine de CA différentes.

Imaginez maintenant que l’une des autorités soit compromise (malveillante ou attaquée):

  1. Quel impact pour les clients reconnaissant cette autorité ?Ils accepteront potentiellement de mauvais certificats (puisqu'ils auront une signature valide pour le site demandé)
  2. Quel impact pour un site dont le certificat est émis par une autre autorité ?Il a perdu aussi, puisque ses usagers, qui reconnaissent cette CA compromise, accepteront potentiellement une autre clé lorsqu'ils tenteront de s'y connecter, il n'a pas la main sur ce que croiront ses usagers

Révocation

La certification est un processus hors-ligne, c’est-à-dire qu’une fois émis, un certificat reste valide jusqu’à une date fixée lors de la signature (typiquement en années). Il ne s’agit pas d’une validation interactive valable à l’instant de la requête HTTPS.

Dans ses processus, une CA doit donc permettre de révoquer des certificats lorsqu’un site se fait voler sa clé privée.

CRL

La CRL (Certificate Revocation List) est une liste des certificats révoqués, émise et tenue à jour par la CA.

  1. En quoi l'utilisation de CRL va à l'encontre de l'approche hors-ligne (non interactive) et quel risque cela pose pour la CA ?Le principe de CRL suppose que les navigateurs doivent régulièrement pouvoir interroger la CA, ce qu'ils ne faisaient pas avant (seuls les serveurs le faisaient). Le risque est ainsi pour la CA de devoir gérer d'importants volumes de trafic, liés au nombre d'usagers d'internet et non du nombre de certificats (et donc de clients commerciaux) qu'elle émet.
  2. Que faire en cas de CRL non à jour et de CA non disponible pour mettre à jour ?Bonne question, hein ? On bloque ? On laisse passer dans le doute ? Si on bloque, on a des risques de DoS. Si on laisse passer, un DoS sur la CA permet de duper un usager... Concrètement, pas de très bonne solution, et les CRL pour toutes ces difficultés n'ont jamais été diffusées par les CA pour les certificats classiques (ni, du coup, implémentés dans les navigateurs)

OCSP

OCSP (Online Certificate Status Protocol) permet à un client de vérifier en temps réel la validité d’un certificat auprès de la CA émettrice.

  1. Cela résoud-il le risque que l'utilisation de CRL fait peser sur les CA ?Pas du tout, puisque maintenant tous les usagers de GMail vont aller toquer chez la CA pour vérifier, cela fait du volume. La CA a un client commercial (GMail) et se retrouve à devoir gérer un flux lié à la popularité de ce client, ce qui décorelle les ressources nécessaires du nombre de ses clients commerciaux
  2. Avec l'agrafage OCSP (_stapling_), c'est le serveur web qui demande à la CA une preuve de validité valable 24h et la présente ensuite à ses clients. Cela résoud-il la surcharge de la CA ? Quelle différence par rapport à des certificats valables 24h ?Oui, cela résoud la surcharge. Cela revient au même que des certificats valables 24h, ne nécessitant donc pas vraiment de révocation. La charge de la CA est cette fois proportionnelle au nombre de ses clients commerciaux.
  3. Que faire en cas d'absence d'agrafage OCSP ?Toujours le même problème. Il faudrait refuser. Mais dans 99% des cas c'est une erreur de gestion. Donc les navigateurs, pour éviter que leurs utilisateurs s'en détournent et en choisissent un autre (guerre de parts de marché), ont tendance à favoriser le fonctionnement et peuvent être laxistes (sur ce point ou d'autre, je n'ai pas vérifié en détail). C'est un vrai point délicat, l'acceptation entraîne évidemment le risque de casser tout l'édifice.

La révocation est un problème qui n’est toujours pas traité de manière satisfaisante et uniforme…

Organisation d’une CA à étages

Pour limiter les risques et impacts d’une compromission, chaque certificat a une durée de vie limitée, spécifiée dans l’association. Les CA emploient de plus plusieurs clés de niveaux de sensibilité différents. Cela permet d’avoir une ancre de confiance connue par A avec une longue durée de vie (par exemple 30 ans) tout en utilisant quotidiennement du matériel cryptographique avec une durée de vie plus courte (par exemple 1 an).

C a ainsi, à l’instant t :

Typiquement, un certificat racine avec une durée de vie longue (30 ans par exemple) est intégré aux navigateurs. La clé privée associée à ce certificat est stockée hors-ligne et est utilisée, chaque année, pour signer un certificat intermédiaire avec une durée de vie plus courte (1 an). C’est ensuite ce certificat intermédiaire qui est utilisé au quotidien.

  1. Formalisez cette organisation (matériel côté CA, matériel côté site, matériel côté client).Côté CA : PubCL/PrivCL, PubCC/PrivCC, PubCC.{h(PubCC)}PrivCL
    Côté site : (B, PubB).{h((B, PubB))}PrivCC.PubCC.{h(PubCC)}PrivCL
    Côté client : PubCL
  2. Quel est le chemin de vérification pour le client ?Le serveur envoie (B, PubB).{h((B, PubB))}PrivCC.PubCC.{h(PubCC)}PrivCL, qui contient : l'association (B, PubB), sa signature avec la clé PrivCC, la clé publique PubCC et la signature de cette clé publique avec la clé PrivCL
    Le client vérifie cette chaîne en partant de PubCL, qui permet de vérifier que PubCC est valide, et ensuite utilise PubCC pour valider (B, PubB)
  3. Comment remédier dans le cas où un certificat intermédiaire est compromis ? Dans le cas où le certificat racine est compromis ?Intermédiaire : on pourrait le révoquer, si la révocation marchait ;).
    Racine : c'est ancré dans la distribution logicielle du navigateur, il faut que l'éditeur du navigateur propose une mise à jour puis que l'utilisateur applique cette mise à jour (assez efficace sur ordinateur, beaucoup moins sur smartphones avec les anciens qui ne reçoivent plus de mise à jour, pire sur l'équipement spécifique industriel/médical/IoT)