Les mots clé pré-partagée apparaissent dans la documentation d’IPsec, d’OpenVPN et de WireGuard, et ils y désignent trois objets différents. L’un est un secret d’authentification, l’autre protège un canal de contrôle, et le troisième ajoute de la matière à un handshake qui possède déjà des identités. Les traiter comme interchangeables produit une connexion qui échoue à une étape que personne n’attendait. Lisez ce que le champ fait dans ce protocole avant d’y copier une valeur.

Trois protocoles, trois significations

Chaque protocole définit la tâche de la clé dans sa propre spécification, et ces tâches ne se recoupent pas. Un secret d’authentification prouve que deux pairs connaissent la même valeur. Une clé de canal de contrôle protège la négociation qui suit. Un complément de handshake modifie le calendrier des clés sans changer qui sont les pairs.

Aucun de ces rôles n’authentifie un utilisateur humain, et c’est cette confusion qui coûte le plus de temps. Une clé pré-partagée est provisionnée sur des appareils ou des passerelles avant l’échange, si bien que chaque détenteur paraît identique à l’autre extrémité. Cette propriété est un atout pour une liaison site à site entre deux routeurs et un risque pour un service d’accès distant avec des employés nommés. Gardez l’identifiant de compte et le secret cryptographique dans deux colonnes séparées du document qui décrit le déploiement.

IPsec et OpenVPN emploient le mot différemment

IKEv2 peut authentifier un pair avec un secret pré-partagé au lieu de certificats, et la valeur doit correspondre aux deux extrémités. Comme le même secret est généralement configuré pour un groupe de pairs, tout détenteur peut usurper les autres, et l’échange ne gagne aucune confidentialité persistante à partir de clés d’identité qu’il n’a jamais eues.

Les options tls-auth et tls-crypt d’OpenVPN attachent une clé statique au canal de contrôle, en ajoutant une signature HMAC ou en chiffrant la négociation elle-même. Cette clé n’est pas un mot de passe utilisateur et ne remplace pas le certificat client. Distinguer les deux compte au moment du renouvellement, quand un changement de mot de passe laisse la clé du canal de contrôle intacte.

Le PSK de WireGuard ajoute, il n’identifie pas

Les pairs WireGuard possèdent déjà des clés publiques et privées Curve25519, et le handshake authentifie ces identités. Une clé pré-partagée facultative est mélangée à la clé de chaînage, apportant de la matière symétrique en plus de l’échange de clés publiques.

Elle ne fournit aucune identité propre et aucun compte utilisateur, si bien qu’un opérateur ne peut pas distinguer deux détenteurs par leur PSK. Les deux extrémités doivent porter la même valeur, sinon le handshake échoue sans message d’erreur utile. C’est pourquoi la rotation doit être planifiée des deux côtés à la fois plutôt que comme la modification d’un seul fichier.

Vérifier la distribution, la rotation et le retrait

La distribution est le point faible de toute conception qui utilise un secret à de nombreux endroits. Une valeur collée dans une fenêtre de discussion, stockée dans un dépôt ou réutilisée d’un environnement à l’autre accumule des copies que personne ne peut énumérer, et chaque copie élargit discrètement le rayon d’impact.

Le texte Base64 n’est pas du chiffrement. Un secret rangé à côté d’un certificat public dans le même répertoire reste un secret en clair.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Effectuez la rotation selon un calendrier et après toute exposition suspectée, en mettant à jour chaque pair prévu avant de révoquer l’ancienne valeur. Testez ensuite la liaison depuis les deux extrémités, car une clé qui ne correspond pas échoue au handshake et ressemble exactement à un problème de pare-feu.

Documentez quel secret protège quelle étape, afin qu’une réinitialisation de mot de passe ne soit jamais prise pour le renouvellement d’une clé cryptographique. Cette ligne fait gagner une heure chaque fois que quelqu’un audite le déploiement.

Articles similaires