Kit cyber - Chapitre 14 : Usurpation d’identité avec faux certificat

Dans le chapitre précédent, nous avons vu comment Alice peut chiffrer un mot de passe avec la clé publique de Bob, puis l’envoyer par radio pour qu’il soit déchiffré avec la clé privée correspondante. Tant que la clé publique utilisée est la bonne, le système fonctionne : seul Bob peut lire le message.
Si l’on regarde maintenant notre solution de plus près, on remarque un point important :

• Alice ne connaît Bob qu’à travers un nom (par exemple « SERVEUR ») et une clé publique associée à ce nom ;
• dans le code, cette association « nom → clé publique » est simplement stockée dans une variable, un tableau ou un message qu’Alice reçoit ;
• À aucun moment Alice ne vérifie par elle-même que cette clé publique est bien celle de Bob : elle se contente de croire ce qui est écrit dans ce « certificat ».

Autrement dit, notre système chiffre correctement les messages, mais il repose entièrement sur l’hypothèse suivante : le certificat utilisé par Alice décrit honnêtement la clé publique de Bob.
Dans ce chapitre, nous allons introduire une troisième carte, Mallory, qui jouera le rôle d’une carte malveillante. Il n’essaiera pas de casser le chiffrement lui-même, mais de profiter de cette confiance accordée au certificat pour perturber la communication entre Alice et Bob.

Pour analyser ce qui se passe, il faut d’abord préciser ce que nous appelons ici certificat : dans notre version simplifiée, c’est un petit paquet d’informations qui relie une identité (par exemple : « je suis Bob, le serveur de mot de passe ») à une clé publique.
Du point de vue d’Alice, ce certificat fait office de « carte d’identité numérique ». Si Alice lui fait confiance, elle utilisera la clé publique du certificat pour chiffrer le message.
Cependant, si ce certificat est erroné ou modifié, Alice continuera à l’utiliser quand même, puisqu’il n’a pas d’autre moyen de vérifier à qui appartient réellement cette clé.

Mallory, que nous allons introduire, représente un attaquant qui ne cherche pas à deviner la clé privée du serveur, mais à présenter un certificat différent, avec sa propre clé publique associée à une identité qui ressemble à celle du serveur.
Dans la partie expérimentation, nous observerons comment le simple fait de changer ce lien « identité → clé publique » peut suffire à détourner la communication, sans toucher au fonctionnement interne du chiffrement RSA. Cela nous amènera à formuler plus précisément la notion de faux certificat et à comprendre pourquoi la gestion de ces certificats est au cœur de la sécurité des communications chiffrées.

On va créer une nouvelle manière d’échanger les clés entre le client et le serveur.
Plutôt que le serveur renvoie simplement sa clé publique, il va également renvoyer son nom, qui sera SERVEUR_MDP. Le serveur renverra une liste qui contient comme premier élément le nom du serveur, et comme second élément sa clé publique. De cette manière, le client est capable de lier le nom du serveur à sa clé. Si ce changement n’apporte pour l’instant pas grand-chose, il sera très utile lors du prochain chapitre.

Il va falloir programmer la carte serveur pour qu’elle renvoie son certificat plutôt que sa clé publique seule, et modifier la carte client pour qu’elle stocke le certificat complet, et utilise correctement la clé publique dans le certificat pour chiffrer / déchiffrer ses messages.
On va également modifier les types de requête envoyées par le serveur et le client, afin de mieux discerner qui envoie quoi :

• Les requêtes du client commenceront toujours par un C (CMDP_GET, CCERTIFICAT)
• Les requêtes du serveur commenceront toujours par un S (SMDP_GET, SCERTIFICAT)

Programme client :



Programme serveur :



Si tu es bloqué :

