Off-the-Record Messaging (OTR, deutsch inoffizielle, vertrauliche, nicht für die Öffentlichkeit bestimmte Nachrichtenübermittlung) ist ein Protokoll zur Nachrichtenverschlüsselung beim Instant Messaging. Es regelt die laufende Aktualisierung und Verwaltung kurzlebiger Sitzungsschlüssel.
Im Gegensatz zur Übertragung verschlüsselter Nachrichten mit OpenPGP (oder in seltenen Fällen auch mittels X.509-Zertifikat) kann man beim Off-the-Record Messaging später nicht mehr feststellen, ob ein bestimmter Schlüssel von einer bestimmten Person genutzt wurde (Prinzip der glaubhaften Abstreitbarkeit, englisch plausible deniability). Dadurch lässt sich nach Beenden der Unterhaltung von niemandem (auch keinem der beiden Kommunikationspartner) beweisen, dass einer der Kommunikationspartner eine bestimmte Aussage gemacht hat.
Umgesetzt wird dieses Prinzip durch kombinierte Verwendung des symmetrischen Kryptoverfahrens Advanced Encryption Standard (AES), des Diffie-Hellman-Schlüsselaustauschs und der kryptographischen Hashfunktion SHA-1. Es stehen eine Programmbibliothek und zahlreiche Instant-Messaging-Programme zur Verfügung, welche das Protokoll entweder direkt oder über Zusatzmodule nutzen können.
Ziele des Projektes Bearbeiten
In den Statuten des Projektes sind die folgenden vier Eckpfeiler definiert:
Technische Umsetzung Bearbeiten
Der folgende Abschnitt stellt vereinfacht die Funktion des OTR-Protokolls in Version 2 dar.
Überblick Bearbeiten
Während ihrer Kommunikation miteinander wählen Alice und Bob private Schlüssel beziehungsweise . Jeweils zwei, zum Beispiel und , werden zur Erzeugung eines gemeinsamen Geheimnisses mittels des Diffie-Hellman-Schlüsselaustauschs verwendet. Aus diesem Geheimnis werden die Schlüssel und berechnet.
dient zur Verschlüsselung jeder Nachricht mittels Advanced Encryption Standard (AES) im Counter Mode. Dadurch wird die symmetrische Blockchiffre AES zur Stromchiffre. Zur anfänglichen Authentifizierung verwenden Alice und Bob digitale Signaturen, wodurch sie sich während der Unterhaltung sicher sein können, mit wem sie kommunizieren. dient zur Authentifizierung einer einzelnen Nachricht mittels der Streuwertfunktion SHA-1 (Secure Hash Algorithm 1), die als Message Authentication Code (MAC) verwendet wird.
Beim Senden von Nachrichten werden neue private Schlüssel beziehungsweise und die dazugehörigen AES- und MAC-Schlüssel erzeugt. Die nicht mehr verwendeten privaten Schlüssel werden gelöscht, damit Alice nicht mehr mit ihren Nachrichten in Verbindung gebracht werden kann. Dies führt aber auch dazu, dass Alice nachträglich weder ihre eigenen noch die Nachrichten von Bob lesen kann. Zudem werden nicht mehr verwendete MAC-Schlüssel veröffentlicht, so dass jede andere Person die Nachrichten von Alice hätte signieren können.
Für den Diffie-Hellman-Schlüsselaustausch werden eine 1536-Bit-Primzahl und eine Primitivwurzel modulo mit benötigt. Alle Exponentiationen erfolgen dann modulo dieser Primzahl.
Initialisierung Bearbeiten
Zu Beginn eines Gesprächs müssen initiale Schlüssel ausgetauscht werden und die Authentizität der Gesprächsteilnehmer überprüft werden, das heißt Alice und Bob müssen sich jeweils sicher sein, mit wem sie kommunizieren. Dies verhindert, dass Alice beispielsweise anstatt mit Bob mit der Angreiferin Eve einen Schlüsselaustausch durchführt. Der ganze Vorgang wird Authenticated Key Exchange (AKE) genannt und mit dem SIGMA-Protokoll umgesetzt:
- Alice und Bob wählen private Schlüssel respektive (min. 320 Bit lang), tauschen die dazugehörigen öffentlichen Schlüssel beziehungsweise aus und erhalten durch das Diffie-Hellman-Verfahren ein gemeinsames Geheimnis .
- Mittels kann nun ein sicherer Kanal geschaffen werden, über den sich jeder Kommunikationsteilnehmer mit Hilfe einer digitalen Signatur gegenüber dem anderen authentifiziert. Derzeit unterstützt OTR nur den Digital Signature Algorithm.
Zwischendurch wird die Verbindung möglichst immer mit AES verschlüsselt und einzelne Nachrichten mittels SHA-256-HMAC authentifiziert.
Senden einer Nachricht Bearbeiten
Angenommen, Alice möchte an Bob die Nachricht schicken. Sie führt dabei folgende Schritte aus:
- Alice wählt ihren letzten von Bob empfangenen Diffie-Hellman-Schlüssel . Dabei gilt der Schlüssel von Bob als empfangen, wenn dieser für eine Nachricht verwendet hat, die Alice empfangen hat oder zuvor mittels AKE (siehe Abschnitt zuvor) ausgetauscht wurde, was offensichtlich nur im Fall sein kann.
- Falls Alices neuester Diffie-Hellman-Schlüssel ist, erzeugt sie zufällig einen neuen Schlüssel von mindestens 320 Bit Länge.
- Sei der letzte empfangene Diffie-Hellman-Schlüssel von Bob. Als empfangen gilt hier der Schlüssel wieder, wenn Bob diesen der letzten Nachricht beigefügt hat (siehe weiter unten) oder er mittels AKE ausgetauscht wurde.
- Das gemeinsame Diffie-Hellman-Geheimnis kann nun (modulo ) als berechnet werden.
- Berechne den AES-Schlüssel , wobei die ersten 128 Bit des SHA-1-Hashwerts von bezeichnet. wurde zuvor in ein bestimmtes Datenformat gebracht und um ein Byte erweitert.
- Berechne den MAC-Schlüssel als den 160-Bit-SHA-1-Hashwert von .
- Für den später verwendeten Counter Mode wird ein Zähler benötigt, der so gewählt wird, dass das Tripel während des gesamten Nachrichtenaustauschs mit Bob nie doppelt vorkommt.
- Die Nachricht wird nun mithilfe des AES-Algorithmus im Counter Mode verschlüsselt. Als Schlüssel dienen dazu und der eben gewählte Zähler . Die so verschlüsselte Nachricht heiße .
- Die verschlüsselte Nachricht , , und einige kryptographisch unwichtige Teile wie die Versionsnummer des Protokolls werden zu zusammengefasst und davon der Message Authentication Code unter Verwendung des Schlüssels berechnet. Hierbei bezeichne den Keyed-Hash Message Authentication Code (HMAC) unter Verwendung der Hashfunktion SHA-1 und des Schlüssels .
- und alle nicht mehr verwendeten MAC-Schlüssel werden an Bob über einen unsicheren Kanal geschickt.
Empfangen einer Nachricht Bearbeiten
Bob empfängt die weiter oben erzeugten Daten von Alice und führt folgende Schritte durch:
- Bob hat entweder bereits durch eine alte Nachricht von Alice oder per AKE erhalten. Dadurch kann er dasselbe Diffie-Hellman-Geheimnis durch berechnen, wobei und die in enthaltenen Indizes bezeichnen.
- Ebenso kann er wie Alice und berechnen.
- Mithilfe von berechnet er und vergleicht den erhaltenen Wert mit dem von Alice übermittelten. Dadurch ist die Authentizität der Nachricht geprüft und gegen einen Mittelsmannangriff geschützt.
- Mithilfe von und , welches in dem durch Alice versandten enthalten ist, entschlüsselt er die Nachricht mit dem AES-Algorithmus in Counter Mode und erhält zurück. Dies funktioniert, da AES symmetrisch ist, also zum Ver- und Entschlüsseln denselben Schlüssel verwendet.
Überprüfung der Ziele Bearbeiten
Ein weiteres Sicherheitskonzept ist die Fälschbarkeit. Durch die zur Verschlüsselung verwendete Stromchiffre (AES im Counter Mode), bei der der Klartext einfach mit einem XOR verknüpft wird, um den Geheimtext zu erhalten, kann bei erfolgreichem Erraten eines Teils des Klartexts der Angreifer den Geheimtext so modifizieren, dass dieser Teil sich zu einem beliebigen Text entschlüsselt. Dies verringert nicht die Sicherheit, da Bob sich durch das Signieren der Nachricht mit dem MAC-Schlüssel sicher sein kann, dass die verfälschte Nachricht nicht von Alice stammt. Im Nachhinein kann aber der Angreifer diese Nachricht signieren, da der zugehörige MAC-Schlüssel veröffentlicht wurde. So wird erschwert, dass Alice durch den Inhalt einer Nachricht mit ihr in Verbindung gebracht werden kann, da nachträglich die Nachricht für jeden signierbar und beschränkt modifizierbar ist.
Kryptoanalyse Bearbeiten
Eine computergestützte Kryptoanalyse des Protokolls in der Version 2 wurde von der Stanford University durchgeführt, wobei mehrere Schwachstellen entdeckt wurden: Durch einen Mittelsmannangriff ist es möglich, auf eine ältere Version des Protokolls (zum Beispiel Version 1) zu wechseln, um so deren Schwachstellen auszunutzen. Weiterhin ist die Abstreitbarkeit im starken Sinne, das heißt, dass jeder eine Nachricht hätte signieren können, bei einem Angreifer mit vollständiger Kontrolle über das Netzwerk nicht mehr gegeben. Dieser kann die veröffentlichten MAC-Schlüssel durch zufällige Daten ersetzen, wodurch es anderen nicht mehr möglich ist, mit diesen Schlüsseln Nachrichten gültig zu signieren. Zudem haben die Autoren einen Angriff bei der Authentifizierung im AKE gefunden, der jedoch entdeckt werden kann und keine weitreichenden Folgen nach sich zieht.
Verfügbarkeit Bearbeiten
Referenzimplementierung Bearbeiten
| libotr | |
|---|---|
| Basisdaten
| |
| Entwickler | Das OTR-Team |
| Aktuelle Version | 4.1.1 (9. März 2016) |
| Betriebssystem | Windows, Linux, xBSD, macOS |
| Programmiersprache | Java (java-otr) bzw. C (libotr) |
| Kategorie | Verschlüsselung |
| Lizenz | LGPL/GPL (Freie Software) |
| deutschsprachig | ja |
| otr.cypherpunks.ca |
Als Referenzimplementierung des Protokolls steht von den beiden Entwicklern, Ian Goldberg und Nikita Borisov, eine Programmbibliothek namens libotr zur Verfügung. Sie ist als freie Software auch im Quelltext veröffentlicht und unter den Bedingungen der GNU Lesser General Public License (LGPL) lizenziert. Mit der Bibliothek wird ein Toolkit zum Fälschen von Nachrichten geliefert. Die Entwickler stellen auch ein Plugin für Pidgin zur Verfügung. Letztere unterstehen beide den Bedingungen der GNU General Public License (GPL).
Native Unterstützung Bearbeiten
Die folgenden Clients unterstützen Off-the-Record Messaging nativ. Das schließt ein, dass man mit ihnen OTR mit allen implementierten Instant-Messaging-Protokollen verwenden kann (zum Beispiel OSCAR, XMPP, MSN und YIM). Eine weitere Liste mit Programmen findet sich auf der Website der Entwickler.
Fester Bestandteil Bearbeiten
- Adium (macOS)
- BitlBee (plattformunabhängig), ab Version 3.0 (optional einstellbar zur Kompilierzeit)
- ChatSecure (iOS)
- climm (Linux/Unix) unterstützt es direkt seit 0.5.4
- IM+ (Android/iOS)
- Jitsi (früher SIP Communicator) (plattformunabhängig)
- LoquiIM (Firefox OS)
- MCabber (Linux, mehrere BSD-Derivate, OS X) unterstützt OTR direkt seit 0.9.4
- Phonix Viewer (plattformunabhängig), ein Betrachter für das Spiel Second Life, unterstützt OTR-Diskussionen innerhalb des Spiels
- qutIM (plattformunabhängig) seit 0.3.1
- Rocket.Chat (plattformunabhängig)
- SecuXabber (Android) unterstützt OTR nativ (Beta)
- Spark (plattformunabhängig)
- Xabber (Android) unterstützt OTR nativ seit 0.9.27 (nur XMPP)
Plugin Bearbeiten
- Gajim (plattformunabhängig) hat ab Version 0.15 ein Plugin
- Irssi (plattformunabhängig) hat ein Plugin
- Kopete (Linux/Unix) hat ein (ab Version 0.50.80/KDE 4.1 offizielles) Plugin
- Miranda IM (Windows) hat ein Plugin
- Miranda NG (Windows) hat ein Plugin
- Mozilla Thunderbird ab Version 68 mit der OTR Bibliothek
- Pidgin (plattformunabhängig) hat ein offizielles Plugin
- Psi (plattformunabhängig) hat ein inoffizielles Plugin, in Psi+ kann dieses (unter Linux) nativ verwendet werden
- Vacuum IM (Linux/Windows)
- WeeChat (plattformunabhängig) hat ein Plugin
- XChat (plattformunabhängig) hat ein Plugin
Proxy Bearbeiten
Zunächst wurde auch ein Proxy entwickelt, der die Nutzung mit dem OSCAR-Protokoll (AIM/ICQ) ermöglichen sollte, auch wenn der Chatclient selbst OTR nicht unterstützt. Die Software wird seit 2005 nicht mehr weiterentwickelt und der Hersteller rät von der Benutzung ab.
Geschichte Bearbeiten
OTR wurde von Nikita Borisov, Ian Avrum Goldberg und Eric A. Brewer 2004 beim „Workshop on Privacy in the Electronic Society“ (WPES) als Verbesserung gegenüber dem OpenPGP- und dem S/MIME-System vorgestellt. Am 21. November 2004 wurde die erste Version 0.8.0 der Referenzimplementierung veröffentlicht. 2005 wurde von Mario Di Raimondo, Rosario Gennaro und Hugo Krawczyk eine Analyse vorgestellt, die auf mehrere Schwachstellen aufmerksam machte und Korrekturen dazu vorschlug, darunter insbesondere eine Sicherheitslücke beim Schlüsselaustausch. Daraufhin wurde 2005 Version 2 des OTR-Protokolls veröffentlicht, die eine Variation der vorgeschlagenen Modifikation umsetzt, die zusätzlich die öffentlichen Schlüssel verbirgt. Zusätzlich wurde für Chatsysteme mit begrenzter Nachrichtengröße die Möglichkeit zur Fragmentierung von OTR-Nachrichten eingeführt und eine einfachere Überprüfungsmöglichkeit gegen Mittelsmannangriffe ohne den Abgleich von Schlüsselprüfsummen implementiert. Dabei kann über das Sozialistische-Millionäre-Protokoll das Wissen um ein beliebiges gemeinsames Geheimnis genutzt werden, bei welchem auch eine relativ niedrige Entropie tolerierbar ist. 2012 wurde Version 3 des Protokolls veröffentlicht. Als Maßnahme gegen fortwährenden Neuaufbau einer Sitzung mit mehreren konkurrierenden Chat-Clients, die gleichzeitig auf dieselbe Benutzeradresse angemeldet sind, wurde in Version 3 eine genauere Kennung der Sender- und Empfänger-Client-Instanz eingeführt. Außerdem wird ein zusätzlicher Schlüssel ausgehandelt, der für einen weiteren Datenkanal genutzt werden kann.
Zur Unterstützung mehrerer Gesprächsteilnehmer wurden mehrere Systeme vorgeschlagen. Ein 2007 von Jiang Bian, Remzi Seker und Umit Topaloglu vorgeschlagenes Verfahren nutzte das System eines Teilnehmers als „virtuellen Server“. Das 2009 veröffentlichte Verfahren „Multi-party Off-the-Record Messaging“ (mpOTR) kam ohne zentrale Organisationsinstanz aus und wurde von Ian Goldberg et al. in Cryptocat eingeführt. 2013 wurde in TextSecure das Axolotl-Protokoll eingeführt, das auf OTR Messaging und dem Silent Circle Instant Messaging Protocol (SCIMP) basiert. Es brachte als zentrales Zusatzmerkmal die Unterstützung asynchroner Kommunikation („Offline-Nachrichten“), sowie außerdem bessere Resilienz bei gestörter Nachrichtenreihenfolge und simplere Unterstützung mehrerer Gesprächsteilnehmer. Das 2015 in Conversations eingeführte OMEMO integriert Axolotl in das Instant-Messaging-Protokoll XMPP („Jabber“) und ermöglicht nunmehr auch Dateiübertragungen abzusichern. Es wurde im Herbst 2015 bei der XMPP Standards Foundation zur Standardisierung eingereicht.
Socialist-Millionaires'-Protokoll Bearbeiten
Das Socialist-Millionaires'-Protokoll (SMP) ermöglicht, den sonst out of band stattfindenden Vergleich der Fingerprints der öffentlichen Schlüssel durch ein shared Secret zu ersetzen.
Weitere Einsatzbereiche Bearbeiten
- Apple iCloud-Schlüsselbund benutzt das OTR-Protokoll zur Datenübertragung von User-ID und Passwörtern von Apple-Gerät zu Apple-Gerät.
Weblinks Bearbeiten
- Projektseite (englisch)
- Off-the-Record Communication, or, Why Not To Use PGP (PDF; 132 kB) – erste Veröffentlichung des OTR-Protokolls von Nikita Borisov, Ian Goldberg und Eric Brewer (englisch)
- Off-the-Record Messaging Protocol version 2 (englisch)
- – Joseph Bonneau, Andrew Morrison: Finite-State Security Analysis of OTR Version 2 (PDF; 105 kB) Stanford University (englisch)
- Off-the-Record Messaging: Useful Security and Privacy for IM – Video von Ian Goldberg, einem der Entwickler (englisch, verschiedene Formate stehen zur Auswahl)
- T. Engel: Sichere Nachrichtenübermittelung mit Off-the-Record Messaging (PDF; 860 kB) – Diplomarbeit von an der Technischen Fachhochschule Berlin
Einzelnachweise Bearbeiten
- ↑ Off-the-Record Messaging Protocol version 2 (englisch)
- Joseph Bonneau, Andrew Morrison: Finite-State Security Analysis of OTR Version 2. (PDF (105 kB)) Stanford University, abgerufen am 13. Juli 2011 (englisch).
- ChatSecure-Website
- IM+ bei Google Play
- github.com
- mcabber-Changelog, siehe Abschnitt „mcabber (0.9.4)“ (englisch)
- Phonix Viewer, OSS
- qutIM 0.3.1 Changelog auf Facebook
- Rocket.Chat Channel Actions, englisch
- SecuXabber im Google Play Store (englisch)
- Spark Changelog
- Xabber im Google Play Store, englisch
- Gajim OTR, englisch
- Irssi OTR, englisch
- (Memento vom 1. März 2012 im Internet Archive), englisch
- MirOTR, Miranda NG Wiki
- thunderbird.net
- Thunderbird:OTR – MozillaWiki. 22. Mai 2019, abgerufen am 20. Juli 2019.
- Pidgin OTR Plugin, englisch
- (Memento vom 26. März 2009 im Internet Archive), englisch
- Website der Psi-Entwicklerversion Psi+, englisch
- Plugin-Sammlung für Vacuum IM
- weechat-otr, englisch
- (Memento des vom 27. Februar 2016 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis., englisch
- Nikita Borisov, Ian Avrum Goldberg, Eric A. Brewer: Off-the-record communication, or, why not to use PGP. In: Association for Computing Machinery (Hrsg.): WPES ’04: Proceedings of the 2004 ACM workshop on Privacy in the electronic society. ACM Press, New York Oktober 2004, S. 77–84 (cypherpunks.ca [PDF]).
- Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk: Secure off-the-record messaging. In: Association for Computing Machinery (Hrsg.): Proceedings of the 2005 ACM workshop on Privacy in the electronic society. 2005, S. 81–89 (unict.it [PDF]).
- Jiang Bian, Remzi Seker, Umit Topaloglu: Off-the-Record Instant Messaging for Group Conversation. In: IEEE (Hrsg.): IEEE International Conference on Information Reuse and Integration. 2007 ( [PDF; 117 kB; abgerufen am 1. September 2021]).
- Chris Alexander, Ian Avrum Goldberg: Improved User Authentication in Off-The-Record Messaging. In: Association for Computing Machinery (Hrsg.): Proceedings of the 2007 ACM workshop on Privacy in electronic society. New York Oktober 2007, S. 41–47, doi:10.1145/1314333.1314340 (cypherpunks.ca [PDF]).
- otr.cypherpunks.ca
- Ian Avrum Goldberg, Berkant Ustaoğlu, Matthew D. Van Gundy, Hao Chen: Multi-party off-the-record messaging. In: Association for Computing Machinery (Hrsg.): Proceedings of the 16th ACM Computer and Communications Security Conference. 2009, S. 358–368, doi:10.1145/1653662.1653705 (cypherpunks.ca [PDF]).
- Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fahl, Henning Perl, Ian Avrum Goldberg, Matthew Smith: SoK: Secure Messaging. In: IEEE Computer Society’s Technical Committee on Security and Privacy (Hrsg.): Proceedings of the 2015 IEEE Symposium on Security and Privacy. 2015, S. 232–249 (ieee-security.org [PDF]).
- Andreas Straub: (Nicht mehr online verfügbar.) In: Website der XMPP Standards Foundation. 25. Oktober 2015, archiviert vom am 29. Januar 2016; abgerufen am 4. Januar 2016 (englisch). Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
- Daniel Gultsch: OMEMO Encrypted Jingle File Transfer. In: Website der XMPP Standards Foundation. 2. September 2015, abgerufen am 4. Januar 2016 (englisch).
- heide.de/... – iCloud-Schlüsselbund: Schwachstelle ermöglichte Fremdzugriff auf Passwörter. 4. August 2017, abgerufen am 5. August 2017.