Was eine Passphrase auf einem privaten VPN-Schlüssel tatsächlich schützt
Sie sperrt die Datei auf der Festplatte, nicht den laufenden Tunnel oder Ihr Kontologin. Erfahren Sie, was die Abfrage abdeckt, was nicht, und was bei einer Offenlegung zu tun ist.
Die Abfrage, die beim Start eines VPN-Clients erscheint, wird leicht falsch gelesen. Sie ist nicht das Passwort des VPN-Kontos, sie ist nicht das Passwort für den Tunnel, und ihre Eingabe beweist nicht, dass die Verbindung sicher ist. Sie entsperrt eine gespeicherte Darstellung eines privaten Schlüssels, damit der Client das Schlüsselmaterial lesen und zur Authentifizierung verwenden kann. Alles, was danach geschieht, ist eine andere Frage.
In der Praxis geht die Antwort an den Rändern schief: Menschen nehmen an, die Passphrase schütze den laufenden Tunnel, oder ihre Änderung widerrufe eine Kopie des Schlüssels, die bereits abgeflossen ist. Beide Annahmen scheitern, und beide scheitern so, dass ein Berechtigungsnachweis offenliegt, während der Betreiber glaubt, die Sache sei erledigt.
Ein Dialog, mehrere verschiedene Geheimnisse
Eine Passphrase für einen privaten Schlüssel entschlüsselt eine Datei. Ein Kontopasswort authentifiziert Sie bei einem Dienst. Ein PKCS#12-Importpasswort entschlüsselt ein Paket, das einen Schlüssel und sein Zertifikat enthält, und es muss nicht dieselbe Zeichenfolge sein wie die Passphrase des Schlüssels selbst. Diese Abfragen können fast identisch aussehen, und zu raten, welches Geheimnis wohin gehört, führt dazu, dass Schlüssel in das falsche Feld eingefügt werden.
Die eigene Verschlüsselung des Tunnels ist eine vierte Sache. Der Datenkanal verwendet Sitzungsschlüssel, die während des Handshakes ausgehandelt werden; die Passphrase des privaten Schlüssels spielt beim Schutz einzelner Pakete keine Rolle. Wenn jemand die Schlüsseldatei lesen kann, kann er versuchen, die Passphrase offline zu erraten; wenn er Pakete lesen kann, ist die Passphrase irrelevant.
Was die Verschlüsselung auf der Festplatte abdeckt
Ein verschlüsselter PEM-Schlüssel hat zwei Formen, und der Kopf sagt Ihnen, welche Sie haben. Die moderne PKCS#8-Form beginnt mit -----BEGIN ENCRYPTED PRIVATE KEY-----; die ältere PEM-Form, die in älteren OpenVPN-Setups noch üblich ist, beginnt mit -----BEGIN RSA PRIVATE KEY----- und trägt Proc-Type: 4,ENCRYPTED und eine DEK-Info-Zeile direkt darunter. Die Datei enthält den privaten Schlüssel verschlüsselt unter einem aus Ihrer Passphrase abgeleiteten Schlüssel, typischerweise über eine passwortbasierte KDF mit angegebener Iterationszahl oder Arbeitsfaktor. Die OpenSSL-pkey-Dokumentation behandelt die Formate und die Passphrase-Optionen, die beim Lesen gelten.
Daraus folgen zwei Konsequenzen. Eine schwache Passphrase ist offline mit der Rate angreifbar, die die KDF zulässt, daher bleiben Dateiberechtigungen und Backup-Zugriff auch bei verschlüsselter Datei wichtig. Und ein Angreifer, der nur die Datei ohne die Passphrase erhält, muss raten; wer Datei und Passphrase erhält, hat den Schlüssel, genau als wäre er nie verschlüsselt gewesen.
head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout
head -3 zeigt den Kopf und bei einer älteren Datei die Zeilen Proc-Type und DEK-Info, die die Verschlüsselung belegen; eine einzelne Zeile ist in keine Richtung ein Beweis. Die Zeile pkey fragt nach der Passphrase und gibt nur die öffentliche Hälfte aus, was belegt, dass Datei und Passphrase funktionieren, ohne den privaten Schlüssel offenzulegen. Verwenden Sie -text nicht für diese Prüfung: Es gibt die privaten Komponenten aus, privateExponent, prime1, prime2 und den Rest, und diese Ausgabe darf niemals irgendwo eingefügt werden, weder in ein Ticket noch in einen Chat oder ein Protokoll. Der PKCS#12-Befehl sagt Ihnen außerdem, ob das Paket ein separates MAC- oder Verschlüsselungspasswort hat, was man wissen sollte, bevor man es einem Kollegen übergibt.
Was sie nicht mehr schützt, sobald der Schlüssel geladen ist
Das Entsperren ist für diesen Prozess ein einmaliges Ereignis. Der Client fragt die KDF nach dem Schlüssel, entschlüsselt die Datei und hält den privaten Schlüssel im Speicher, solange er ihn braucht. Von diesem Moment an schützt die Passphrase nichts an der laufenden Sitzung: nicht den Prozessspeicher, nicht einen Core-Dump, nicht eine am Client hängende Debug-Sitzung und nicht ein Backup des Rechners, das während der Nutzung des Schlüssels erstellt wurde.
Das ist dieselbe Grenze wie bei einem SSH-Schlüssel mit Passphrase oder einem entsperrten Tresor eines Passwortmanagers. Sie erhöht die Kosten des Diebstahls der Datei im Ruhezustand und tut nichts gegen Malware, die als Ihr Benutzer läuft, eine autorisierte Anwendung, die den Client zum Signieren auffordert, oder einen Administrator, der Speicher lesen kann. Behandeln Sie sie als eine Schicht, nicht als die Kontrolle, die einen Schlüssel sicher herumliegen lässt.
Warum die Abfrage immer wiederkommt
Ein Client, der bei jeder Wiederverbindung erneut fragt, ist nicht unbedingt defekt. Manche Clients cachen die Passphrase für die Sitzung, manche speichern sie im Schlüsselbund des Betriebssystems, und manche lassen sich auf einen Helfer verweisen, der sie liefert; welches Verhalten Sie erhalten, hängt vom Client und seiner Konfiguration ab, nicht von der Schlüsseldatei.
Wenn die wiederholte Abfrage das eigentliche Problem ist, prüfen Sie die Caching- und Authentifizierungsoptionen des Clients, bevor Sie die Verschlüsselung vom Schlüssel entfernen. Das Entfernen der Passphrase macht aus einer geschützten Datei einen Klartextschlüssel, und die Wiederverbindung wird ruhig auf Kosten der einzigen Ruhekontrolle, die Sie hatten. Eine bessere Antwort ist meist ein unterstützter Anmeldedatenspeicher mit denselben Dateiberechtigungen, die Sie ohnehin verwenden würden.
Verlust und Offenlegung sind nicht dieselbe Reparatur
Eine verlorene Passphrase lässt sich nicht aus dem Zertifikat wiederherstellen. Das Zertifikat ist öffentliches Material, das einen Namen an einen Schlüssel bindet; es enthält keinen Weg zurück zum privaten Schlüssel und keinen Hinweis auf die Passphrase. Die praktischen Optionen sind ein autorisiertes Backup des Schlüssels oder eine neue Identität, die über den normalen Prozess des Betreibers ausgestellt wird. Wer anbietet, die Passphrase zu 'wiederherstellen', bietet an, sie zu erraten.
Offenlegung erfordert eine andere Reaktion. Das erneute Verschlüsseln desselben Schlüssels mit einer neuen Passphrase lässt das Schlüsselmaterial unverändert, sodass eine Kopie, die anderswo bereits entsperrt wurde, weiter funktioniert. Die Reparatur besteht darin, den Berechtigungsnachweis zu widerrufen oder zu ersetzen: einen neuen Schlüssel und ein neues Zertifikat ausstellen, verteilen und den alten beim Gegenüber außer Betrieb nehmen. Bis dahin ist das Ändern des Dateipassworts Hausarbeit, keine Eindämmung. Halten Sie die alte Datei erst aus Backups heraus, nachdem die neue Identität nachweislich funktioniert, und notieren Sie, welche Seriennummer oder welcher Fingerabdruck sie ersetzt hat.