Off-the-Record Messaging

Während ihrer Kommunikation miteinander wählen Alice und Bob private Schlüssel ${\displaystyle x_{1},x_{2},\ldots }$ beziehungsweise ${\displaystyle y_{1},y_{2},\ldots }$. Jeweils zwei, zum Beispiel ${\displaystyle x_{i}}$ und ${\displaystyle y_{j}}$, werden zur Erzeugung eines gemeinsamen Geheimnisses ${\displaystyle s}$ mittels des Diffie-Hellman-Schlüsselaustauschs verwendet. Aus diesem Geheimnis ${\displaystyle s}$ werden die Schlüssel ${\displaystyle K_{\text{AES}}}$ und ${\displaystyle K_{\text{MAC}}}$ berechnet.

${\displaystyle K_{\text{AES}}}$ 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. ${\displaystyle K_{\text{MAC}}}$ 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 ${\displaystyle x_{i+1}}$ beziehungsweise ${\displaystyle y_{j+1}}$ 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 ${\displaystyle p}$ und eine Primitivwurzel ${\displaystyle g}$ modulo ${\displaystyle p}$ mit ${\displaystyle 2\leq g\leq p-2}$ benötigt. Alle Exponentiationen erfolgen dann modulo dieser Primzahl.

Zu Beginn e​ines Gesprächs müssen initiale Schlüssel ausgetauscht werden u​nd die Authentizität d​er Gesprächsteilnehmer überprüft werden, d​as heißt Alice u​nd Bob müssen s​ich jeweils sicher sein, m​it wem s​ie kommunizieren. Dies verhindert, d​ass Alice beispielsweise anstatt m​it Bob m​it der Angreiferin Eve e​inen Schlüsselaustausch durchführt. Der g​anze Vorgang w​ird Authenticated Key Exchange (AKE) genannt u​nd mit d​em SIGMA-Protokoll[1] umgesetzt:

1. Alice und Bob wählen private Schlüssel ${\displaystyle x_{1}}$ respektive ${\displaystyle y_{1}}$ (min. 320 Bit lang), tauschen die dazugehörigen öffentlichen Schlüssel ${\displaystyle g^{x_{1}}}$ beziehungsweise ${\displaystyle g^{y_{1}}}$ aus und erhalten durch das Diffie-Hellman-Verfahren ein gemeinsames Geheimnis ${\displaystyle s=\left(g^{x_{1}}\right)^{y_{1}}=\left(g^{y_{1}}\right)^{x_{1}}=g^{x_{1}\cdot y_{1}}}$.
2. Mittels ${\displaystyle s}$ 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 w​ird die Verbindung möglichst i​mmer mit AES verschlüsselt u​nd einzelne Nachrichten mittels SHA-256-HMAC authentifiziert.

Angenommen, Alice möchte an Bob die Nachricht ${\displaystyle M}$ schicken. Sie führt dabei folgende Schritte aus:

1. Alice wählt ihren letzten von Bob empfangenen Diffie-Hellman-Schlüssel ${\displaystyle x_{i}}$. Dabei gilt der Schlüssel von Bob als empfangen, wenn dieser ${\displaystyle g^{x_{i}}}$ für eine Nachricht verwendet hat, die Alice empfangen hat oder ${\displaystyle g^{x_{i}}}$ zuvor mittels AKE (siehe Abschnitt zuvor) ausgetauscht wurde, was offensichtlich nur im Fall ${\displaystyle i=1}$ sein kann.
2. Falls ${\displaystyle x_{i}}$ Alices neuester Diffie-Hellman-Schlüssel ist, erzeugt sie zufällig einen neuen Schlüssel ${\displaystyle x_{i+1}}$ von mindestens 320 Bit Länge.
3. Sei ${\displaystyle g^{y_{j}}}$ 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.
4. Das gemeinsame Diffie-Hellman-Geheimnis kann nun (modulo ${\displaystyle p}$) als ${\displaystyle s:=\left(g^{y_{j}}\right)^{x_{i}}}$ berechnet werden.
5. Berechne den AES-Schlüssel ${\displaystyle K_{\text{AES}}:=H(s)}$, wobei ${\displaystyle H(s)}$ die ersten 128 Bit des SHA-1-Hashwerts von ${\displaystyle s}$ bezeichnet. ${\displaystyle s}$ wurde zuvor in ein bestimmtes Datenformat gebracht und um ein Byte erweitert.
6. Berechne den MAC-Schlüssel ${\displaystyle K_{\text{MAC}}}$ als den 160-Bit-SHA-1-Hashwert von ${\displaystyle K_{\text{AES}}}$.
7. Für den später verwendeten Counter Mode wird ein Zähler ${\displaystyle c}$ benötigt, der so gewählt wird, dass das Tripel ${\displaystyle (i,j,c)}$ während des gesamten Nachrichtenaustauschs mit Bob nie doppelt vorkommt.
8. Die Nachricht ${\displaystyle M}$ wird nun mithilfe des AES-Algorithmus im Counter Mode verschlüsselt. Als Schlüssel dienen dazu ${\displaystyle K_{\text{AES}}}$ und der eben gewählte Zähler ${\displaystyle c}$. Die so verschlüsselte Nachricht heiße ${\displaystyle N}$.
9. Die verschlüsselte Nachricht ${\displaystyle N}$, ${\displaystyle i,j,c}$, ${\displaystyle g^{x_{i+1}}}$ und einige kryptographisch unwichtige Teile wie die Versionsnummer des Protokolls werden zu ${\displaystyle T}$ zusammengefasst und davon der Message Authentication Code ${\displaystyle MAC_{K_{\text{MAC}}}(T)}$ unter Verwendung des Schlüssels ${\displaystyle K_{\text{MAC}}}$ berechnet. Hierbei bezeichne ${\displaystyle MAC_{K_{\text{MAC}}}}$ den Keyed-Hash Message Authentication Code (HMAC) unter Verwendung der Hashfunktion SHA-1 und des Schlüssels ${\displaystyle K_{\text{MAC}}}$.
10. ${\displaystyle T,MAC_{K_{\text{MAC}}}(T)}$ und alle nicht mehr verwendeten MAC-Schlüssel werden an Bob über einen unsicheren Kanal geschickt.

