Confidentialité persistante pour un VPN : ce qu'une clé volée peut ouvrir

Enregistrez aujourd'hui un tunnel chiffré, volez l'an prochain la clé privée à long terme du serveur et essayez de déchiffrer l'enregistrement. La confidentialité persistante est la propriété qui dit que la clé volée ne suffira pas à elle seule. C'est une affirmation sur des sessions enregistrées et des secrets précis, pas une promesse générale que le tunnel était sûr. Bien cerner la portée, voilà ce qui rend le terme utile.

La question porte sur un enregistrement, pas sur la session active

La clé à long terme identifie l'extrémité et signe la poignée de main. Les clés de session chiffrent le trafic réel et, dans une conception à confidentialité persistante, elles dérivent d'un matériel d'échange de clés frais que les deux côtés génèrent puis jettent. Un attaquant qui ne détient que la clé à long terme ne peut pas reconstruire ces valeurs jetées. Un attaquant qui détient l'état de session actif le peut encore, et c'est pourquoi la garantie porte sur le passé plutôt que sur le présent.

L'affirmation est conditionnelle : elle n'est vraie que si les secrets éphémères ont réellement été détruits et si le protocole est bien celui que vous croyez. Un déploiement mixte peut la satisfaire sur un tunnel et échouer sur un autre.

Un secret ne doit pas reconstruire les autres

Vérifiez le mode négocié plutôt que la page marketing. La sortie de la poignée de main nomme l'échange de clés et la version du protocole.

openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sas

Le résumé de s_client montre la version de TLS et le groupe d'échange de clés, et un groupe éphémère est le signe visible d'un accord de clés à confidentialité persistante. La liste de swanctl montre les associations IKE et CHILD avec leurs minuteries de renouvellement de clés, de sorte que vous voyez si le déploiement renouvelle les clés selon un calendrier. Un échange de clés RSA statique, ou un ancien mode de compatibilité, perd la propriété quel que soit le nom du chiffrement. Notez le mode que vous avez observé, pas celui que le fournisseur annonçait.

Renouveler les clés n'est pas automatiquement de la confidentialité persistante

La fréquence à laquelle un tunnel renouvelle ses clés est une question distincte de la façon dont chaque clé est dérivée. Une conception qui régénère les clés à partir d'un secret à long terme peut renouveler les clés chaque minute et échouer quand même au test, parce qu'une compromission ultérieure les reconstruit toutes. À l'inverse, un protocole à renouvellement peu fréquent peut rester à confidentialité persistante lorsque chaque échange est indépendant. Lisez la dérivation, pas l'intervalle, et ne confondez pas une minuterie de reconnexion courte avec une garantie cryptographique.

La même confusion apparaît avec les noms de chiffrement : un chiffrement moderne ne dit rien sur la façon dont sa clé est arrivée.

Ce qui reste visible après la garantie

La confidentialité persistante protège le texte en clair des sessions enregistrées contre une compromission future de clés, et elle ne fait rien contre un attaquant qui lit le trafic actif sur une extrémité compromise. Elle ne retire pas de l'enregistrement les adresses de destination, le moment ni le volume, et elle ne limite pas la durée de conservation des journaux de connexion par un opérateur. Elle ne rend pas non plus un client compromis fiable, car l'attaquant se trouve déjà là où le contenu existe en clair.

Quand un fournisseur revendique la confidentialité persistante, demandez quel secret à long terme est supposé volé et quels secrets de session restent indisponibles. Si ces deux questions ont des réponses nettes, l'affirmation veut dire quelque chose.