OMEMO: Endlich auf vielen Geräten verschlüsselt chatten
Wer verschlüsselte Chat-Nachrichten auf mehreren Geräten gleichzeitig darstellen will, hat derzeit nur eine sehr begrenzte Auswahl an geeigneten Apps. Mit dem OTR-Workaround für verschlüsselte Chats über Jabber (XMPP) können zudem nur Nachrichten verschlüsselt werden, wenn beide Nutzer zur gleichen Zeit online sind. Die XMPP-Erweiterung OMEMO soll dieses Problem lösen.
Im Rahmen des Google Summer of Codes hat es OMEMO in den Android-XMPP-Client Conversations geschafft, und seit Anfang des Jahres steht ein Plugin für den Desktopclient Gajim bereit. Einer der Macher von OMEMO erklärt im Folgenden, wie man es benutzt, was man beachten muss und welche Technik im Hintergrund arbeitet – und räumt mit ein paar Missverständnissen bezüglich XMPP auf.
Jabber – der etablierte Standard
XMPP, umgangssprachlich auch Jabber genannt, ist ein Protokoll für providerunabhängiges Instant Messaging. Ähnlich wie bei E-Mail werden Benutzer über benutzername@server identifiziert. Das erweiterbare Basisprotokoll ist von der Internet Engineering Task Force (IETF) standardisiert und definiert, wie Clients und Server sowie Server untereinander Pakete austauschen können. Welche Informationen in diesen Paketen konkret übertragen werden, ist über Erweiterungen definiert.
Diese Erweiterungen, XEPs (XMPP Extension Protocol) genannt, werden über die XMPP Standards Foundation standardisiert. Es existieren Erweiterungen für alle möglichen Einsatzzwecke. Lange Zeit vermisst wurde jedoch eine standardisierte Erweiterung für Ende-zu-Ende-Verschlüsselung – diese ist mit OMEMO in der Vorbereitung und kann auch bereits genutzt werden. Doch auch ohne Standardisierung fanden zwei Verschlüsselungsmethoden mit der Zeit ihre Anwendung in XMPP: OpenPGP und OTR.
OTR ist nur eine halbe Lösung
OpenPGP hat in Form einer inoffiziellen, nicht standardisierten Erweiterung, XEP-0027(öffnet im neuen Fenster), Einzug in diverse XMPP-Clients erhalten. Die zurzeit am weitesten verbreitete Verschlüsselungsmethode OTR (Off-the-Record-Messaging) hingegen ist keine Erweiterung für XMPP – das wird oft missverstanden. Sie funktioniert unabhängig vom verwendeten Instant Messenger und verpackt sich selber in herkömmliche Textnachrichten. Ein Problem im Zusammenspiel von OTR und XMPP ergibt sich jedoch aus der Tatsache, dass OTR am Anfang einer Sitzung einen Schlüsselaustausch durchführen muss. In Ermangelung eines Standards, der definiert, von wann bis wann eine Sitzung gültig ist, handhabt jede Implementierung dies ein bisschen anders, was im schlimmsten Fall zum Verlust von Nachrichten führen kann, wenn ein Client Nachrichten in einer Sitzung verschickt, die am anderen Ende schon nicht mehr existiert.
Traditionell ermöglicht es XMPP dem Benutzer, mit mehreren Clients gleichzeitig angemeldet zu sein. Der Schlüsselaustausch von OTR findet jedoch immer nur zwischen zwei Geräten statt. Ein zweiter Client bekommt folglich nur unlesbaren Datenmüll zugeschickt. Nach über zehn Jahren OTR-Nutzung wurde 2015 zumindest der Versuch unternommen, ein paar Regeln für den Versand von OTR-verschlüsselten Nachrichten über XMPP aufzustellen (XEP-0364(öffnet im neuen Fenster)). Die Limitierungen von OTR sollen künftig durch Verwendung von OMEMO nicht mehr auftauchen.
Eine Lösung der Probleme: OMEMO
Im Rahmen des Google Summer of Code 2015(öffnet im neuen Fenster) hat der Entwickler Andreas Straub eine Referenzimplementierung einer neuen Erweiterung für Ende-zu-Ende-Verschlüsselung entwickelt. Als Basis für die Referenzimplementierung wählte er den Android-XMPP-Client Conversations, der zu dem Zeitpunkt schon OpenPGP und OTR implementierte. Als Mentor fungierte der Autor dieses Artikels.
Anforderungen an den neuen Standard waren eine gute Integration in bestehende XMPP-Erweiterungen und die Möglichkeit, Nachrichten an mehrere Geräte zu schicken. Nach der Fertigstellung wurde der Standardentwurf OMEMO Encryption(öffnet im neuen Fenster) (OMEMO Multi End Message and Object Encryption) genannt.
Stark vereinfacht ausgedrückt ist OMEMO eine Abstraktion über dem Signal-Protokoll. Das Signal-Protokoll kann im Grunde als eine moderne Alternative zu OTR angesehen werden und findet mittlerweile in diversen Instant Messengers wie Whatsapp oder Signal Anwendung. Der wichtigste Unterschied zu OTR ist, dass Sitzungen nicht mehr regelmäßig auf- und abgebaut werden, sondern über die ganze Lebenszeit des Instant Messengers bestehen bleiben.
Schlüsselmaterial geht nicht verloren
Lebenszeit bedeutet in diesem Falle: so lange, dass das Schlüsselmaterial auf dem Gerät nicht durch Deinstallation oder Neuinstallation verloren geht. Darüber hinaus ist das Signal-Protokoll im Gegensatz zu OTR immun gegen den Verlust von Nachrichten. OTR erzeugt den Schlüssel einer einzelnen Nachricht aus der vorherigen Nachricht. Geht bei OTR eine Nachricht verloren, ist das Entschlüsseln nachfolgender Nachrichten unmöglich.
Das Signal-Protokoll löst dieses Problem, indem Schlüsselmaterial nicht immer aus dem direkten Vorgänger generiert wird, sondern aus der letzten Nachricht, deren Erhalt vom Empfänger bestätigt wurde. Bestätigt wird der Empfang in der Regel durch das Antworten mit einer ebenfalls verschlüsselten Nachricht. Eine Unterhaltung zwischen zwei Personen besteht aus einer gemeinsamen, aufeinander aufbauenden Abfolge von Nachrichten. Jedes Mal, wenn eine Antwort ankommt, wird diese Folge weitergeführt.
Solange keine Antwort kommt, teilt sich diese Folge in eine Unterfolge auf, die benutzt wird, bis die nächste Antwort ankommt. In der offiziellen Literatur werden diese Folgen von Nachrichten ratchets (englisch für Knarre oder Ratsche) genannt. Jede Nachricht dreht die Ratsche um einen Klick weiter, aber sie kann nicht zurückgedreht werden. Was bei realen Ratschen durch eine Mechanik erreicht wird, wird im Signal-Protokoll durch das Entsorgen von altem Schlüsselmaterial erreicht. Auf diese Weise kommt Forward Secrecy zustande. Wird Forward Secrecy verwendet, kann ein Angreifer eine mitgeschnittene Kommunikation auch dann nicht entschlüsseln, wenn das Schlüsselmaterial zu einem späteren Zeitpunkt kompromittiert wird. OMEMO bietet aber noch weitere Features.
Der Gesprächspartner muss nicht online sein
Ein weiter Fortschritt des Signal-Protokolls im Vergleich mit OTR ist, dass für den initialen Schlüsselaustausch die Gegenstelle nicht mehr zwangsläufig online sein muss. Erreicht wird das, indem der erste Schritt dieses Schlüsselaustausches in Form sogenannter Prekeys auf dem Server vorgehalten wird. Ein Client, der eine Signal-Protokoll-Sitzung starten möchte, muss infolgedessen die Gegenstelle nicht mehr explizit um Schlüsselmaterial bitten. Die Prekeys werden regelmäßig vom Client neu erzeugt und ausgetauscht.
Die Firma Openwhispersystems, die das Signal-Protokoll ursprünglich entwickelt hat, hat es erst vor kurzem so genannt. In diversen Dokumentationen ist noch die alte Bezeichnung zu lesen: Axolotl. Der Algorithmus, der beschreibt, wie genau die Nachrichtenschlüssel aus der Ratchet erzeugt werden und wie eine Ratchet aus den Prekeys erstellt wird, hieß ebenfalls Axolotl. Um Verwirrung zu vermeiden, wurde der Algorithmus in Double-Ratchet umbenannt und das Protokoll, das beschreibt, in welcher Form die Daten tatsächlich übertragen werden, ist das Signal-Protokoll. Der Algorithmus ist Public Domain und das Signal-Protokoll ist unter der GPLv3 lizenziert.
OMEMO ist noch kein offizieller Standard
OMEMO ist ein Entwurf für einen Standard, der aus dem Signal-Protokoll eine XMPP-Erweiterung macht und gleichzeitig die Möglichkeit schafft, Nachrichten an mehrere Geräte zu verschlüsseln. Dazu baut OMEMO Sitzungen mit allen beteiligten Geräten auf. Benutzen sowohl Sender als auch Empfänger zum Beispiel je einen Desktop und einen mobilen XMPP-Client, werden pro Gerät jeweils drei Signal-Sitzungen aufgebaut: eine mit dem jeweils anderen eigenen Gerät und zwei Sitzungen mit den Geräten des Gegenübers.
Diese Sitzungen werden nun benutzt, um pro Nachricht einen zufällig generierten Nachrichtenschlüssel zu übertragen. Die ursprüngliche Nachricht wird dann symmetrisch mit dem Verschlüsselungsmodus AES-GCM und diesem Schlüssel verschlüsselt. Eine OMEMO-Nachricht besteht somit aus n-Signal-Protokoll-Nachrichten sowie dem Payload, der den eigentlichen Inhalt enthält. Der Empfänger stellt fest, welche der Nachrichten für sein Gerät bestimmt ist und entschlüsselt sie, um in Besitz des Nachrichtenschlüssels zu gelangen, mit dem dann die eigentliche Nachricht entschlüsselt wird.
Die Prekeys werden in PEP abgelegt. PEP (XEP-0163(öffnet im neuen Fenster)) ist eine XMPP-Erweiterung, die es einem Benutzer ermöglicht, serverseitig eine Information abzulegen und diese seinen Kontakten automatisch zur Verfügung zu stellen. Benutzt wird dies zum Beispiel für die Veröffentlichung des Avatars. Aktualisiert ein Benutzer seinen Avatar, werden automatisch alle Kontakte darüber informiert. OMEMO benutzt das gleiche System. Jedes Gerät veröffentlicht seinen eigenen Satz von Prekeys. Kommt ein neues Gerät hinzu oder wird eines entfernt, werden automatisch alle Kontakte darüber in Kenntnis gesetzt und können bei Bedarf eine neue Signal-Sitzung mit dem neuen Gerät erstellen. Das bedeutet zwar etwas mehr Arbeit, weil die Geräte einzeln verifiziert werden müssen, hat aber Vorteile.
Geräte werden einzeln verifiziert
Da jedes Gerät eigenes Schlüsselmaterial hat, muss auch jedes Gerät einzeln verifiziert werden. Vor dem Schreiben der ersten Nachricht wird ein OMEMO-fähiger XMPP-Client dem Benutzer die Fingerprints von allen aktiven Geräten präsentieren und sie bestätigen lassen. Die Verifikation des Fingerprints geschieht out-of-Band, also zum Beispiel über die Webseite des Gegenübers, ein Telefonat oder ein persönliches Treffen. Dabei können einzelne Geräte auch gezielt ausgenommen werden.
Hat das Gegenüber zum Beispiel nur einen Fingerprint auf seiner Webseite angegeben, benutzt aber zwei Geräte, kann auch zunächst nur einem Gerät vertraut werden. Die Nachrichten werden dann nur an die schon verifizierten Geräte verschlüsselt geschickt. Den Geräten einzeln zu vertrauen, mag zwar auf den ersten Blick etwas umständlich klingen, hat aber Vorteile, wenn eines von mehreren Geräten kompromittiert wird. Statt das Vertrauen in dieser Situation komplett neu etablieren zu müssen, kann man das Vertrauen mittels eines anderen Geräts neu aufbauen.
Im Mai dieses Jahres wurden der Protokollentwurf und die Referenzimplementierung von der Security Consulting Firma Radically Open Security einem Audit(PDF(öffnet im neuen Fenster)) unterzogen. Dabei wurden keine kritischen Probleme gefunden.
Ebenfalls seit Mai 2016 gibt es parallel zu OMEMO auch erstmals einen offiziellen Standard für die Verwendung von OpenPGP in XMPP (XEP-0373(öffnet im neuen Fenster)). Auch Golem hat darüber schon berichtet, deshalb sei an dieser Stelle kurz auf die Unterschiede eingegangen.
Limitierungen durch Forward-Secrecy
Die Forward-Secrecy, die OMEMO mitbringt, verhindert ein wichtiges Einsatzszenario: Fügt der Benutzer ein neues Gerät hinzu, ist dieses nicht in der Lage, auf die Nachrichtenhistorie zuzugreifen. Oder mit anderen Worten ausgedrückt: Ein Gerät, das zum Zeitpunkt der Verschlüsselung noch nicht existiert hat, wird niemals in der Lage sein, die Nachricht zu entschlüsseln.
Des Weiteren kann jedes Gerät jede Nachricht nur genau einmal entschlüsseln. Danach wird das Schlüsselmaterial im Rahmen der Forward-Secrecy automatisch gelöscht. Das heißt allerdings, wenn ein Gerät die lokal verfügbaren Nachrichten, zum Beispiel aus Platzmangel, löscht, können diese nicht wiederhergestellt werden. Eine auf OpenPGP basierende Lösung ist von dieser Problematik nicht betroffen, erkauft sich diesen Vorteil allerdings mit dem Wegfall von Forward-Secrecy. Beide Ansätze haben folglich ihre Daseinsberechtigung und es bleibt dem Benutzer überlassen, anhand der konkreten Bedrohung den für ihn richtigen Kompromiss aus Komfort und Sicherheit zu wählen. Abschließend wollen wir demonstrieren, wie Nutzer OMEMO bereits heute nutzen können.
OMEMO in der Praxis ausprobieren: Howto
Bisher hat OMEMO noch keine offizielle XEP-Nummer erhalten, ist also ein Standardentwurf. Grund für die Verzögerung ist die Tatsache, dass die Referenzimplementierung auf dem Signal-Protokoll aufbaut, das unter der GNU General Public License (GPLv3) lizenziert ist. Wäre das beim offiziellen Standard genauso, wäre es unmöglich für proprietäre XMPP-Clients, OMEMO zu implementieren. Aus diesem Grund wird der Standardentwurf dahingehend angepasst, dass dieser eine freie Version des gleichen Double-Ratchet-Algorithmus verwendet. Ein möglicher Kandidat hierfür ist zum Beispiel Olm. Bei dieser Anpassung wird dann auch Feedback aus dem Audit berücksichtigt.
Für den Endanwender und Benutzer eines GPL-lizenzierten XMPP-Clients spielt es jedoch keine Rolle, ob der Standard bereits offiziell ist oder nicht. Immerhin wurden OTR und OpenPGP auch jeweils über zehn Jahre lang benutzt, ohne überhaupt einen Standard für XMPP zu haben.
Um OMEMO auszuprobieren, benötigt man zunächst einen XMPP-Account. Zahlreiche Organisationen stellen kostenlose XMPP-Server der Allgemeinheit zur Verfügung. Vor dem Anlegen lohnt sich ein Blick in den XMPP Compliance Tester(öffnet im neuen Fenster), da OMEMO auf die serverseitigen Erweiterungen Message Carbons (XEP-0280(öffnet im neuen Fenster)) und PEP aufbaut. Zudem verhindern Bugs in alten Versionen der Serversoftware die korrekte Funktion von OMEMO. Ein gutes Abschneiden im Compliance Tester ist ein guter Indikator für einen aktuellen Server.
Erstellt werden kann der Account auf den meisten Servern direkt aus dem Client heraus. Dazu ist lediglich ein Haken bei 'Neuen Account auf dem Server anlegen' zu setzen. Fertige OMEMO-Implementierungen gibt es aktuell im Desktopclient Gajim(öffnet im neuen Fenster) und dem Android-Client Conversations(öffnet im neuen Fenster). An einer Implementierung für den iOS-Client Chatsecure(öffnet im neuen Fenster) wird aktuell gearbeitet.
Gajim benötigt OMEMO-Plugin
Für Gajim ist das OMEMO-Plugin(öffnet im neuen Fenster) notwendig, das aus dem Programm heraus installiert werden kann. Außerdem empfiehlt es sich, das HTTP Upload Plugin und das Image Preview Plugin zu nutzen, um den Bildversand zwischen Conversations und Gajim zu ermöglichen.
Damit OMEMO als verfügbar angezeigt wird, müssen sich beide Kontakte gegenseitig in ihrer Kontaktliste haben. OMEMO für Gruppenchats wird in Conversations zurzeit noch als experimentell eingestuft und hat ein paar Voraussetzungen, die in den FAQ von Conversations(öffnet im neuen Fenster) erläutert werden. Für Gajim befindet sich die Unterstützung für Gruppenchats gerade in Arbeit.
Auch wenn noch nicht alle Arbeiten abgeschlossen sind, kann OMEMO bereits als leistungsfähige Alternative für verschlüsselte Chats über XMPP genutzt werden. Der größte Vorteil im Vergleich mit anderen Kryptomessengern: Nutzer können unter verschiedenen Clients auswählen und sind nicht auf einen einzelnen Hersteller angewiesen.
Hinweis: Der Autor dieses Artikels war an der Entwicklung von OMEMO maßgeblich beteiligt.
- Anzeige Hier geht es zu Hacking & Security: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.