Begriff
Perfect Forward Secrecy (PFS)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir vor, der Geheimdienst zeichnet HEUTE all deine verschlüsselten Chats auf. Sie können sie nicht lesen (da verschlüsselt). In 5 Jahren klauen sie den Private Key von WhatsApp/Telegram/Server. Können sie jetzt die Aufzeichnungen von heute entschlüsseln?
- Ohne PFS: JA. Der Private Key entschlüsselt alles rückwirkend ("Master Key").
- Mit PFS: NEIN. Bei PFS wird für jede Sitzung (oder jede Nachricht) ein neuer, temporärer Schlüssel ausgehandelt (Ephemerer Key). Der Server-Key dient nur zum Signieren ("Ich bin wirklich der Server"), nicht zum Verschlüsseln der Daten. Selbst wenn der Server-Key gestohlen wird, bleiben alte Nachrichten sicher. Der Dieb kann nur ab jetzt mitlesen (Man-in-the-Middle), aber nicht in die Vergangenheit schauen.
Merksatz: Eine Eigenschaft von Schlüsselaustauschprotokollen, die sicherstellt, dass die Kompromittierung langfristiger Schlüssel (Private Keys) nicht zur Entschlüsselung vergangener aufgezeichneter Kommunikation führt.
In TLS 1.3 ist PFS Pflicht. (Früher bei RSA Key Exchange war es optional, jetzt bei ECDH Standard). In Signal / WhatsApp: Jeder Chat nutzt das "Double Ratchet Algorithm". Der Schlüssel ändert sich mit jeder Nachricht. Wenn jemand dein Handy klaut, kann er (theoretisch) nicht die alten Nachrichten entschlüsseln, wenn die alten Keys gelöscht wurden.
1. Ephemeral Diffie-Hellman (DHE / ECDHE)
Das "E" steht für Ephemeral (Flüchtig). Alice und Bob generieren für jede Session ein neues Zufalls-Schlüsselpaar ($a, g^a$ und $b, g^b$). Sie tauschen die Public Parts aus und berechnen das Shared Secret ($g^{ab}$). Danach werfen sie $a$ und $b$ weg. Der Langzeit-Key (RSA/ECDSA) signiert nur den Austausch, um Authentizität zu garantieren.
2. Session Resumption
Performance-Optimierung. Wenn ich mich kurz danach wieder verbinde, will ich nicht den ganzen Handshake machen. TLS Session Tickets erlauben schnellen Reconnect. Achtung: Wenn die Tickets nicht sicher verwaltet werden (rotierender Ticket-Key), können sie PFS aushebeln!
1. The Diffie-Hellman Key Exchange (ECDHE) Math
Wie tauschen Alice und Bob einen Schlüssel (Session Key) vor den Augen von Spion Eve sicher aus, der nur für diese eine Session gilt? Sie nutzen die Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) Mathematik: Sie einigen sich offen auf eine zyklische Gruppe über einem endlichen Körper (Base Point $G$). Alice wählt einen zufälligen Private Scalar $a$ (Zahl) und sendet $A = a \cdot G$ (Punkt auf der Kurve). Das $a$ bleibt extrem geheim. Bob wählt Scalar $b$ und sendet $B = b \cdot G$. Das Geheimnis von PFS: Alice berechnet den Shared Key $K = a \cdot B$. Bob rechnet $K = b \cdot A$. Mathematisch ist beides $a \cdot b \cdot G$. Eve sieht nur $A$ und $B$. Wegen des "Elliptic Curve Discrete Logarithm Problem" (ECDLP) ist es für einen klassischen Computer unmöglich, aus der puren Kenntnis des Punktes $A$ auf Alices geheimen Multiplikator $a$ zurückzurechnen. Nach der Verbindung verwerfen Alice und Bob die Pointer $a$ und $b$ unwiderruflich aus dem RAM! PFS ist garantiert.
2. TLS Session Tickets: PFS Kryptonit
PFS ist rechenintensiv (mehrfache Punkt-Multiplikationen auf Kurven pro Handshake). Hochlast-APIs (Microservices) umgehen das mit TLS Session Resumption. Der Server schickt dem Client beim ersten Mal ein "Session Ticket". Dieses Ticket beinhaltet den ausgehandelten symmetrischen Schlüssel (Master Secret), der jedoch mit einem dem Server exklusiv gehörenden STEK (Session Ticket Encryption Key) verschlüsselt ist. Kommt der Client 5 Minuten später wieder, liefert er das Ticket. Der Server entschlüsselt es mit dem STEK, hat das Master Secret wieder und spart die teure Diffie-Hellman Mathe. Das Horror-Szenario: Wenn Administratoren den symmetrischen STEK Master auf dem Load Balancer niemals rotieren, killt dies PFS! Diebe stehlen den STEK vom Disk-Image und entschlüsseln damit rückwirkend jeglichen Traffic aller aufgefangenen Session-Tickets der letzten Wochen. Best Practice: STEK in Nginx/HAProxy als In-Memory-Array stündlich rotieren und restlos überschreiben.
3. Asynchronous Ratcheting in Signal (Double Ratchet)
Web-Sitzungen (TLS) sind flüchtig, aber wie skaliert PFS in asynchronen Messengern (Signal), in denen der Bob oft tagelang gar nicht online ist, während Alice im Minutentakt textet? Signal hat das "Double Ratchet Algorithm" erfunden. Der "Asymmetric Ratchet" erneuert bei jedem Wechsel des Sprechers die Diffie-Hellman Keypairs (ECHDE). Der "Symmetric Ratchet" generiert für jede einzelne abgesetzte Textnachricht via KDF (Key Derivation Function) einen völlig neuen Encrypt-Key ($K_i$) und einen neuen Chain-Key ($C_{i+1}$) und droppt danach sofort gnadenlos $K_i$. Das stellt sicher, dass selbst bei Diebstahl des Telefons nicht nur die Vergangenheit verschlossen bleibt (Forward Secrecy), sondern dass ein Spion nach einem temporären Leak einer Key-Iteration auch zukünftige neue Antworten nicht lesen kann, weil ein eintreffender Diffie-Hellman Step aus dem Nichts das KDF-Material radikal neu entmischt ("Post-Compromise Security" / Future Secrecy).
Quick-Check
Warum nicht immer?
Rechenaufwand. Früher war "RSA Key Exchange" billiger als "Diffie-Hellman". Heute sind CPUs schnell genug, deshalb ist PFS jetzt Standard.Heartbleed?
Der Heartbleed-Bug (2014) erlaubte Hackern, Private Keys aus dem RAM zu stehlen. Websites mit PFS waren fein (alte Daten sicher). Websites ohne PFS waren katastrophal (alles rückwirkend lesbar).E-Mail?
PGP hat traditionell KEIN PFS. Wenn dein PGP-Key geklaut wird, sind alle deine alten E-Mails lesbar. Das ist eine große Schwäche von PGP.