Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung

Der Aufhänger: Zwei Menschen, ein Server, der niemals mitlesen darf

Stell dir vor, du schreibst deiner Kollegin eine Nachricht. Du tippst sie in dein Telefon, drückst auf Senden, und Sekundenbruchteile später erscheint sie auf ihrem Display – vielleicht am anderen Ende der Stadt, vielleicht auf einem anderen Kontinent. Dazwischen liegt eine ganze Kaskade von Maschinen: dein Mobilfunknetz, mehrere Router, ein Rechenzentrum mit den Servern des Messenger-Betreibers, wieder Router, wieder Mobilfunk. Deine Nachricht reist durch fremde Hände. Und dennoch soll niemand von diesen Zwischenstationen sie lesen können – nicht der Betreiber, nicht sein Cloud-Anbieter, nicht ein Angreifer, der sich in eine der Leitungen eingeklinkt hat, und nicht einmal eine Behörde, die später mit einem Durchsuchungsbeschluss beim Betreiber auftaucht und dessen komplette Datenbank beschlagnahmt.

Das ist das Versprechen der Ende-zu-Ende-Verschlüsselung: Der Klartext existiert nur an den beiden Enden – auf deinem Gerät und auf dem deiner Kollegin. Alles dazwischen sieht nur Chiffretext, eine Folge scheinbar zufälliger Bytes. Der Server, über den die Nachricht läuft, ist ein blinder Briefträger: Er stellt zu, ohne den Inhalt zu kennen.

Dieses Versprechen ist leicht ausgesprochen und schwer gehalten. Denn die naive Umsetzung – beide Seiten einigen sich einmal auf einen geheimen Schlüssel und verwenden ihn für alle Nachrichten – hat einen fatalen Fehler. Wird dieser eine Schlüssel jemals kompromittiert, sei es durch einen Einbruch in ein Gerät, eine erpresste Passphrase oder einen kryptografischen Durchbruch, dann fällt nicht eine Nachricht, sondern die gesamte Kommunikation – rückwirkend und für alle Zukunft. Ein Angreifer, der jahrelang geduldig den verschlüsselten Datenstrom mitgeschnitten hat, kann mit diesem einen Schlüssel alles nachträglich entziffern.

Das Signal-Protokoll ist die bislang eleganteste Antwort auf dieses Problem. Sein Kerngedanke ist so einfach wie radikal: Statt eines Schlüssels für alles verwendet es für jede einzelne Nachricht einen frischen Schlüssel, der unmittelbar nach Gebrauch gelöscht wird und aus dem sich weder die vorherigen noch die nachfolgenden Schlüssel berechnen lassen. Der Schlüssel stirbt, sobald die Nachricht entschlüsselt ist. Diese ständige Erneuerung nennt man Ratcheting – nach der Ratsche, dem Sperrzahnrad, das sich nur in eine Richtung drehen lässt und niemals zurück.

Für jemanden wie Sven – Senior AI Engineer mit einem Bein in der Cloud-Architektur und einem in der IT-Sicherheit – ist das Signal-Protokoll ein Musterbeispiel dafür, wie sich starke Sicherheitseigenschaften nicht durch ein einzelnes geniales Primitiv erreichen lassen, sondern durch das kluge Ineinandergreifen mehrerer einfacher Bausteine. Dieser Artikel nimmt dich auf die ganze Strecke mit: von der historischen Wurzel über die asynchrone Schlüsselvereinbarung X3DH und das doppelte Zahnradwerk der Double Ratchet bis zu den formalen Sicherheitsbeweisen, dem Sprung in die Post-Quanten-Ära und den Grenzen, die auch das beste Protokoll nicht überwinden kann.

Teil 1: Das Problem hinter dem Problem – Sicherheit gegen die Zukunft

Zwei Eigenschaften, die man leicht verwechselt

Bevor wir zur Mechanik kommen, lohnt es sich, zwei Sicherheitseigenschaften scharf zu trennen, die im Zentrum des gesamten Entwurfs stehen und die man in der Praxis oft durcheinanderwirft.

Die erste ist Forward Secrecy, auf Deutsch etwa „vorwärtsgerichtete Geheimhaltung". Sie beantwortet die Frage: Was passiert mit alten Nachrichten, wenn heute ein Schlüssel gestohlen wird? Bei Forward Secrecy lautet die Antwort: nichts. Die bereits gesendeten Nachrichten bleiben sicher, weil die Schlüssel, mit denen sie verschlüsselt wurden, längst gelöscht sind und sich aus dem aktuell erbeuteten Material nicht rekonstruieren lassen. Der Angreifer, der jahrelang mitgeschnitten und dann heute ein Gerät kompromittiert hat, geht für die Vergangenheit leer aus. Der Begriff geht auf die Eigenschaft klassischer Schlüsselaustauschverfahren zurück und wird manchmal „Perfect Forward Secrecy" genannt.