Bob empfängt d​ie weiter o​ben erzeugten Daten v​on Alice u​nd führt folgende Schritte durch:

1. Bob hat entweder ${\displaystyle g^{x_{i}}}$ bereits durch eine alte Nachricht von Alice oder per AKE erhalten. Dadurch kann er dasselbe Diffie-Hellman-Geheimnis durch ${\displaystyle s:=\left(g^{x_{i}}\right)^{y_{j}}=g^{x_{i}\cdot y_{j}}=\left(g^{y_{j}}\right)^{x_{i}}}$ berechnen, wobei ${\displaystyle i}$ und ${\displaystyle j}$ die in ${\displaystyle T}$ enthaltenen Indizes bezeichnen.
2. Ebenso kann er wie Alice ${\displaystyle K_{\text{AES}}}$ und ${\displaystyle K_{\text{MAC}}}$ berechnen.
3. Mithilfe von ${\displaystyle K_{\text{MAC}}}$ berechnet er ${\displaystyle MAC_{K_{\text{MAC}}}(T)}$ 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.
4. Mithilfe von ${\displaystyle K_{\text{AES}}}$ und ${\displaystyle c}$, welches in dem durch Alice versandten ${\displaystyle T}$ enthalten ist, entschlüsselt er die Nachricht ${\displaystyle N}$ mit dem AES-Algorithmus in Counter Mode und erhält ${\displaystyle M}$ zurück. Dies funktioniert, da AES symmetrisch ist, also zum Ver- und Entschlüsseln denselben Schlüssel ${\displaystyle (K_{\text{AES}},c)}$ verwendet.

Verschlüsselung (Encryption)

Das verwendete Kryptosystem AES wurde eingehenden kryptoanalytischen Prüfungen unterzogen und gilt als praktisch berechnungssicher.

Beglaubigung (Authentication)

Mittels AKE und digitalen Signaturen kann sich Bob (auch zu einem späteren Zeitpunkt) sicher sein, dass Alice den öffentlichen Schlüssel ${\displaystyle g^{x_{1}}}$ gewählt hat. Da mithilfe dieses Schlüssels die nächste Nachricht und damit auch der nächste Schlüssel ${\displaystyle g^{x_{2}}}$ signiert wird, kann sich Bob auch bei allen darauf folgenden Nachrichten der Identität seines Gesprächspartners sicher sein.

Abstreitbarkeit (Deniability)

Alice verwendet ihre digitale Signatur nur zu Beginn des Gesprächs. Alle nachfolgenden Nachrichten werden mit den MAC-Schlüsseln ${\displaystyle K_{\text{MAC}}}$ signiert. Da zum Erzeugen der MAC-Schlüssel das gemeinsame Geheimnis ${\displaystyle s}$ benötigt wird, kann sich Bob sicher sein, dass Alice die Nachricht signiert hat. Jedoch kann er dies niemand anderem beweisen, da genauso er die Nachricht hätte signieren können. Hinzu kommt, dass durch die Veröffentlichung nicht mehr verwendeter MAC-Schlüssel niemand mehr die Authentizität der Nachrichten überprüfen kann, da jeder sie hätte signieren können. Nur Bob kann sich sicher sein, dass Alice die Nachricht geschickt hat, da zum Zeitpunkt des Empfangs nur sie beide den dazugehörigen MAC-Schlüssel kennen. Durch die Verwendung einer digitalen Signatur zum Beginn des Gesprächs kann jedoch niemand abstreiten, dass ein Gespräch stattgefunden hat.

Folgenlosigkeit (Perfect Forward Secrecy)

Verliert Alice ihren langlebigen privaten Schlüssel, so kann daraus keiner der kurzlebigen privaten Schlüssel ${\displaystyle x_{1},x_{2},\ldots }$ hergeleitet werden, da diese nie veröffentlicht und kurz nach ihrer Verwendung gelöscht wurden. Da nur diese kurzlebigen privaten Schlüssel zum Verschlüsseln und Signieren der Nachrichten verwendet wurden, ist trotz des Verlusts des langlebigen privaten Schlüssels das Gespräch nicht kompromittiert worden.