• Vérifie que le client et le serveur sont bien sur le même canal / groupe radio et que le serveur génère son certificat (identité + clé publique) au démarrage.
• Assure-toi que le serveur envoie bien le certificat avec le même nom de message que celui que le client attend (par exemple SCERTIFICAT), et que le client n’enregistre que ce message-là.
• Côté client, contrôle que tu stockes le certificat reçu (identité + clé publique) dans les bonnes variables. Si besoin, affiche temporairement dans la console le contenu du message reçu (nom + valeur) et les variables où tu ranges l’identité et la clé pour voir où ça coince.

La carte malveillante va se comporter comme la carte serveur, à quelques détails près :

• La carte ne va pas attendre que le client envoie sa demande de certificat. Elle va plutôt envoyer plusieurs fois sa propre requête de certificat à son démarrage, avant que la carte serveur honnête ne puisse répondre. Les messages radio sur micro:bit sont envoyés en broadcast, c’est-à-dire que tout le monde reçoit les messages de tout le monde. Ces derniers s’accumulent dans une file d’attente. Si la carte malveillante est la première à envoyer un message, alors ce sera le premier message lu par la carte client.
• La carte malveillante va, lorsque le client envoie MDP_SET, afficher le mot de passe du client sur sa matrice de LED, pour montrer que le mot de passe a fuité.

Si tu es bloqué :

• Vérifie que les trois cartes (client, serveur honnête, carte malveillante) sont bien sur le même canal / groupe radio et que chacune envoie son certificat au démarrage.
• Assure-toi que la carte malveillante envoie bien son certificat en boucle (ou plusieurs fois de suite) avec le même nom de message que le serveur honnête, afin que le client puisse le recevoir en premier.
• Côté client, contrôle que tu enregistres uniquement le premier certificat reçu et que tu ne le remplaces plus ensuite. Si besoin, affiche dans la console le contenu du certificat (identifiant + clé publique) au moment où il est mémorisé.
• Vérifie enfin que, pour la suite de l’activité, le client utilise bien la clé publique contenue dans ce certificat (même si elle vient de la carte malveillante).

Téléverse les programmes sur les trois cartes, puis lance d’abord la carte Bob, puis la carte Mallory et enfin la carte Alice. Observe ce qui se passe au démarrage : Alice enregistre le premier certificat qu’elle reçoit, qui provient en général de Mallory puisqu’il envoie son certificat en continu.
Lorsqu’Alice chiffrera ensuite un mot de passe ou un message “secret”, elle utilisera la fausse clé publique contenue dans ce certificat. Mallory pourra alors déchiffrer le message, tandis que Bob ne le comprendra plus.

Dans ce chapitre, nous avons conservé le même mécanisme de chiffrement RSA que précédemment, mais nous avons modifié la façon dont Alice apprend la clé publique de Bob : au lieu de recevoir seulement des nombres, elle récupère désormais un certificat qui lie un nom de serveur à une clé publique. Cette petite évolution nous a permis d’introduire une troisième carte, Mallory, qui envoie son propre certificat avant Bob. Alice, qui fait confiance au premier certificat reçu, se met alors à chiffrer son mot de passe avec la clé publique de Mallory, et c’est lui – et lui seul – qui peut le déchiffrer. Bob, lui, reçoit éventuellement les messages… mais n’est plus capable de les lire.

Cette activité montre que le chiffrement asymétrique, pris isolément, ne suffit pas : les messages restent bien chiffrés, mais cela n’empêche pas un attaquant de se faire passer pour le destinataire en diffusant un faux certificat. La véritable faiblesse ne vient pas des mathématiques de RSA, mais de la confiance aveugle accordée au certificat utilisé par le client.

Pour aller plus loin :

• Chercher les mots-clés « usurpation d’identité », « faux certificat » et « attaque de type man-in-the-middle » pour voir comment ce genre de scénario peut se produire sur un vrai réseau.
• Se renseigner sur la façon dont les navigateurs vérifient les certificats HTTPS (chaîne de confiance, autorités de certification, alertes en cas de certificat invalide) pour comprendre comment on limite ce type d’usurpation dans la pratique.