Die zweite Eigenschaft ist subtiler und war lange Zeit ein bloßes theoretisches Wunschbild: Post-Compromise Security, auch Future Secrecy oder Break-in Recovery genannt. Sie beantwortet die spiegelbildliche Frage: Was passiert mit zukünftigen Nachrichten, wenn heute ein Schlüssel gestohlen wird? Naiv würde man sagen: Alles ist verloren, denn der Angreifer kennt nun den Schlüssel und kann alles Weitere mitlesen. Post-Compromise Security macht das erstaunliche Versprechen, dass sich die Kommunikation nach einem Einbruch von selbst wieder heilt – vorausgesetzt, der Angreifer bleibt passiv und die beiden legitimen Parteien tauschen weiter Nachrichten aus. Nach einigen Runden ist der gestohlene Schlüssel wertlos, und der Angreifer ist wieder ausgesperrt.

Diese zweite Eigenschaft ist das eigentliche Kronjuwel des Signal-Protokolls. In der wissenschaftlichen Analyse von Cohn-Gordon und Kollegen aus dem Jahr 2017 wird Post-Compromise Security als eine „substanziell stärkere" Garantie gegen einen aktiven Angreifer formal definiert und für Signal nachgewiesen. Sie ist der Grund, warum ein einmaliger Einbruch – der in der realen Welt eben doch vorkommt – nicht das Ende der gesamten Vertraulichkeit bedeutet.

Das asynchrone Dilemma

Es gibt noch eine dritte Anforderung, die weniger nach Sicherheit klingt und doch den gesamten Entwurf prägt: Asynchronität. Ein klassischer verschlüsselter Schlüsselaustausch – etwa das Diffie-Hellman-Verfahren, das TLS beim Aufbau einer HTTPS-Verbindung nutzt – setzt voraus, dass beide Parteien gleichzeitig online sind und ein paar Nachrichten hin und her schicken, um sich auf einen gemeinsamen Schlüssel zu einigen. Bei einer Website ist das kein Problem: Server und Browser sind im Moment des Verbindungsaufbaus beide präsent.

Beim Messaging aber ist genau das nicht garantiert. Du schreibst deiner Kollegin um drei Uhr nachts, während ihr Telefon in der Schublade liegt und sie schläft. Deine Nachricht muss trotzdem sofort verschlüsselt werden und beim Server ankommen – und wenn sie morgens ihr Telefon anschaltet, soll sie sie entschlüsseln können, ohne dass ihr aktuell die Möglichkeit hatte, mit dir einen Handschlag auszuhandeln. Das Protokoll muss also einen sicheren gemeinsamen Schlüssel etablieren können, ohne dass beide Parteien gleichzeitig anwesend sind. Genau diese Quadratur des Kreises löst der erste Baustein des Signal-Protokolls: X3DH.

Teil 2: Die Ahnenreihe – von OTR zur Axolotl-Ratsche

Das Signal-Protokoll ist nicht aus dem Nichts entstanden. Sein direkter Vorfahre ist Off-the-Record Messaging (OTR), ein Protokoll aus dem Jahr 2004, das erstmals Forward Secrecy und abstreitbare Authentifizierung in einen Instant-Messenger brachte. OTR erneuerte die Schlüssel bei jeder Antwortrunde durch einen frischen Diffie-Hellman-Austausch – ein früher „Ratchet". Sein entscheidender Nachteil aber war genau die eben beschriebene Synchronität: OTR brauchte einen laufenden Dialog. Für die abgehackte, asynchrone Realität des mobilen Messagings, in der Nachrichten in beliebiger Reihenfolge, gebündelt oder mit stundenlanger Verzögerung eintreffen, war es untauglich.

Die Lösung entwickelten Moxie Marlinspike und Trevor Perrin ab etwa 2013 im Rahmen der App TextSecure, dem Vorgänger von Signal. Ihr zentraler Einfall trug zunächst den einprägsamen Namen Axolotl (nach dem mexikanischen Schwanzlurch, der berühmt dafür ist, verlorene Gliedmaßen nachwachsen zu lassen – ein Bild für die Selbstheilung der Post-Compromise Security). Später wurde das Verfahren nüchterner in zwei Komponenten aufgeteilt und dokumentiert: die X3DH-Schlüsselvereinbarung und die Double-Ratchet-Verschlüsselung, beide in offenen Spezifikationen auf der Signal-Website beschrieben.

