zur Startseitezur Info-Startseite

verbreitete Irrtümer

  1. Ende-zu-Ende-Verschlüsselung reicht aus

  2. Schlüssellänge – viel hilft viel

  3. Alles soll verschlüsselt werden

  4. Es reicht aus, den öffentlichen Schlüssel zu importieren

  5. Smartcards sind sicher

  6. Gültigkeit vs. Vertrauen

  7. präventiv ein Widerrufszertifikat erzeugen

  8. Fingerprints auf Webseiten

  9. Zusammenhang von Unterschlüsseln und User-IDs

Ende-zu-Ende-Verschlüsselung reicht aus

Ende-zu-Ende-Verschlüsselung (wie OpenPGP) schützt nur dafür, dass die fraglichen Daten einfach (passiv) mitgelesen werden. Die Daten liegen auf dem Absender- und Empfängersystem meist unverschlüsselt vor, auf jeden Fall befinden sich dort die Schlüssel, um sie zu lesen. Wenn die gewissen Leute anfangen, sich für einen zu interessieren, dann wird ungemein wichtig, dass es auf das schwächste Glied in der Kette ankommt, und das ist nicht die Verschlüsselung, sondern das sind die Systeme, die Verschlüsselung nutzen.

Siehe diesen Vorschlag für eine einheitliche Sicherheits-Skala.

Schlüssellänge – viel hilft viel

Es ist nicht immer sinnvoll, Schlüssel so lang wie möglich zu machen. Dafür gibt es mehrere Gründe:

Mehrere technische Organisationen schätzen, dass 2048-Bit-RSA 10+ Jahre sicher ist. Das ist eine konservative Schätzung; gemeint ist nicht, dass danach einzelne(!) Schlüssel dieser Länge problemlos geknackt werden können, sondern dass bis dahin auf keinen Fall Gefahr droht. Unwichtige Schlüssel dieser Länge sind womöglich auch 20 Jahre nach Ablauf dieser Frist noch nicht geknackt. Bei Schlüsseln für normale Aktivitäten sollte man sich bei Unterschlüsseln auf 2048 Bit beschränken.

Auf www.keylength.com gibt es eine Übersicht der Schätzungen unterschiedlicher Quellen.

Auch die GnuPG-FAQ beschäftigt sich mit diesem Thema.

Alles soll verschlüsselt werden

Nicht wenige Leute empfehlen, grundsätzlich alles zu verschlüsseln. Die Verschlüsselung an sich sei schon ein Wert, unanhängig von der Art der jeweiligen Informationen. Diese Empfehlung kommt aber kaum mal von echten Experten; sie ist aus mehreren Gründen fragwürdig und droht den Blick auf die wahren (schwieriger zu lösenden) Probleme zu verstellen. Das gilt jedenfalls für asynchrone, Ende-zu-Ende-Verschlüsselung. Transportverschlüsselung ist selbstverständlich fast ausnahmslos zu begrüßen.

Ein häufiges Argument dafür, alles zu verschlüsseln: So ist nicht gleich ersichtlich, was wichtige verschlüsselte Informationen sind, die dann gezielt angegangen werden können.

Man kann im allgemeinen verschlüsselte Nachrichten nicht "gezielt angehen". Wie soll denn das aussehen? Das wäre nur dann möglich, wenn die Schnüffler z.B. nur die Kapazität hätten, 1% der E-Mails zu entschlüsseln. Die Realität ist aber: Knacken kann sogar die NSA die nicht einmal einzelne Nachrichten. Was sie machen können, ist in die Absender- oder Empfängerrechner einzubrechen, um sich dort die Schlüssel zu holen oder zumindest einzelne Nachrichten dort zu lesen. Und warum sollen sie in einen Rechner einbrechen, von dem aus (oder an den) nur ab und zu verschlüsselt wird, aber nicht, wenn alles verschlüsselt wird? Ergibt das irgendeinen Sinn? Eher nicht. Man darf davon ausgehen, dass Geheimdienste, Polizei usw. sich für bestimmte Leute interessieren, nicht aber für Verschlüsselungsquoten.

