Unter vier Augen

Sichere Kurznachrichten – mehr als verschlüsseln

Wissen | Know-how

PGP schön und gut, aber die damals für E-Mail entwickelte Verschlüsselung ist bereits etwas in die Jahre gekommen. Die Verschlüsselung von Chat, Instant Messaging und Kurznachrichten stellt Anforderungen, denen der Krypto-Klassiker nicht mehr gerecht wird.

Angesichts der allgegenwärtigen Überwachung aller Kommunikation durch Geheimdienste und Internet-Konzerne mit fragwürdigen Geschäftsmodellen wird es höchste Zeit, unsere Privatsphäre zurückzufordern. Das gilt auch und gerade beim Austausch von Chat-Nachrichten – etwa über eine sichere WhatsApp-Alternative. Die Anforderungen dafür sind eigentlich ganz einfach zusammenzufassen.

Intuitiv erwarte ich von einer solchen Kommunikation das Gleiche wie von einem Gespräch unter vier Augen: Ich will sicher sein, dass ich tatsächlich mit meiner Freundin rede und sich nicht jemand anders für sie ausgibt. Außerdem soll nur sie mitbekommen, was ich ihr schreibe; das geht niemand sonst etwas an. Wer nicht dabei war, soll auch nicht im Nachhinein durch irgendwelche Tricks herausfinden können, worüber wir gesprochen haben.

Bei einem vertraulichen Gespräch unter vier Augen abends beim Bier soll mein Arbeitskollege kein laufendes Aufnahmegerät auf den Tisch stellen, das dann womöglich objektiv bezeugt, dass ich mich abfällig über unseren Chef geäußert habe. Wenn er mein Vertrauen bricht und rumerzählt, was ich angeblich gesagt habe, soll wenigstens sein Wort gegen meines stehen. Genauso wenig will ich, dass jedes Wort, das ich in ein Chat-Fenster eintippe, automatisch den Status eines unterzeichneten Dokuments bekommt. Der Empfänger sollte gegenüber Dritten nicht beweisen können, was ich nur ihm anvertraut habe.

Kryptologen übersetzen dies in vier Anforderungen: Authentifizierung, Verschlüsselung, Forward Secrecy und Abstreitbarkeit. Die lassen sich im Prinzip alle vier mit bekannten Krypto-Bausteinen sehr verlässlich umsetzen. Erst das kürzlich veröffentlichte Protokoll TextSecure V2 macht das aber auf eine Art und Weise, die sich sinnvoll auf Kurznachrichten anwenden lässt.

Who is who

Doch zunächst zu PGP. Für die Authentifizierung ist die asymmetrische Verschlüsselung mit dem RSA-Verfahren zuständig. Dabei hat jeder Benutzer ein zusammengehöriges Schlüsselpaar aus einem öffentlichen und einem geheimen Schlüssel, die unterschiedliche Funktionen haben – sie arbeiten asymmetrisch. Wenn ich etwas mit meinem geheimen Schlüssel signiere, kann jeder mit meinem öffentlichen Schlüssel überprüfen, dass es tatsächlich von mir stammt. Das kennt man als digitale Signatur. Mit ihr kann der Empfänger einer Nachricht deren Echtheit überprüfen.

Mit RSA kann man aber nicht nur die Echtheit einer Nachricht überprüfen, sondern diese auch verschlüsseln. Das funktioniert mit dem gleichen zusammengehörigen Schlüsselpaar, nur anders herum: Verschlüsselt jemand etwas mit meinem öffentlichen Schlüssel, kann es nur mein geheimer Schlüssel wieder dechiffrieren. Da diese asymmetrische Verschlüsselung sehr aufwendig ist, benutzt man sie nur für den gesicherten Austausch eines Sitzungsschlüssels. Die eigentliche Nachricht wird dann mit diesem Schlüssel mit AES chiffriert. Das arbeitet symmetrisch; Ver- und Entschlüsseln passiert also mit demselben Schlüssel.

Konkret läuft das so ab: Die Absenderin Alice erzeugt einen zufälligen AES-Sitzungsschlüssel. Diesen verschlüsselt sie mit dem öffentlichen Schlüssel von Bob und stellt ihn an den Anfang der Nachricht, die sie Bob schicken will. Nur Bob kann den AES-Schlüssel dechiffrieren und damit dann die damit verschlüsselte, eigentliche Botschaft dekodieren. Anhand der gültigen digitalen Unterschrift kann Bob feststellen, dass die Nachricht tatsächlich von Alice stammt. Genau so arbeitet PGP.

