Kit cyber - Chapitre 15 : Autorité de certification

Dans les chapitres précédents, nous avons réussi deux choses :

• mettre en place une communication chiffrée entre Alice et Bob grâce à RSA ;
• montrer qu’en jouant uniquement sur le certificat (le lien entre un nom et une clé publique), Mallory peut se faire passer pour Bob et lire le mot de passe à sa place.

Si l’on regarde maintenant notre système du point de vue du client, le problème devient très clair.

Alice reçoit sur la radio des certificats qui disent tous « Je suis SERVEUR_MDP, voici ma clé publique… » . Elle n’a aucun moyen, seule, de faire la différence entre :

• le certificat envoyé par Bob ;
• et le certificat envoyé par Mallory ;

Alice choisit donc un certificat (le premier reçu, ou le plus récent) et lui fait confiance… même si c’est le mauvais.
Autrement dit, Alice sait chiffrer correctement, mais ne sait pas à qui elle doit faire confiance. Tant que n’importe qui peut annoncer « je suis SERVEUR_MDP » et fournir une clé publique, l’usurpation d’identité reste possible.
La question qui se pose alors naturellement est : Comment Alice pourrait-elle vérifier qu’un certificat est « vrai », c’est-à-dire qu’il décrit bien la clé de Bob, et pas celle de Mallory ?

Pour résoudre le problème d’usurpation, on introduit une nouvelle actrice : l’autorité de certification (CA), que l’on appellera Trent. C’est une entité à qui Alice décide, une fois pour toutes, de faire confiance. Concrètement, Trent possède lui aussi une paire de clés RSA : une clé privée, qu’il garde secrète, et une clé publique, connue à l’avance de Alice (par exemple écrite en dur dans son programme).

Le rôle de Trent n’est pas de chiffrer les mots de passe, mais de garantir le lien entre une identité et une clé publique. Lorsque qu’une entité veut prouver qu’il est bien « SERVEUR_MDP », il lui envoie sa clé publique, et Trent construit un certificat qui contient au minimum :

• le nom du serveur
• sa clé publique

Dans notre version simplifiée, on peut voir la signature de ce certificat comme une petite partie de données que Trent va chiffrer avec sa clé privée. Le certificat « signé » contient donc deux choses : les informations visibles (nom + clé publique du serveur) et une signature, section du certificat chiffrée par la clé privée de l’autorité.

Quand Alice reçoit ce certificat via la radio, elle peut le vérifier grâce à la clé publique de Trent qu’elle connaît déjà : si ce qu’elle obtient en « déchiffrant » la signature avec la clé publique de Trent correspond bien au contenu du certificat, elle peut en déduire que ce certificat a été produit par Trent et qu’il n’a pas été modifié. Dans le cas contraire, Alice rejette le certificat.
L’idée essentielle à retenir est la suivante : chiffrer quelque chose avec la clé privée de Trent, puis déchiffrer ce quelque chose avec la clé publique de Trent permet de prouver que ce quelque chose vient bien de Trent.

Bob, qui a obtenu un certificat signé par Trent, peut donc convaincre Alice que sa clé publique est la bonne. Mallory, qui ne possède pas de certificat signé par Trent, ne peut pas fabriquer un certificat qui passera ce test. C’est ce mécanisme de signature que nous allons exploiter dans la partie expérimentation pour limiter l’usage de faux certificats.

La première chose à faire va être de créer une paire de clés permanente pour le CA. En effet, dans la vie réelle, la clé publique du CA est connue à l’avance et ne change pas, on va donc faire la même chose ici. Vous pouvez simplement afficher dans la console une paire de clés générée aléatoirement, et la noter quelque part pour ne pas la perdre.

On va ensuite initialiser les clés du CA avec les clés générées précédemment, en les entrant “en dur” dans le code.
Ensuite, on va définir un nouveau type de requête, que les serveurs pourront utiliser pour demander au CA de valider leur certificat, nommé VALIDER (CVALIDER et SVALIDER). Le serveur devra envoyer son certificat, ainsi qu’un mot de passe, lui aussi connu à l’avance et partagé entre le serveur honnête et le CA. Dans la réalité, les personnes voulant valider leurs certificats doivent fournir différents documents au CA, qui attestent de l’authenticité du serveur, mais nous avons décidé de simplifier cette démarche par un simple mot de passe.
Le contenu de la requête VALIDER sera de la forme suivante : [certificat, mdp], qui correspond à [[identite_serveur, cle_publique_serveur], mdp]. Par exemple, on pourrait avoir [[SERVEUR_MDP, (13, 5)], test].
Lorsque le CA analyse la demande de certificat, il vérifie si le mot de passe est correct, et dans ce cas, renvoie une version validée du certificat, où l’identité du serveur (SERVEUR_MDP) est chiffrée avec la clé privée du CA. Ainsi, lorsque le client recevra un certificat, il essaiera de déchiffrer l’identité du serveur avec la clé publique du CA. Si l’identité correspond bien, alors le certificat sera authentique, sinon il sera considéré comme falsifié.


Si tu es bloqué :

