Warum ist volle Forward Secrecy für (so etwas wie) Qabel nicht sinnvoll?

von Paul Rösler

 

Dieser Blogartikel soll beleuchten, warum wir uns beim Design des Drop Protokolls gegen volle Forward Secrecy entschieden haben.


Definition Forward Secrecy

Bei einem Protokoll, das Forward Secrecy erfüllt, kann der langfristige Schlüssel von einem Angreifer gestohlen werden, ohne dass damit alte übertragene Nachrichten entschlüsselt werden können. Protokolle wie Axolotl erfüllen diese Eigenschaft.
Das Qabel Drop Protokoll setzt auf Noise, welches unter dem implementierten Einsatz nur Sender Forward Secrecy oder „Weak Forward Secrecy“ erreicht. Das bedeutet, dass bei einem Diebstahl des langfristigen Schlüssels von Identität A nicht die Nachrichten entschlüsselt werden können, die A gesendet hat. Nachrichten, die A empfangen hat, können hingegen entschlüsselt werden.


Definition von „(so etwas wie) Qabel”

Qabel ist ein asynchrones Multi-Device Protokoll. Das bedeutet, dass Sender und Empfänger nicht gleichzeitig online sein müssen, weshalb ein Server die gesendeten Nachrichten vorhalten muss, bis der Empfänger sie dort anfragen kann. Außerdem können Sender und Empfänger mehrere Geräte besitzen, die alle jederzeit die Nachrichten senden bzw. empfangen können. Das erfordert sowohl eine Synchronisation beim Sender als auch beim Empfänger.


Implikationen von Forward Secrecy auf „(so etwas wie) Qabel“

Es ist kein Protokoll bekannt, das Forward Secrecy für asynchrone Kommunikation erreicht, bei dem nicht regelmäßig temporäre Schlüssel ausgetauscht werden müssen. Da die privaten temporären Schlüssel auf allen Geräten einer Identität verfügbar sein müssen, um Nachrichten zu entschlüsseln, müssen diese entweder synchronisiert oder für jedes Gerät separat erzeugt und ausgetauscht werden. Die Synchronisation der privaten temporären Schlüssel käme für ein effizientes Protokoll nicht ohne die Verschlüsselung mit dem Geräteschlüssel aus. Falls dieser Geräteschlüssel gestohlen würde, könnte der temporäre private Schlüssel gewonnen werden, was die Forward Secrecy brechen würde.


Für den Fall, dass jedes Gerät eigene temporäre Schlüssel besitzt und bereitstellt, müsste jede Nachricht an alle Geräte des Empfängers verschlüsselt und gesendet werden. Außerdem müsste die Nachricht zur Synchronisation an alle eigenen Geräte gesendet werden. Das bedeutet eine gesendete Nachricht würde x Mal übertragen werden, wobei x die Summe der Anzahl der Geräte des Senders und des Empfängers ist.

 

Abbildung 1: Zugreifen auf archivierte Nachrichten oder Knacken des Passworts um den Schlüssel zu erlangen: Wann Forward Secrecy keinen Vorteil bringt

 

Hinweis: Diese Darstellung dient lediglich der Veranschaulichung und entspricht nicht den von Qabel gespeicherten Daten.


Besonderheit des Qabel Drop Protokolls

Da das Qabel Drop Protokoll, um Anonymität zu gewährleisten, Nachrichten für mehrere Empfänger zusammen in einer Drop ID vorhält, und der vorhaltende Drop Server nicht weiß an wen die Nachrichten gerichtet sind, müssen immer alle neuen vorgehaltenen Nachrichten an alle Empfänger hinter einer Drop ID gesendet werden. Der Faktor x würde also noch einmal mit einem Faktor y, der die Anzahl aller Empfänger hinter einer Drop ID repräsentiert, multipliziert.
Insgesamt würde jeder Empfänger eine so große Vielzahl an überflüssigen Nachrichten empfangen, dass die Verarbeitung das empfangende Gerät überlasten oder die Anonymität gefährdet würde.
Eine Möglichkeit zum Erreichen von vollständiger Forward Secrecy wäre ein temporärer synchroner Kanal zwischen zwei Geräten, der nur hergestellt wird, wenn er benötigt würde. Die Implementierung eines solchen Kanals wird noch evaluiert.


Wann Forward Secrecy (nicht) sinnvoll ist

Forward Secrecy ist nur dann sinnvoll, wenn Nachrichten bei der Übertragung aufgezeichnet werden können, aber nicht langfristig auf dem Gerät gespeichert sind. Da der private Schlüssel üblicherweise nur vom Gerät des Besitzers gestohlen werden kann, könnten gespeicherte Nachrichten direkt mit gestohlen werden, ohne dass die aufgezeichneten Nachrichten mit dem Schlüssel entschlüsselt werden müssten.
Da Qabel die Konversationen persistiert und in Zukunft synchronisieren soll, wäre das Stehlen der Nachrichten vom Gerät einfacher als das Aufzeichnen der Konversationen mit anschließendem Diebstahl des privaten Schlüssels vom Gerät. Ein temporärer Kanal, der Forward Secrecy garantiert, würde also sinnvollerweise nicht persistiert werden.

---

^1 Die Implikationen von Forward Secrecy und die Auflistung der Eigenschaften eines entsprechenden Protokolls sind hier aufgrund von Komplexität gekürzt und unvollständig dargestellt. Die Debatte zur Evaluierung der Vor- und Nachteile ist auf github verfügbar. Moxie Marlinspike hat hier bereits eine weitreichende Übersicht zu diesem Thema geliefert.