Peut-on partager une clé publique VPN ? Vérifiez ces trois points

Vous pouvez confier votre clé publique VPN à un pair, à un fournisseur ou à un forum, et le tunnel tient toujours. La clé privée, en revanche, vous ne pouvez pas la remettre, même au support, sans remettre l’identité que cette clé prouve. La décision reste rarement aussi nette, parce que les gens confondent la moitié du couple qu’ils regardent et parce que certains déploiements traitent la valeur publique comme un nom. Trois vérifications tranchent : quelle moitié vous avez, à quoi le déploiement la lie et ce que coûte un remplacement.

Vérification un : quelle moitié du couple est dans votre presse-papiers

Les clés asymétriques vont par paires, et le sens de la dérivation est tout l’enjeu. Dans WireGuard, la clé privée est constituée de 32 octets aléatoires et la clé publique est calculée à partir d’elle ; l’inverse est impossible. wg genkey écrit la valeur privée, wg pubkey dérive la publique, et seule la seconde a sa place dans un message destiné à un pair.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

Le monde des certificats utilise la même séparation avec plus de pièces mobiles. Un certificat de serveur porte une clé publique et des noms, et il est signé par une clé privée d’autorité de certification qui ne quitte jamais cette autorité. Un client qui vérifie ce serveur a besoin du certificat de l’autorité, qui est public, et n’a aucun usage de la clé privée de signature de l’autorité.

Si vous ne savez pas quelle valeur vous tenez, cherchez le marqueur plutôt que le nom du fichier. Un bloc PEM commençant par -----BEGIN PRIVATE KEY-----, ou l’ancienne forme BEGIN RSA PRIVATE KEY, est la moitié secrète. Une valeur que vous pouvez coller sans ce marqueur est candidate au partage, sous réserve des deux vérifications suivantes.

Vérification deux : à quoi le déploiement lie cette valeur publique

La sécurité cryptographique et l’anonymat sont deux propriétés différentes. La clé publique d’un pair WireGuard est un identifiant stable à l’intérieur du déploiement : la configuration du serveur la liste, la poignée de main la nomme et un administrateur qui lit les journaux voit la même chaîne chaque fois que ce pair se connecte. Publiez la clé à côté d’une question sur votre installation et vous avez relié cette chaîne à tout le reste du message.

Les certificats fuient l’identité par conception. Les champs Subject et subject alternative name sont lisibles, et pour les certificats TLS à confiance publique le certificat lui-même est publié dans les journaux Certificate Transparency, qui sont consultables. Rien de tout cela n’expose une clé privée, et tout cela expose une relation.

C’est là que les déploiements diffèrent, et cela décide de la réponse. Un pair de test jetable sur un serveur de laboratoire est un autre objet que la clé qui identifie l’extrémité inter-sites d’une entreprise, même si les octets semblent identiques.

Vérification trois : ce que vous pouvez révoquer, et à quelle vitesse

La troisième vérification sépare complètement les deux moitiés. Une clé publique qui a été publiée peut être remplacée selon votre calendrier. Une clé privée qui a été publiée ne peut pas être rappelée : supprimer votre copie ne touche pas les copies déjà prises, et chaque pair qui lui faisait confiance fait désormais confiance à ce que détient un tiers.

La révocation est une action de configuration, pas une action cryptographique. WireGuard ne fournit aucune liste de révocation, donc vous retirez le pair :

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN les déploiements fondés sur des certificats révoquent le certificat et publient une CRL que le serveur vérifie réellement via crl-verify. Sans cette directive, la liste de révocation n’est que décorative. Dans tous les cas la séquence est la même : émettre un remplacement, le distribuer par le canal pris en charge, puis retirer l’ancienne identité.

Les erreurs qui viennent de confondre les trois vérifications

La plupart des fuites réelles ne sont pas une personne qui décide de publier une clé privée. C’est un profil entier collé dans un forum : un fichier .conf WireGuard avec une ligne PrivateKey, ou un paquet .ovpn contenant un bloc de clé intégré, ou une capture d’écran d’une fenêtre de client qui inclut par hasard le champ de la clé. La valeur publique était probablement correcte ; elle a voyagé avec la partie qui ne l’était pas.

Les parcours de support sont la seconde source. Aucune étape de vérification légitime n’a besoin de votre clé privée, car l’autre côté dérive de la moitié publique ce dont il a besoin. Quand un formulaire ou une personne demande la valeur privée, la bonne réponse est la valeur publique plus la commande locale qui la produit.

Les journaux et les captures d’écran relèvent de la même catégorie. Une sortie de diagnostic peut transporter du matériel de clé, des identifiants de session et des adresses internes, et tout publier pour obtenir une réponse échange un petit confort contre une exposition plus large.

Après la fuite d’une valeur privée, retirez l’identité

Si une valeur privée a fui, considérez cette identité comme retirée. Générez une nouvelle paire, installez la moitié publique là où les pairs l’attendent, retirez l’ancien pair ou révoquez l’ancien certificat, et vérifiez les endroits où vous l’avez publiée. Vous ne pouvez pas effacer des copies que vous ne contrôlez pas, donc le retrait concerne l’avenir, pas le passé.

Ensuite, écrivez la distribution : quelle clé appartient à quel appareil, qui détient une copie, comment un remplacement est livré et qui retire un pair révoqué. Ce sont les parties que les gens oublient, et elles décident combien de temps une fuite reste utile.