Kategorien
Blog

Kryptographie ist schwierig

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).

Vertrauenswürdig, soso.

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):

Das muss doch, warum geht das, ach...

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).

Von dentaku

Site Reliability Engineer, Internet-Ureinwohner, Infrastrukturbetreiber, halb 23-Nerd halb 42-Nerd, links, gesichtsblind.

Schreibt mit "obwaltendem selbstironischem Blick auf alles Expertentum" (Süddeutsche Zeitung)

8 Antworten auf „Kryptographie ist schwierig“

[…] RT @iblog0711: Kryptographie ist schwierig dentaku.wazong.de/2013/07/12/k…schwierig/ (via @dentaku)  #  Microblog     […]

[…] @piratsimon @ziromr Kommt ruhig vorbei beim Artikel mit dem Bild zum Tweet (gegen Ende): dentaku.wazong.de/2013/07/12/k…schwierig/ // @baranek  #  Microblog     […]

[…] einer Zertifizierungsstelle. Allerdings ist PGP auch im Jahr 22 nur Menschen zu empfehlen, die eine gewisse Leidensfähigkeit mitbringen (kann man das so sagen, Thomas? ). Ein weiterer Nachteil von PGP ist, dass es derzeit nicht auf […]

[…] dem Erklärbärartikel letzte Woche schrieb ich über die Identitätsprüfung im Web Of […]

[…] Das war meine erste Session am Samstag, gehalten von Thomas und Frank. Viele können das Thema Internetsicherheit und NSA vielleicht nicht mehr hören. Ich wollte hier aber mein Fachwissen zum dem Thema auffrischen und die genaue Funktionsweise und Tools kennen lernen. Ich gebe offen zu: Ich verschlüssel meine E-Mails aus Bequemlichkeit nicht. Um verschlüsselt Mails zu verschicken, muss der Nutzer auf einigen Komfort verzichten und ggf. seinen privaten Schlüssel immer auf seinem USB-Stick mitnehmen. Mobil E-Mails zu verschicken kann so schon zu einem echten Krampf werden, wenn man nicht möchte, dass sein privater Schlüssel bei irgendeinem Drittanbieter landet, auf den man keinen Einfluss mehr hat. Und das ist auch das Schwierigste: Der Nutzer muss das schwächste Glied der Kette, wo sein privater Schlüssel abgegriffen werden könnte, erkennen und meiden. Dafür fehlt aus meiner Sicht nach zu vielen das Verständnis und Know-How. Mehr dazu könnt Ihr bei Thomas nachlesen. […]

[…] Daten, um eine sichere und überprüfte Verschlüsselung aufzubauen. Weiterführende Artikel: Kryptographie ist schwierig und Aktion: Zeig mir Deinen Key […]

[…] (d.h. eigentlich war sie das schon vorher aber wir wussten es nicht). Die Inhalte können wir verschlüsseln, aber inzwischen wissen wir, dass die Metadaten für die Überwacher fast genau so interessant […]

[…] Herausgeber sieht gar nicht so vertrauenswürdig aus, wie man sich das wünschen würde (siehe hier). Es gab immer wieder Fälle, in denen sehr neugierige Menschen sich von einer der zwielichtigeren […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert