Ce qu'une phrase secrète sur une clé privée VPN protège réellement

L'invite qui apparaît au démarrage d'un client VPN est facile à mal lire. Ce n'est pas le mot de passe du compte VPN, ce n'est pas le mot de passe du tunnel, et la saisir ne prouve pas que la connexion est sûre. Elle déverrouille une représentation stockée d'une clé privée pour que le client puisse lire le matériel de clé et l'utiliser pour s'authentifier. Tout ce qui se passe ensuite est une autre question.

En pratique, la réponse se casse aux extrémités : les gens supposent que la phrase secrète protège le tunnel en cours, ou que la changer révoque une copie de la clé qui a déjà fuité. Les deux hypothèses échouent, et toutes deux échouent d'une manière qui laisse un identifiant exposé pendant que l'opérateur croit l'affaire réglée.

Une boîte de dialogue, plusieurs secrets différents

Une phrase secrète de clé privée déchiffre un fichier. Un mot de passe de compte vous authentifie auprès d'un service. Un mot de passe d'importation PKCS#12 déchiffre un paquet qui contient une clé et son certificat, et il peut ne pas être la même chaîne que la phrase secrète propre à la clé. Ces invites peuvent sembler presque identiques, et deviner quel secret va où est notamment ce qui fait coller les clés dans le mauvais champ.

Le chiffrement propre au tunnel est une quatrième chose. Le canal de données utilise des clés de session négociées pendant la poignée de main ; la phrase secrète de la clé privée ne joue aucun rôle dans la protection des paquets individuels. Si quelqu'un peut lire le fichier de clé, il peut tenter de deviner la phrase secrète hors ligne, mais s'il peut lire les paquets, la phrase secrète n'a aucune importance.

Ce que couvre le chiffrement sur le disque

Une clé PEM chiffrée se présente sous deux formes, et l'en-tête vous dit laquelle vous avez. La forme moderne PKCS#8 commence par -----BEGIN ENCRYPTED PRIVATE KEY----- ; l'ancienne forme PEM, encore courante dans les anciennes installations OpenVPN, commence par -----BEGIN RSA PRIVATE KEY----- et porte Proc-Type: 4,ENCRYPTED et une ligne DEK-Info juste en dessous. Le fichier contient la clé privée chiffrée sous une clé dérivée de votre phrase secrète, généralement via un KDF basé sur un mot de passe avec un nombre d'itérations ou un facteur de travail indiqué. La documentation OpenSSL pkey couvre les formats et les options de phrase secrète applicables lors de la lecture.

Deux conséquences en découlent. Une phrase secrète faible est attaquable hors ligne au rythme que le KDF permet, donc les permissions du fichier et l'accès aux sauvegardes restent importants même lorsque le fichier est chiffré. Et un attaquant qui n'obtient que le fichier sans la phrase secrète doit deviner ; celui qui obtient le fichier et la phrase secrète a la clé, exactement comme si elle n'avait jamais été chiffrée.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 affiche l'en-tête et, sur un ancien fichier, les lignes Proc-Type et DEK-Info qui prouvent le chiffrement ; une seule ligne n'est pas une preuve dans un sens ou dans l'autre. La ligne pkey demande la phrase secrète et n'imprime que la moitié publique, ce qui prouve que le fichier et la phrase secrète fonctionnent sans exposer la clé privée. N'utilisez pas -text pour cette vérification : il imprime les composants privés, privateExponent, prime1, prime2 et le reste, et cette sortie ne doit jamais être collée nulle part, ni dans un ticket, ni dans un chat, ni dans un journal. La commande PKCS#12 vous indique aussi si le paquet possède un mot de passe MAC ou de chiffrement distinct, ce qu'il vaut mieux savoir avant de le confier à un collègue.

Ce qu'elle cesse de protéger une fois la clé chargée

Le déverrouillage est un événement à sens unique pour ce processus. Le client demande la clé au KDF, déchiffre le fichier et garde la clé privée en mémoire aussi longtemps qu'il en a besoin. À partir de ce moment, la phrase secrète ne protège plus rien de la session en cours : ni la mémoire du processus, ni un vidage de noyau, ni une session de débogage attachée au client, ni une sauvegarde de la machine prise pendant que la clé était utilisée.

C'est la même frontière qu'une clé SSH avec phrase secrète, ou le coffre déverrouillé d'un gestionnaire de mots de passe. Cela augmente le coût du vol du fichier au repos et ne fait rien contre un logiciel malveillant exécuté sous votre utilisateur, une application autorisée qui demande au client de signer, ou un administrateur capable de lire la mémoire. Traitez-la comme une couche, pas comme le contrôle qui rend une clé sûre à laisser traîner.

Pourquoi l'invite revient sans cesse

Un client qui redemande à chaque reconnexion n'est pas forcément défectueux. Certains clients mettent la phrase secrète en cache pour la session, d'autres la stockent dans le trousseau du système d'exploitation, et d'autres peuvent être pointés vers un assistant qui la fournit, donc le comportement dépend du client et de sa configuration, pas du fichier de clé.

Si l'invite répétée est la vraie plainte, examinez les options de mise en cache et d'authentification du client avant de retirer le chiffrement de la clé. Supprimer la phrase secrète transforme un fichier protégé en clé en texte clair, et la reconnexion devient silencieuse au prix du seul contrôle au repos dont vous disposiez. Une meilleure réponse est généralement un magasin d'identifiants pris en charge avec les mêmes permissions de fichier que vous auriez utilisées de toute façon.

La perte et l'exposition ne sont pas la même réparation

Une phrase secrète perdue ne peut pas être récupérée à partir du certificat. Le certificat est un matériel public qui lie un nom à une clé ; il ne contient aucun chemin de retour vers la clé privée ni aucun indice sur la phrase secrète. Les options pratiques sont une sauvegarde autorisée de la clé, ou une nouvelle identité délivrée par le processus normal de l'opérateur. Quiconque propose de « récupérer » la phrase secrète propose de la deviner.

L'exposition exige une réponse différente. Rechiffrer la même clé avec une nouvelle phrase secrète laisse le matériel de clé inchangé, donc une copie déjà déverrouillée ailleurs fonctionne toujours. La réparation consiste à révoquer ou remplacer l'identifiant : émettre une nouvelle clé et un nouveau certificat, les distribuer et retirer l'ancien chez le pair. Tant que ce n'est pas fait, changer le mot de passe du fichier est de l'entretien, pas du confinement. Gardez l'ancien fichier hors des sauvegardes seulement après avoir confirmé que la nouvelle identité fonctionne, et notez quel numéro de série ou empreinte l'a remplacée.