Ist Telegram sicher?

Die Antwort lautet: Nein.

In erster Linie wurde Telegram von Mathematikern entworfen und nicht durch Kryptographen entwickelt, welche eine etwas “andere” Sicht auf die Dinge haben. Mathematiker haben etwas Hintergrundwissen im Bereich Verschlüsselung, aber von einer Spezialisierung kann man i.d.R. nicht sprechen. ¹

Darüber hinaus werden die Nachrichten über Server geroutet, welche auf der gesamten Welt verteilt sind. Die Authentication ist außerdem nur zwischen dem Server und Client gegeben und nicht Client-to-Client.  Eine Verschlüsselung über bspw. TLS wurde durch ein “hauseigenes” Protokoll ersetzt (!) und besitzt somit keinen Community Background. An dieser Stelle lässt sich anmerken, dann die Verschlüsselung zwar End-to-End stattfinden kann, jedoch ohne vorherige authentication. Somit lässt sich der Verkehr leicht (mit etwas Wissen) durch eine “Man in the Middle” Attack abfangen und ggf. manipulieren. ¹

Ein weiteres Problem ist die nicht vorhandene Verschlüsselung auf dem Server selbst, d.h. die NSA oder andere Einrichtungen können Nachrichten/ Medien direkt vom Betreiber anfordern. Genauso kritisch ist die Tatsache, dass der Server kompromittiert werden kann und der Angreifer somit Zugriff auf den gesamten Datenverkehr erlangen kann. Durch eine solche Sicherheitslücke lässt sich eine “Man in the Middle” Attack nicht erkennen oder gar vermeiden. ¹

Das genutzte Protokoll von Telegram teilt sich grundlegend in zwei Phasen auf: Der Schlüsseltausch und die eigentliche Kommunikation. ¹

Der Schlüsseltausch ist in erster Linie dazu du, um ein neues Smartphone am Server anzumelden. Dafür haben die Betreiber ein eigenes Protokoll geschrieben, um nicht TLS verwenden zu müssen, da es für diese Zwecke eher auf Grund der Geschwindigkeit ungeeignet ist. Telegram hat sich dafür entschieden den Tausch auf drei “Roundtrips” beruhen zu lassen: RSA > AES-IGE > Diffie-Hellmann. IV (Initialisierungsvektor, Konstante bzw. Hash Wert, der vor dem eigentlichen Datenpaket sitzt, um zu vermeiden, dass die gleichen Klartextblöcke die selben Geheimtextblöcke besitzen. ³ ) und Nonces (“a number used only once – eine Kombination, welche in diesem Kontext nur einmal verwendet wird ²) werden vom Server und vom Client generiert, wobei der vom Server generierte Nonce im Klartext übertragen wird.

Folgende Zeilen zeigen die Art, wie Telegram Key und IV generiert ⁴

• key = SHA1(new_nonce + server_nonce) + substr (SHA1(server_nonce + new_nonce), 0, 12);
• IV = substr (SHA1(server_nonce + new_nonce), 12, 8) + SHA1(new_nonce + new_nonce) + substr (new_nonce, 0, 4);

Anzumerken ist, dass AES-IGE nur die Intigrität sicherstellen soll und nicht als Verschlüsselung genutzt wird. Jede Änderung am Ciphertext (verschlüsselter Text) verändert also den Klartext. Wobei der AES Key und der IV vom Inhalt der Nachricht abhängen und somit eine Sicherheitslücke darstellen kann. Solche Keys müssen (!) immer unabhängig vom Inhalt erstellen werden. Ein weiterer Grund zu zweifeln ist die Generierung SHA1 Keys aus einer Mac Adresse – eine kleine, aber feine Tür für ein Backdoor. ⁵ 

Der Hash wird, wie man sieht, noch mal durch einen Plain-SHA1 gejagt.

Der daraus resultierende Diffie-Hellmann Tausch (symmetrische Verschlüsselung für Kommunikation über öffentliche Kanäle) erstellt einen Schlüssel, welcher als Klartext (!!) auf dem Client und Server gespeichert wird.

Kommen wir zu Phase 2: Die Kommunikation. Ein Server Salt, eine Nachrichten ID und eine Nachrichten Sequenz-Nummer werden hier verwendet, um erst mal Spam zu unterbinden. Darüber hinaus wird ein Nachrichten-Key verwendet, welcher aus den 128 Bits des SHA1 Hashes der Nachricht selber generiert wird. Der Nachrichten-Key wird unverschlüsselt übertragen und kann zusammen mit dem Header der Nachricht interessante Infos zaubern.¹

Das zuvor genannte AES-IGE wird an dieser Stelle zur eigentlichen Verschlüsselung der Nachricht verwendet:

The algorithm for computing aes_key and aes_iv from auth_key and msg_key is as follows:

• sha1_a = SHA1 (msg_key + substr (auth_key, x, 32));
• sha1_b = SHA1 (substr (auth_key, 32+x, 16) + msg_key + substr (auth_key, 48+x, 16));
• sha1_с = SHA1 (substr (auth_key, 64+x, 32) + msg_key);
• sha1_d = SHA1 (msg_key + substr (auth_key, 96+x, 32));
• aes_key = substr (sha1_a, 0, 8) + substr (sha1_b, 8, 12) + substr (sha1_c, 4, 12);
• aes_iv = substr (sha1_a, 8, 12) + substr (sha1_b, 0, 8) + substr (sha1_c, 16, 4) + substr (sha1_d, 0, 8);

 

x = 0 bildet hier die Kommunikation zwischen Client > Server und x = 8 zwischen Server > Client ab.

Auffällig ist, dass die Unterhaltungen innerhalb der App nicht automatisch verschlüsselt sind, sondern erst durch die Funktion “Secure Chat” aktiviert werden muss. An dieser Stelle frage ich mich: Warum?

Als Letztes lässt sich anmerken, dass Telegram das verwendete Protokoll veröffentlicht hat (https://core.telegram.org/mtproto) und somit nicht sicher gegen gezielte Angriffe ist. Die 1. Regel eines Kryptographen lautet: “don’t roll your own crypto!”

[usr 2] für diese App. Der Versuch war gut, aber die Umsetzung schlecht.

Quelle:

1: vgl. Unhandled expression: http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/. (25.02.2014)

2: vgl. Roger M. Needham, Michael D. Schroeder: Using encryption for authentication in large networks of computers. In: ACM (Hrsg.): Communications of the ACM. 21, Nr. 12, New York, NY, USA Dezember 1978

3: vgl. Viola, Gerald: Initialization vector | Initialisierungsvektor | IV. http://www.security-insider.de/glossar/IV/articles/181899/. (25.02.2014)

4: vgl. https://core.telegram.org/mtproto/auth_key

5: vgl. Laurie, Ben: OpenSSL’s Implementation of Infinite Garble Extension. http://www.links.org/files/openssl-ige.pdf. (25.02.2014)