Die Bedeutung dieser Arbeit lässt sich an der Verbreitung ablesen. Das Signal-Protokoll ist heute nicht nur die Grundlage der Signal-App, sondern verschlüsselt auch die Chats von WhatsApp – seit dem großflächigen Rollout 2016 – sowie Teile von Facebook Messenger, Google-Diensten und diversen weiteren Anwendungen. Es schützt damit die Kommunikation von weit über einer Milliarde Menschen. Ich bin der Meinung, dass es sich um eines der erfolgreichsten und folgenreichsten kryptografischen Protokolle der Geschichte handelt – wenige akademische Ideen haben so unmittelbar so viele Menschen erreicht.

Teil 3: X3DH – der Handschlag mit einem Schlafenden

Die Idee des Schlüsselbriefkastens

X3DH steht für Extended Triple Diffie-Hellman, also „erweitertes dreifaches Diffie-Hellman". Es löst das asynchrone Dilemma durch einen simplen, aber genialen Kniff: Jede Nutzerin hinterlegt im Voraus ein Bündel öffentlicher Schlüssel auf dem Server – eine Art Schlüsselbriefkasten, aus dem sich jeder bedienen kann, der ihr schreiben möchte, ohne dass sie selbst gerade online sein muss.

Dieses Bündel enthält drei Sorten von Schlüsseln, und der Unterschied zwischen ihnen ist wichtig:

Erstens den Identitätsschlüssel (Identity Key). Das ist der langlebige öffentliche Schlüssel, der die Person eindeutig repräsentiert und über lange Zeit stabil bleibt – er ist gewissermaßen der kryptografische Ausweis.

Zweitens einen signierten Vorabschlüssel (Signed Pre-Key). Das ist ein mittelfristiger Schlüssel, der vom Identitätsschlüssel signiert ist (damit ein Angreifer keinen falschen unterschieben kann) und regelmäßig – etwa wöchentlich – ausgetauscht wird.

Drittens einen Vorrat an einmaligen Vorabschlüsseln (One-Time Pre-Keys). Von diesen liegen viele im Briefkasten, und jeder wird nur ein einziges Mal verwendet: Sobald jemand einen davon abholt, um eine Konversation zu beginnen, wird er vom Server entfernt.

Drei bis vier Diffie-Hellman-Berechnungen, die zu einem Geheimnis verschmelzen

Will Alice nun Bob schreiben, der gerade offline ist, holt sie sein Bündel aus dem Briefkasten: seinen Identitätsschlüssel, seinen signierten Vorabschlüssel und – falls vorhanden – einen seiner einmaligen Vorabschlüssel. Sie erzeugt zusätzlich ein frisches, flüchtiges Schlüsselpaar nur für diese Konversation (den ephemeren Schlüssel).

Jetzt kommt der eigentliche Trick. Diffie-Hellman erlaubt es zwei Parteien, aus je einem eigenen privaten und einem fremden öffentlichen Schlüssel dasselbe gemeinsame Geheimnis zu berechnen, ohne dass ein Lauscher es rekonstruieren kann. X3DH führt nicht eine solche Berechnung durch, sondern drei oder vier – daher „triple" – und kombiniert die verschiedenen Schlüsselrollen über Kreuz:

• DH1: Alices Identitätsschlüssel mit Bobs signiertem Vorabschlüssel.
• DH2: Alices ephemerer Schlüssel mit Bobs Identitätsschlüssel.
• DH3: Alices ephemerer Schlüssel mit Bobs signiertem Vorabschlüssel.
• DH4 (falls ein einmaliger Vorabschlüssel vorhanden ist): Alices ephemerer Schlüssel mit Bobs einmaligem Vorabschlüssel.

Warum diese scheinbar umständliche Über-Kreuz-Kombination? Jede der Berechnungen trägt eine bestimmte Sicherheitseigenschaft bei. Die Kombinationen, die Bobs Identitätsschlüssel einbeziehen, authentifizieren ihn – nur der echte Bob kennt den zugehörigen privaten Schlüssel und kann später dasselbe Geheimnis berechnen. Umgekehrt authentifiziert DH1 Alice gegenüber Bob. Und die Einbindung des ephemeren und des einmaligen Schlüssels sorgt für Forward Secrecy: Da diese Schlüssel nach der Sitzung gelöscht werden, lässt sich das gemeinsame Geheimnis später nicht mehr aus den langlebigen Schlüsseln allein rekonstruieren.

