OTR
Aus Ubuntu-Forum Wiki
Zero77 (Diskussion | Beiträge) |
Zero77 (Diskussion | Beiträge) (→Installation und Konfiguration) |
||
| (Der Versionsvergleich bezieht 13 dazwischenliegende Versionen mit ein.) | |||
| Zeile 2: | Zeile 2: | ||
__TOC__ | __TOC__ | ||
=Allgemeines= | =Allgemeines= | ||
| - | OTR steht für "Off-the-Record" und bedeutet sinngemäß ''nicht zur Mitschrift bestimmt''. Es ist ein Prinzip der Nachrichten-Verschlüsselung, das bei [[Instant Messaging |Instant Messaging Clients]] (kurz: ''IM | + | OTR steht für "''Off-the-Record''" und bedeutet sinngemäß "''nicht zur Mitschrift bestimmt''". Es ist ein Prinzip der Nachrichten-Verschlüsselung, das bei [[Instant Messaging |Instant Messaging Clients]] (kurz: ''IM-Client'' für ''Sofortnachrichten-Dienst'') angewendet wird. |
| - | Dabei ist es unerheblich, welches Protokoll im Endeffekt eingesetzt wird - ausschlaggebend ist dabei allein der verwendete [[Client]]. | + | Dabei ist es unerheblich, welches Protokoll im Endeffekt zum Chatten eingesetzt wird - ausschlaggebend ist dabei allein der verwendete [[Client]]. |
| - | + | Einige IM-Clients verfügen von Haus aus über die Fähigkeit, verschlüsselt per OTR kommunizieren zu können. Bei den meisten kann diese Funktionalität per Plugin nachinstalliert werden. Einige wenige unterstützen dies allerdings gar nicht oder nur unzureichend. | |
| - | + | Allgemein kann man sagen, dass es für jedes Betriebssystem auch einen IM-Client gibt, der sich auf OTR versteht. Eine verschlüsselte Kommunikation ist so plattformübergreifend und unabhängig von den verwendeten Clients möglich. | |
| + | Einen Überblick der OTR-fähigen IM-Clients bietet die [http://de.wikipedia.org/wiki/Off-the-Record_Messaging#Verf.C3.BCgbarkeit Wikipedia-Seite] zu OTR. | ||
| + | Die Verschlüsselung [http://de.wikipedia.org/wiki/Off-the-Record_Messaging funktioniert] durch eine kombinierte Verwendung des symmetrischen Kryptoverfahrens AES, des Diffie-Hellman-Schlüsselaustauschs und der Hash-Funktion SHA-1. | ||
| + | |||
| + | =Funktionen= | ||
| + | ;Verschlüsselung: | ||
| + | Kein Unbeteiligter, auch kein Protokollanbieter, kann die verschlüsselten Nachrichten entschlüsseln oder gar mitlesen. | ||
| + | |||
| + | Das sollte man zum Beispiel beachten, wenn man [[ICQ]] nutzt. Egal welchen Client man verwendet, die Kommunikation findet immer über deren Server statt. Nach den [http://www.icq.com/legal/policy.html Nutzungsbestimmungen] gibt man mit Absenden eines Textes sein Copyright an diesem auf und somit ICQ freie Hand bei dessen Nutzung. | ||
| + | ;Authentisierung: | ||
| + | OTR bietet die Sicherheit, dass man sich auch wirklich mit demjenigen unterhält, von dem man ausgeht. | ||
| + | |||
| + | ;Bestreitbarkeit: | ||
| + | Die versendeten Nachrichten werden nicht digital signiert. ''Nach'' einer Unterhaltung könnte man deshalb die Nachrichten so bearbeiten, dass sie es den Anschein hat, sie kämen von einem anderen Teilnehmer. Während einer Sitzung ist dies allerdings nicht möglich. | ||
| + | Das bedeutet, dass man sich ''während'' der Sitzung sicher sein kann, dass die gesendeten Nachrichten nicht modifiziert sind und auch vom ''echten'' Absender stammen. Dies gilt so im Nachhinein aber nicht mehr. So kann keiner, weder der Unterhaltungspartner noch etwaige Dritte, behaupten bzw. rechtssicher beweisen, dass eine bestimmte Aussage auch von einer bestimmten Person gemacht wurde. | ||
| + | |||
| + | Anders ist dies bei der Verschlüsselung bzw. Signierung mittels [[GnuPG]]. Diese Nachrichten, auch E-Mails, können zweifelsfrei und rechtssicher einem Empfänger zugeordnet werden. Das bringt natürlich nur etwas, wenn der Inhalt entschlüsselt werden konnte. | ||
| + | |||
| + | ;Zukunftssichere Geheimhaltung: | ||
| + | Sollte man die Kontrolle über seine privaten Schlüssel verlieren, so werden vorherige Unterhaltungen nicht kompromittiert. | ||
| + | |||
| + | Da die meisten IM-Clients die Protokolle der Unterhaltung lokal auf der Festplatte ablegen, muss diese durch eine Verschlüsselung gesichert werden. Alternativ kann bzw. sollte auch die Protokollierung im jeweiligen Client deaktiviert werden. | ||
= Prinzip = | = Prinzip = | ||
| - | + | OTR arbeitet nach folgendem Prinzip: | |
| - | *Beide Benutzer schreiben sich über einen verschlüsselten Kanal | + | * Beide Benutzer schreiben sich über einen verschlüsselten Kanal |
| - | *Der Kanal wird einmal authorisiert - | + | * Der Kanal wird einmal authorisiert - dies geschieht, indem man den ''Fingerprint'' also ''Fingerabdruck'' des anderen verifiziert, also bestätigt. Der Ablauf ist abhängig vom verwendeten verwendenten Client. |
| - | *Beim Starten und Beenden | + | * Beim Starten und Beenden einer Unterhaltungen wird eine Sitzung gestartet. Für diese gilt dann jeweils ein Schlüssel. |
| - | Es ist natürlich sinnvoll, ein möglichst langes und sicheres Passwort (also eines mit Zahlen-, Buchstaben- und Symbolkombinationen) zu verwenden. Das Ganze ad absurdum | + | Es ist natürlich sinnvoll, ein möglichst langes und sicheres Passwort (also eines mit Zahlen-, Buchstaben- und Symbolkombinationen) zu verwenden. Das Ganze wird natürlich ad absurdum geführt, wenn dieses Passwort vorher dem anderen Benutzer ''unverschlüsselt'' gesendet wird. Theoretisch könnte das Passwort mitgeschnitten werden und dann macht der Schutz keinen Sinn mehr. Am Besten greift man hierfür auf ein persönliches Gespräch oder ein anderes verschlüsseltes Medium zurück. |
| + | =Installation und Konfiguration= | ||
| + | Wie schon erwähnt, ist die Nutzung von OTR abhängig vom verwendeten Client: | ||
| + | * [[Kopete#OTR|Kopete]] | ||
| + | * [[Mcabber#OTR-Verschl.C3.BCsselung|Mcabber]] | ||
| + | * [[Pidgin]] | ||
| - | + | Allen gemein ist allerdings, dass man ihnen mitteilen muss, wann sie eine Verbindung verschlüsseln sollen. Das Verhalten nennt man ''OTR-Policy''. Es gibt vier verschiedene Einstellungen dafür. Clientabhängig tragen sie verschiedene Namen, das Prinzip bleibt aber erhalten: | |
| - | + | ||
| - | + | ;Immer bzw. always: | |
| - | + | Nachrichten werden immer verschlüsselt. Diese Methode hat einen gravierenden Nachteil - ist der Client das Gesprächsteilnehmers nicht OTR-fähig, kann er die Nachrichten nicht entschlüsseln und somit auch nicht lesen. | |
| + | |||
| + | ;Automatisch bzw. opportunistic : | ||
| + | Der eigene Client prüft, ob die Gegenseite ebenfalls einen OTR-fähigen Client besitzt. Ist dies der Fall, wird die Sitzung automatisch verschlüsselt. Dies Einstellung gilt als die ''empfohlene''. | ||
| + | |||
| + | ;Manuell bzw. manual: | ||
| + | Eine OTR-Sitzung muss jedes Mal selber aufgebaut werden. Erst dann ist die Übertragung verschlüsselt. | ||
| + | |||
| + | ;Niemals, never bzw. plain: | ||
| + | Bei dieser Einstellung werden Nachrichten niemals verschlüsselt. | ||
| + | |||
| + | =Ablauf und Arbeitsweise einer Verschlüsselung= | ||
| + | ;Eigenen Schlüssel generieren: | ||
| + | Ist OTR erst einmal verfügbar, möchte man es auch nutzen. Dazu muss man zunächst ''einmalig'' seinen eigenen Schlüssel generieren. Dies dauert einige Zeit. Je nach Client muss man in das OTR-Untermenü wechseln und kann dort die Schlüsselgenerierung anstoßen. Die meisten Clients generieren diesen Schlüssel auch automatisch, wenn OTR das erste Mal zum Einsatz kommt. Für jeden Schlüssel gibt es einen ''Fingerprint'', also seinen Fingerabdruck, doch dazu später mehr. | ||
| + | |||
| + | ;Aufbau einer verschlüsselten Verbindung: | ||
| + | Je nach eingestellter ''OTR-Policy'' kann man nun eine verschlüsselte Verbindung zum Gesprächspartner aufbauen, so lange dessen Client auch OTR-fähig ist. | ||
| + | |||
| + | Beim erstmaligen Aufbau einer verschlüsselten Verbindung zwischen zwei Gesprächspartnern müssen diese sich gegenseitig ihre ''Echtheit'' bestätigen. Diese sogenannte Authentisierung geschieht entweder durch die Eingabe eines ''Geheimnisses'', also einer Textphrase, die beide eingeben müssen. Oder man teilt sich über ein ''sicheres Medium'' oder auch persönlich seinen Fingerprint mit. Dann kann man die Authentifierung auch manuell vornehmen. Erst dann, also wenn beide Seiten sicher sind, dass sie mit dem gewünschten und gemeinten (''authentischen'') Gesprächspartner kommunizieren, ist auch die Verbindung sicher verschlüsselt. | ||
| + | |||
| + | Der Authentifierzierungs-Dialog befindet sich meist im Chatfenster des genutzten Clients. | ||
= Links = | = Links = | ||
| + | * [http://www.cypherpunks.ca/otr/index.php Projektseite] | ||
* [http://de.wikipedia.org/wiki/Off-the-Record_Messaging Wikipedia zum Thema "Off-the-record"] | * [http://de.wikipedia.org/wiki/Off-the-Record_Messaging Wikipedia zum Thema "Off-the-record"] | ||
| - | |||
[[Kategorie:Verschlüsselung]] | [[Kategorie:Verschlüsselung]] | ||
Aktuelle Version vom 29. Juli 2008, 09:05 Uhr
 Begriffserklärung
|
Inhaltsverzeichnis |
1 Allgemeines
OTR steht für "Off-the-Record" und bedeutet sinngemäß "nicht zur Mitschrift bestimmt". Es ist ein Prinzip der Nachrichten-Verschlüsselung, das bei Instant Messaging Clients (kurz: IM-Client für Sofortnachrichten-Dienst) angewendet wird.
Dabei ist es unerheblich, welches Protokoll im Endeffekt zum Chatten eingesetzt wird - ausschlaggebend ist dabei allein der verwendete Client.
Einige IM-Clients verfügen von Haus aus über die Fähigkeit, verschlüsselt per OTR kommunizieren zu können. Bei den meisten kann diese Funktionalität per Plugin nachinstalliert werden. Einige wenige unterstützen dies allerdings gar nicht oder nur unzureichend. Allgemein kann man sagen, dass es für jedes Betriebssystem auch einen IM-Client gibt, der sich auf OTR versteht. Eine verschlüsselte Kommunikation ist so plattformübergreifend und unabhängig von den verwendeten Clients möglich.
Einen Überblick der OTR-fähigen IM-Clients bietet die Wikipedia-Seite zu OTR.
Die Verschlüsselung funktioniert durch eine kombinierte Verwendung des symmetrischen Kryptoverfahrens AES, des Diffie-Hellman-Schlüsselaustauschs und der Hash-Funktion SHA-1.
2 Funktionen
- Verschlüsselung
Kein Unbeteiligter, auch kein Protokollanbieter, kann die verschlüsselten Nachrichten entschlüsseln oder gar mitlesen.
Das sollte man zum Beispiel beachten, wenn man ICQ nutzt. Egal welchen Client man verwendet, die Kommunikation findet immer über deren Server statt. Nach den Nutzungsbestimmungen gibt man mit Absenden eines Textes sein Copyright an diesem auf und somit ICQ freie Hand bei dessen Nutzung.
- Authentisierung
OTR bietet die Sicherheit, dass man sich auch wirklich mit demjenigen unterhält, von dem man ausgeht.
- Bestreitbarkeit
Die versendeten Nachrichten werden nicht digital signiert. Nach einer Unterhaltung könnte man deshalb die Nachrichten so bearbeiten, dass sie es den Anschein hat, sie kämen von einem anderen Teilnehmer. Während einer Sitzung ist dies allerdings nicht möglich. Das bedeutet, dass man sich während der Sitzung sicher sein kann, dass die gesendeten Nachrichten nicht modifiziert sind und auch vom echten Absender stammen. Dies gilt so im Nachhinein aber nicht mehr. So kann keiner, weder der Unterhaltungspartner noch etwaige Dritte, behaupten bzw. rechtssicher beweisen, dass eine bestimmte Aussage auch von einer bestimmten Person gemacht wurde.
Anders ist dies bei der Verschlüsselung bzw. Signierung mittels GnuPG. Diese Nachrichten, auch E-Mails, können zweifelsfrei und rechtssicher einem Empfänger zugeordnet werden. Das bringt natürlich nur etwas, wenn der Inhalt entschlüsselt werden konnte.
- Zukunftssichere Geheimhaltung
Sollte man die Kontrolle über seine privaten Schlüssel verlieren, so werden vorherige Unterhaltungen nicht kompromittiert.
Da die meisten IM-Clients die Protokolle der Unterhaltung lokal auf der Festplatte ablegen, muss diese durch eine Verschlüsselung gesichert werden. Alternativ kann bzw. sollte auch die Protokollierung im jeweiligen Client deaktiviert werden.
3 Prinzip
OTR arbeitet nach folgendem Prinzip:
- Beide Benutzer schreiben sich über einen verschlüsselten Kanal
- Der Kanal wird einmal authorisiert - dies geschieht, indem man den Fingerprint also Fingerabdruck des anderen verifiziert, also bestätigt. Der Ablauf ist abhängig vom verwendeten verwendenten Client.
- Beim Starten und Beenden einer Unterhaltungen wird eine Sitzung gestartet. Für diese gilt dann jeweils ein Schlüssel.
Es ist natürlich sinnvoll, ein möglichst langes und sicheres Passwort (also eines mit Zahlen-, Buchstaben- und Symbolkombinationen) zu verwenden. Das Ganze wird natürlich ad absurdum geführt, wenn dieses Passwort vorher dem anderen Benutzer unverschlüsselt gesendet wird. Theoretisch könnte das Passwort mitgeschnitten werden und dann macht der Schutz keinen Sinn mehr. Am Besten greift man hierfür auf ein persönliches Gespräch oder ein anderes verschlüsseltes Medium zurück.
4 Installation und Konfiguration
Wie schon erwähnt, ist die Nutzung von OTR abhängig vom verwendeten Client:
Allen gemein ist allerdings, dass man ihnen mitteilen muss, wann sie eine Verbindung verschlüsseln sollen. Das Verhalten nennt man OTR-Policy. Es gibt vier verschiedene Einstellungen dafür. Clientabhängig tragen sie verschiedene Namen, das Prinzip bleibt aber erhalten:
- Immer bzw. always
Nachrichten werden immer verschlüsselt. Diese Methode hat einen gravierenden Nachteil - ist der Client das Gesprächsteilnehmers nicht OTR-fähig, kann er die Nachrichten nicht entschlüsseln und somit auch nicht lesen.
- Automatisch bzw. opportunistic
Der eigene Client prüft, ob die Gegenseite ebenfalls einen OTR-fähigen Client besitzt. Ist dies der Fall, wird die Sitzung automatisch verschlüsselt. Dies Einstellung gilt als die empfohlene.
- Manuell bzw. manual
Eine OTR-Sitzung muss jedes Mal selber aufgebaut werden. Erst dann ist die Übertragung verschlüsselt.
- Niemals, never bzw. plain
Bei dieser Einstellung werden Nachrichten niemals verschlüsselt.
5 Ablauf und Arbeitsweise einer Verschlüsselung
- Eigenen Schlüssel generieren
Ist OTR erst einmal verfügbar, möchte man es auch nutzen. Dazu muss man zunächst einmalig seinen eigenen Schlüssel generieren. Dies dauert einige Zeit. Je nach Client muss man in das OTR-Untermenü wechseln und kann dort die Schlüsselgenerierung anstoßen. Die meisten Clients generieren diesen Schlüssel auch automatisch, wenn OTR das erste Mal zum Einsatz kommt. Für jeden Schlüssel gibt es einen Fingerprint, also seinen Fingerabdruck, doch dazu später mehr.
- Aufbau einer verschlüsselten Verbindung
Je nach eingestellter OTR-Policy kann man nun eine verschlüsselte Verbindung zum Gesprächspartner aufbauen, so lange dessen Client auch OTR-fähig ist.
Beim erstmaligen Aufbau einer verschlüsselten Verbindung zwischen zwei Gesprächspartnern müssen diese sich gegenseitig ihre Echtheit bestätigen. Diese sogenannte Authentisierung geschieht entweder durch die Eingabe eines Geheimnisses, also einer Textphrase, die beide eingeben müssen. Oder man teilt sich über ein sicheres Medium oder auch persönlich seinen Fingerprint mit. Dann kann man die Authentifierung auch manuell vornehmen. Erst dann, also wenn beide Seiten sicher sind, dass sie mit dem gewünschten und gemeinten (authentischen) Gesprächspartner kommunizieren, ist auch die Verbindung sicher verschlüsselt.
Der Authentifierzierungs-Dialog befindet sich meist im Chatfenster des genutzten Clients.