In der heutigen (2014) Situation ist es eher so, dass man die Sicherheit der Kommunikation insgesamt reduziert, wenn man alle E-Mails verschlüsselt. Das Sicherheitsproblem entsteht dadurch, dass man vor dem Entschlüsseln nicht weiß, ob etwas wichtig oder dringend ist. Wenn plötzlich auch jede Belanglosigkeit verschlüsselt wird, dann nötigt man die Empfänger, sich auch an weniger sicheren Rechnern (Smartphones; Firmenrechner; Internetcafé) in die Lage zu versetzen, ihre Mails zu lesen. Das reduziert die Sicherheit der Schlüssel, und damit hat man sich dann toll in den Fuß geschossen. Wenn nur Wichtiges verschlüsselt wird, kann man eher darauf hoffen (bzw. mit dem Empfänger explizit vereinbaren), dass er kapiert, dass er das aus gutem Grund auf unsicheren Systemen nicht lesen kann und sich damit abfindet, auf das Lesen der Nachricht warten zu müssen. Man mag diese Problematik in seiner Schlüsselrichtlinie ansprechen.

Damit ohne diese Probleme alles verschlüsselt werden kann, brauchen die Kryptografie-Nutzer eine einheitliche Skala für die Sicherheit von Systemen und mehrere Schlüssel (für dieselben Adressen), jeweils einen für unterschiedliche Sicherheitsniveaus. Dann kann man dem Mailclient beim Senden mitteilen, welches Schutzniveau die Daten haben, so dass er den passendsten Schlüssel des Empfängers heraussuchen kann. siehe diesen Vorschlag

Unabhängig von dem Sicherheitsproblem darf man davon ausgehen, dass nicht wenige Leute genervt sind, wenn sie sogar wertlose Information noch entschlüsseln müssen; vor allem, wenn die dann nicht einmal signiert ist.

Es reicht aus, den öffentlichen Schlüssel zu importieren

Technisch zwingend nötig für den Versand verschlüsselter Nachrichten (oder die Prüfung von Signaturen) ist zwar nur, dass man den öffentlichen Schlüssel (das Zertifikat) des Empfängers importiert, aber ungemein wichtig für das Sicherheitsniveau des ganzen Prozesses ist, dass man den importierten Schlüssel vor der Verwendung auch verifiziert, also dessen Fingerprint mit dem vergleicht, den man sich aus einer sicheren Quelle (nein, das ist keine Webseite) besorgt, also idealerweise durch persönlichen Kontakt (auf Papier), mit Einschränkungen auch telefonisch. Damit man die Verifikation auch erkennen kann, sollte man den Schlüssel anschließend zertifizieren (mit dem eigenen Schlüssel unterschreiben), im Zweifelsfall erst mal nur mit einer lokalen Signatur (lsign, nicht für die Öffentlichkeit).

Wenn man einen Schlüssel aus unsicherer Quelle (Keyserver, Webseite, E-Mail-Anhang) ohne Verifizierung verwendet, dann hat man nur die "Sicherheit", dass man für irgend jemanden verschlüsselt, also niemand außer dem letztlich unbekannten Schlüsselbesitzer die Nachricht lesen kann, bzw. dass irgend jemand eine Nachricht signiert hat. Jeder kann Zertifikate mit beliebigen Namen und E-Mail-Adressen fälschen. Es ist zwar nicht einfach, jemandem einen falschen Schlüssel unterzuschieben, wenn schon ein legitimer existiert, aber gemessen an der Sicherheit von Kryptografie ist es ein Klacks.

Smartcards sind sicher

Smartcards sind kleine Computer, die nur über eine recht einfache Schnittstelle mit der Außenwelt kommunizieren. Insbesondere sind sie – anders als etwa USB-Sticks – keine Speicher, die man nach Belieben auslesen kann. Und anders als bei einem USB-Stick (oder einer Festplatte) kann man sie auch nicht einfach auseinanderbauen, um die Speicherbausteine direkt auszulesen.

