Autor: dentaku

In den letzten Tagen ist viel über die Arroganz derer geschrieben worden, die jetzt Verschlüsselung empfehlen. Das gipfelte in Artikeln wie diesem von Friedemann Karig, der sich dazu versteigt, die Verschlüsselung zu einer der Ursachen der Überwachung zu erklären:

Die Hackerkaste, die jetzt auf Cryptopartys den DJ gibt und sich ganz avantgardistisch und clever vorkommt, leistet der Überwachung indirekt Vorschub, indem sie sich ihr publikumswirksam entzieht. Es ist die ewige Dialektik des Informationswettrennens. Und wenn wir mithecheln, statt “Stopp!” zu rufen, sind wir mit dafür verantwortlich.

Das, mit Verlaub, ist Quark. Verschlüsselung ist, wie Frank Rieger sagt, eher „[…] wie Wohnungstür abschließen. Wäre schön wenn unnötig, leider meistenorts notwendig“

Es waren aber auch vernünftige Argumente zu lesen wie z.B. bei Martin Pittenauer (aka @map):

Das eigentliche Problem: Niemand will die wirklich harte Arbeit machen. Sichere Kommunikation, die intuitiv benutzbar ist. Angefangen bei den Konzepten, bis hin zur UI. Vielleicht sogar transparent. Stattdessen machen wir Vorträge zu GPG, die nur uns helfen uns prometheisch zu fühlen.

Damit hat er mindestens teilweise recht. Und weil irgendwer irgendwo ja mal anfangen muss, versuche ich jetzt mal, die Konzepte hinter der gängigen Mailverschlüsselung zu erklären.

Wie? Was?

Wir wollen eMails verschlüsseln. Das tun wir, weil die sonst in jedem Zwischenschritt vom Betreiber des Servers mitgelesen und auch an andere Leute weitergegeben werden können. Diese Form von Angriffen heißt Man-in-the-middle-attack (aber es gibt noch einige andere Varianten davon), und damit hat der Bösewicht in unserem Szenario einen Namen: MITM.

Zeichensalat

Mailverschlüsselung ist üblicherweise sogenannte asymmetrische Kryptographie. Das bedeutet, dass der Schlüssel aus zwei Komponenten besteht, einen öffentlichen und einen privaten Teil. Die sind jeweils Blöcke von Zeichensalat, mit denen mathematische Operationen durchgeführt werden können (irgendwas mit Primzahlen, aber darum geht es jetzt gar nicht), auf deren Basis zwei Hauptfunktionen zur Verfügung stehen:

• Daten mit dem öffentlichen Schlüssel so verschlüsseln, dass sie mit dem privaten Schlüssel wieder entschlüsselt werden können.
• Mit Daten und dem privaten Schlüssel eine Prüfsumme erzeugen, die mit dem öffentlichen Schlüssel überprüft werden kann, so dass garantiert ist, dass die Daten nicht mehr verändert worden sind. Das ist die sogenannte kryptographische Signatur.

Mit passender Software in meinem Mailprogramm kann ich jetzt, wenn ich den öffentlichen Schlüssel des Empfängers habe, eine Mail schicken, in der der MITM nur Zeichensalat sieht. Außerdem kann ich Mails (verschlüsselte und unverschlüsselte) so verschicken, dass ihr Inhalt nachweislich nicht mehr verändert worden ist, seit sie mit meinem privaten Schlüssel unterschrieben wurden. Wenn der Empfänger auch meinen öffentlichen Schlüssel hat, dann kann er das überprüfen. So weit, so einfach.

Vertrauen und Kontrolle

Einen größeren Knoten im Kopf erzeugt schon der zweite Aspekt: das Vertrauen in die Echtheit der Schlüssel. Die ganze Verschlüsselung ist nämlich komplett nutzlos, wenn es dem MITM gelingt, mir für meinen Kommunikationspartner einen anderen öffentlichen Schlüssel unterzuschieben. Dann kann er nämlich die Nachrichten bei sich entschlüsseln, lesen und mit dem echten Schlüssel wieder verschlüsseln. Das ist dann nur noch so sicher wie De-Mail (SCNR — 😉 ).

Gut, dass wir ja eine Möglichkeit haben, Daten zu unterschreiben. Der öffentliche Schlüssel wird also zur Bestätigung seiner Echtheit einfach mit einem anderen privaten Schlüssel unterschrieben. Dabei gibt es zwei verschiedene Ansätze,  wem dieser private Schlüssel denn gehört. Jedes mit seinen eigenen Vor- und Nachteilen.

Der Zentralistisch-Hierarchischer Ansatz

