die raven homepage
Verschlüsseltes & anonymisiertes IM per Jabber - Seite 3
Verschlüsselung, Signierung und Authentifizierung
Verschlüsselung und Signierung Benutzer-zu-Benutzer

Zur Zeit gibt es drei Methoden zur Verschlüsselung und Signierung von Jabber Nachrichten.

Die erste Methode verwendet S/MIME und wird im IETF RFC 3923 End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) beschrieben. Aufgrund des Aufwands, der mit der Implementierung von S/MIME verbunden ist, wird diese Methode von der Mehrheit der Jabber Client Entwickler nicht umgesetzt.

Die zweite Methode verwendet die Verschlüsselung nach dem OpenPGP Standard mithilfe OpenPGP kompatibler Programme wie GnuPG. Diese Methode wird im Dokument XEP-0027 Current Jabber OpenPGP Usage der XMPP Standards Foundation (XSF) beschrieben.

Bei dem letzteren Dokument handelt es sich um ein "XMPP Extension Protocol (XEP)", d. h. um eine Erweiterung der XMPP Kern-Protokolle, die im Rahmen der XSF beschlossen wurde, aber (noch) nicht Bestandteil des Standardisierungsverfahrens der IETF oder der Standards der XSF ist, jedoch in der Jabber Community "weit" verbreitet ist.

Die dritte Methode ist das nicht jabberspezifische Off-the-Record Messaging (OTR), das aber auch mit Jabber Konten verwendet werden kann.

OTR basiert auf einer Kryptobibliothek von Ian Goldberg und Nikita Borisov, die ein eigenes Instant Messaging Protokoll implementiert, das über die libgcrypt Bibliothek AES, SHA1-HMAC, RSA und DSA Schlüssel mit dem Diffie-Hellmann Schlüsselaustauschprotokoll einsetzt, um die Verschlüsselung von Instant Messaging Nachrichten/Chats und die Authentitizät der Nachrichten/Chats während der Kommunikation gewährleistet.

OTR ist dabei so ausgelegt, dass weder eine nachträgliche Entschlüsselung der Nachrichten noch eine beweiskräftige Zuordnung der Urheberschaft der Nachrichten durch einen Angreifer oder die Kommunikationspartner selbst durchgeführt werden kann.

OTR kann für Jabber Nachrichten mit den Jabber Anwendungen Pidgin, Miranda, Adium, Kopete und SIP Communicator eingesetzt werden. Für die Psi Plus (Psi+) Linuxversion von Psi gibt es von Timo Engel ein OTR-Plugin, für dessen Anwendung der Psi+ Quellcode kompiliert wird. Die Psi und Psi+ Entwickler bieten keine Psi Version für alle Plattformen an, die neben OpenPGP auch OTR unterstützt.

Die Anwendung der OTR Verschlüsselung bei Jabber wird am Beispiel des Pidgin Client auf der Seite Jabber mit OTR ("Off-the-record") Verschlüsselung und Tor Anonymisierung vorgestellt.

Im XEP-0116: Encrypted Session Negotiation wird eine vierte Verschlüsselungsmethode beschrieben, die auf SSH, dem SSH Transport Layer Protokoll und OTR basiert. Die "verschlüsselten Jabber Sitzungen" werden von keiner Jabber Anwendung außer dem guten Jabber Client Gajim implementiert.

Die tatsächliche Verwendung der Methoden ist davon abhängig, ob und wie die Entwickler der Jabber Client Programme die nötigen Funktionen in ihre Applikationen implementieren.

Ohne eine Benutzer-zu-Benutzer Verschlüsselung ist es jedem Betreiber oder Administrator eines Jabber Servers möglich, Jabber Nachrichten und Chats genauso mitzulesen wie das bei unverschlüsselten E-Mails der Fall ist. Diese Möglichkeit haben auch Geheimdienste und Sicherheitsbehörden, wenn sie mit Abhörbegehren an die Betreiber herantreten.

Verschlüsselung und Authentifizierung zwischen Benutzer-zu-Server und Server-zu-Server

Die Methoden und Mechanismen zur Verschlüsselung und Authentifizierung werden in den IETF XMPP RFCs und im XEP-0078: Non-SASL Authentication definiert.

Gemäß der IETF Spezifikation soll zur Verschlüsselung des Kanals zwischen Benutzer und Server und des Servers einer Domain zum Server einer anderen Domain sowie zur Authentifizierung des Servers gegenüber einem Benutzer das Transport Layer Security (TLS) Protokoll zusammen mit der STARTTLS Erweiterung verwendet werden. Zur nachfolgenden Authentifizierung des Benutzers gegenüber dem Server das Simple Authentication and Security Layer (SASL) Protokoll.

