Wo ein privater VPN-Schlüssel liegen sollte: Datei, CNG oder TPM?

Zwei Fragen entscheiden, wohin ein privater VPN-Schlüssel gehört: ob das Schlüsselmaterial vom Host kopiert werden kann und ob ein Prozess ihn nutzen kann, ohne dass jemand an der Tastatur sitzt. Das Marketing-Etikett eines Speichers beantwortet keine der beiden. Ein Tunnel-Daemon, der nach einem Neustart wieder hochkommen muss, braucht unbeaufsichtigte Nutzung, was alles ausschließt, was an eine von Menschen eingegebene PIN gebunden ist.

Zwischen Kopieren und Nutzen entscheiden

Kopieren und Nutzen scheitern auf unterschiedliche Weise, behandeln Sie sie daher als zwei Anforderungen statt als eine. Ein Angreifer, der die Schlüsselbytes lesen kann, trägt die Identität auf einen anderen Host, und die ursprüngliche Maschine merkt nichts davon. Ein Angreifer, der die Bytes nicht lesen, aber den Signaturprozess erreichen kann, authentifiziert sich weiterhin, solange dieser Zugriff währt.

Ein Dateischlüssel ist trivial kopierbar, weshalb er sich am einfachsten sichern und wiederherstellen lässt. Ein Software-Schlüsselspeicher ändert die API, nicht die Grenze: Der Anbieter verweigert seine eigenen Exportaufrufe, doch derselbe Administratorkontext, der den Schlüssel installiert hat, hat meist andere Wege zum Material. Nicht exportierbar bei einem Software-Anbieter ist eine Aussage über unterstützte Operationen, kein Beweis einer Hardware-Mauer. Behandeln Sie es als Hemmschwelle gegen beiläufiges Kopieren, nicht als Schutz vor jemandem, der Ihre Sitzung bereits hat.

Ein TPM oder eine Smartcard führt die Signaturoperation in der Hardware aus und gibt nur das Ergebnis zurück. Das schließt den Kopierpfad und lässt den Nutzungspfad für alles offen, was eine Signatur anfordern kann.

Speicher und Tunnel-Daemon aufeinander abstimmen

Der Daemon schränkt dies stärker ein als die Sicherheitsrichtlinie. WireGuard nimmt einen Base64-privaten Schlüssel aus einer Datei oder aus der Eingabe von wg set und hat keinen Weg in einen Zertifikatsspeicher, ein TPM-gestützter Schnittstellenschlüssel ist also nicht möglich. OpenVPN, gegen OpenSSL 3 gebaut, kann einen Schlüssel über eine Provider-URI laden, und strongSwan liefert ein TPM-Plugin neben PKCS#11-Unterstützung mit, doch beides hängt davon ab, wie Ihr Paket kompiliert wurde.

Ein Daemon, der den gewählten Speicher nicht erreicht, macht aus der Hardware-Grenze Dekoration. Jemand exportiert den Schlüssel einmal, lässt ihn in einer Datei liegen, und der Rest des Entwurfs läuft still auf dieser Kopie.

Die Erneuerung ist die andere Hälfte der Abstimmung, und hier scheitern die meisten Entwürfe. Ein Speicher, der bei der ersten Registrierung funktioniert, aber für jede Neuausstellung eine Konsolenanmeldung verlangt, wird beim ersten Mal umgangen, wenn ein Zertifikat zu einer ungünstigen Stunde abläuft. Testen Sie den Neuausstellungsweg, solange der aktuelle Schlüssel noch Monate hat.

Den Schlüssel vor dem Umzug inventarisieren

Halten Sie fest, was der Schlüssel ist, bevor Sie ändern, wo er lebt, denn eine Migration, die die Subject Alternative Names verliert, bricht den Tunnel auf eine Weise, die sich wie ein Routingfehler liest. Geben Sie das Zertifikat aus, prüfen Sie, ob der private Schlüssel dort lesbar ist, wo der Daemon ihn erwartet, und stellen Sie sicher, dass das Paar tatsächlich zusammenpasst.

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

