Off-the-Record Messaging

Off-the-Record Messaging
Off-the-Record Messaging
Entwickler Das OTR-Team
Aktuelle Version 3.2.0
(15. Juni 2008)
Betriebssystem Microsoft Windows, Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X
Programmier­sprache Java(java-otr) bzw. C(libotr)
Kategorie Plugin
Lizenz LGPL/GPL (Freie Software)
Deutschsprachig ja
www.cypherpunks.ca/otr

Off-the-Record Messaging (zu deutsch: inoffizielle; vertrauliche, nicht für die Öffentlichkeit bestimmte Nachrichtenvermittlung) ist ein Protokoll zur Nachrichten-Verschlüsselung von Instant Messaging. Im Gegensatz zur Übertragung der verschlüsselten Nachrichten mittels GPG, PGP (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 (deniability; Prinzip der Abstreitbarkeit). 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 AES, des Diffie-Hellman-Schlüsselaustauschs und der Hashfunktion SHA-1. Die beiden Entwickler, Ian Goldberg und Nikita Borisov, stellen eine unter der LGPL lizenzierte und damit freie Bibliothek sowie ein Plugin für Pidgin, früher Gaim, zur Verfügung. Dieses Plugin, ein Toolkit um Nachrichten zu fälschen und die Proxy-Software sind dagegen unter der GPL lizenziert.

Inhaltsverzeichnis

Ziele des Projektes

In den Statuten des Projektes sind die folgenden vier Eckpfeiler definiert:

Verschlüsselung (Encryption)
Niemand kann die Nachrichten mitlesen.
Beglaubigung (Authentication)
Man kann sich sicher sein, dass der Empfänger derjenige ist, für den man ihn hält.
Abstreitbarkeit (Deniability)
Verschlüsselte Nachrichten enthalten keine elektronische Signatur. Es ist also möglich, dass jemand Nachrichten nach einer Konversation so fälscht, dass sie von einem selbst zu stammen scheinen. Während eines Gespräches kann der Empfänger aber gewiss sein, dass die empfangenen Nachrichten authentisch und unverändert sind.
Folgenlosigkeit (Perfect Forward Secrecy)
Wenn man seinen langlebigen privaten Schlüssel verloren hat, so hat dies keine Auswirkung auf die Kompromittierung bisher getätigter Gespräche.

Technische Umsetzung

Der folgende Abschnitt stellt vereinfacht die Funktion des OTR-Protokolls in Version 2[1] dar.

Überblick

Während der Kommunikation zwischen Alice und Bob wählen sie private Schlüssel x_1, x_2, \ldots beziehungsweise y_1, y_2, \ldots. Jeweils zwei, z. B. xi und yj, werden zur Erzeugung eines gemeinsamen Geheimnisses s mittels des Diffie-Hellman-Schlüsselaustauschs verwendet. Aus diesem Geheimnis s werden die Schlüssel KAES und KMAC berechnet.

KAES dient zur Verschlüsselung jeder Nachricht mittels Advanced Encryption Standard (AES) im Counter Mode. Dadurch wird das symmetrische Blockchiffre AES zum 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. KMAC dient zur Authentifizierung einer einzelnen Nachricht mittels der Hashfunktion SHA-1 (Secure Hash Algorithm), welche als Message Authentication Code (MAC) verwendet wird.

Bei Senden von Nachrichten werden neue private Schlüssel xi + 1 bzw. yj + 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 im Nachhinein 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 wird eine 1536 Bit Primzahl p und eine Primitivwurzel g modulo p mit 2 \le g \le p-2 benötigt. Alle Exponentiationen erfolgen dann modulo dieser Primzahl.

Initialisierung

Zu Beginn eines Gesprächs müssen initiale Schlüssel ausgetauscht werden und die Authentizität der Gesprächsteilnehmer überprüft werden, d.h. 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[1] umgesetzt:

  1. Alice und Bob wählen private Schlüssel x1 respektive y1 (min. 320 Bit lang), tauschen die dazugehörigen öffentlichen Schlüssel g^{x_1} bzw. g^{y_1} aus und erhalten durch das Diffie-Hellman-Verfahren ein gemeinsames Geheimnis s = \left ( g^{x_1} \right )^{y_1} = \left ( g^{y_1} \right )^{x_1} = g^{x_1 \cdot y_1}.
  2. Mittels s kann nun ein sicherer Kanal geschaffen werden, über diesen 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 SHA256-HMAC authentifiziert.

Senden einer Nachricht

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

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

Empfangen einer Nachricht

Bob empfängt die weiter oben erzeugten Daten von Alice und führt folgende Schritte durch:

  1. Bob hat entweder g^{x_i} bereits durch eine alte Nachricht von Alice oder per AKE erhalten. Dadurch kann er dasselbe Diffie-Hellman-Geheimnis durch s := \left ( g^{x_i} \right )^{y_j} = g^{x_i \cdot y_j} = \left ( g^{y_j} \right )^{x_i} berechnen, wobei i und j die in T enthaltenen Indizes bezeichnen.
  2. Ebenso kann er wie Alice KAES und KMAC berechnen.
  3. Mithilfe von KMAC berechnet er MAC_{K_{MAC}}(T) und vergleicht den erhaltenen Wert mit dem von Alice übermittelten. Dadurch ist die Authentizität der Nachricht geprüft und gegen einen Man-in-the-middle-Angriff geschützt.
  4. Mithilfe von KAES und c, welches in dem durch Alice versandten T enthalten ist, entschlüsselt er die Nachricht N mit dem AES-Algorithmus in Counter Mode und erhält M zurück. Dies funktioniert, da AES symmetrisch ist, also zum Ver- und Entschlüsseln denselben Schlüssel (KAES,c) verwendet.

Überprüfung der Ziele

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 g^{x_1} gewählt hat. Da mithilfe dieses Schlüssels die nächste Nachricht und damit auch der nächste Schlüssel 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 KMAC signiert. Da zum Erzeugen der MAC-Schlüssel das gemeinsame Geheimnis 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 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 ist die Fälschbarkeit. Durch die zur Verschlüsselung verwendete Stromchiffre (AES in 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 beliebigem 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 im Nachhinein die Nachricht für jeden signierbar und beschränkt modifizierbar ist.

Kryptoanalyse

Eine computergestützte Kryptoanalyse des Protokolls in der Version 2 wurde von der Stanford University durchgeführt[2] und dabei mehrere Schwachstellen entdeckt: Durch einen Man-in-the-middle-Angriff ist es möglich, auf eine ältere Version des Protokolls (z. B. Version 1) zu wechseln, um so dessen Schwachstellen auszunutzen. Weiterhin ist die Abstreitbarkeit im starken Sinne, d. h. 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.

Verfügbarkeit

Native Unterstützung

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 (z. B. OSCAR, XMPP, MSN und YIM).

Fester Bestandteil

  • Adium (Mac OS X) unterstützt OTR von Haus aus
  • climm (Linux/Unix) unterstützt es direkt seit 0.5.4
  • MCabber (Linux, mehrere BSD-Derivate, Mac OS X) unterstützt OTR direkt seit 0.9.4[3]
  • CenterIM (Linux/Unix) unterstützt OTR seit Version 4.21.0
  • Jitsi (früher SIP Communicator) (plattformunabhängig)
  • BitlBee (plattformunabhängig), seit Version 3.0 (optional einstellbar zur Kompilierzeit)
  • Phonix Viewer[4] (plattformunabhängig), ein Viewer für das Spiel SecondLife, unterstützt OTR-Diskussionen innerhalb des Spiels

Plugin

Proxy

Für jene Clients, die OTR nicht nativ unterstützen, gibt es einen lokalen Proxy. Das bedeutet, dass die unverschlüsselten Nachrichten zum lokal installierten Proxy gesendet, dort verschlüsselt und dann erst zum eigentlichen Empfänger gesendet werden. Derzeit unterstützt der vom OTR-Projekt zur Verfügung gestellte Proxy nur das OSCAR-Protokoll und kann daher nur mit Mac, ICQ und AIM genutzt werden. Der OTR-Proxy beherrscht SOCKS5, HTTPS und HTTP.

Einige Mac-, ICQ- und AIM-Clients, die Proxys, aber nativ kein OTR unterstützen:

Quellen

  1. a b Off-the-Record Messaging Protocol version 2 (englisch)
  2. Joseph Bonneau, Andrew Morrison: Finite-State Security Analysis of OTR Version 2. Stanford University, abgerufen am 13. Juli 2011 (PDF (105 kB), englisch).
  3. mcabber-Changelog, siehe Abschnitt „mcabber (0.9.4)“, englisch
  4. Phonix Viewer, OSS
  5. Pidgin OTR Plugin, englisch
  6. Psi-Patch und OTR-Plugin auf tfh-berlin.de, englisch
  7. Website der Psi-Entwicklerversion Psi+, englisch
  8. Miranda OTR Plugin, englisch
  9. Trillian OTR, englisch
  10. Irssi OTR, englisch
  11. Gajim OTR, englisch
  12. Xchat OTR, englisch

Weblinks


Wikimedia Foundation.

Игры ⚽ Поможем решить контрольную работу

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Off-the-Record Messaging — Off the Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric key algorithm, the Diffie–Hellman key exchange,… …   Wikipedia

  • Off-the-record messaging — Off the Record Messaging, appelé communément OTR, est un protocole cryptographique. Sommaire 1 Description 2 Disponibilité 2.1 D origine dans 2.2 Sous forme de plugin …   Wikipédia en Français

  • Off-the-Record Messaging — Off the Record Messaging, appelé communément OTR, est un protocole cryptographique. Sommaire 1 Description 2 Disponibilité 2.1 D origine dans 2.2 Sous forme de plugin …   Wikipédia en Français

  • Off-the-Record Messaging — OTR (Off the Record) encryption  протокол шифрования сообщений для сетей обмена мгновенных сообщений, созданный Никитой Борисовым и Ианом Голдбергом (англ. Ian Goldberg). Авторами создана библиотека, распространяемая под лицензией GNU… …   Википедия

  • Off the record — is a term related to journalism sourcing; see Journalism sourcing#Using confidential information. Off the record may also refer to: Contents 1 Music 2 Television …   Wikipedia

  • OTR Messaging — Off the Record Messaging Entwickler: cypherpunks Aktuelle Version: 3.2.0 (15. Juni 2008) Betriebssystem: Microsoft Windows, Linux, FreeBSD, NetBSD, Mac OS X …   Deutsch Wikipedia

  • Extensible Messaging and Presence Protocol — Familie: Internetprotokollfamilie Einsatzgebiet: Instant Messaging Ports: 5222/TCP (Client zu Server) 5269/TCP (Server zu Server) Legacy SSL: 5223/TCP (SSL) XMPP im TCP/IP‑Protokollstapel: Anwendung …   Deutsch Wikipedia

  • Proteus (instant messaging client) — Infobox Software name = Proteus caption = Proteus in action developer = Proteusapps released = ? frequently updated = no, abandoned programming language = Cocoa operating system = Mac OS X language = genre = Instant messaging client license =… …   Wikipedia

  • The CW Television Network — Type Broadcast television network …   Wikipedia

  • Comparison of instant messaging clients — The following tables compare general and technical information for a number of instant messaging clients. Please see the individual products articles for further information. This article is not all inclusive or necessarily up to date. External… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”