Forward Secrecy für ein VPN: Was ein gestohlener Schlüssel entsperren kann

Zeichnen Sie heute einen verschlüsselten Tunnel auf, stehlen Sie nächstes Jahr den langfristigen privaten Schlüssel des Servers und versuchen Sie, die Aufzeichnung zu entschlüsseln. Forward Secrecy ist die Eigenschaft, die besagt, dass der gestohlene Schlüssel allein nicht ausreicht. Es ist eine Aussage über aufgezeichnete Sitzungen und bestimmte Geheimnisse, kein allgemeines Versprechen, dass der Tunnel sicher war. Den Geltungsbereich richtig zu fassen, macht den Begriff nützlich.

Die Frage betrifft eine Aufzeichnung, nicht die laufende Sitzung

Der langfristige Schlüssel identifiziert den Endpunkt und signiert den Handshake. Sitzungsschlüssel verschlüsseln den eigentlichen Datenverkehr, und in einem Forward-Secret-Design werden sie aus frischem Schlüsselaustauschmaterial abgeleitet, das beide Seiten erzeugen und später verwerfen. Ein Angreifer, der nur den langfristigen Schlüssel besitzt, kann diese verworfenen Werte nicht rekonstruieren. Ein Angreifer mit laufendem Sitzungszustand kann es weiterhin, weshalb die Garantie die Vergangenheit und nicht die Gegenwart betrifft.

Die Behauptung ist bedingt: Sie gilt nur, wenn die ephemeren Geheimnisse wirklich zerstört wurden und das Protokoll das ist, für das Sie es halten. Ein gemischtes Deployment kann sie auf einem Tunnel erfüllen und auf einem anderen scheitern.

Ein Geheimnis darf die anderen nicht wieder aufbauen

Prüfen Sie den ausgehandelten Modus statt die Marketingseite. Die Handshake-Ausgabe nennt den Schlüsselaustausch und die Protokollversion.

openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sas

Die s_client-Zusammenfassung zeigt die TLS-Version und die Schlüsselaustauschgruppe, und eine ephemere Gruppe ist das sichtbare Zeichen einer Forward-Secret-Schlüsselvereinbarung. Die swanctl-Auflistung zeigt IKE- und CHILD-Assoziationen mit ihren Rekey-Timern, sodass Sie sehen, ob das Deployment Schlüssel planmäßig erneuert. Ein statischer RSA-Schlüsselaustausch oder ein alter Kompatibilitätsmodus verliert die Eigenschaft unabhängig vom Cipher-Namen. Notieren Sie den beobachteten Modus, nicht den vom Anbieter beworbenen.

Rekeying ist nicht automatisch Forward Secrecy

Wie oft ein Tunnel Schlüssel erneuert, ist eine separate Frage davon, wie jeder Schlüssel abgeleitet wird. Ein Design, das Schlüssel aus einem langfristigen Geheimnis neu erzeugt, kann jede Minute neu verschlüsseln und den Test trotzdem nicht bestehen, weil eine spätere Kompromittierung alle rekonstruiert. Umgekehrt kann ein Protokoll mit seltener Erneuerung immer noch Forward Secret sein, wenn jeder Austausch unabhängig ist. Lesen Sie die Ableitung, nicht das Intervall, und verwechseln Sie einen kurzen Wiederverbindungstimer nicht mit einer kryptografischen Garantie.

Dieselbe Verwechslung zeigt sich bei Cipher-Namen: Eine moderne Cipher sagt nichts darüber, wie ihr Schlüssel zustande kam.

Was nach der Garantie sichtbar bleibt

Forward Secrecy schützt den Klartext aufgezeichneter Sitzungen vor einer künftigen Schlüsselkompromittierung und tut nichts gegen einen Angreifer, der laufenden Datenverkehr auf einem kompromittierten Endpunkt liest. Sie entfernt weder Zieladressen noch Timing oder Volumen aus der Aufzeichnung und begrenzt nicht, wie lange ein Betreiber Verbindungsprotokolle aufbewahrt. Sie macht auch keinen kompromittierten Client vertrauenswürdig, weil der Angreifer bereits dort sitzt, wo Inhalt im Klartext vorliegt.

Wenn ein Anbieter Forward Secrecy behauptet, fragen Sie, welches langfristige Geheimnis als gestohlen gilt und welche Sitzungsgeheimnisse unzugänglich bleiben. Wenn diese beiden Fragen klare Antworten haben, bedeutet die Behauptung etwas.