Allerdings bringt diese Methode gleich zwei Probleme mit sich. Erstens hat jede einzelne PGP-Mail von Alice an Bob, die ihre Unterschrift trägt, den Status eines digitalen Dokuments, dessen Echtheit nicht nur Bob überprüfen kann, sondern jeder. Bob kann seinem Chef damit jederzeit beweisen, dass Alice abfällige Bemerkungen über ihn gemacht hat. Der muss sich dabei nicht auf Bobs Wort verlassen, sondern kann selbst die digitale Unterschrift von Alice unter der Mail überprüfen. Es fehlt die Abstreitbarkeit eines Vier-Augen-Gesprächs.

Zweitens kann jemand, der eine von Alice verschlüsselt an Bob gesendete Nachricht aufgezeichnet hat und irgendwann später an Bobs geheimen Schlüssel kommt, nachträglich diese und alle anderen Nachrichten an Bob entschlüsseln. Forward Secrecy hätte das verhindert; aber PGP bietet die leider nicht.

Off The Record

Das im Umfeld von Instant-Messaging-Chats vor allem mit Jabber beliebte Protokoll Off The Record (OTR) räumt damit auf. Analog zu PGP bestätigen sich Alice und Bob beim Gesprächsaufbau gegenseitig ihre Identität mit dem jeweils nur ihnen bekannten geheimen Schlüssel (OTR verwendet dazu DSA statt RSA).

Hier wird der AES-Sitzungsschlüssel für den Chat mit dem Diffie-Hellman-Verfahren ausgehandelt. Dabei schicken Alice und Bob jeweils eine Nachricht, woraufhin sie ein gemeinsames Geheimnis berechnen können. Die Mathematik hinter dem Verfahren stellt sicher, dass jemand, der die Nachrichten sieht, damit nichts anfangen kann – insbesondere kann er das Geheimnis nicht errechnen.

Der Clou: Alice und Bob haben danach einen gemeinsamen, geheimen Schlüssel, der nie „über die Leitung“ gegangen ist – auch nicht verschlüsselt. Wenn die beiden nach der Chat-Sitzung ihre Kopien vernichten, gibt es keine Möglichkeit mehr, die Nachrichten zu dekodieren – OTR bietet also Forward Secrecy.

Statt digitaler Signaturen unter jeder Nachricht kommen sogenannte Message Authentication Codes (MACs) zum Einsatz, die deren Echtheit bestätigen. Das funktioniert so: Alice errechnet aus dem Text der Nachricht und einem aus dem Sitzungsschlüssel abgeleiteten Geheimnis einen Hashwert und verschickt diesen mit der Nachricht zusammen. Bob berechnet ebenfalls den MAC und vergleicht ihn mit dem Wert unter der empfangenen Nachricht. Stimmen sie überein, ist die Nachricht unverändert und von Alice. Jede Manipulation am Text führt zu einem anderen Hash-Wert.

Eine Angreiferin kann auch keinen neuen, gültigen MAC errechnen, da ihr das dazu benötigte Geheimnis fehlt. Zu beachten ist, dass die eingesetzte Verschlüsselung keine eigene Integritätssicherung oder Authentifizierung enthalten darf – sonst wäre die Abstreitbarkeit wieder beim Teufel. OTR erreicht das, indem es AES als Stream Cipher im Counter Mode (CTR) einsetzt.

Bob kann jetzt zwar immer noch mit seiner aufgezeichneten Kommunikation zum Chef petzen gehen. Beweisen kann er aber nur, dass er mit Alice gesprochen hat, aber nicht, was diese ihm gesagt hat. Denn jeder, der das MAC-Geheimnis kennt, hätte auch die Nachricht mit korrektem MAC erstellen können. Und das hätte genauso gut Bob machen können. Letztlich steht Bobs Wort gegen das von Alice – OTR bietet den Kommunikationspartnern Abstreitbarkeit.

Offline-Chat

OTR wurde für Online-Chats konzipiert und funktioniert problemlos, wenn beide Gesprächspartner online sind und sich entscheiden, ab jetzt lieber verschlüsselt zu kommunizieren. Der notwendige OTR-Verbindungsaufbau mit dem Austausch der DH-Nachrichten fällt da nicht weiter ins Gewicht.

