zurück zur Übersicht

Einfach sichere Kommunikation mit OMEMO

OMEMO soll sichere Kommunikation z.B. über Instant-Messaging ermöglichenMotivation

Kommunikation über Sofortnachrichten ist als schnelle und unkomplizierte Alternative zu E-Mail & Co. nicht mehr aus dem geschäftlichen und privaten Alltag wegzudenken.

Häufige Anforderungen an sichere Sofortnachrichten-Kommunikation sind:

  • Ende-zu-Ende-Verschlüsselung (Vertraulichkeit)
  • Perfect Forward Secrecy
  • Authentizität der Nachrichten
  • Abstreitbarkeit
  • Offline-Funktion (asynchrone Kommunikation)
  • mehrere Geräte (synchronisierter Gesprächsverlauf und nahtloses Gerätewechseln in einer Unterhaltung)
  • Dateitransfer mit gleicher Absicherung

 

Die Basis: Off-the-Record- und Signal-Protokoll

Einige dieser häufig gewünschten Features kann das vergleichsweise etablierte Off-the-Record-Protokoll (OTR) erfüllen – zumindest sofern es nicht fehlerhaft implementiert ist. Allerdings werden die Offline-Funktion, die Unterstützung mehrerer Geräte und der Dateitransfer von OTR nur stark eingeschränkt bzw. nicht erfüllt.

OTR kann auf fast beliebige Nachrichten-Transporte aufsetzen (üblich sind oder waren beispielsweise IRC, ICQ oder XMPP). Ein beliebter Transport für OTR ist das „Extensible Messaging and Presence Protocol“ (XMPP; früherer Name „Jabber“). XMPP wird unter anderem – ähnlich wie bei E-Mail – in einem Netzwerk aus vielen unabhängigen XMPP-Servern (Föderation) eingesetzt. Wie bei E-Mail mittlerweile üblicherweise auch wird die Kommunikation zwischen den Servern per TLS gesichert. Die für XMPP namensgebenden  Erweiterungen werden als sogenanntes XMPP Extension Protocol (XEP) definiert.

Die Ideen von OTR wurden vom Signal-Protokoll deutlich weiterentwickelt: Die wichtigste Verbesserung ist die Ermöglichung von vollständig gesicherter Kommunikation auch mit Offline-Kontakten. Ein Sicherheitsaudit des Signal-Protokolls im Oktober 2014 findet zwar einen (leicht korrigierbaren) Unknown-Key-Share-Angriff auf das Protokoll, kommt aber insgesamt zu einem positivem Urteil. Ein erneutes Sicherheitsaudit des Signal-Protokolls im Oktober 2016 urteilte ebenfalls positiv.

OMEMO als konsequente Weiterentwicklung von OTR

Das im unföderierten System verwendete Signal-Protokoll wurde von Andreas Straub im Sommer 2015 während seines Google Summer-of-Code-Projekts für XMPP adaptiert und unter dem Namen „OMEMO Multi-End Message and Object Encryption“ (OMEMO) veröffentlicht. Es verwendet zum Ermöglichen des Schlüsselaustauschs (auch mit Offline-Kontakten) die XMPP-Erweiterung Personal Eventing Protocol (XEP-0163).

OMEMO-Entwurf 0.0.1, welcher auf dem Signal-Protokoll Version 3 basiert, wurde im Oktober 2015 bei der XMPP Standards Foundation zur Standardisierung eingereicht und in der XMPP -Android-App „Conversations“ implementiert. Der Hauptentwickler Daniel Gultsch war Andreas’  Projektmentor.

Als problematisch wurde von einigen Stellen auch gesehen, dass außer dem GPL-lizenzierten Quellcode keine öffentliche Protokollspezifikation von Signal existiert und somit jegliche weiteren Implementierungen, die auf diesem Quellcode basieren, ebenfalls der GPL unterliegen müssten. Sebastian Verschoor führte einen Audit von OMEMO-Entwurf 0.0.1 und Conversations durch und kam zu dem Schluss, dass eine sichere Kommunikation möglich ist, dass aber Fehler der Benutzer zu einer Kompromittierung der Kommunikation führen können.

Seit Ende Oktober 2016 liegt OMEMO-Entwurf 0.0.2 vor, welcher nun auf dem Olm-Protokoll Version 1 basiert. Die Spezifikation von Olm ist als Public Domain verfügbar und Olm basiert ebenfalls auf dem Double Ratchet Algorithm. Weiterhin wurden einige der Kleinigkeiten verbessert, die in dem Audit gefunden wurden. Die Federführung für den Standardisierungsentwurf wird möglicherweise auf Daniel Gultsch übergehen.

In der Zwischenzeit wurde im November 2016 dann die ehemals ersehnte Spezifikation des Signal-Protokolls veröffentlicht – als Public Domain. Wir dürfen auf die künftige Entwicklung rund um OMEMO gespannt sein.

Mögliche Problemstellen

  • Das Protokoll ist noch jung – daher:
    • Noch nicht ausgiebig begutachtet
    • Weitere Protokollentwurfsänderungen sind zu erwarten, dadurch eventuell Inkompatibilitäten
    • Noch kaum Unterstützung durch Clients
  • Inaktive Geräte können die Perfect Forward Secrecy gefährden, da hier kein Key-Refresh mehr durchgeführt wird. Hieran wird gearbeitet.
  • Feste Cipher (AES-128 in Galois/Counter Mode), dadurch kein einfaches Ausweichen bei Bekanntwerden einer Schwachstelle möglich
  • Zumindest in Version 0.0.1 mehrere weitere Kleinigkeiten (siehe Audit), die in bestimmter Konstellation zu einer unsicheren Kommunikation führen können.

Verfügbarkeit

Client-Software

Client-Software mit OMEMO-Unterstützung:

  • Conversations (Android). Standardmäßige Verwendung vorerst allerdings wieder deaktiviert – dies verdeutlicht die Herausforderungen für Client-Entwickler auch im User-Interface-Design.
  • ChatSecure (nur die iOS-Version) – aktuell nur in der Beta-Version, veröffentlicht voraussichtlich im nächstem Release (circa im Dezember 2016)
  • Gajim mittels experimentellem Plugin (Linux/Unix, Windows)

Client-Software, die OMEMO als internes Transportprotokoll verwendet:

Server

XMPP-Server müssen für OMEMO zwingend das Personal Eventing Protocol (XEP-0163) unterstützen. Dies tun die meisten Server. Zusätzlich sind insbesondere die XEPs Message Carbons (XEP-0280) und Message Archive Management (XEP-0313) zur Verwendung mit mehreren Geräten sinnvoll. Daniel Gultsch hat Liste von Servern nach Unterstützung bestimmter XEPs zusammengestellt. Generell sollte bei der Auswahl eines XMPP-Servers natürlich auch seine sonstige Sicherheitskonfiguration beachtet werden: XMPP-Server-Verzeichnis bzw. XMPP-Server-Sicherheitstest.

Weitere Artikel-Quellen

 


 

Bild: ©iT-CUBE SYSTEMS AG 2016

Schreibe einen Kommentar