Die Ergebnisse aller DH-Berechnungen werden aneinandergehängt und durch eine Schlüsselableitungsfunktion (KDF) geschickt – eine Einwegfunktion, die aus dem Rohmaterial einen sauberen, gleichverteilten Schlüssel destilliert. Das Resultat ist das initiale gemeinsame Geheimnis der Konversation. Alice kann es sofort berechnen und ihre erste Nachricht verschlüsseln; die dafür nötigen öffentlichen Informationen (ihren Identitätsschlüssel, ihren ephemeren Schlüssel und die Angabe, welchen Vorabschlüssel sie benutzt hat) hängt sie an die Nachricht. Wenn Bob am nächsten Morgen sein Telefon einschaltet, holt er diese Angaben ab, führt seinerseits dieselben DH-Berechnungen mit vertauschten Rollen durch – und erhält exakt dasselbe Geheimnis. Der Handschlag hat stattgefunden, ohne dass beide je gleichzeitig wach waren.

Teil 4: Die Double Ratchet – zwei ineinandergreifende Zahnräder

Das initiale Geheimnis aus X3DH ist erst der Anfang. Würden Alice und Bob es einfach für alle folgenden Nachrichten verwenden, hätten sie die Sicherheit gegen die Zukunft, die wir eingangs beschrieben haben, noch nicht erreicht. Hier setzt die Double Ratchet an – das Herzstück des Protokolls. Ihr Name verrät die Grundarchitektur: Sie besteht aus zwei Ratschen, die ineinandergreifen und sich gegenseitig antreiben. Die eine sorgt für Forward Secrecy, die andere für Post-Compromise Security. Verstehen wir sie einzeln, bevor wir sie zusammensetzen.

Die symmetrische Ratsche: eine Kette von Einwegschritten

Der erste Mechanismus ist die symmetrische Schlüsselratsche (Symmetric-Key Ratchet). Sie beruht auf einer KDF-Kette – einer fortlaufenden Kette von Schlüsselableitungen. Stell dir einen sogenannten Chain Key (Kettenschlüssel) vor. Aus ihm leitet eine KDF zwei Dinge ab: erstens einen Message Key (Nachrichtenschlüssel), mit dem genau eine Nachricht ver- oder entschlüsselt wird, und zweitens einen neuen Chain Key, der den alten ersetzt.

Der entscheidende Punkt ist die Einwegnatur der KDF: Aus dem neuen Chain Key lässt sich der alte nicht zurückrechnen, und aus dem Chain Key lässt sich der zuvor abgeleitete Message Key nicht rekonstruieren. Jede Nachricht dreht die Ratsche einen Zahn weiter. Nach dem Verschlüsseln wird der Message Key gelöscht, der alte Chain Key wird durch den neuen überschrieben – und damit ist der Weg zurück unwiderruflich versperrt.

Genau das liefert Forward Secrecy innerhalb einer Senderichtung: Kompromittiert ein Angreifer heute den aktuellen Chain Key, kann er zwar zukünftige Nachrichten dieser Kette entschlüsseln, aber keine einzige vergangene. Die alten Message Keys sind längst weg, und die Kette lässt sich nicht rückwärts abwickeln. Man spricht bildlich von einer Ratsche, weil sie sich – wie das Sperrzahnrad einer Ratsche – nur in eine Richtung bewegen lässt.

Was die symmetrische Ratsche allein aber nicht leistet, ist Heilung. Kennt der Angreifer den Chain Key, folgt er der Kette mühelos in die Zukunft. Für die Selbstheilung braucht es die zweite Ratsche.

Die Diffie-Hellman-Ratsche: frisches Zufallsmaterial von außen

Die zweite Ratsche ist die Diffie-Hellman-Ratsche (DH Ratchet). Ihre Aufgabe ist es, in regelmäßigen Abständen frische, unvorhersehbare Zufälligkeit in das System einzuspeisen – Material, das ein Angreifer selbst mit gestohlenem aktuellem Zustand nicht kennen kann.