Aus Anwendersicht ist der entscheidende Punkt: Man kann Schlüssel in eine Smartcard hineinkopieren, aber nicht heraus. Aus diesem Grund schreibt das Signaturgesetz (de facto) vor, dass die Schlüssel qualifizierter Zertifikate zwingend nur auf Smartcards gespeichert werden dürfen (damit auch der Schlüsselbesitzer nicht rankommt und man die Gewissheit hat: Der Schlüssel ist da, wo die Smartcard ist – und nirgendwo sonst.). Man kopiert den Schlüssel auf die Smartcard, damit sie damit arbeitet. Alternativ könnte man ihn auch auf der Smartcard selber erzeugen.

Ein weiterer wichtiger Aspekt ist, dass es nicht ausreicht, die Hardware zu besitzen. Ähnlich einer Passphrase muss man eine Smartcard durch Eingabe einer PIN freischalten, bevor man sie verwenden kann; entweder einmalig, solange sie mit Strom versorgt wird, oder für jede Operation einzeln. Und da es sich um einen Computer und nicht nur um dummen Speicher handelt, kann man das nicht beliebig oft versuchen (eher so dreimal) – im Gegensatz zu Knackversuchen einer (in Software) verschlüsselten Festplatte.

Das waren die guten Nachrichten. Die schlechte ist: Dass ein Schlüssel nicht geklaut werden kann, ist nicht dasselbe wie, dass er nicht missbraucht werden kann. Letztlich geht es einem ja nicht primär darum, dass niemand den eigenen Schlüssel klaut, sondern darum, dass (a) niemand anderer die für einen verschlüsselten Daten lesen und (b) niemand die eigene (digitale) Unterschrift fälschen kann. Aber für beides muss ein Angreifer den Schlüssel gar nicht klauen: Es reicht völlig, dass er ihn benutzen kann.

Wie so oft ist auch hier die Frage, gegen welche Form von Angriff man sich schützen will. Wenn man eine Smartcard verliert, braucht man sich keine Sorgen zu machen – falls die PIN brauchbar ist. Das gilt aber auch für einen verlorenen USB-Stick, wenn die Passphrase sicher ist. Der typische Fall ist aber, dass der Angreifer Zugriff auf den Rechner hat, auf dem der Schlüssel verwendet wird (z.B. der Rechner, den man bei seinem Arbeitgeber benutzt). In dem Fall ist klar, dass er die Schlüsseldatei einfach kopieren kann, sobald sie den Rechner erreicht. Auch die Tastatureingaben kann er mitlesen. Wie sieht der Fall bei der Smartcard aus? Runterkopieren kann er den Schlüssel nicht, aber er kann die Smartcard, solange sie am Rechner steckt (und benutzt wurde), verwenden, um Daten zu entschlüsseln oder zu signieren. Wenn man keinen Kartenleser mit PIN-Pad verwendet, kann er das sogar in beliebiger Menge tun (die Smartcard entschlüsselt nicht die ganze Datei, sondern – Stichwort hybride Verschlüsselung – nur den session key, also 16 bis 32 Byte). Und wenn man den Kartenleser nicht selber mitgebracht hat... Der wesentliche Unterschied ist, dass im Smartcard-Fall nur diejenigen Daten in Gefahr sind, die dem Angreifer konkret vorliegen. Wenn er dagegen den Schlüssel klaut, kann er auch alle Daten entschlüsseln, auf die er erst später Zugriff bekommt, und alle Daten signieren, die erst später verfügbar werden. Der Missbrauch einer Smartcard ist nicht einmal sicher erkennbar. Die OpenPGP-Smartcard hat einen Zähler für die erstellten Signaturen (dessen Veränderung man bemerken könnte), aber keinen für Entschlüsselungen.

Wenn es hart auf hart kommt, sind "Software-Schlüssel" sogar sicherer als "Hardware-Schlüssel": Wenn der Angreifer eine Million Euro investieren kann, bekommt er wahrscheinlich den Schlüssel aus einer (nur begrenzt aufwendig herstellbaren 10-EUR-)Smartcard heraus. Wenn er aber die Schlüsseldatei klaut und der Schlüssel mit einer 18stelligen Zufallspassphrase gesichert ist (an die der Angreifer nicht herankommt), dann käme er auch mit einer Billion Euro nicht weiter.

Fazit: Eine Smartcard erhöht die Sicherheit, ist aber kein Allheilmittel!

Gültigkeit vs. Vertrauen

