Verschlüsselung: Validation von Threema ist wenig aussagekräftig

Der Messenger Threema verspricht sichere Verschlüsselung und bietet eine sogenannte "Validation", bei der ein Nutzer angeblich überprüfen kann, ob eine Nachricht korrekt verschlüsselt wurde. Doch die Validation sagt wenig über die Sicherheit des Systems.

Artikel veröffentlicht am 8. März 2014, 9:20 Uhr, Hanno Böck

Die Threema-Validation funktioniert zwar, sagt aber wenig aus. (Bild: Screenshot / Hanno Böck)

Threema profitiert zurzeit wie viele andere mobile Messenger von abwandernden Whatsapp-Nutzern. Der von einem Schweizer Unternehmen entwickelte Messenger wirbt mit Ende-zu-Ende-Verschlüsselung. Der größte Kritikpunkt an Threema ist der fehlende Quellcode: Das Programm steht Nutzern nur als Binärpaket zur Verfügung. Gerade bei Kryptographie ist aber für viele Fachleute die Verfügbarkeit des Quellcodes essentiell. Denn damit können Dritte am besten überprüfen, ob eine Verschlüsselung auch wirklich sicher ist. Als der Autor dieses Artikels vor kurzem in einem Kommentar Threema kritisierte, wurden wir von vielen Lesern darauf hingewiesen, dass Threema die Möglichkeit biete, die Verschlüsselung zu prüfen. Wir haben uns daher die Threema Encryption Validation näher angesehen.

Die Verschlüsselung von Threema

Threema nutzt für die Verschlüsselung die NaCl-Bibliothek. Hinter NaCl stehen die bekannten Kryptographen Daniel Bernstein und Tanja Lange. Das Ziel bei der Entwicklung von NaCl war explizit, eine Bibliothek zu schaffen, bei der man wenig falsch machen kann. Die Komplexität der kryptographischen Operationen ist weitgehend abstrahiert, so dass ein Programmierer mit wenigen Funktionsaufrufen eine Verschlüsselung realisieren kann.

NaCl genießt unter Kryptographen einen exzellenten Ruf, und an der Nutzung dieser Bibliothek ist wenig auszusetzen. Der Quellcode von NaCl ist Public Domain und kann von jedem geprüft und genutzt werden, egal ob in freier Software oder in proprietären Programmen wie Threema.

Die Validation von Threema

Threema ermöglicht es, verschlüsselte Nachrichten in einem Logfile auf dem Smartphone zu speichern. Diese können dann mit zwei kleinen Programmen überprüft werden, die die NaCl-Bibliothek verwenden und auf der Threema-Webseite im Quellcode heruntergeladen werden können. Hierzu ist der private Schlüssel des Anwenders nötig.

Wir konnten die Funktionsweise dieser Validation nachvollziehen. Das Programm ließ sich unter Linux problemlos kompilieren. Die Threema-Entwickler werben auf der Webseite zur Validation mit einem großen Versprechen: "Threema enthält ein 'Validation logging'-Feature, welches es jedem ermöglicht, unabhängig zu prüfen, dass die von Threema versendeten Nachrichten mit der NaCL-Bibliothek Ende-zu-Ende-verschlüsselt wurden."

Doch was sagt die Validation wirklich aus? Zunächst ist es für einen Nutzer nicht möglich zu prüfen, ob die Nachricht, die von Threema geloggt wird, auch wirklich der Nachricht entspricht, die online versendet wurde. Wir haben das getestet und den Datenverkehr von Threema beobachtet. Das Problem dabei: Threema verbindet sich per HTTPS mit einem API-Server unter api.threema.ch. Das ist im Grunde eine sinnvolle Maßnahme, um den Protokolldatenverkehr zusätzlich zu schützen, doch die Validation wird damit zur Makulatur.

Wir haben testweise versucht, den HTTPS-Datenstrom mit einer Man-in-the-Middle-Attacke und einem gefälschten Zertifikat mitzulesen; das hat aber erwartungsgemäß nicht funktioniert, da Threema offenbar das Zertifikat des API-Servers prüft. Auch das ist selbstverständlich sinnvoll, doch es unterbindet jeden Versuch, Einblick in den Datenverkehr zu bekommen.

Doch selbst wenn ein Nutzer darauf vertraut, dass eine verschlüsselte Nachricht, die im Logfile abgespeichert wird, auch der tatsächlich verschickten Nachricht entspricht: Die Aussagekraft ist gering. Dazu lohnt sich ein Blick auf eine von Threema geloggte Nachricht. Diese besteht aus einem Nonce und der eigentlichen, verschlüsselten Nachricht. Der Nonce ist ein Zufallswert, zumindest dann, wenn die Verschlüsselung korrekt arbeitet. Darauf muss der Anwender aber vertrauen. Will ein Programmautor eine böswillige Hintertür in eine Verschlüsselungssoftware einbauen, bietet sich der Nonce geradezu an. Man könnte dort etwa Informationen einbauen, die mit einem geheimen, im Programm integrierten Schlüssel verschlüsselt sind. Ein so verschlüsseltes Datenpaket sieht ohne Kenntnis des Geheimschlüssels nach Zufallszahlen aus, für den Nutzer scheint also alles in Ordnung zu sein.