Der Mechanismus: Jede Partei besitzt ein aktuelles DH-Schlüsselpaar (Ratchet Key). Bei jeder Nachricht sendet sie ihren aktuellen öffentlichen DH-Schlüssel mit. Sobald eine Partei einen neuen öffentlichen DH-Schlüssel der Gegenseite empfängt, führt sie eine neue Diffie-Hellman-Berechnung durch, erzeugt anschließend selbst ein frisches DH-Schlüsselpaar und wird es mit ihrer nächsten Nachricht mitschicken. So entsteht ein Ping-Pong: Bei jedem Richtungswechsel des Gesprächs tauschen beide Seiten neue DH-Schlüssel aus und speisen ein neues gemeinsames Geheimnis ein.

Diese frischen DH-Geheimnisse fließen in eine dritte, übergeordnete Kette – die Root Chain (Wurzelkette). Aus dem aktuellen Root Key und dem neuen DH-Geheimnis leitet die KDF einen neuen Root Key und zugleich einen frischen Chain Key für die symmetrische Ratsche ab. Mit anderen Worten: Jeder Richtungswechsel setzt die symmetrische Ratsche auf einen komplett neuen, frisch zufälligen Startwert.

Genau hier entsteht die Post-Compromise Security. Angenommen, ein Angreifer stiehlt zu einem Zeitpunkt den gesamten Sitzungszustand – Root Key, Chain Keys, alles. Er kann nun mitlesen. Doch sobald die legitimen Parteien das nächste Mal die Richtung wechseln und einen neuen DH-Schlüssel austauschen, kommt ein Diffie-Hellman-Geheimnis ins Spiel, dessen privater Anteil frisch erzeugt wurde und dem Angreifer unbekannt ist. Der neue Root Key hängt von diesem unbekannten Wert ab – und damit ist der gesamte weitere Verlauf für den Angreifer wieder undurchdringlich. Die Kommunikation hat sich geheilt, ganz wie die nachwachsenden Gliedmaßen des Axolotl. Voraussetzung ist allein, dass der Angreifer passiv bleibt: Solange er nur mitliest und nicht selbst aktiv Nachrichten fälscht, sperrt ihn das nächste DH-Ping-Pong wieder aus.

Das Zusammenspiel

Setzen wir die beiden Ratschen zusammen, ergibt sich das vollständige Bild:

Die DH-Ratsche dreht sich langsam – einmal pro Richtungswechsel des Gesprächs. Sie liefert das frische Zufallsmaterial und ist die Quelle der Selbstheilung.

Die symmetrische Ratsche dreht sich schnell – einmal pro Nachricht innerhalb einer Senderichtung. Sie liefert für jede einzelne Nachricht einen eigenen Schlüssel und ist die Quelle der Forward Secrecy.

Beide zusammen sorgen dafür, dass jede Nachricht ihren eigenen, kurzlebigen Schlüssel bekommt, dass die Vergangenheit nach einem Einbruch geschützt bleibt und dass sich die Zukunft nach einem Einbruch von selbst wieder verschließt. Das ist die vollständige Bedeutung des Bildes vom Schlüssel, der nach jeder Nachricht stirbt.

Verlorene und vertauschte Nachrichten

Ein Protokoll, das für jede Nachricht den Schlüssel weiterdreht, hat ein praktisches Problem: Im mobilen Netz kommen Nachrichten manchmal vertauscht oder gar nicht an. Was, wenn Nachricht 5 vor Nachricht 4 eintrifft? Der Empfänger hat den Message Key für 4 noch gar nicht abgeleitet, weil er die Kette erst bis 4 hätte weiterdrehen müssen.

Die Double Ratchet löst das elegant. Jede Nachricht trägt in ihrem Kopf eine Zählernummer (die Position in der aktuellen Kette) sowie die Länge der vorherigen Kette. Trifft Nachricht 5 zuerst ein, dreht der Empfänger die symmetrische Ratsche bis Position 5 vor, benutzt den Message Key für 5 – und speichert die übersprungenen Message Keys für 4 zwischen, statt sie zu verwerfen. Kommt Nachricht 4 später doch noch an, liegt ihr Schlüssel bereit. So bleibt das Protokoll robust gegen die Unordnung realer Netze, ohne die Einwegnatur der Kette aufzugeben. Damit dieser Zwischenspeicher nicht zum Sicherheitsleck oder zur Angriffsfläche für Speichererschöpfung wird, sind die Zahl und die Lebensdauer der aufbewahrten Schlüssel begrenzt.

Teil 5: Vertrauen und Beweise – warum man dem Protokoll glauben darf

Das Problem des ersten Kontakts