Die erste Variante arbeitet mit einer Liste von vertrauenswürdigen Zertifizierungsstellen (CA). Die öffentlichen Schlüssel der Zertifizierungsstellen sind auf Euren Rechnern schon hinterlegt, so dass die Identität des Zertifikats sofort überprüft werden kann. Wer (initial) auf die Liste der „Vertrauenswürdigen“ kommt, entscheiden Betriebssystem- und/oder Browserhersteller.

Und genau da liegt auch das Problem: nicht jede dieser Zertifizierungsstellen hat das in sie gesetzte Vertrauen tatsächlich verdient; immer wieder sind besorgniserregende Geschichten zu lesen, und wer mal einen Blick in die Liste wirft, wie sie im Moment z.B. mit Windows ausgeliefert wird, sieht dort Verisign, Microsoft und die Deutsche Telekom (überhaupt die großen Telekommunikationsunternehmen der meisten Technologieländer) friedlich neben Behörden wie dem Finnischen Personenregister (VRK).

Es gibt also allen Grund zu der Annahme, dass staatliche Stellen der verschiedensten Länder keine Probleme hätten, sich für jeden von uns auszugeben.

Zusätzlich verlangen die meisten der CAs eine  jährliche Gebühr dafür, dass sie die Identität überprüfen und bestätigen (es geht aber auch kostenlos).

Diesen Ansatz verfolgt X.509, das für TLS (also z.B. https) und S/MIME verwendet wird. Das ist wiederum sein großer Vorteil, denn S/MIME beherrschen die meisten Mailprogramme, sogar auf Telefonen, ohne Zusatzsoftware.

Das Web Of Trust

Bei der zweiten Variante wird auf zentrale Stellen verzichtet. Stattdessen kann jeder Schlüsselinhaber den Schlüssel eines anderen Schlüsselinhabers unterschreiben, wenn er hinreichend davon überzeugt ist, dass Schlüssel und Identität zusammengehören. Dazu muss über einen zweiten Kanal (der so sicher wie möglich nicht unter der Kontrolle des MITM steht, am besten also ein persönliches Treffen) der sogenannte Fingerabdruck des Schlüssels miteinander verglichen werden. Ist alles in Ordnung, so kann auch ich den Schlüssel unterschreiben und mit meiner Unterschrift öffentlich zur Verfügung stellen.

Sind erst einmal einige der Schlüssel im eigenen Schlüsselbund verifiziert, erlaubt ein einstellbares „Vertrauen“ mit einem Punktesystem, zukünftig auch Schlüssel ohne persönlichen Kontakt automatisch als echt anzuerkennen, wenn sie von genügend vertrauenswürdigen Benutzern verifiziert worden sind.

dentaku@nyx:~$ gpg --list-sigs --fingerprint A8FAE80D
pub   4096R/A8FAE80D 2013-02-17 [expires: 2018-02-16]
      Key fingerprint = 7383 4D64 1725 FB40 B119  F474 5CD7 78E6 A8FA E80D
uid                  Thomas Renger (Dentaku) <dentaku@wazong.de>
sig 3        A8FAE80D 2013-02-17  Thomas Renger (Dentaku) <dentaku@wazong.de>
sig 3        6752A51F 2013-07-11  Sven Schoengarth <sven.schoengarth@gmx.net>
sub   4096R/A0CFC2A5 2013-02-17 [expires: 2018-02-16]
sig          A8FAE80D 2013-02-17  Thomas Renger (Dentaku) <dentaku@wazong.de>

Das ist so kompliziert, wie es klingt, befreit aber von der Pflicht, irgendwelchen unkontrollierbaren Unternehmen und Behörden zu vertrauen (siehe oben).

Diesen Ansatz verfolgt PGP / GnuPG, und er ist auch der Grund für die im Moment zahlreich stattfindenden CryptoPartys.

Und was ist jetzt das Problem?

So, und jetzt ist die Aufgabe, für diese Operationen ein benutzbares User Interface zu bauen. Alles, was mit Kryptographie zu tun hat, ist im Moment nämlich hässlich und benutzerfeindlich. Zum Beweis habe ich hier ein Bild von gestern, auf dem zwei gestandene Nerds ratlos vor GPGTools sitzen (Foto: @baranek):

Da ich aber ein „typischer“ Entwickler bin, muss ich an der Stelle passen. Denn uns darf man das User Interface nie machen lassen, wenn normale Leute damit klar kommen sollen (zur Verdeutlichung: das oben abgebildete Problem habe ich schließlich gelöst, indem ich auf die Kommandozeile ausgewichen bin).