Le Perfect Forward Secrecy : et si chaque conversation avait sa propre clé ?

Temps de lecture estimé : 6 minutes

Dans les articles précédents, on a vu comment le chiffrement symétrique utilise une clé partagée pour chiffrer et déchiffrer les données, et comment le chiffrement asymétrique permet d'échanger cette clé de manière sécurisée. Tout ça, c'est bien beau. Mais ceux qui sont attentifs auront remarqué qu'il reste un problème qui n'est pas vraiment résolu... 

Imaginez que vous communiquez avec votre banque via HTTPS. Votre navigateur et le serveur de la banque négocient une clé secrète symétrique (on appelle ça une session key) grâce au chiffrement asymétrique. Toute la session est ensuite chiffrée avec cette clé. C'est ce qu'on a vu dans l'article précédent...

Maintenant imaginez qu'un attaquant (un hacker, un état) enregistre tous vos échanges chiffrés aujourd'hui, en se disant : "Je ne peux pas les lire maintenant, mais peut-être que dans quelques années, j'aurai accès à la clé privée du serveur."

Ce scénario a même un nom : "Harvest now, decrypt later" (récolter maintenant, déchiffrer plus tard). Et ce n'est pas une théorie fumeuse : c'est une stratégie activement utilisée par certains services de renseignement.

Si la clé privée du serveur est un jour compromise — par un hack, une fuite interne, ou une saisie judiciaire — alors toutes les communications passées deviennent lisibles d'un coup. Des années de conversations, de transactions, de données sensibles, déchiffrées en une seconde.

Voilà le problème que le Perfect Forward Secrecy (PFS) résout.

Le Perfect Forward Secrecy est un mécanisme qui garantit que chaque session de communication utilise une clé éphémère unique, qui n'est jamais stockée et qui disparaît une fois la session terminée.

Même si quelqu'un récupère un jour la clé privée du serveur, cette clé ne lui servira à rien pour déchiffrer les communications passées. Pourquoi ? Parce que les clés de session n'ont jamais été chiffrées avec cette clé privée : elles ont été générées de manière indépendante, à la volée, et immédiatement jetées.

L'analogie classique : imaginez que pour chaque conversation secrète, vous et votre interlocuteur tirez chacun un dé, vous combinez les résultats pour obtenir un code unique, vous utilisez ce code, et ensuite vous brûlez le dé. Personne ne peut reconstituer le code après coup, même s'ils vous connaissent parfaitement.

Bonne question ! Le chiffrement asymétrique vu à l'article précédent reste toujours très utile, mais pas pour la partie "chiffrement", plutôt pour la partie "signature". La clé privée permanente du serveur n'est ici plus utilisée pour générer la clé de session. Elle sert à authentifier le serveur : elle prouve que vous parlez bien au vrai serveur, et pas à quelqu'un qui se fait passer pour lui (attaque man-in-the-middle).

En pratique, lors de la poignée de main TLS (le protocole qui sécurise HTTPS), le serveur utilise sa clé privée pour signer les clés temporaires échangées. Votre navigateur vérifie cette signature grâce au certificat du serveur.

Résultat : vous savez à qui vous parlez et la clé de session reste protégée même si la clé permanente (la clé privée) est un jour volée. Le meilleur des deux mondes.

En gros, dans à peu près toutes les communications sécurisées modernes :

• HTTPS : la version la plus récente du protocole (TLS 1.3) rend le PFS obligatoire. Votre navigateur le fait automatiquement sur tous les sites HTTPS modernes.
• Signal, WhatsApp, iMessage : les messageries modernes chiffrent chaque message avec une clé éphémère. C'est ce qui explique pourquoi, même si le serveur est un jour compromis, les messages passés restent illisibles.
• VPN modernes : les protocoles comme WireGuard ou OpenVPN supportent le PFS avec ECDHE.
• SSH : quand vous vous connectez à un serveur distant de manière sécurisée, SSH utilise également un échange de clés éphémères.

Par contre, ce n'est pas utilisé dans les services mails chiffrés (le protocole PGP/GPG mentionné dans l'article sur le chiffrement asymétrique), et ce pour une bonne raison : l'échange de clé éphémère avant chaque communication nécessite que les 2 correspondants soient en ligne en même temps. Or les mails fonctionnent de manière asynchrone : on peut en effet envoyer un mail à son destinataire même si il n'est pas en ligne, et dans ce cas, impossible de négocier avec lui une clé éphémère avant d'envoyer le message...

En résumé, le Perfect Forward Secrecy, c'est le principe des clés éphémères. C'est l'assurance vie de vos communications chiffrées. Même si une clé est compromise dans le futur, vos échanges passés restent protégés, car les clés de session éphémères n'ont jamais été stockées nulle part.

C'est la pièce qui manquait au puzzle : le hashage garantit l'intégrité (empreinte numérique), le chiffrement symétrique assure le chiffrement rapide et sûr, le chiffrement asymétrique sécurise l'échange des clés et permet l'authentification... et le PFS s'assure que même si la clé privée est compromise un jour, déchiffrer les conversations passées reste hors de portée.

Vous commencez à avoir une belle vue d'ensemble sur la cryptographie moderne. Mais on n'a pas encore parlé de comment tout ça s'assemble concrètement dans le protocole TLS — celui qui se cache derrière ce petit cadenas dans votre navigateur quand vous naviguez sur un site HTTPS (la très grosse majorité des sites aujourd'hui).

Ça tombe bien, ce sera justement l'objet du prochain article...