Alle bisherige Mechanik schützt die Nachrichten im Transit. Doch es bleibt eine Urfrage jeder Verschlüsselung: Woher weiß Alice, dass der öffentliche Identitätsschlüssel, den sie aus dem Briefkasten geholt hat, wirklich Bob gehört – und nicht einem Angreifer, der sich zwischen beide geschoben hat? Dieser klassische Man-in-the-Middle-Angriff ließe sich vom Protokoll allein nicht ausschließen: Ein bösartiger Server könnte Alice den Schlüssel des Angreifers unterschieben und beiden Seiten vorgaukeln, sie sprächen direkt miteinander.

Signal begegnet dem mit Sicherheitsnummern (Safety Numbers). Aus den beiden Identitätsschlüsseln berechnet die App eine kurze Zahlen- oder QR-Code-Repräsentation, die beide Nutzer über einen zweiten Kanal – ein Treffen, ein Telefonat, ein Blick auf denselben Bildschirm – vergleichen können. Stimmen die Zahlen überein, ist ausgeschlossen, dass ein Dritter dazwischensitzt. Dieser Schritt ist freiwillig, und ich bin der Meinung, dass er die eigentliche Achillesferse im Alltag ist: Kaum jemand verifiziert seine Kontakte tatsächlich, und die Sicherheit gegen einen aktiven, den Server kontrollierenden Angreifer hängt genau daran.

Die formalen Beweise

Ein Protokoll dieser Tragweite darf nicht nur „plausibel sicher" wirken. Die kryptografische Wissenschaft verlangt Beweise. Und tatsächlich gehört das Signal-Protokoll zu den am gründlichsten analysierten Verfahren überhaupt.

Der Meilenstein ist die Arbeit „A Formal Security Analysis of the Signal Messaging Protocol" von Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt und Douglas Stebila, vorgestellt 2017 auf der IEEE European Symposium on Security and Privacy (EuroS&P) und später erweitert im Journal of Cryptology (2020). Die Autoren modellierten die Kombination aus X3DH und Double Ratchet als mehrstufigen authentifizierten Schlüsselaustausch und bewiesen unter Standardannahmen die zentralen Sicherheitseigenschaften – einschließlich einer formalen Definition von Post-Compromise Security als Garantie gegen einen aktiven Angreifer. Ihr Fazit: Der Kernentwurf ist kryptografisch solide. Spätere Arbeiten, etwa mit werkzeuggestützter Verifikation, haben diese Befunde bestätigt und verfeinert.

Das ist bemerkenswert. Viele weit verbreitete Sicherheitsprotokolle wurden erst nachträglich auseinandergenommen – und dabei fielen oft schwere Mängel auf. Beim Signal-Protokoll lief es umgekehrt: Ein sauberer, minimalistischer Entwurf lud die Wissenschaft geradezu ein, ihn zu prüfen, und er hielt der Prüfung stand.

Teil 6: Der Sprung in die Post-Quanten-Ära – PQXDH

Warnschuss aus der Zukunft

So solide X3DH ist – es ruht auf Diffie-Hellman über elliptischen Kurven, und dessen Sicherheit beruht auf der Schwierigkeit des diskreten Logarithmus. Ein hinreichend großer, fehlertoleranter Quantencomputer würde dieses Problem mit dem Shor-Algorithmus effizient lösen und damit jeden klassischen Diffie-Hellman-Austausch brechen. Noch existiert diese Maschine nicht. Aber es gibt eine Bedrohung, die schon heute wirkt: „Harvest now, decrypt later" – ernte jetzt, entschlüssle später. Ein Angreifer, etwa ein Nachrichtendienst, kann heute verschlüsselten Verkehr in großem Stil aufzeichnen und archivieren, um ihn zu entschlüsseln, sobald die Quantentechnik reif ist. Für Daten, die noch in zehn oder zwanzig Jahren vertraulich bleiben müssen, ist das eine reale Gefahr.

PQXDH: das Beste beider Welten

Signals Antwort ist PQXDH – Post-Quantum Extended Diffie-Hellman, eingeführt 2023. Die Idee: Man ersetzt das klassische Diffie-Hellman nicht, sondern ergänzt es. Zusätzlich zu den bisherigen DH-Berechnungen führt PQXDH einen post-quanten-sicheren Schlüsselkapselungsmechanismus (KEM) ein – konkret CRYSTALS-Kyber (heute als ML-KEM standardisiert), ein gitterbasiertes Verfahren, dessen Sicherheit auf einem Problem beruht, das auch Quantencomputer nach heutigem Kenntnisstand nicht effizient lösen. Bob legt dazu einen zusätzlichen, signierten post-quanten-Vorabschlüssel in seinen Briefkasten.

