Chiffrement symétrique vs. à clé publique dans un VPN : ce que fait chacun

Les gens décrivent un VPN comme „utilisant le chiffrement à clé publique“, puis imaginent chaque paquet verrouillé par le certificat du serveur. Cette image est fausse d'une manière qui compte quand on lit un fichier de configuration ou une capture de paquets. La moitié à clé publique d'un VPN consiste à prouver qui est le pair et à convenir d'un matériau secret ; la moitié symétrique est ce qui protège réellement le trafic, paquet après paquet, pendant toute la durée de la session.

Les deux moitiés ont des durées de vie, des modes de défaillance et des éléments publiables différents. Une fois séparées, des questions comme „RSA 2048 est-il plus faible qu'AES-128“ cessent de troubler, car ils n'ont jamais été comparables.

Trois opérations que l'on confond

La cryptographie à clé publique est un parapluie couvrant au moins trois opérations distinctes. Une signature prouve que le détenteur d'une clé privée a approuvé un message donné. L'accord de clés permet à deux pairs de dériver un secret partagé à partir de valeurs échangées en public. Le chiffrement à clé publique cache des données sous la clé publique de quelqu'un, de sorte que seule la clé privée peut les ouvrir.

Les poignées de main VPN utilisent surtout les deux premières. Un certificat n'est pas une clé de chiffrement ; c'est une déclaration signée qui lie un nom à une clé publique et permet à l'autre partie de décider si elle fait confiance à la clé qu'elle vient de recevoir. L'établissement de clés de TLS 1.3, par exemple, repose sur un accord de clés (EC)DHE plus des signatures de certificat, non sur le chiffrement de la session avec la clé publique du serveur.

Ce que produit réellement la poignée de main

Dans une poignée de main moderne, chaque partie génère une paire de clés éphémère, échange les moitiés publiques et calcule un secret partagé qui ne traverse jamais le câble. Ce secret passe ensuite par une fonction de dérivation de clés pour produire des clés distinctes par direction, ainsi que les nonces et le matériau IV dont la couche d'enregistrement a besoin. WireGuard le fait avec sa construction fondée sur Noise ; TLS 1.3 le fait avec HKDF sur le transcript de la poignée de main.

L'identifiant de longue durée — certificat et clé privée, ou une clé WireGuard statique — authentifie cet échange. Il signe ou se mêle au transcript pour qu'un inconnu ne puisse pas terminer la poignée de main à la place du pair. Ensuite, l'identifiant ne fait pas de travail par paquet. S'il en faisait, chaque paquet exigerait une opération de clé privée, et un tunnel occupé serait limité par l'opération la plus lente de la pile.

Deux effets secondaires s'ensuivent. Premièrement, les clés de session sont fraîches à chaque fois, ce qui explique qu'un attaquant qui vole plus tard la clé de longue durée ne puisse pas déchiffrer des sessions enregistrées auparavant, à condition que l'accord ait été éphémère. Deuxièmement, une clé de session compromise compromet une session, pas l'identité.

Pourquoi les gros volumes de données utilisent des clés symétriques

Les chiffrements symétriques gèrent bien le volume : AES-GCM ou ChaCha20-Poly1305 traitent chaque paquet avec une clé déjà en mémoire, authentifient l'en-tête et incrémentent un compteur. Le côté récepteur vérifie le nonce et l'étiquette d'authentification, et rejette tout ce qui échoue ou se répète. C'est assez peu coûteux pour tourner à la vitesse de la ligne sur du matériel ordinaire, et la même construction assure confidentialité et intégrité en une seule passe.

La construction est aussi là où vivent la plupart des bugs d'implémentation. Un nonce répété dans GCM casse à la fois la confidentialité et l'authenticité, c'est pourquoi les protocoles dérivent des clés par direction et tiennent un compteur ou une époque explicite. Si vous lisez une capture de paquets et que la longueur du texte chiffré correspond au texte clair plus un surcoût fixe, c'est la couche symétrique qui travaille, pas une opération à clé publique par paquet.

Durées de vie, renouvellement des clés et confidentialité persistante

Les clés de session sont censées expirer. TLS 1.3 autorise un message KeyUpdate à faire tourner les clés de trafic ; WireGuard renouvelle une session après un temps ou un nombre de messages configuré et garde brièvement l'ancienne pour les paquets en vol. OpenVPN renégocie les clés de son canal de données selon un calendrier, reneg-sec contrôlant l'intervalle.

Aucune de ces rotations n'équivaut à renouveler un certificat. Un certificat peut être valide un an tandis que les clés de session changent toutes les quelques minutes, et un certificat peut être remplacé sans toucher aux clés du tunnel en cours. Quand vous planifiez une expiration, demandez quel objet vous faites tourner ; la réponse décide si les clients se reconnectent ou renouvellent simplement leurs clés.

Lire les configurations et les diagnostics sans mélanger les objets

En pratique, vous choisissez un protocole complet et ses primitives prises en charge, vous n'assemblez pas le vôtre. La clé --tls-crypt d'OpenVPN protège le canal de contrôle ; le canal de données utilise des chiffrements symétriques négociés. Les entrées PrivateKey et PublicKey de WireGuard sont du matériau d'identité, tandis que ses clés de transport sont dérivées en interne. Lire ces champs comme le même type de secret mène à des erreurs comme coller une clé publique là où une clé privée a sa place.

Gardez le matériau public séparé du privé. Un certificat, une clé publique WireGuard et une empreinte sont sûrs à partager dans un ticket. Une clé privée, une clé pré-partagée et une clé de session exportée ne le sont pas. Quand vous comparez des forces, comparez au sein d'un même type : un identifiant de courbe elliptique, une taille de module RSA et une taille de clé AES mesurent des choses différentes sous des hypothèses différentes. La spécification TLS 1.3 est une référence utile pour la façon dont les deux couches s'emboîtent, même quand votre tunnel n'est pas TLS.