Grob gesagt weist sich per TLS, einer Weiterentwicklung des Secure Socket Layer (SSL) Protokolls, der Server gegenüber dem Benutzer mit seinem Zertifikat aus und die Daten zwischen Benutzer und Server oder auch zwischen den Servern werden mit einem kryptografischen Schlüssel verschlüsselt übertragen. Über die Länge des Schlüssels und den verwendeten Algorithmus (AES, RC4, IDEA, Triple-DES) einigen sich Client und Server über ein Schlüsselaustauschverfahren, das mit RSA oder DH Verschlüsselung arbeitet.

SASL bietet zur Übermittlung von Benutzernamen und Passwort zum Server und zur Überprüfung der Identität des Benutzers einen Frage-Antwort-Mechanismus, der DIGEST-MD5 oder CRAM-MD5 verwendet, aber auch die Klartextform. Bei den Verfahren, die nicht die Klartextform benutzen, wird das Passwort des Benutzers und der gegenseitige Austausch von Identifizierungszeichenketten über Hash- und Verschlüsselungsalgorithmen verschlüsselt übertragen. TLS und SASL werden auch bei verschlüsselten Verbindungen zu Web- und Mailservern und bei der Authentifizierung von Benutzern durch Mailserver verwendet.

Das Problem im Bereich der Benutzer-Authentifizierung liegt darin, dass für die Nutzung von SASL nicht für jede Plattform, für die oder auf der Jabber Programme entwickelt werden, die nötigen SASL Bibliotheken vorhanden sind.

Deshalb wurde als Fallback-Lösung von der XSF eine Protokollerweiterung beschlossen, die Mechanismen zur Authentifizierung festlegen, die nicht auf SASL aufbauen. Dem XEP-0078: Non-SASL Authentication zufolge, kann ein Client die Daten des Benutzers entweder in Klartextform übermitteln oder er verkettet das Passwort des Benutzers mit einem ID-String, der ihm vom Server übermittelt wurde, bildet daraus mit dem SHA-1 Algorithmus einen Hashwert und sendet diesen zur Authentifizierung an den Server zurück.

Das XEP-Dokument merkt dazu an, dass dieses Digestverfahren nicht so sicher ist wie die SASL Mechanismen. Die Klartextform sollte nur gewählt werden, wenn das Digestverfahren nicht möglich ist, der Austausch über einen zuvor per TLS gesicherten Kanal (s. o.) erfolgt und das Serverzertifikat vom Client (Benutzer) geprüft wurde.

Es dürfte klar sein, dass die Verwendung eines Jabber Client ohne TLS bzw. eines Jabber Servers, der TLS nicht anbietet und die Übertragung der eigenen Zugangsdaten in Klartextform die unsicherste Form der Jabber Nutzung darstellt. Deshalb ist es wichtig, dass alle an einer Kommunikation beteiligten Jabber Server und Anwendungen TLS beherrschen und anwenden, damit von einem Kommunikationspartner zum anderen eine ununterbrochende Verschlüsselungsverbindung für die Verschlüsselung der Kommunikation in der Fom besteht:

Alice < TLS > Server v. Alice < TLS > Server v. Bob < TLS > Bob

An jeder Verbindungsstrecke, an der die Transportverschlüsselung inaktiv ist und Benutzer keine zusätzliche Inhaltsverschlüsselung anwenden, werden Daten in Klartextform übertragen, die damit Ansatzpunkte für Angreifer bieten:

Alice < TLS > Server v. Alice < nichts > Server v. Bob < TLS > Bob

oder

Alice < TLS > Server v. Alice < TLS > Server v. Bob < nichts > Bob

Aus diesem Grund sollte man sich nur dann auf die TLS/SSL Verschlüsselung verlassen, wenn Informationen vorliegen, dass alle Beteiligten per TLS/SSL kommunizieren und stets die zusätzliche Benutzer-zu-Benutzer Verschlüsselung per OpenPGP oder OTR (falls vom Client unterstützt) einsetzen.

Wie man mit dem Jabber Client TLS/SSL zur Verschlüsselung und Authentifizierung des Jabber Servers nutzt, wird im Kapitel TLS- und SSL-Verschlüsselung mit dem Jabber Server erklärt.

[ Inhalt | Top | Zurück | Weiter ]