Das gemeinsame Geheimnis wird nun aus beiden Quellen abgeleitet: dem klassischen DH-Material und dem post-quanten-KEM-Geheimnis. Diese Kombination ist bewusst so gewählt, dass die Konstruktion so lange sicher bleibt, wie mindestens eines der beiden Verfahren hält. Bricht ein Quantencomputer eines Tages das elliptische Diffie-Hellman, schützt noch immer Kyber; sollte sich umgekehrt eine unerwartete Schwäche in dem noch jüngeren Gitterverfahren zeigen, schützt weiterhin das jahrzehntelang erprobte DH. PQXDH zielt damit gezielt auf die Vertraulichkeit gegen „Harvest now, decrypt later" – es sichert das initiale Geheimnis gegen künftige Quantenangriffe ab.

Formale Verifikation als Teil des Entwurfs

Bemerkenswert – und ein Zeichen der methodischen Reife dieses Feldes – ist, wie PQXDH abgesichert wurde. Eine Gruppe um Karthikeyan Bhargavan, Charlie Jacomme und Kollegen unterzog das Protokoll einer formalen Verifikation mit den Werkzeugen ProVerif und CryptoVerif und stellte die Ergebnisse 2024 auf dem USENIX Security Symposium vor. Sie prüften drei Fragen: Bewahrt PQXDH alle Garantien von X3DH? Bietet es tatsächlich post-quanten-Forward-Secrecy? Und lässt es sich sicher parallel zum alten X3DH betreiben?

Die Analyse legte mehrere Schwachpunkte und potenzielle Verwundbarkeiten in der Spezifikation offen – die allerdings, dank konkreter Implementierungsentscheidungen, in der realen Signal-App nicht ausnutzbar waren. Insbesondere zeigten die Forscher, dass ein zusätzliches Bindungseigenschaft des KEM nötig ist, die sie formal definierten und für Kyber bewiesen. In Zusammenarbeit mit den Protokoll-Designern entstand eine überarbeitete Spezifikation, bei der jede Änderung formal verifiziert und mit einem Sicherheitsbeweis untermauert wurde. Ich bin der Meinung, dass genau diese Zusammenarbeit von Protokoll-Designern und Formal-Methods-Forschern der eigentliche Fortschritt ist – Sicherheit wird nicht mehr nur behauptet, sondern maschinell mitbewiesen, bevor das Protokoll ausgerollt wird.

Wichtig zur Einordnung: PQXDH härtet den Handschlag ab. Die laufende Double Ratchet blieb zunächst klassisch; die Weiterentwicklung hin zu einer vollständig post-quanten-sicheren fortlaufenden Ratsche ist Gegenstand aktueller Arbeit. Der Bezug zum Thema Post-Quanten-Kryptographie und zum Wettlauf gegen den Quantencomputer wird im Vault an anderer Stelle ausführlich behandelt (siehe Querverweise).

Teil 7: Die Grenzen – was auch das beste Protokoll nicht kann

Bei aller Eleganz ist es wichtig, nüchtern zu bleiben. Das Signal-Protokoll schützt den Inhalt der Nachrichten während der Übertragung – nicht mehr und nicht weniger. Drei Grenzen sollte man kennen.

Erstens die Metadaten. Verschlüsselt ist das Was, nicht zwangsläufig das Wer mit wem, wann und wie oft. Diese Verbindungsdaten – wer wem schreibt, zu welcher Uhrzeit, in welcher Frequenz – sind oft aussagekräftiger als der Inhalt selbst und werden vom Kernprotokoll nicht verborgen. Signal begegnet dem mit zusätzlichen Techniken wie Sealed Sender, das die Absenderangabe vor dem eigenen Server verbirgt, doch das perfekte Verstecken von Metadaten bleibt ein hartes, nur teilweise gelöstes Problem.

Zweitens die Endpunkte. Die gesamte Sicherheit gilt nur zwischen den Geräten. Ist eines der beiden Geräte selbst kompromittiert – durch Schadsoftware, einen physischen Zugriff, eine bösartige App oder einfach einen Screenshot –, liegt der Klartext offen. Ende-zu-Ende-Verschlüsselung schützt die Leitung, nicht das Endgerät. Der stärkste Riegel nützt nichts, wenn der Einbrecher schon im Haus ist.

Drittens das Vertrauen beim Erstkontakt. Wie in Teil 5 beschrieben, hängt der Schutz gegen einen aktiven, den Server kontrollierenden Angreifer an der Verifikation der Sicherheitsnummern – einem Schritt, den kaum jemand ausführt. Hier ist die Kryptografie so stark wie eh und je, aber die menschliche Praxis ist die Schwachstelle.