Die letzten beiden Digests müssen identisch sein. Sind sie es nicht, schließt der Daemon seine Einrichtung ab und scheitert dann bei jedem Versuch mit einem Zertifikat- oder Signaturfehler, der nirgends auf die eigentliche Ursache zeigt. Das WireGuard-Äquivalent ist kürzer, weil der öffentliche Schlüssel direkt aus dem privaten abgeleitet wird: wg pubkey < /etc/wireguard/wg0.key muss den Peer-Schlüssel ausgeben, den Ihr Server bereits gespeichert hat.

Berechtigungen gehören in dieselbe Bestandsaufnahme. stat -c '%a %U:%G' /etc/wireguard/wg0.key sollte 600 root:root zurückgeben, und alles, was für Gruppe oder Welt lesbar ist, bedeutet, dass der Schlüssel bereits Prozessen zur Verfügung stand, die Sie nie im Sinn hatten.

Speicher und Nutzungspfad prüfen

Die Verifikation hat drei Teile, und der dritte wird gern übersprungen. Bestätigen Sie, dass der Schlüssel in dem gewählten Speicher existiert, bestätigen Sie, dass der Daemon diesen Schlüssel geladen hat und keine übrig gebliebene Kopie, und bestätigen Sie dann, dass er noch startet, wenn das Export-Artefakt weg ist.

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

Unter Windows listet der erste Befehl den persönlichen Speicher auf und gibt neben jedem Eintrag den Schlüsselanbieter aus, und dort taucht ein Zertifikat auf, das hardwaregestützt aussieht, aber im Software-Anbieter sitzt. Der zweite listet Schlüssel des Plattform-Krypto-Anbieters, eine dort fehlende VPN-Identität bei vorhandenem Zertifikat bedeutet also, dass die private Hälfte woanders lebt. Auf einem Linux-Gateway meldet ipsec listcerts, was strongSwan geladen hat, einschließlich Schlüsseln aus dem TPM-Plugin. Vergleichen Sie Fingerabdrücke oder Public-Key-Hashes mit der Bestandsaufnahme, statt der Anzahl der Einträge zu vertrauen.

Der Negativtest ist der, der den Entwurf beweist. Verschieben Sie den exportierten Schlüssel aus dem Konfigurationsverzeichnis des Daemons, starten Sie den Dienst neu und lesen Sie im Protokoll, welche Identität er vorweist. Ein Tunnel, der trotzdem hochkommt, nutzt den Speicher; ein fehlgeschlagener Start bedeutet, dass der Entwurf wirklich von einer Kopie lief.

Erneuerung und Rollback aufschreiben

Der Rollback unterscheidet sich stark zwischen den beiden Familien, und dieser Unterschied gehört in die Entwurfsnotiz statt in einen Incident-Anruf. Ein Dateischlüssel lässt sich verschlüsselt sichern und wiederherstellen, eine fehlgeschlagene Migration ist also umkehrbar. Ein nicht exportierbarer Schlüssel lässt sich überhaupt nicht sichern, was Neuausstellung und Neuregistrierung zum einzigen Wiederherstellungsweg macht, wenn das Gerät stirbt.

Prüfen Sie den Ablauf, bevor daraus ein Ausfall wird: openssl x509 -in vpn.crt -noout -checkend 2592000 endet mit einem Nicht-Null-Code, sobald das Zertifikat innerhalb von dreißig Tagen abläuft, und passt damit direkt in eine Überwachungsprüfung. Ein wöchentlicher Lauf dieser Zeile fängt die Erneuerung, die niemand eingeplant hat.

Die Entfernung findet auf dem Server statt: Peer löschen oder die Seriennummer widerrufen, dann bestätigen, dass der Tunnel scheitert, denn ein Client mit zwischengespeicherter Sitzung kann einen halbfertigen Widerruf eine Weile verbergen. Der Widerruf muss auch den CRL- oder OCSP-Pfad des Konzentrators erreichen, nicht nur die CA-Datenbank. Ein Zertifikat ist ein öffentliches Dokument, und das RFC-5280-Profil regelt, wie es validiert wird; nichts an dieser Validierung schützt einen privaten Schlüssel, der vor der Rotation kopiert wurde.

Schreiben Sie die Entscheidung an eine Stelle: welcher Speicher den Schlüssel hält, welcher Prozess ihn nutzen darf, wer ihn neu ausstellen kann und wie das Rollback aussieht. Dieser Absatz ist es, wonach Prüfer fragen, und er übersteht einen Personalwechsel.