• Vérifie que tu as bien recopié la paire de clés du CA dans le programme : les deux nombres de la clé publique et les deux de la clé privée, dans le bon ordre [(n, e), (n, d)].
• Assure-toi que le mot de passe partagé entre le serveur et le CA est exactement le même des deux côtés (mêmes lettres, pas d’espace en plus).
• Contrôle que le CA ne traite que les messages dont le nom est CVALIDER, et qu’il renvoie bien un message SVALIDER dont la valeur est un certificat de la forme [identité_chiffrée, cle_publique_serveur].
• Pour déboguer, affiche dans la console du CA le contenu de la requête reçue (contenu_requete) et le certificat validé avant de l’envoyer.

En reprenant le programme du serveur du chapitre précédent, il va falloir modifier la façon dont le serveur gère son certificat. Il va tout d’abord falloir stocker le mot de passe partagé avec le CA, puis, au démarrage du serveur, demander au CA la validation du certificat, en utilisant la requête CVALIDER (dans ce cas-ci la carte serveur se comporte comme un client, car elle demande quelque chose, au CA, qui est aussi un serveur). Lorsque le CA aura validé le certificat, alors le serveur pourra à nouveau fonctionner normalement, en envoyant son certificat validé au client lorsque ce dernier le demandera.


Si tu es bloqué :

• Vérifie qu’au démarrage le serveur génère sa paire de clés, construit son certificat [identite_serveur, cle_publique_serveur] et envoie bien une requête CVALIDER au CA avec [certificat, mdp_CA] en valeur.
• Assure-toi que le mot de passe envoyé dans CVALIDER est le même que celui attendu par le CA.
• Quand le serveur reçoit un message SVALIDER, il doit remplacer son ancien certificat par la version validée renvoyée par le CA, et n’envoyer plus que ce certificat validé au client.
• Tu peux afficher temporairement dans la console du serveur le certificat avant / après validation pour vérifier qu’il est bien mis à jour.

La carte client, elle, lorsqu’elle va recevoir le certificat de la part de la carte serveur, va vérifier si celui-ci est validé, en déchiffrant l’identité du serveur avec la clé publique du CA, qui sera présente en dur dans le code de la carte client. Si le texte déchiffré correspond au serveur, ici SERVEUR_MDP, alors la carte client pourra communiquer sans souci avec la carte serveur. Sinon, c’est qu’une carte malveillante a essayé de se faire passer pour la carte serveur.


Si tu es bloqué :

• Vérifie que la clé publique du CA est bien écrite “en dur” dans le code du client, avec les mêmes nombres que dans le programme du CA.
• Assure-toi que, lorsqu’il reçoit le certificat du serveur (par exemple sur un message SCERTIFICAT), le client récupère bien :
• l’identité chiffrée dans le premier élément de la liste ;
• la clé publique du serveur dans le second.
• Le client doit déchiffrer l’identité avec la clé publique du CA, puis vérifier qu’il obtient bien SERVEUR_MDP avant d’accepter la clé du serveur. Si ce n’est pas le cas, il doit rejeter le certificat.
• Pour déboguer, affiche dans la console du client l’identité déchiffrée et la clé serveur mémorisée pour voir à quel moment ça coince.

Commence par téléverser les programmes sur les trois cartes : CA, serveur et client, en vérifiant qu’elles sont sur le même canal et le même groupe radio.

1. Lance d’abord le CA et le serveur : au démarrage, le serveur envoie une requête CVALIDER au CA, qui lui renvoie un certificat validé (SVALIDER).
2. Lance ensuite le client : il demande le certificat du serveur, le reçoit, puis vérifie la signature avec la clé publique du CA inscrite dans son programme.
3. Si tout fonctionne, le client doit accepter le certificat du serveur honnête et pouvoir communiquer normalement avec lui.
4. Tu peux enfin rebrancher la carte malveillante du chapitre précédent : tu observeras que le client ignore désormais son certificat, puisqu’il n’a pas été signé par le CA.

ans ce chapitre, nous avons renforcé notre système de communication chiffrée en ajoutant un nouvel acteur : Trent. Au lieu de faire confiance au premier certificat reçu sur la radio, Alice ne se fie plus qu’aux certificats qui ont été signés par Trent, grâce à sa clé privée. En chiffrant une partie du certificat avec cette clé privée, puis en laissant Alice vérifier ce chiffrement avec la clé publique de Trent écrite « en dur » dans son programme, nous avons mis en place une forme simplifiée de signature numérique : seul Trent peut produire un certificat qu’Alice pourra reconnaître comme authentique.

Lorsque l’on rebranche Mallory, le comportement du système change complètement : il peut toujours envoyer de faux certificats, mais ceux-ci ne portent pas la marque de l’autorité de certification, et Alice les rejette. Le chiffrement RSA continue d’assurer la confidentialité des messages, tandis que la signature de Trent vient, elle, garantir l’identité du serveur avec lequel on communique. On voit ainsi comment la combinaison de ces deux mécanismes – chiffrement et certification – permet de se protéger à la fois contre les curieux qui voudraient lire les messages, et contre ceux qui essaieraient de se faire passer pour quelqu’un d’autre.

Pour aller plus loin :

• Chercher les mots-clés « certificat numérique », « autorité de certification » et « PKI (infrastructure à clés publiques) » pour voir comment ce mécanisme est utilisé à grande échelle sur Internet.
• Se renseigner sur les protocoles HTTPS et TLS : le navigateur vérifie lui aussi les certificats des sites web grâce à des autorités de certification reconnues, afin d’éviter les faux sites et les usurpations d’identité.