Symmetrische vs. Public-Key-Verschlüsselung in einem VPN: Was jede leistet

Leute beschreiben ein VPN als „mit Public-Key-Verschlüsselung arbeitend“ und stellen sich dann vor, jedes Paket werde mit dem Zertifikat des Servers verschlossen. Dieses Bild ist auf eine Weise falsch, die zählt, wenn man eine Konfigurationsdatei oder einen Paketmitschnitt liest. Die Public-Key-Hälfte eines VPN beweist, wer die Gegenstelle ist, und einigt sich auf geheimes Material; die symmetrische Hälfte schützt den Verkehr tatsächlich, Paket für Paket, über die gesamte Lebensdauer der Sitzung.

Die beiden Hälften haben unterschiedliche Lebensdauern, unterschiedliche Fehlermodi und unterschiedliche Dinge, die man gefahrlos veröffentlichen kann. Sobald man sie trennt, hören Fragen wie „ist RSA 2048 schwächer als AES-128“ auf zu verwirren, weil sie nie vergleichbar waren.

Drei Vorgänge, die oft vermischt werden

Public-Key-Kryptografie ist ein Dach über mindestens drei verschiedene Vorgänge. Eine Signatur beweist, dass der Inhaber eines privaten Schlüssels eine bestimmte Nachricht gebilligt hat. Schlüsselvereinbarung lässt zwei Gegenstellen aus öffentlich ausgetauschten Werten ein gemeinsames Geheimnis ableiten. Public-Key-Verschlüsselung verbirgt Daten unter dem öffentlichen Schlüssel von jemandem, sodass nur der private Schlüssel sie öffnen kann.

VPN-Handshakes nutzen meist die ersten beiden. Ein Zertifikat ist kein Verschlüsselungsschlüssel; es ist eine signierte Erklärung, die einen Namen an einen öffentlichen Schlüssel bindet und es der anderen Seite erlaubt zu entscheiden, ob sie dem gerade erhaltenen Schlüssel traut. Die Schlüsseletablierung in TLS 1.3 etwa beruht auf (EC)DHE-Schlüsselvereinbarung plus Zertifikatssignaturen, nicht darauf, die Sitzung mit dem öffentlichen Schlüssel des Servers zu verschlüsseln.

Was der Handshake tatsächlich erzeugt

In einem modernen Handshake erzeugt jede Seite ein ephemeres Schlüsselpaar, tauscht die öffentlichen Hälften aus und berechnet ein gemeinsames Geheimnis, das nie über die Leitung geht. Dieses Geheimnis läuft dann durch eine Schlüsselableitungsfunktion, um getrennte Schlüssel für jede Richtung zu erzeugen, dazu die Nonces und das IV-Material, das die Datensatzschicht braucht. WireGuard tut dies mit seiner Noise-basierten Konstruktion; TLS 1.3 tut es mit HKDF über das Handshake-Transkript.

Das langfristige Credential — Zertifikat und privater Schlüssel oder ein statischer WireGuard-Schlüssel — authentifiziert diesen Austausch. Es signiert oder mischt sich in das Transkript, damit ein Fremder den Handshake nicht anstelle der Gegenstelle abschließen kann. Danach leistet das Credential keine Arbeit pro Paket. Täte es das, bräuchte jedes Paket eine Private-Key-Operation, und ein ausgelasteter Tunnel wäre durch die langsamste Operation im Stack begrenzt.

Daraus folgen zwei Nebeneffekte. Erstens sind die Sitzungsschlüssel jedes Mal frisch, weshalb ein Angreifer, der später den langfristigen Schlüssel stiehlt, früher aufgezeichnete Sitzungen nicht entschlüsseln kann, sofern die Vereinbarung ephemer war. Zweitens kompromittiert ein geleakter Sitzungsschlüssel eine Sitzung, nicht die Identität.

Warum Massendaten symmetrische Schlüssel nutzen

Symmetrische Chiffren verkraften Volumen gut: AES-GCM oder ChaCha20-Poly1305 verarbeiten jedes Paket mit einem Schlüssel, der bereits im Speicher liegt, authentifizieren den Header und erhöhen einen Zähler. Die Empfangsseite prüft die Nonce und das Authentifizierungs-Tag und verwirft alles, was scheitert oder wiederholt wird. Das ist billig genug für Leitungsgeschwindigkeit auf gewöhnlicher Hardware, und dieselbe Konstruktion liefert Vertraulichkeit und Integrität in einem Durchgang.

Die Konstruktion ist auch der Ort, an dem die meisten Implementierungsfehler leben. Eine wiederholte Nonce in GCM bricht Vertraulichkeit und Authentizität auf einmal, deshalb leiten Protokolle Schlüssel pro Richtung ab und führen einen expliziten Zähler oder eine Epoche. Wenn Sie einen Paketmitschnitt lesen und die Länge des Geheimtexts der Klartextlänge plus festem Overhead entspricht, arbeitet die symmetrische Schicht, nicht eine Public-Key-Operation pro Paket.

Lebensdauern, Rekeying und Forward Secrecy

Sitzungsschlüssel sollen ablaufen. TLS 1.3 erlaubt eine KeyUpdate-Nachricht, um die Verkehrsschlüssel zu rollen; WireGuard erneuert eine Sitzung nach einer konfigurierten Zeit oder Nachrichtenzahl und hält den alten kurz für Pakete unterwegs. OpenVPN handelt seine Datakanalschlüssel nach einem Zeitplan neu aus, wobei reneg-sec das Intervall steuert.

Keine dieser Rotationen ist dasselbe wie das Erneuern eines Zertifikats. Ein Zertifikat kann ein Jahr gültig sein, während die Sitzungsschlüssel alle paar Minuten wechseln, und ein Zertifikat lässt sich ersetzen, ohne die Schlüssel des laufenden Tunnels anzufassen. Wenn Sie einen Ablauf planen, fragen Sie, welches Objekt Sie rotieren; die Antwort entscheidet, ob Clients sich neu verbinden oder einfach neu verschlüsseln.

Konfigurationen und Diagnosen lesen, ohne Objekte zu vermischen

In der Praxis wählen Sie ein vollständiges Protokoll und dessen unterstützte Primitive, statt ein eigenes zusammenzubauen. OpenVPNs --tls-crypt-Schlüssel schützt den Steuerkanal; der Datenkanal nutzt ausgehandelte symmetrische Chiffren. WireGuards PrivateKey- und PublicKey-Einträge sind Identitätsmaterial, während seine Transportschlüssel intern abgeleitet werden. Diese Felder als dieselbe Art Geheimnis zu lesen führt zu Fehlern wie dem Einfügen eines öffentlichen Schlüssels, wo ein privater hingehört.

Halten Sie öffentliches Material vom privaten getrennt. Ein Zertifikat, ein öffentlicher WireGuard-Schlüssel und ein Fingerabdruck sind sicher in einem Ticket teilbar. Ein privater Schlüssel, ein vorab geteilter Schlüssel und ein exportierter Sitzungsschlüssel sind es nicht. Wenn Sie Stärken vergleichen, vergleichen Sie innerhalb eines Typs: eine Elliptische-Kurve-Kennung, eine RSA-Modulusgröße und eine AES-Schlüsselgröße messen unterschiedliche Dinge unter unterschiedlichen Annahmen. Die TLS-1.3-Spezifikation ist eine nützliche Referenz dafür, wie die beiden Schichten zusammenpassen, auch wenn Ihr Tunnel kein TLS ist.