Es gibt zwei wichtige Konzepte beim Umgang mit (fremden) Schlüsseln bei OpenPGP, die leider ständig verwechselt werden. Die OpenPGP-Terminologie trägt ihren Teil dazu bei, dass (nicht nur) Neulinge das falsch verstehen. Es geht um die Gültigkeit eines Schlüssels (validity) und das Vertrauen, manchmal verschlimmbessert zu Besitzervertrauen (trust, owner trust). Da es aber auch nicht um den Besitzer geht, sondern nur um den konkreten Schlüssel (man kann und wird oftmals unterschiedliche Schlüssel desselben Besitzers unterschiedlich bewerten), habe ich vorgeschlagen, nur noch von Gültigkeit und Zertifizierungsvertrauen zu sprechen. Der Begriff Vertrauen wird von den meisten Leuten falsch verstanden als: Darauf vertrauen, dass es der richtige Schlüssel ist. Also gerade mit Gültigkeit verwechselt, weil das Problem der Gültigkeit viel eingängiger ist als das Web of Trust.

Jeder kann einen Schlüssel mit beliebigen Nutzerdaten (Name, E-Mail-Adresse, Kommentar) erzeugen; nur den Fingerprint kann man sich nicht aussuchen. Deshalb wäre es fahrlässig, ohne weitere Vorkehrungen einen Schlüssel zu benutzen, den man gerade "irgendwoher" importiert hat. Man muss unterscheiden zwischen Schlüsseln, deren Besitzer unklar ist, und denen, bei denen der Besitzer überprüft wurde. Wenn man weiß (bzw. als hinreichend sicher annimmt), dass es sich bei einem Schlüssel um "den richtigen" handelt, dann ist er gültig. Das hat zur Folge, dass er von den Applikationen ohne Nörgeln akzeptiert wird.

Das Web of Trust funktioniert so: Man vertraut den Zertifizierungen, die ein bestimmter Schlüssel durchführt. Das ist nur dann sinnvoll,

  1. wenn der (Haupt-)Schlüssel ein hohes Sicherheitsniveau hat

    und

    1. man den Schlüsselbesitzer gut kennt und auf diesem Gebiet einschätzen kann

      (Es geht ja nicht darum, ob derjenige ein netter Mensch ist, sondern darum, ob er das Web of Trust richtig verstanden hat, seine Technik unter Kontrolle hat und für die Öffentlichkeit nur belastbare Signaturen erstellt.)

      oder

    2. man andere gute Gründe hat, davon auszugehen, dass diese Person nur belastbare Signaturen erstellt (etwa bei entsprechenden IT-Sicherheits-Experten)

Wenn einem Schlüssel ein positives Zertifizierungsvertrauen zugewiesen wurde und dieser Schlüssel gültig ist, dann kann er (je nach Menge des zugewiesenen Vertrauens) weitere Schlüssel gültig machen oder zumindest dazu beitragen, dass sie gültig werden. Diese beiden Aspekte sind von sehr unterschiedlicher Bedeutung für die Nutzung von OpenPGP:

  1. Gültigkeit ist ein elementarer Bestandteil von OpenPGP. Ohne gültige Schlüssel kann man nicht ernsthaft damit arbeiten. Gültigkeit ist leicht zu verstehen und leicht zu handhaben (man zertifiziert den jeweiligen Schlüssel).

    Die Gültigkeit wird für jede User-ID einzeln bestimmt (weil nie Schlüssel als Ganzes zertifiziert werden, sondern immer nur einzelne User-IDs). Auch wenn das ganze Zertifikat als gültig angesehen wird, sobald es eine seiner User-IDs ist, kann die Verwendung unterschiedlicher Adressen (Empfängeradressen, wenn man selber verschlüsselt; Absenderadresse, wenn man die Signatur einer eingehenden Mail prüft) dazu führen, dass es im einen Fall eine Warnung oder sogar Fehlermeldung gibt, im anderen aber nicht – obwohl exakt derselbe Schlüssel benutzt wird.

  2. Mit Zertifizierungsvertrauen braucht man sich im allgemeinen nicht zu befassen oder auszukennen, um OpenPGP gut nutzen zu können. Das dadurch einbezogene Web of Trust ist deutlich schwieriger zu verstehen und auch schwieriger zu handhaben als die Gültigkeit von Schlüsseln.

    Das Zertifizierungsvertrauen dagegen wird nicht für einzelne User-IDs vergeben, sondern nur für das Zertifikat als Ganzes. Das ergibt sich schon daraus, dass man im allgemeinen nicht sehen kann, für welche User-ID eine Signatur erzeugt wurde.