Ein weiteres Sicherheitskonzept i​st die Fälschbarkeit. Durch d​ie zur Verschlüsselung verwendete Stromchiffre (AES i​m Counter Mode), b​ei der d​er Klartext einfach m​it einem XOR verknüpft wird, u​m den Geheimtext z​u erhalten, k​ann bei erfolgreichem Erraten e​ines Teils d​es Klartexts d​er Angreifer d​en Geheimtext s​o modifizieren, d​ass dieser Teil s​ich zu e​inem beliebigen Text entschlüsselt. Dies verringert n​icht die Sicherheit, d​a Bob s​ich durch d​as Signieren d​er Nachricht m​it dem MAC-Schlüssel sicher s​ein kann, d​ass die verfälschte Nachricht n​icht von Alice stammt. Im Nachhinein k​ann aber d​er Angreifer d​iese Nachricht signieren, d​a der zugehörige MAC-Schlüssel veröffentlicht wurde. So w​ird erschwert, d​ass Alice d​urch den Inhalt e​iner Nachricht m​it ihr i​n Verbindung gebracht werden kann, d​a nachträglich d​ie Nachricht für j​eden signierbar u​nd beschränkt modifizierbar ist.

Eine computergestützte Kryptoanalyse des Protokolls in der Version 2 wurde von der Stanford University durchgeführt,[2] 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öffentlichen 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.

Als Referenzimplementierung d​es Protokolls s​teht von d​en beiden Entwicklern, Ian Goldberg u​nd Nikita Borisov, e​ine Programmbibliothek namens libotr z​ur Verfügung. Sie i​st als freie Software a​uch im Quelltext veröffentlicht u​nd unter d​en Bedingungen d​er GNU Lesser General Public License (LGPL) lizenziert. Mit d​er Bibliothek w​ird ein Toolkit z​um Fälschen v​on Nachrichten geliefert. Die Entwickler stellen a​uch ein Plugin für Pidgin z​ur Verfügung. Letztere unterstehen b​eide den Bedingungen d​er GNU General Public License (GPL).

Die folgenden Clients unterstützen Off-the-Record Messaging nativ. Das schließt ein, d​ass man m​it ihnen OTR m​it allen implementierten Instant-Messaging-Protokollen verwenden k​ann (zum Beispiel OSCAR, XMPP, MSN u​nd YIM). Eine weitere Liste m​it Programmen findet s​ich auf d​er Website d​er Entwickler.

• Adium (macOS)
• BitlBee (plattformunabhängig), ab Version 3.0 (optional einstellbar zur Kompilierzeit)
• CenterIM (Linux/Unix) unterstützt OTR ab Version 4.21.0
• ChatSecure (iOS)[3]
• climm (Linux/Unix) unterstützt es direkt seit 0.5.4
• IM+ (Android/iOS)[4]
• Jitsi (früher SIP Communicator) (plattformunabhängig)
• LoquiIM (Firefox OS)[5]
• MCabber (Linux, mehrere BSD-Derivate, OS X) unterstützt OTR direkt seit 0.9.4[6]
• Phonix Viewer[7] (plattformunabhängig), ein Betrachter für das Spiel Second Life, unterstützt OTR-Diskussionen innerhalb des Spiels
• qutIM (plattformunabhängig) seit 0.3.1[8]
• Rocket.Chat (plattformunabhängig)[9]
• SecuXabber (Android) unterstützt OTR nativ (Beta)[10]
• Spark (plattformunabhängig)[11]
• Xabber (Android) unterstützt OTR nativ seit 0.9.27 (nur XMPP)[12]

• Gajim (plattformunabhängig) hat ab Version 0.15 ein Plugin[13]
• Irssi (plattformunabhängig) hat ein Plugin[14]
• Kopete (Linux/Unix) hat ein (ab Version 0.50.80/KDE 4.1 offizielles) Plugin
• Miranda IM (Windows) hat ein Plugin[15]
• Miranda NG (Windows) hat ein Plugin[16]
• Mozilla Thunderbird ab Version 68[17] mit der OTR Bibliothek[18]
• Pidgin (plattformunabhängig) hat ein offizielles Plugin[19]
• Psi (plattformunabhängig) hat ein inoffizielles Plugin,[20] in Psi+[21] kann dieses (unter Linux) nativ verwendet werden
• Vacuum IM (Linux/Windows)[22]
• WeeChat (plattformunabhängig) hat ein Plugin[23]
• XChat (plattformunabhängig) hat ein Plugin[24]

Zunächst w​urde auch e​in Proxy entwickelt, d​er die Nutzung m​it dem OSCAR-Protokoll (AIM/ICQ) ermöglichen sollte, a​uch wenn d​er Chatclient selbst OTR n​icht unterstützt. Die Software w​ird seit 2005 n​icht mehr weiterentwickelt u​nd der Hersteller rät v​on der Benutzung ab.