Où doit vivre une clé privée VPN : fichier, CNG ou TPM ?

Deux questions tranchent l'emplacement d'une clé privée VPN : le matériel de clé peut-il être copié hors de l'hôte, et un processus peut-il l'utiliser sans personne au clavier. L'étiquette marketing d'un magasin ne répond ni à l'une ni à l'autre. Un démon de tunnel qui doit revenir après un redémarrage exige un usage sans surveillance, ce qui exclut tout ce qui dépend d'un code PIN saisi par un humain.

Choisir entre copier et utiliser

La copie et l'usage échouent différemment : traitez-les comme deux exigences, non comme une seule. Un attaquant qui peut lire les octets de la clé emporte l'identité sur un autre hôte, et la machine d'origine ne s'en aperçoit pas. Un attaquant qui ne peut pas lire les octets mais qui peut atteindre le processus de signature s'authentifie encore tant que cet accès dure.

Une clé en fichier se copie trivialement, ce qui explique aussi qu'elle soit la plus facile à sauvegarder et à restaurer. Un magasin de clés logiciel change l'API, pas la frontière : le fournisseur refuse ses propres appels d'export, mais le même contexte administrateur qui a installé la clé dispose généralement d'autres voies vers le matériel. Non exportable chez un fournisseur logiciel est une déclaration sur les opérations prises en charge, pas la preuve d'un mur matériel. Voyez-le comme un ralentisseur contre la copie occasionnelle, non comme une protection contre quelqu'un qui détient déjà votre session.

Un TPM ou une carte à puce exécute l'opération de signature dans le matériel et ne renvoie que le résultat. Cela ferme la voie de copie tout en laissant la voie d'usage ouverte à tout ce qui peut demander une signature.

Adapter le magasin au démon de tunnel

Le démon contraint davantage que la politique de sécurité. WireGuard prend une clé privée base64 dans un fichier ou dans l'entrée de wg set et n'a aucune voie vers un magasin de certificats : une clé d'interface portée par TPM n'est donc pas envisageable. OpenVPN compilé contre OpenSSL 3 peut charger une clé via une URI de fournisseur, et strongSwan fournit un greffon TPM en plus du support PKCS#11, mais les deux dépendent de la façon dont votre paquet a été compilé.

Un démon qui ne peut pas atteindre le magasin choisi transforme la frontière matérielle en décoration. Quelqu'un exporte la clé une fois, la laisse dans un fichier, et le reste de la conception tourne discrètement sur cette copie.

Le renouvellement est l'autre moitié de l'appariement, et c'est là que la plupart des conceptions s'effondrent. Un magasin qui fonctionne pour la première inscription mais exige une connexion console à chaque réémission sera contourné la première fois qu'un certificat expire à une heure peu commode. Testez le chemin de réémission tant que la clé actuelle a encore des mois devant elle.

Inventorier la clé avant de la déplacer

Consignez ce qu'est la clé avant de changer l'endroit où elle vit, car une migration qui perd les subject alternative names casse le tunnel d'une manière qui se lit comme une panne de routage. Exportez le certificat, confirmez que la clé privée est lisible là où le démon l'attend, et vérifiez que la paire correspond réellement.

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

Les deux dernières empreintes doivent être identiques. Si elles ne le sont pas, le démon termine son installation puis échoue à chaque tentative avec une erreur de certificat ou de signature qui ne pointe nulle part près de la vraie cause. L'équivalent WireGuard est plus court, puisque la clé publique dérive directement de la privée : wg pubkey < /etc/wireguard/wg0.key doit afficher la clé de pair que votre serveur possède déjà.

Les permissions relèvent du même inventaire. stat -c '%a %U:%G' /etc/wireguard/wg0.key devrait renvoyer 600 root:root, et tout ce qui est lisible par le groupe ou par le monde signifie que la clé a déjà été disponible pour des processus que vous n'aviez jamais prévus.

Vérifier le magasin et la voie d'usage

La vérification comporte trois parties, et la troisième est celle qu'on saute. Confirmez que la clé existe dans le magasin choisi, confirmez que le démon a chargé cette clé et non une copie résiduelle, puis confirmez qu'il démarre encore une fois l'artefact d'exportation supprimé.

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Sous Windows, la première commande liste le magasin personnel et imprime le fournisseur de clé à côté de chaque entrée, et c'est là qu'apparaît un certificat qui semble adossé au matériel mais siège dans le fournisseur logiciel. La seconde liste les clés détenues par le fournisseur cryptographique de la plateforme : une identité VPN absente alors que son certificat est présent signifie que la moitié privée vit ailleurs. Sur une passerelle Linux, ipsec listcerts indique ce que strongSwan a chargé, y compris les clés issues du greffon TPM. Comparez les empreintes ou les hachages de clé publique à l'inventaire plutôt que de vous fier au nombre d'entrées.

Le test négatif est celui qui prouve la conception. Déplacez la clé exportée hors du répertoire de configuration du démon, redémarrez le service et lisez dans le journal l'identité qu'il présente. Un tunnel qui monte encore utilise le magasin ; un démarrage raté signifie que la conception tournait réellement sur une copie.

Consigner le renouvellement et le retour arrière

Le retour arrière diffère nettement entre les deux familles, et cette différence appartient à la note de conception, pas à un appel d'incident. Une clé en fichier peut être sauvegardée chiffrée et restaurée, donc une migration ratée est réversible. Une clé non exportable ne peut pas être sauvegardée du tout, ce qui fait de la réémission et de la réinscription le seul chemin de récupération quand l'appareil meurt.

Vérifiez l'expiration avant qu'elle ne devienne une panne : openssl x509 -in vpn.crt -noout -checkend 2592000 se termine avec un code non nul lorsque le certificat expire dans trente jours, donc il s'intègre directement dans un contrôle de supervision. Une exécution hebdomadaire de cette ligne attrape le renouvellement que personne n'avait planifié.

La suppression se fait sur le serveur : supprimez le pair ou révoquez le numéro de série, puis confirmez que le tunnel échoue, car un client tenant une session en cache peut masquer une révocation à moitié faite pendant un moment. La révocation doit aussi atteindre le chemin CRL ou OCSP du concentrateur, pas seulement la base de données de l'AC. Un certificat est un document public, et le profil RFC 5280 couvre sa validation ; rien de cette validation ne protège une clé privée copiée avant la rotation.

Écrivez la décision en un seul endroit : quel magasin détient la clé, quel processus peut l'utiliser, qui peut la réémettre et quel est le retour arrière. Ce paragraphe est ce que les auditeurs demandent, et ce qui survit à un changement de personnel.