Diese Grenzen schmälern die Leistung des Protokolls nicht. Sie verorten sie nur präzise. Das Signal-Protokoll ist ein herausragend gebautes Schloss an einer Tür – aber ein Schloss ersetzt weder eine Alarmanlage im Haus noch die Prüfung, ob man dem Besucher tatsächlich öffnet.

Erkenntnis zum Mitnehmen

Der praktische Kern dieses Artikels lässt sich in einem einzigen Entwurfsprinzip verdichten, das weit über das Messaging hinausreicht: Verteile Vertrauen über die Zeit, statt es in einem einzigen Punkt zu bündeln. Die naive Verschlüsselung setzt alles auf einen Schlüssel und macht ihn damit zum Single Point of Failure – ein einziger erfolgreicher Angriff kompromittiert Vergangenheit und Zukunft zugleich. Das Signal-Protokoll zerlegt dieses eine Vertrauen in eine lange Kette winziger, kurzlebiger Geheimnisse, von denen jedes für sich fast nichts verrät und die sich nach einem Einbruch sogar selbst wieder heilen.

Für Svens Arbeit – ob in der Cloud-Architektur, im Sicherheitsdesign oder beim Bau von Systemen, die mit sensiblen Daten umgehen – ist die übertragbare Lektion diese: Frage bei jedem Geheimnis in deinem System nicht nur „Wie gut ist es geschützt?", sondern „Was passiert, wenn es doch kompromittiert wird – bleibt die Vergangenheit sicher, und heilt sich die Zukunft?" Kurzlebige, regelmäßig rotierende Schlüssel, sauber getrennte Schlüsselableitungen und die bewusste Trennung von Forward Secrecy und Post-Compromise Security sind Werkzeuge, die man auch außerhalb eines Messengers einsetzen kann – bei Session-Tokens, bei API-Schlüsseln, bei der Verschlüsselung ruhender Daten. Die Ratsche ist kein Gimmick, sondern eine Haltung: Nichts, was einmal geheim war, soll durch einen späteren Einbruch nachträglich verloren gehen.

Reflexionsfrage

Das Signal-Protokoll heilt sich nach einem Einbruch selbst – aber nur, solange der Angreifer passiv bleibt und die legitimen Parteien weiter kommunizieren. In welchen deiner eigenen Systeme verlässt du dich implizit darauf, dass ein einmal vergebenes Geheimnis „für immer" gilt, und wo könntest du durch bewusste Rotation und getrennte Schlüsselableitung dafür sorgen, dass ein erfolgreicher Angriff von heute nicht automatisch die Daten von gestern und morgen mitreißt?

Querverweise im Vault

• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – die ausführliche Behandlung der Quantenbedrohung, der NIST-Standardisierung und des „Harvest now, decrypt later"-Prinzips, das PQXDH motiviert.
• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – warum die stärkste Kryptografie am Endpunkt scheitern kann: mikroarchitektonische Seitenkanäle als Beispiel für die Verwundbarkeit der Geräte, auf denen der Klartext liegt.
• Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs – Vertrauen als Angriffsfläche: dort in der Lieferkette, hier beim Erstkontakt und in der Implementierung des Protokolls.

Quellen

• Signal Foundation: The Double Ratchet Algorithm (Spezifikation, T. Perrin & M. Marlinspike). https://signal.org/docs/specifications/doubleratchet/
• Signal Foundation: The X3DH Key Agreement Protocol (M. Marlinspike & T. Perrin, 2016). https://signal.org/docs/specifications/x3dh/
• Signal Foundation: The PQXDH Key Agreement Protocol (E. Kret & R. Schmidt). https://signal.org/docs/specifications/pqxdh/
• K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt, D. Stebila: A Formal Security Analysis of the Signal Messaging Protocol, IEEE EuroS&P 2017 / Journal of Cryptology 2020. https://eprint.iacr.org/2016/1013.pdf
• K. Bhargavan, C. Jacomme et al.: Formal Verification of the PQXDH Post-Quantum Key Agreement Protocol for End-to-End Secure Messaging, USENIX Security 2024. https://www.usenix.org/system/files/usenixsecurity24-bhargavan.pdf

Hinweis: Dieser Artikel gibt den überprüfbaren, wissenschaftlich gesicherten Stand wieder. Wo eigene Einschätzungen einfließen, sind sie mit „Ich bin der Meinung, dass ..." gekennzeichnet.

← All articles