Und so sieht es in der Konsole aus:

  1. In der Standardeinstellung sieht man gar nichts (gpg --list-keys):

    pub   4096R/1A571DF5 2012-11-04 [verfällt: 2014-11-05]
    uid                  Hauke Laging (Standardadresse) <hauke@laging.de>
    sub   2048R/3F96AD8E 2012-11-04 [verfällt: 2014-11-05]
    sub   2048R/81F06169 2012-11-04 [verfällt: 2014-11-05]
  2. Mit --list-options show-uid-validity taucht dann die Gültigkeit auf:

    pub   4096R/1A571DF5 2012-11-04 [verfällt: 2014-11-05]
    uid       [ uneing.] Hauke Laging (Standardadresse) <hauke@laging.de>
    sub   2048R/3F96AD8E 2012-11-04 [verfällt: 2014-11-05]
    sub   2048R/81F06169 2012-11-04 [verfällt: 2014-11-05]
  3. Und beides bekommt man nur mit z.B. --edit-key zu sehen:

    pub  4096R/0x1A571DF5  erzeugt: 2012-11-04  verfällt: 2014-11-05  Aufruf: SCE 
                           Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
    sub  2048R/0x3F96AD8E  erzeugt: 2012-11-04  verfällt: 2014-11-05  Aufruf: S   
    sub  2048R/0x81F06169  erzeugt: 2012-11-04  verfällt: 2014-11-05  Aufruf: E   
    [ uneing.] (1). Hauke Laging (Standardadresse) <hauke@laging.de>

Die Verwendung derselben Namen für die Abstufungen der beiden Kategorien macht es nicht einfacher.

Auch die alte Wikipedia-Grafik zu dem Thema war fehlerhaft; ich habe die verbessert, nachdem ich vor einer Weile schon den Artikel vielfach korrigiert habe. Die gültigen Schlüssel reichen einen Schritt über die Schlüssel hinaus, denen man (vollständiges) Zertifizierungsvertrauen zuweist (was man schon bei vielen Bekannten nicht tun wird, bei Fremden auf keinen Fall).

präventiv ein Widerrufszertifikat erzeugen

Von vielen Anleitungen – insbesondere von Enigmail im Rahmen der Schlüsselerzeugung – wird empfohlen, dass man direkt nach der Schlüsselerzeugung ein Widerrufszertifikat erzeugt. Dies ist nicht automatisch eine gute Idee; damit sind Vor- und Nachteile verbunden. Die sollte man sich bewusst machen und dann in Abhängigkeit von der konkreten Situation entscheiden, was man macht.

Was ist ein Widerrufszertifikat?

Ein Widerrufszertifikat kann man auch später erzeugen; ein präventives Widerrufszertifikat hat nur dann einen konkreten Nutzen, wenn man entweder den privaten Hauptschlüssel oder die zugehörige Passphrase verliert. Und nicht einmal das ist wirklich schlimm, vor allem wenn der Schlüssel ein Ablaufdatum hat. Wirklich wichtig ist der Widerruf nur dann, wenn der Schlüssel kompromittiert wurde, also jemand Zugriff auf wenigstens einen der privaten Schlüssel bekommen hat; und auch dann braucht man nicht den ganzen Schlüssel zu widerrufen, wenn nur ein Unterschlüssel betroffen ist und man den privaten Hauptschlüssel noch benutzen kann.

Wer meint, ein Widerrufszertifikat sicher verwahren zu können, der sollte auch ein Backup von (geheimem) Schlüssel und Passphrase verwahren können – und dann braucht er kein Widerrufszertifikat. Da ein kompromittierter Schlüssel größeren Schaden anrichtet als ein unerwünscht widerrufener, darf der Schutz des Widerrufszertifikats durchaus geringer sein als der des Offline-Hauptschlüssels, aber er sollte immer noch angemessen hoch sein.