Kurznachrichten funktionieren jedoch anders. Da schalte ich mein Handy ein, tippe eine Nachricht und schicke sie ab, ohne mich darum zu kümmern, ob der Empfänger gerade online ist. Wenn nicht, soll er sie einfach bekommen, sobald er wieder Netz hat. Die eine Nachricht muss also alles enthalten, was der Empfänger – beziehungsweise dessen Messenger-App – braucht, um sie zu entschlüsseln und dabei auch die Echtheit zu prüfen. Die Abstreitbarkeit durch den Einsatz von MACs statt digitaler Signaturen könnte man noch recht einfach in solch ein asynchrones Protokoll einbauen.

Probleme bereitet jedoch die Forward Secrecy. Zum Schlüsselaustausch mit dem Diffie-Helman-Verfahren müssen Sender und Empfänger zunächst DH-Nachrichten austauschen, bevor Alice den verschlüsselten Text auf den Weg schicken kann. Ist Bob gerade nicht online, muss Alice also warten. Wenn Bob endlich mit seinem DH-Token antwortet, ist womöglich Alice gerade nicht online – kurz: Das Ganze hakt gewaltig.

TextSecure

Um diese Defizite in den Griff zu bekommen, hat der Krypto-Experte Moxie Marlinspike das OTR-Konzept weiterentwickelt. Ausgangspunkt für sein Protokoll TextSecure V2 ist die Tatsache, dass die ausgetauschten Diffie-Hellman-Tokens nicht geheim sind. Diffie-Hellman ist so konstruiert, dass ein Lauscher, der die Tokens mitliest, daraus nicht den Schlüssel errechnen kann. Wenn die Tokens nicht geheim sind, kann man sie genauso gut auch veröffentlichen.

Die App TextSecure erzeugt also beim ersten Start gleich einen ganzen Satz dieser DH-Tokens, signiert sie mit dem geheimen Schlüssel des Anwenders und lädt sie auf den zentralen TextSecure-Server. Wer also Bob eine Nachricht schicken will, holt sich dort eines seiner DH-Tokens ab, erzeugt selber eines und schickt es zusammen mit seiner AES-verschlüsselten Nachricht an Bob. Der hat damit alles beisammen, um via Diffie-Hellman den AES-Sitzungsschlüssel zu errechnen, mit dem er die Nachricht auspacken kann.

Letztlich kann also Alice damit jederzeit eine verschlüsselte Nachricht an Bob schicken, ganz egal, ob der grade online ist oder nicht. Der kann diese Nachricht direkt öffnen, lesen und weiß dabei, dass sie von Alice stammt. Deren Inhalt ist während der Übertragung jedoch so verschlüsselt, dass nur Bob ihn lesen kann. Alice kann Dritten gegenüber jederzeit abstreiten, dass sie geschrieben hat, was Bob da als ihr Werk ausgibt; genauso gut könnte Bob deren Urheber sein – oder jeder andere, der die Nachricht entschlüsseln konnte. Haben Alice und Bob die Nachricht einschließlich des direkt damit verbundenen Schlüsselmaterials gelöscht, friert eher die Hölle zu, als dass jemand aus den mitgeschnittenen, verschlüsselten Aufzeichnungen den Inhalt der Nachricht rekonstruieren könnte. So muss es sein.

Meta-Daten

Eigentlich wäre auch wünschenswert, dass auch niemand anders mitbekommt, wenn jemand einen solchen Vier-Augen-Chat führt. Doch das ist leider mit den aktuell verfügbaren Systemen nicht möglich. Der Betreiber eines Dienstes sieht auf seinem zentralen Server immer, wer wann mit wem spricht, schließlich fungiert der ja als Vermittler. Das ließe sich nur mit einer echten Peer-to-Peer-Infrastruktur verhindern, die es derzeit nicht gibt. Immerhin verhindert die zusätzlich via SSL/TLS verschlüsselte Verbindung zum Server des Dienstbetreibers, dass jeder Lauscher im Internet diese Information auf dem Silbertablett serviert bekommt. Dagegen, dass er sich die Verbindungsdaten gezielt vom Server-Betreiber holt, ist derzeit leider kein Kraut gewachsen. (ju)

Artikel kostenlos herunterladen

Kommentare

Anzeige