Fingerprints auf Webseiten

Viele Webseiten von OpenPGP-Nutzern enthalten neben dem Link auf das Zertifikat einen Hinweis der Art:

mein Fingerprint: CF51 CB88 7D9A B184 AD50 21F4 DA6B 2836 5A21 B2D0

Fingerprintvergleiche mit Webseiten (insbesondere ohne SSL/TLS) sind natürlich irgendwie albern; vor allem dann, wenn man das Zertifikat (direkt oder indirekt) von derselben Seite heruntergeladen hat. Wenn man den Fingerprint erwähnt, sollte man immer darauf hinweisen (z.B. mit einem Link auf diesen Abschnitt), dass die Leser sich den aus einer sicheren Quelle besorgen müssen, nicht von einer Webseite.

Was eine "sichere Quelle" ist, muss jeder für sich entscheiden (und das durchaus unterschiedlich, je nach den Anforderungen der jeweiligen Situation), denn man selber ist der Leidtragende, wenn diesbezüglich etwas schiefgeht.

Das realistische Optimum ist, den Schlüsselbesitzer persönlich zu treffen und den Fingerprint auf Papier zu bekommen (Visitenkarte oder gesonderte Zettel). Auch wenn man die Identität nicht sicher geprüft hat, weiß man zumindest, dass der Schlüssel demjenigen gehört, den man getroffen hat. In hohem Maß sicher sind auch Fingerprints in gedruckten Publikationen (wie der c’t), weil man sich das Heft irgendwo besorgen (bzw. anschauen) kann, und das auch mehrfach über einen längeren Zeitraum hinweg mit unterschiedlichen Ausgaben. Früher hat man auch noch Telefonanrufe für sicher gehalten; zumindest wenn die Stimme des anderen Bekannt war. Inzwischen würde ich nur noch sagen: Das grenzt den Kreis der möglichen Angreifer stark ein...

Ein sicherer Abgleich des Fingerprints ist oftmals nicht (zeitnah) möglich. Man sollte natürlich trotzdem verschlüsselt kommunizieren. Wichtig ist, dass man sich dessen bewusst bleibt, dass die Sicherheit der Kommunikation erst mal begrenzt ist. Leider unterstützen die Mailprogramme (und sogar die Schlüsselverwaltungsprogramme) einen darin bisher nicht.

Zusammenhang von Unterschlüsseln und User-IDs

Ein Aspekt von Zertifikaten, bei dem fast alle neuen Nutzer durcheinanderkommen, ist der Zusammenhang zwischen Schlüsseln (Haupt- und Unterschlüsseln) auf der einen Seite und User-IDs auf der anderen Seite.

Es besteht – derzeit; man könnte das ändern, um OpenPGP für den Einsatz mit qualifizierten Signaturen fit zu machen – keinerlei Zusammenhang zwischen User-IDs und Unterschlüsseln. Sowohl User-IDs als auch Unterschlüssel sind an den Hauptschlüssel gebunden, und zwar "gleichberechtigt". Es beziehen sich also immer alle User-IDs gleichermaßen auf das gesamte Zertifikat, also auf den Hauptschlüssel und alle Unterschlüssel.

Wenn man ein Zertifikat für die Verschlüsselung einer Nachricht über eine User-ID referenziert (was nicht ungefährlich ist, weil es mehrere Zertifikate mit dieser User-ID geben könnte), dann bestimmt das OpenPGP-System zunächst den zugehörigen Hauptschlüssel und dann den zu verwendenden Schlüssel (Haupt- oder Unterschlüssel).

Wenn für eine Verschlüsselung oder Signatur die zugehörige User-ID angezeigt werden soll, dann wird über die (in die OpenPGP-Nachricht eingetragene) ID des Schlüssels, für den verschlüsselt wurde oder der die Signatur erstellt hat, der zugehörige Hauptschlüssel ermittelt (bzw. festgestellt, dass es sich dabei um einen Hauptschlüssel handelt) und dann die (primäre, alternativ die mit dem neusten Zeitstempel signierte) User-ID dieses Hauptschlüssels angezeigt.

[Hier ist die Seite zu Ende.]