Version 1.1, 21.04.2011 (Signaturdatei dieser Seite, hoffentlich aktuell..., und der CSS-Datei)
Authentifizieren
Bedeutung von Signaturen: technische und organisatorische Maßnahmen
Im folgenden werden viele Möglichkeiten erläutert, wie man mit gpg arbeiten kann. Unerfahrene Nutzer sollten sich nicht vom Umfang und dem technischen Tiefgang abschrecken lassen. Man muss diese Seite nicht verstanden haben, um gpg nutzen zu können. Ich halte es aber für einen guten Überblick der Technologie, sich das hier einmal durchzulesen. An vielen Stellen wird man für sich entscheiden, dass man das jeweilige Feature nicht braucht, aber dann hat man mal davon gehört und ist zudem mit einigen wichtigen Aspekten des Umgangs mit Kryptografie konfrontiert worden. Es ist nichts dagegen zu sagen, dass man erst mal irgendwie mit OpenPGP "rumspielt", um damit vertraut zu werden, und sich das wünschenswerte tiefere Verständnis erst später aneignet. Man sollte dann nur nicht den Fehler machen, dem Schutz der Daten und der Vertrauenswürdigkeit von Daten während dieser Spielphase einen großen Umfang zu attestieren!
Und damit klar ist, was Normalsterbliche für den ersten Überblick gerne überspringen dürfen, stehen die weniger wichtigen Details in Absätzen, die so markiert sind wie dieser.
1991 veröffentlichte der amerikanische Programmierer Phil Zimmermann seine Software Pretty Good Privacy (PGP). Sie wurde von seiner Firma kommerziell vertrieben, war aber für Privatanwender kostenlos nutzbar. Als Alternative wurde 1998 der OpenPGP-Standard verabschiedet und in der FOS-Software GnuPG (Gnu Privacy Guard) implementiert. GnuPG ist die dominante (wenn nicht sogar einzige) Basis für freie und offene OpenPGP-Software.
Installation und Aufruf von gpg macht niemanden zum Experten. Man kann, erst recht per GUI, mit Kryptografiesoftware hantieren, ohne auch nur den blassesten Schimmer davon zu haben, was man gerade macht. Die Software kann Wissensmängel ihres Benutzers nicht ausgleichen und wird das auch nicht zufällig tun.
Es ist auf jeden Fall sinnvoll, sich mit GnuPG zu beschäftigen, aber es ist für ein gutes Ergebnis absolut unerlässlich, dass man sich klar macht, inwieweit man verstanden hat, was man tut. Solange man das nötige Verständnis nicht erworben hat, sollte man sich bewusst machen, dass die in der konkreten Situation gebotene Sicherheit möglicherweise sehr begrenzt ist, und sich nicht darauf verlassen, dass die 4096 Bit Schlüssellänge es schon irgendwie regeln werden. Das tun sie nämlich auf keinen Fall. Auch "kurze" schlüssel sind für die meisten Angreifer unüberwindbar. Selbstüberschätzung wenig qualifizierter Anwender ist dagegen eine Einladung.
GnuPG bzw. gpg/gpg2 (der technische Programmname) ist ein Konsolen-Programm und deshalb aus Sicht der meisten Anwender nicht benutzerfreundlich. Es gibt allerdings einige Programme, die als grafische Oberfläche für gpg fungieren, so dass man sich meist nicht mit dem Eintippen von Befehlen auseinandersetzen muss, sondern die gewünschten Aktionen intuitiv mit der Maus oder einem Menü vornehmen kann. Viele sehr spezielle Funktionen werden allerdings von den grafischen Programmen nicht angeboten. In solchen Fällen muss man gpg direkt aufrufen (in der Konsole/Shell), um das Gewünschte zu erreichen.
Man kann über eine gpg-Konfigurationsdatei (unter Linux: ~/.gnupg/gpg.conf bzw. ~/.gnupg/gpg.conf-2) das Standardverhalten von gpg und Programmen, die es aufrufen, beeinflussen.
GnuPG kann inzwischen nicht mehr nur OpenPGP verwenden, sondern auch das zweite relevante Kryptografieverfahren, S/MIME. Es wird auch von dem grafischen Programm Kleopatra unterstützt, das sowohl für Windows als auch für Linux (usw.) zur Verfügung steht.
Man kann gpg direkt von der GnuPG-Webseite herunterladen. Das ist aber zumeist nicht der beste Weg (Ausnahme: frühe Updates unter Windows).
Unter Linux u.Ä. sollte gpg sowieso installiert sein, alleine schon für die Prüfung der Integrität von Updates. Jede relevante Distribution bietet die Installation und Updates für gpg an.
Für Windows-Anwender ist es am einfachsten, das kostenlose Programm gpg4win zu installieren. Dies ist ein grafisches Installationsprogramm, das gpg und einige (grafische) Zusatzprogramme (Schlüsselverwaltung; Integration in den Windows-Dateimanager) beinhaltet. Außerdem gibt es eine deutsches Onlinehilfe.
wie so ziemlich jede komplexe Software wird auch GnuPG ständig weiterentwickelt, was alleine schon der Entwicklung der Kryptografie geschuldet ist. Das bringt es mit sich, dass nicht alle Funktionen abwärtskompatibel sind. Wenn man die Möglichkeiten einer neuen Version von GnuPG ausreizt, erzeugt man Daten, die die Nutzer alter Versionen oder anderer PGP-Programme nicht verwenden können. Es gibt eine Reihe von Optionen in GnuPG, um die Kompatibilität zu beeinflussen (z.B. --pgp2, --pgp6, --pgp7, --pgp8), aber manche Hürden lassen sich damit nicht umgehen.
In der Praxis ist das kein großes Problem, zumal sowieso die meisten Leute GnuPG einsetzen (und leicht aktualisieren können). Wenn man aus eigenem Antrieb GnuPG benutzt, sollte man eine moderne Konfiguration wählen. Für den seltenen Fall, dass man später mit jemandem korrespondieren will, der engere technische Restriktionen hat, kann man schlimmstenfalls immer noch einen neuen Schlüssel erzeugen. Man tut sich und der Welt aber keinen gefallen, wenn man sich rein präventiv auf den kleinsten gemeinsamen Nenner beschränkt.
Viele grafische OpenPGP-Programme bieten zunächst die Erzeugung eines Schlüsselpaars an, wenn sie beim Start feststellen, dass es noch keins gibt. Die Erzeugung eines Schlüssels ist nichts anderes als die Bestimmung einer geeigneten, sehr großen Zufallszahl. So groß, dass es "unmöglich" ist, sie zu raten oder durch Ausprobieren zu finden, auch wenn man tausende von Computern zusammenschaltet und jahrelang arbeiten lässt.
Darin liegt ein Problem (Sicherheitsrisiko), weil Computer eben nicht dafür geschaffen sind, zufällige Ergebnisse zu produzieren, sondern ganz im Gegenteil deterministisch arbeiten. Computer sind grundsätzlich schlechte Zufallszahlengeneratoren. Nur wenige Computer verfügen über entsprechende Zusatzhardware, die dieses Problem mehr oder weniger beseitigt (wenn man Hardware dafür hat, stellt sich nämlich die Frage, ob sie fehlerfrei funktioniert... :-) ). Deshalb passiert es leicht (vor allem bei langen Schlüsseln), dass man bei der Schlüsselerzeugung aufgefordert wird, irgendwelche Aktivitäten vorzunehmen (Tasten drücken, Maus bewegen), damit der Rechner genügend Entropie ("Zufallsdaten") sammeln kann. Unter Linux kann man sich mit dem Kommando cat /proc/sys/kernel/random/entropy_avail anzeigen lassen, wie groß der Entropiepool des Kernels gerade ist.
Sowohl aus technischen als auch organisatorischen Gründen bestehen OpenPGP-Schlüssel normalerweise aus mehr als einem Schlüssel, typischerweise aus zweien. Der Primärschlüssel ist, man ahnt es schon, der wichtigste. Seine Wichtigkeit resultiert daraus, dass er zwingend in der Lage sein muss und als einziger in der Lage ist, andere Schlüssel (vor allem die eigenen Unterschlüssel) und außerdem Benutzerkennungen (Name, E-Mail-Adresse) zu unterschreiben. Wenn ein OpenPGP-Schlüssel in seiner Gesamtheit identifiziert wird ("der Schlüssel für die E-Mail-Adresse oder Person XY"), bezieht sich dies immer auf den Primärschlüssel (genauer: auf eine an den Primärschlüssel gebundene Benutzerkennung (UID); der Fingerprint identifiziert den Primärschlüssel).
Es ist sinnvoll, einen Schlüssel so zu erzeugen, dass der Primärschlüssel nur zertifizieren (d.h. eigene Unterschlüssel und andere Hauptschlüssel signieren) kann, und diesen nicht auf einem normalen Arbeitsrechner zu speichern (oder ihn zumindest mit einer langen (20 Zufallszeichen bei Groß- und Kleinbuchstaben und Ziffern, so wie ZlpZn5DFYlrULFCh3ywS) Passphrase zu schützen, die im normalen Betrieb nie eingegeben wird, sondern etwa nur dann, wenn man von einem sicheren Medium bootet). Die Motivation dafür und die Vorgehensweise sind hier erklärt.
Die derzeit von GnuPG unterstützten Schlüsseltypen sind RSA, DSA und ElGamal. Für normale Zwecke bestehen keine relevanten Unterschiede zwischen den beiden Verfahren. Der Primärschlüssel kann nur ein DSA- oder RSA-Schlüssel sein. Ich empfehle die Verwendung von RSA-Schlüsseln.
Die gängigen Algorithmen für einen Primärschlüssel sind RSA und DSA. RSA-Schlüssel haben den wesentlichen Vorteil, auf die aktuelle Version der g10-Smartcard kopiert werden zu können. Wenn man den Hauptschlüssel aber sowieso nur in einer sicheren Umgebung verwendet (Booten von CD/DVD) und sicher verwahrt (lange Passphrase, die nur auf sicheren Systeme eingegeben wird), ist das weniger wichtig; dann reicht es, die Unterschlüssel auf der Smartcard zu haben. Man kann also einen DSA-Hauptschlüssel mit RSA-Unterschlüsseln auf einer Smartcard kombinieren. Ob es dafür gute Gründe gibt, ist eine andere Frage...
Die gängige Struktur eines OpenPGP-Schlüssels sieht so aus, dass er einen RSA- oder DSA-Primärschlüssel hat, der Daten (S) und andere Schlüssel (C; nur diese Fähigkeit ist ganz allgemein zwingend) signieren kann (bzw. darf) und eventuell auch zur Authentifizierung (A) verwendet werden kann und der einen Elgamal-Unterschlüssel zum Verschlüsseln (E) hat.
DSA hat bei Verwendung von Schlüsseln bis 1024 Bit den Nachteil, dass Hashwerte nur bis 160 Bit Länge erzeugt werden können. 2048-Bit-DSA-Schlüssel sind aber zu alten Implementierungen nicht kompatibel (und müssen in früheren GnuPG-Versionen erst mit -enable-dsa2 freigeschaltet werden).
Es bestehen große Unterschiede in der Performance von RSA-, DSA- und ElGamal-Operationen. Für Leute, die nur im üblichen Umfang Kryptooperationen durchführen, ist das belanglos. Wenn jemand zigtausende von Signaturen erzeugen oder prüfen muss, mag es relevant werden. RSA verschlüsselt mehr als zehnmal so schnell wie ElGamal, ist beim Entschlüsseln aber etwa 15% langsamer. ElGamal-Nachrichten sind länger als dieselbe Nachricht in RSA-Verschlüsselung. Für die Erzeugung einer Signatur braucht RSA etwa fünfmal so lange wie DSA, aber DSA für die Prüfung einer Signatur etwa 30mal so lange wie RSA. Bei großen Datenmengen pro Signatur sollten sich diese Unterschiede verringern.
Für alle Schlüssel muss die gewünschte Länge angegeben werden. Meist sind dies 1024, 2048 oder 4096 Bit. Für normale Anwendungen reicht 1024 Bit aus; ich empfehle 2048 Bit.
Die Erzeugung eines 2048-Bit-Schlüssels dauert schon merklich lange (ganz abgesehen von dem o.g. Problem, dass normale Rechner gar nicht so viel Entropie besitzen, so dass man am Ende viel scheinbare Sicherheit hat). Bei einem 4096-Bit-Schlüssel dauert nicht nur die Erzeugung ewig, sondern auf langsamen Rechnern auch die Verwendung des Schlüssels lange.
Die g10-Smartcard kann nur RSA-Schlüssel mit einer Länge bis 3072 Bit Länge verwenden. Man sollte längere RSA-(Unter-)Schlüssel (und auch Nicht-RSA-Unterschlüssel) deshalb nur dann erzeugen, wenn man genau weiß, was man tut; also speziell, dass man niemals (für diesen Schlüssel) eine Smartcard verwenden wird.
Der Sicherheitsgewinn bei RSA- und DSA-Schlüsseln durch eine größere Länge ist bescheiden. Die Zukunft der Schlüssel liegt deshalb in neuen Verfahren (eliptische Kurven, ECC), die mit sehr viel kürzeren Schlüsseln auskommen. Man darf die Länge eines RSA-Schlüssels nicht mit der eines symmetrischen Schlüssels verwechseln. Ein symmetrischer 128-Bit-Schlüssel ist nach menschlichem Ermessen nicht zu knacken (das Restrisiko liegt in der fraglichen Zufälligkeit des Schlüssels und der Sicherheit des Verschlüsselungsverfahrens).
Sinnvoll ist eine Beschränkung des Gültigkeitszeitraums für Unterschlüssel. Wenn nur diese ungültig werden, können die Verwender des eigenen Schlüssels sich mit wenig Aufwand den Nachfolgeschlüssel beschaffen.
Man kann (mit dem Konsolen-gpg auch getrennt für Primär- und Unterschlüssel) die maximale Gültigkeit des Schlüssels festlegen. Nach dem Zieldatum verweigern die Programme normalerweise die Verwendung des Schlüssels. Eine endliche Lebensdauer verhindert, dass versehentlich uralte Schlüssel verwendet werden, die vom Eigentümer gar nicht mehr benutzt werden und vielleicht schon kompromittiert sind. Eine kurze Gültigkeit des Primärschlüssels bringt allerdings das Problem mit sich, dass nach entsprechend kurzer Zeit alle Verwender des Schlüssels den Nachfolgeschlüssel erhalten müssen. Wenn dies nicht gelingt, bevor die Gültigkeit abläuft, ist dies mit erneutem Authentifizierungsaufwand verbunden.
Man kann (mit Hilfe des Hauptschlüssels) sogar nachträglich die Gültigkeitszeiträume verändern. Allerdings taucht dann das Problem auf, dass man sich nicht darauf verlassen kann, dass die Verwender des Schlüssels immer die neuste Version haben. Ein Angreifer kann jemandem gezielt die alte Version eines Schlüssels unterschieben, ohne dass derjenige das mit den üblichen Mitteln von GnuPG erkennen kann. Deshalb sollte man dies unterlassen.
Das häufige Wechseln von Unterschlüsseln kann problematisch sein, wenn man für diese Schlüssel eine Smartcard nutzt, weil man dann nicht mehr alle Schlüssel auf einer Karte hat. die Gültigkeitsbegrenzung bietet sich also in erster Linie für Schlüssel an, die ganz normal auf einem PC gespeichert sind, zumal Schlüssel auf einer Smartcard kaum in Gefahr sind, kompromittiert zu werden.
Es können beliebig viele Unterschlüssel angelegt werden, deren Algorithmus (DSA/RSA/Elgamal), Länge und Fähigkeiten (S/A/E) nichts mit dem Primärschlüssel zu tun haben, allerdings begrenzt der Algorithmus des Unterschlüssels dessen Länge und Fähigkeiten (so kann beispielsweise Elgamal nur verschlüsseln).
Es kann sinnvoll sein, mehrere Unterschlüssel für dieselbe Aktion zu haben. Auf diese Weise kann man etwa Kompatibilitätsprobleme umgehen. Wenn ein Kommunikationspartner einen neuen Unterschlüssel nicht verwenden kann, weil seine OpenPGP-Implementierung z.B. den Algorithmus noch nicht kennt, dann muss man auf die Vorteile der neuen Technik nicht verzichten: Man erzeugt einfach zwei Schlüssel, einen davon zu Kompatibilitätszwecken in einer älteren Variante. Man sollte aber den Schlüssel, der bevorzugt verwendet werden soll, als letzten erzeugen, damit GnuPG ihn standardmäßig auswählt. Wenn der für jemanden nicht funktioniert, weicht sein System automatisch auf den anderen aus.
Im allgemeinen spielt die Geschwindigkeit von Kryptografieoperationen keine Rolle (Ausnahmen: beispielsweise massenhafte Verschlüsselung / Signierung; lange Schlüssel auf langsamer Hardware); der Vollständigkeit halber: RSA ist beim Verschlüsseln immens schneller als ElGamal; beim Entschlüsseln ist es geringfügig langsamer. Beim Erstellen von Signaturen RSA drastisch langsamer als DSA, beim Überprüfen aber extrem schneller. Sollte man wirklich mal ein Performanceproblem haben oder befürchten, mag es sinnvoll sein, jeweils beide Arten von Unterschlüsseln zu erzeugen und in relevanten Fällen die jeweils geeigneteren zu verwenden.
Ein abschreckendes Beispiel:
start cmd:> gpg --list-keys 71FDC5CB pub 1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25] uid Test Key (Demo) <test@key.inv> sub 1024D/DE57F59A 2010-02-25 [verfällt: 2010-12-22] sub 1024R/BB8A54D2 2010-02-25 [verfällt: 2011-01-21] sub 512g/801FDB58 2010-02-25 [verfällt: 2010-12-22] sub 1024R/7D2C11A4 2010-02-25 [verfällt: 2011-01-21] sub 1024D/1C0A9017 2010-02-25 [verfällt: 2012-02-25] sub 1024R/027DBA86 2010-02-25 [verfällt: 2013-02-24]
Angezeigt werden Länge (1024 Bit), Typ (DSA), (short) ID (71FDC5CB), Erzeugungs- und Verfallsdatum des Primärschlüssels sowie von sechs unterschiedlichen Unterschlüsseln sowie die einzige UID dieses Schlüssels. Warum es so viele Unterschlüssel sind, zeigt sich bei einem anderen gpg-Aufruf:
start cmd:> gpg --expert --edit-key 71FDC5CB
Geheimer Schlüssel ist vorhanden.
pub 1024D/71FDC5CB erzeugt: 2010-02-25 verfällt: 2011-02-25 Aufruf: C
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024D/DE57F59A erzeugt: 2010-02-25 verfällt: 2010-12-22 Aufruf: S
sub 1024R/BB8A54D2 erzeugt: 2010-02-25 verfällt: 2011-01-21 Aufruf: S
sub 512g/801FDB58 erzeugt: 2010-02-25 verfällt: 2010-12-22 Aufruf: E
sub 1024R/7D2C11A4 erzeugt: 2010-02-25 verfällt: 2011-01-21 Aufruf: E
sub 1024D/1C0A9017 erzeugt: 2010-02-25 verfällt: 2012-02-25 Aufruf: A
sub 1024R/027DBA86 erzeugt: 2010-02-25 verfällt: 2013-02-24 Aufruf: A
[ uneing.] (1). Test Key (Demo) <test@key.inv>
Jeweils zwei Unterschlüssel können Daten signieren, verschlüsseln/entschlüsseln oder authentifizieren. Der Primärschlüssel kann als einziger beglaubigen (C) und auch nur das. Normalerweise hat man nicht so viele Schlüssel gleichzeitig im Einsatz; das dient hier nur Demonstrationszwecken.
Es folgt die Anzeige der Signaturen:
start cmd:> gpg --list-sigs 71FDC5CB pub 1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25] uid Test Key (Demo) <test@key.inv> sig 3 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sig 3 ECCB5814 2010-02-25 Hauke Laging <hauke@laging.de> sub 1024D/DE57F59A 2010-02-25 [verfällt: 2010-12-22] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sub 1024R/BB8A54D2 2010-02-25 [verfällt: 2011-01-21] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sub 512g/801FDB58 2010-02-25 [verfällt: 2010-12-22] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sub 1024R/7D2C11A4 2010-02-25 [verfällt: 2011-01-21] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sub 1024D/1C0A9017 2010-02-25 [verfällt: 2012-02-25] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sub 1024R/027DBA86 2010-02-25 [verfällt: 2013-02-24] sig 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv>
Man sieht, dass die UID und alle Unterschlüssel vom Primärschlüssel beglaubigt sind und dass andere Schlüssel (hier: ECCB5814) nur UIDs beglaubigen. Die 3 hinter sig gibt an, dass die beglaubigende Person die beglaubigte Identität sehr sorgfältig geprüft hat. 2 würde bedeuten, dass er ihn flüchtig geprüft hat, 1, dass er ihn gar nicht geprüft hat, und 0 bzw. keine Anzeige bedeutet, dass die beglaubigende Person keine Angabe dazu macht, wie sorgfältig sie war.
gpg wählt automatisch den (bzw. einen) passenden Unterschlüssel aus. Normalerweise gibt man als Benutzer nur an, welcher Hauptschlüssel verwendet werden soll. Wenn mehrere Schlüssel in Frage kommen, wählt gpg denjenigen aus, der zuletzt erzeugt wurde. Man kann aber auch, was selten benötigt werden sollte, den zu verwendenden Unterschlüssel angeben. Statt des Hauptschlüssels 71FDC5CB
gpg --encrypt --symmetric --recipient 71FDC5CB testdatei.txt
gibt man dann mit Ausrufezeichen die ID des Unterschlüssels an, etwa 801FDB58:
gpg --encrypt --symmetric --recipient 801FDB58! testdatei.txt
Das funktioniert natürlich nicht, wenn man – wie üblich – gpg nicht direkt verwendet, sondern über eine Anwendung (Mailprogramm). Mir ist auch keine Möglichkeit bekannt, das über die Konfiguration von gpg zu regeln. Man kann natürlich immer – auf die harte Tour – den Empfängerschlüssel sichern, alle zu vermeidenden Unterschlüssel löschen, die Aktion durchführen und dann die Unterschlüssel (durch Importieren des vorher exportierten Schlüssels) wiederherstellen. Völlig unabhängig von gpg kann man unter Linux u.Ä. in der Konsole Probleme bei der Verwendung des Ausrufezeichens bekommen (wegen history expansion). Dieses Problem löst man, indem man !
durch \!
ersetzt.
Zu einem Primärschlüssel gehört mindestens eine Benutzerkennung. Diese besteht typischerweise aus dem Namen, der E-Mail-Adresse und eventuell einem Kommentar (z.B., dass es sich vorbildlicherweise um einen Offline-Hauptschlüssel handelt). Man kann nach belieben UIDs hinzufügen und löschen, allerdings muss immer eine erhalten bleiben.
So kann man denselben Schlüssel für mehrere E-Mail-Adressen verwenden: Man trägt einfach alle E-Mail-Adressen als UIDs ein. Das ist bequem und nur dann problematisch, wenn nicht jeder wissen soll, dass alle Adressen zu derselben Person gehören (etwa bei beruflichen und privaten oder solchen, die spamfrei bleiben sollen und deshalb nicht auf Keyservern veröffentlicht werden sollen).
Wenn man alle UIDs löscht (bzw. mit --edit-key und dem Kommando revuid zurückzieht), die ein Kommunikationspartner signiert hat (oder über das web of trust verifizieren kann), dann ist der Schlüssel für ihn mehr oder weniger wertlos. Das sollte man sich deshalb gut überlegen. Vor diesem Hintergrund erscheint es sinnvoll, einem Schlüssel gleich bei der Erzeugung eine UID ohne E-Mail-Adresse zu spendieren, also nur mit dem Namen, denn diese wird man nie zurückziehen, und so bleibt immer eine signierte UID erhalten.
start cmd:> gpg --list-sigs 71FDC5CB pub 1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25] uid Test Key (Demo) <test@key.inv> sig 3 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv> sig 3 ECCB5814 2010-02-25 Hauke Laging <hauke@laging.de> uid Neue UID (nach der Signierung hinzugefügt) <test2@key.inv> sig 3 71FDC5CB 2010-02-25 Test Key (Demo) <test@key.inv>
Zu der ersten UID Test Key (Demo) <test@key.inv> ist nun die UID Neue UID (nach der Signierung hinzugefügt) <test2@key.inv> hinzugekommen. Da dies nach der Signierung durch den anderen Schlüssel ECCB5814 erfolgte, hat nur die alte UID eine Signatur von ECCB5814.
Die hier angezeigten Informationen finden sich (fast alle) auch in der Schlüsselübersicht der grafischen Programme. Diese Zusammenhänge muss man verstehen:
Ein Schlüssel wird über seinen öffentlichen Primärschlüssel identifiziert (bzw. über (den letzten Teil von) dessen Fingerabdruck).
Zu einem Primärschlüssel gehören eine oder mehrere UIDs (Name, E-Mail).
Alle UIDs und alle Unterschlüssel sind von dem Primärschlüssel unterschrieben. Eine UID oder ein Unterschlüssel ohne Signatur (so was kann man regulär gar nicht erzeugen) ist wertlos bzw. sogar ein Hinweis auf Manipulation.
Signaturen von anderen Schlüsseln betreffen immer nur UIDs (genauer: die Kombination aus Primärschlüssel und UID).
Jeder Primär- und Unterschlüssel besteht aus einem öffentlichen und einem privaten Schlüssel. Mit dieser Unterscheidung hat man aber nur selten zu tun, etwa dann, wenn man seine privaten Schlüssel sichern oder auf einem anderen Rechner verfügbar machen will und sie deshalb exportieren muss. gpg verwendet immer automatisch den richtigen der beiden Schlüssel.
Bei der Erzeugung eines Schlüssels wird man nach einer Passphrase gefragt. Diese Bezeichnung anstelle von Passwort soll zum Ausdruck bringen, dass die Eingabe auch Leerzeichen enthalten darf, also aus mehreren Wörtern, etwa einem Satz, bestehen kann. Der Sinn einer Passphrase ist zu verhindern, dass jemand, der die Datei, die den geheimen Schlüssel enthält, in seinen Besitz bringt, den Schlüssel sofort verwenden kann. Die Sicherheit einer Passphrase kann üblicherweise nicht mal im Ansatz mit der Sicherheit von OpenPGP-Schlüsseln mithalten. Eine normale Passphrase ist schnell geknackt. Man sollte also (jedenfalls bei "wertvollen" Schlüsseln) eine lange Zufallsfolge wählen (was man sich eben gerade noch so merken kann). Für selten genutzte Schlüssel kann man auch eine lange Passphrase wählen, die man sich aufschreiben muss. Eine gute Kombination ist eine Passphrase, die man häufig verwendet und dementsprechend nicht vergisst, und eine, die man sich aufschreiben muss.
Für Schlüssel, die man nur auf sicheren Systemen (Knoppix o.Ä.) verwendet, sollte man nicht dieselbe Passphrase verwenden wir für einen Schlüssel, den man auf einem normalen Rechner verwendet. Allgemeiner: Man sollte für einen Offline-Schlüssel nichts als Passphrase verwenden, das man auch auf einem normalen Rechner eingibt.
Alle Teile eines von GnuPG eingelesenen Schlüssels haben dieselbe Passphrase (das ist wohl nicht technisch zwingend, aber eine GnuPG-Limitation). Wenn man dennoch etwa für den Hauptschlüssel eine andere Passphrase nehmen will als für die Unterschlüssel, muss man den Schlüssel in zwei Schlüsselbunden speichern und in einem davon den Hauptschlüssel löschen. Je nachdem, mit welchem Schlüsselbund man GnuPG aufruft, wird die eine oder andere Passphrase benötigt.
Gegen das Knacken der Passphrase kann man sich mit einer hohen Anzahl Iterationen beim passphrase mangling schützen. Diese wird über die Option --s2k-count festgelegt. Der zulässige Wertebereich ist 1024 bis 65011712, der Standardwert ist 65536. --s2k-count 655360 verzehnfacht also den Rechenaufwand zum Knacken einer Passphrase gegenüber der Standardeinstellung. Auf langsamen Systemen mag man mit sehr großen Werten allerdings merkliche Verzögerungen auslösen. Diese Option greift auch dann, wenn man nicht asymmetrisch (also für einen öffentlichen Schlüssel), sondern symmetrisch verschlüsselt, also für Ver- und Entschlüsselung dasselbe Passwort angeben muss.
Man setzt den Wert, indem man ihn konfiguriert (in der Konfigurationsdatei oder per Kommandozeile) und dann die Passphrase "ändert" (mit --edit-key → passwd; kann auch gleich bleiben, muss nur noch mal eingegeben werden). Der Wert wird dann in den Schlüssel geschrieben. Der Schlüssel kann also immer verwendet werden, unabhängig davon, welcher Wert gerade für die gpg-Installation konfiguriert ist, die auf dem Schlüssel zugreift. Es kann aber sein, dass man durch eine Änderung der Passphrase unbeabsichtigt (und unbemerkt) diesen Wert verändert.
Es ist sehr wichtig zu verstehen, warum Schlüssel signiert werden (also was eine Signatur bedeutet und was nicht). Technik löst zumeist nicht von allein alle Probleme des Anwenders. Sie bietet ihm lediglich die Möglichkeit dazu. Um sein Problem zu lösen (und nicht noch zu vergrößern) muss der Anwender die Technik aber noch richtig einsetzen!
Die Motivation dafür, Verschlüsselung zu benutzen, ist typischerweise die, dass nur der beabsichtigte Empfänger die Nachricht lesen kann. Das erreicht man, indem man die Nachricht mit seinem Schlüssel verschlüsselt. Das muss aber auch wirklich der korrekte Schlüssel sein, den sonst wäre ein Dritter in der Lage, die Nachticht zu lesen. Wenn man einen Schlüssel aus einer unsicheren Quelle hat (von einem Schlüsselserver, von einer Webseite, aus einer E-Mail), dann kann der manipuliert sein. Man will etwas an Person A schicken, und Person B ist in der Lage, die Daten zu manipulieren, die man bekommt (durch Manipulation der Verbindung oder der Daten am Ziel). Dann kann B den Schlüssel von A gegen den eigenen austauschen. Man verschlüsselt also unwissentlich an B, der fängt die Nachricht ab, packt sie aus, packt sie für A mit dessen richtigem Schlüssel ein, und weder man selber noch der Empfänger hat eine Chance, die Manipulation zu erkennen. Das nennt man einen Man-in-the-middle-Angriff.
Deshalb ist es ungemein wichtig, dass man die Zuordnung von Schlüsseln zu einer Person oder Organisation gegen Fehler absichert. Das geschieht, indem man sich den Schlüssel oder seinen Fingerabdruck aus einer sicheren Quelle beschafft, oder mit Hilfe einer indirekten Bestätigung. Die gängigsten Möglichkeiten der Überprüfung sind, dass man den Fingerabdruck schriftlich (nichtelektronisch, am besten persönlich) oder telefonisch erhält. Man vergleicht ihn mit dem Fingerabdruck des Schlüssels, den man importiert hat. Wenn der Fingerabdruck stimmt, stimmt auch der Schlüssel.
Das bedeutet aber noch nicht, dass auch alle UIDs korrekt sind. Wer es besonders gut machen will, prüft deshalb auch, ob die E-Mail-Adresse der UID stimmt. Und das für jede UID (mit anderer E-Mail-Adresse) einzeln. Das kann man leicht händisch machen, indem man eine verschlüsselte Nachricht an die jeweilige Adresse schickt, mit jeweils unterschiedlichem Inhalt. Man signiert dann alle UIDs, von deren E-Mail-Adresse man eine Antwort erhalten hat, die das entschlüsselte Zitat enthält.
Das Programm caff (CA – fire and forget
) hat eine elegante Lösung dafür: Es erzeugt für jede UID eine einzelne Signaturdatei, verschlüsselt diese für den signierten Schlüssel und mailt die an die jeweilige Adresse. Wenn der Schlüsselbesitzer auch Zugriff auf die E-Mail-Adresse hat, kann er die Signaturdatei entschlüsseln und importieren.
Signaturen bestätigen nur die Zuordnung eines Schlüssels zu einer Person (oder Organisation). Sie sagen nichts über die Person (z.B. ihre Vertrauenswürdigkeit) aus! Es gibt deshalb keinen Grund, Schlüssel nur deshalb nicht zu signieren, weil man den Besitzer nicht mag.
Indirekte Überprüfung funktioniert so: Man will den Schlüssel von A überprüfen; den von B hat man erfolgreich überprüft. Wenn B den Schlüssel von A signiert hat und man dieser Signatur vertraut (also darauf vertraut, dass B den Schlüssel ordentlich überprüft hat), kann der Schlüssel als überprüft gelten. Wenn man der Überprüfung durch B nur begrenzt vertraut, mag man zufrieden sein, wenn nicht nur B, sondern auch C und D den Schlüssel signiert haben. Das ist keine technische Entscheidung, sondern ein organisatorisches bzw. soziales Problem. Je mehr Signaturen ein Schlüssel hat, desto besser. Bei mehr Signaturen ist die Wahrscheinlichkeit größer, dass ein Benutzer des Schlüssels wenigstens einer davon vertraut, ebenso die, dass er mehrere bekannte Signaturen findet und dem Schlüssel dadurch stärker vertrauen kann.
Die indirekte Überprüfung dient aber nur der Konfiguration der eigenen OpenPGP-Anwendung (damit sie weiß, was sie als Vertrauenswürdig ansehen soll und was nicht). Einen nur indirekt überprüften Schlüssel sollte man nicht signieren, jedenfalls nicht für die Öffentlichkeit (sondern allenfalls lokal).
Das Risiko schlampigen Signierens liegt darin, dass man von anderen dafür "haftbar" gemacht werden kann, wenn auch meist nicht im rechtlichen Sinn. Das Web of Trust lebt davon, dass man den Angaben anderer vertrauen kann. Wenn sich herausstellt, dass jemand Informationen signiert, die falsch sind, werden andere demjenigen das Vertrauen entziehen. Technisch hat das für denjenigen erst mal keine Folgen, weil er ja nur auf verlässliche Signaturen anderer angewiesen ist, nicht aber darauf, dass seine Signaturen für andere von Wert sind.
Natürlich kann dieser Vertrauensverlust auch außerhalb der OpenPGP-Welt Folgen haben. Um solchen Ärger zu vermeiden, bietet es sich an, andere nicht im Unklaren darüber zu lassen, was die eigenen Signaturen zu bedeuten haben (policy URL).
Es gibt Situationen, in denen man einen Schlüssel zertifizieren will, ohne dass man ihn hinreichend überprüfen konnte. gpg meckert, wenn man nichtzertifizierte Schlüssen für Verschlüsselung verwendet oder deren Signaturen prüft. Das möchte man womöglich vermeiden. Es wäre nun sehr ärgertlich, wenn diese Signatur in die freie Wildbahn käme, weil Dritte nicht wüssten, dass das "keine echte" Signatur ist (auch wenn man --ask-cert-level auf 1 setzen könnte). Außerdem mag es sein, dass (auch bei richtiger Prüfung) Dritte nicht wissen sollen, dass man den Schlüssel signiert hat (und ihn vermutlich benutzt).
In solchen Situationen kann man eine lokale Signatur erzeugen. Solche Signaturen werden nicht exportiert (und auch nicht ohne Verrenkungen importiert). Dies erreicht man mit der Option --lsign-key oder dem Kommando lsign (statt sign) im Menü von --edit-key.
start cmd:>gpg --fingerprint 71FDC5CB pub 1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25] Schl.-Fingerabdruck = A92E 91A9 5526 AB4C 7B80 3B11 E47D A993 71FD C5CB
Relevant ist üblicherweise nur der Fingerabdruck des Primärschlüssels. Es handelt sich dabei um einen SHA-1-Hash; die 40 Zeichen entsprechen einer Hashlänge von 160 Bit (10^48). Die letzten acht Zeichen ergeben die short ID des Schlüssels, die letzten 16 die long ID.
Es ist hilfreich, den eigenen Fingerprint immer ausgedruckt auf ein paar kleinen Zetteln dabei zu haben. Papier erlebt in der High-Tech-Welt eine ungeahnte Renaissance... So können Leute, die man getroffen hat, sich später den Schlüssel aus unsicherer Quelle besorgen, aber ihn verifizieren.
Hauke Laging
hauke@laging.de
D44C 6A5B 71B0 427C CED3
025C BD7D 6D27 ECCB 5814
Man kann allerlei ergänzende Angaben machen, wenn man einen Schlüssel signiert. Die häufigste dürfte sein, wie gründlich man den Schlüssel geprüft hat (--ask-cert-level). Möglich sind die Angaben 0 (keine Angabe), 1 (keine Prüfung), 2 (flüchtige Prüfung) und 3 (sehr sorgfältige Prüfung). Das Ergebnis indirekter Prüfungen kann man davon abhängig machen, was die anderen diesbezüglich angegeben haben. Man kann auch die Gültigkeit der Signatur zeitlich begrenzen (--ask-cert-expire) und eine URL hinzufügen (mit --cert-policy-url URL, sinnvollerweise in der Konfigurationsdatei), unter der man Angaben dazu macht, wie man Schlüssel prüft, bevor man sie selber signiert, damit Dritte sich ein besseres Bild davon machen können, welchen Wert die eigenen Signaturen haben.
Für das Erzeugen einer Signatur benötigt man den eigenen privaten Schlüssel, wird also nach der Passphrase gefragt.
start cmd:> gpg --local-user ECCB5814 --ask-cert-level --ask-cert-expire --edit-key 71FDC5CB [...]
Man muss in dem Menü, das von --edit-key erzeugt wird, das Kommando sign eingeben. --local-user ECCB5814 gibt an, welcher eigene Schlüssel verwendet werden soll, um die Signatur zu erzeugen. Man kann in der Konfigurationsdatei allerdings einen Standardschlüssel definieren.
Für Spezialfälle gibt es Variationen: lsign, tsign, nrsign. Durch die Optionen --ask-cert-level und --ask-cert-expire wird man nach dem Prüfungsablauf und der Gültigkeitsdauer der Signatur gefragt. Wenn man das nicht benötigt, lässt man sie weg. Manche grafischen Oberflächen für gpg fragen das entweder nicht ab oder tragen die Antwort nicht in die Signatur ein. In dem Fall bleibt einem dann womöglich nur der Weg über die Kommandozeile.
Man kann problemlos Signaturen erneuern. Das bietet sich an, wenn man die Zuordnung des Schlüssels zur Person erst nur oberflächlich und später gründlich geprüft hat oder wenn man eine policy URL ergänzen will. Es ist zudem quasi unvermeidbar, wenn man die Gültigkeit der Signatur beschränkt hat. Leider lässt GnuPG eine Signatur nicht zu, wenn bereits eine besteht. Das lässt sich aber ganz einfach dadurch lösen, dass man vor der Signierung die alte Signatur löscht (--edit-key, dann delsig) oder zurückzieht (--edit-key, dann revsig). Wenn man die alte Signatur behalten will, kann man vorher den Schlüssel exportieren und hinterher importieren. GnuPG stört sich nicht an mehreren vorhandenen Signaturen; es verwendet immer die neuste.
Zumeist verschlüsselt man E-Mails; das erledigt dann der Mailclient für einen; mit gpg hat man da nicht zu tun. Man wählt ggf. aus, dass diese Mail verschlüsselt werden soll, eventuell noch den zu verwendenden Schlüssel (den der Mailclient typischerweise anhand der Empfängeradresse(n) auswählt, und das war’s auch schon. Bei guten Mailprogrammen kann man für den Body der Mail und alle Attachments einzeln angeben, ob der jeweilige Teil verschlüsselt werden soll.
Neben E-Mails kann man aber auch Dateien und sonstige Datenströme (z.B. Text) verschlüsseln. Dabei kann man eine Reihe interessanter Optionen nutzen. Neben der üblichen, asymmetrischen Verschlüsselung (mit dem öffentlichen Schlüssel des Empfängers) kann man Daten auch mit einem Passwort verschlüsseln ("symmetrisch") und sogar beides zusammen:
start cmd:> gpg --encrypt --symmetric --recipient 71FDC5CB testdatei.txt [...]
Dieser Aufruf fragt die Verschlüsselungspassphrase ab und erzeugt eine Datei testdatei.txt.gpg, die man sowohl alleine mit der Passphrase als auch alleine mit dem privaten Schlüssel von 71FDC5CB entschlüsseln kann. Durch mehrfache Verwendung von --recipient kann die Datei für mehrere Empfänger verschlüsselt werden (sie wird dadurch kaum größer, siehe Abschnitt technische Details). Es ist oftmals sinnvoll, eine Nachricht auch für sich selber zu verschlüsseln. Das kann man in der Konfigurationsdatei mit den Optionen encrypt-to und hidden-encrypt-to und der Angabe der eigenen Schlüssel-ID einstellen. Für einen einzelnen Aufruf nimmt man ganz normal --recipient.
Die Option --armor sorgt dafür, dass die verschlüsselte Datei (fast) nur auch alphanumerischen Zeichen besteht. So kann man verschlüsselte Daten auch über Medien transportieren, die dafür nicht gedacht sind, etwa Chatprogramme oder Webseiten:
echo "$kompromittierende_aussage" | gpg --armor --encrypt --sign
-----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.15 (GNU/Linux) hQEMA44903pRsnn6AQgAsac1BympF9+mLFGKshbWWawVKQucT+8LSHejFBdd5Tco tN6Om3/e8gDXaze+CocMJ8/S5Seli1s6a5aamW2J+QW8w4kMU87+cdfGTQ3QRoge 6r08rCMzAYLq8AcO/fegpDVm6wTl9WPnjmNmEFcTeshVbFzxUbsaIFtFciD/nopV GDhZW6111V+TafAHkvpwdwxFMMLIQpl/xe06wZTip/zJWVCSSpnYupQ4OzsFABvL 9GFGBXegXKTOBKcGpywO6hO9t51Q6JLuK+Gug/2Sd2D9G2kuWep+cnRX4D7KGa3n P57XYzzk+Fk3JXug33aed8Nj19DnAUkS9TKm2+3fotLBAwH8TzR/jn914jkb7tfj AfS3J/UIb7Q9Yr53BBQlR1v1LV8xpeYxlBNoFbD1XHrj0Iucpru6seTmxZJjnhml l60DEFqt0RPwWIoApmZo5hgicwJHJP/JsNTU2tDjfxGc2uUnuHpr9Yg0D/KjO6+z /fKTY/WK0OJ0fGq2h36LOY0/H8KQ7bo2VoyPuOxZGZ/WVYLtPSP3aX7oPELWsGeP yQRELtCqN/ak/yvTONwUCaXm+Np+Zj+jX3SgcUPNHb9OHfQ9YnPIcd/WvVhUuKWz a6TqRR+3LtgCkdMl37Aif2p5zcQYIgz3BIh153Cfm9oLQueseZWW/BIjWXqqHR9h p6B8YE2ULnEsLtrjRd/nN11dBNQLW5mX5/a/Cae3in8cGnU9Jni1BIJbYLDJDGKM wXy0COhvISRJ7Req81eUgapgHbEjeIheMhImLP3lOdTBJXx7B/isOEcOfyWBwUO0 6+vv6zxWMTB0TuUxMDPCgYjZyPFIuw4C0yJ1AcE49lg2Vj1J4yw0gZzDMdepBwDj +D4PT7djKGrGTKkP+24Od/0TkSayH6NVCEv6+ia5aSwZIFHSvFah6iP73NxQuFic HGvGAgI= =GKpQ -----END PGP MESSAGE-----
Ganz heikel, aber das sollte außer mir niemand lesen können... ;-)
Es wird nicht die ganze Nachricht asymmetrisch verschlüsselt; das wäre viel zu aufwendig. Für jede Nachricht wird ein zufälliger Schlüssel ermittelt, mit dem die Nachricht symmetrisch verschlüsselt wird. Nur dieser Einmalschlüssel wird asymmetrisch verschlüsselt. Deshalb kann man eine Nachricht auch mehrfach verschlüsseln: Der Zufallsschlüssel wird für jeden Empfänger verschlüsselt, und alle diese verschlüsselten Varianten werden in die Containerdatei geschrieben.
start cmd:> gpg --encrypt --cipher-algo AES192 --recipient 71FDC5CB --output test.html.AES192.gpg test.html start cmd:> gpg --encrypt --cipher-algo AES256 --recipient 71FDC5CB --output test.html.AES256.gpg test.html start cmd:> gpg --decrypt --show-session-key --output /dev/null test.html.AES192.gpg [...] gpg: session key: `8:6B56B66C5765209B279FA95ED23485BF22A4CF84082A7132' start cmd:> gpg --decrypt --show-session-key --output /dev/null test.html.AES256.gpg [...] gpg: session key: `9:7E4C85F5D7805467FA2D05B4CECC9BD11144E20A836AE9BFA6416AAFD689461C'
Hier wurde die Datei test.html mit zwei unterschiedlichen Algorithmen (die unterschiedlich lange Schlüssel verwenden) verschlüsselt. Beim Entschlüsseln mit der Option --show-session-key wird der symmetrische Schlüssel angezeigt. Wegen der unterschiedlichen Algorithmen sind die beiden Zufallsschlüssel unterschiedlich lang. Das --output /dev/null sorgt dafür, dass die zum Testen uninteressanten Ausgabedaten weggeworfen werden (nicht über einen gpg-, sondern einen Linux-Mechanismus).
Wenn man nicht möchte, dass ersichtlich ist, für wen (also für welchen Schlüssel) Daten verschlüsselt wurden, kann man sich der Optionen --hidden-recipient (zur Verschleierung einzelner Empfänger) und --throw-keyids (aller Empfänger) bedienen. Der Empfänger muss dann alle seine geheimen Schlüssel ausprobieren (das macht gpg automatisch). automatisch).
gpg schreibt zwar nur die ID des Empfängerschlüssels in den Header der verschlüsselten Nachricht, es ist aber oftmals möglich, (z.B. über Keyserver) herauszufinden, welche E-Mail-Adresse zu dieser ID gehört.
Auch Signaturen betreffen zumeist E-Mails und sind dann komfortabel vom Benutzer abgeschirmt.
Wenn man mit gpg (oder einem GUI) normale Dateien (oder Datenströme) signiert, muss man wissen, dass es unterschiedliche Arten gibt, eine Signatur zu speichern (und natürlich auch unterschiedliche Arten von Signaturen):
integrierte (Daten und Signatur in derselben neu erzeugten Datei) und abgetrennte Signatur
binäre Signatur, Klartextsignatur, ASCII-Verpackung
Eine Signatur ist ein Hashwert der zu signierenden Daten, der mit dem privaten Schlüssel so verrechnet wird, dass mit Hilfe des öffentlichen Schlüssels nachgewiesen werden kann, dass der zugehörige Private Schlüssel die Signatur erzeugt hat. Eine Signatur ist deshalb nur so sicher wie der verwendete Hash. Wenn für den Hashwert eine Kollision erzeugt werden kann, rettet einen der längste PGP-Schlüssel nicht. gpg unterstützt eine Menge Hashfunktionen, allerdings kann es beim Einsatz der OpenPGP-Smartcard zu Problemen kommen. SHA-1 (aktuelle Standardeinstellung) ist derzeit sicher und funktioniert mit der Smartcard. Die Hash-Auswahl kann man mit der Option personal-digest-preferences steuern.
Man kann Daten und Signatur in dieselbe Datei schreiben. Das passiert bei Verwendung der Kommandos --sign. Wenn man die zu signierenden Daten als unveränderte Datei behalten will (ohne eine neue vergleichbar große Datei) oder mehrere Dateien auf einmal signieren will, verwendet man --detach-sign (kann mit --encrypt kombiniert werden; aber eine Signatur muss man normalerweise nicht verschlüsseln). Wenn man auf diese Weise mehrere Dateien signiert, dann kann man die Signatur auch nur über alle Dateien gleichzeitig (und in derselben Reihenfolge) prüfen!
Erzeugen einer signierten Datei test.html.gpg, die die Daten von test.html enthält:
start cmd:> l test* -rw-r--r-- 1 hl hauke 18 11. Jun 02:09 test2.html -rw-r--r-- 1 hl hauke 810 11. Jun 02:09 test.html ec:0 02:09:52 hl@inno:~/tmp start cmd:> gpg --sign test.html Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren. Benutzer: "Hauke Laging <hauke@laging.de>" 2048-Bit RSA Schlüssel, ID 0x3A403251, erzeugt 2010-03-04 (Hauptschlüssel-ID 0xECCB5814) ec:0 02:10:23 hl@inno:~/tmp start cmd:> l test* -rw-r--r-- 1 hl hauke 18 11. Jun 02:09 test2.html -rw-r--r-- 1 hl hauke 810 11. Jun 02:09 test.html -rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg
Erzeugen einer Datei test.html.sig, die nur die Signatur von test.html enthält (also ohne die Bezugsdatei wertlos ist). Anschließend Überprüfung der Signatur.
start cmd:> gpg --detach-sign test.html [...] ec:0 02:11:02 hl@inno:~/tmp start cmd:> l test* -rw-r--r-- 1 hl hauke 18 11. Jun 02:09 test2.html -rw-r--r-- 1 hl hauke 810 11. Jun 02:09 test.html -rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg -rw-r--r-- 1 hl hauke 335 11. Jun 02:11 test.html.sig ec:0 02:11:04 hl@inno:~/tmp start cmd:> gpg test.html.sig gpg: Signatur vom Fr 11 Jun 2010 02:11:01 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
Erzeugen einer gemeinsamen Signaturdatei test.html.all.sig für die beiden Dateien test.html und test2.html. Überprüfung scheitert, wenn nicht beide angegeben werden:
start cmd:> gpg --detach-sign --output test.html.all.sig test.html test2.html [...] ec:0 02:11:50 hl@inno:~/tmp start cmd:> l test* -rw-r--r-- 1 hl hauke 18 11. Jun 02:09 test2.html -rw-r--r-- 1 hl hauke 810 11. Jun 02:09 test.html -rw-r--r-- 1 hl hauke 335 11. Jun 02:11 test.html.all.sig -rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg -rw-r--r-- 1 hl hauke 335 11. Jun 02:11 test.html.sig ec:1 02:12:37 hl@inno:~/tmp start cmd:> gpg --verify test.html.all.sig test.html gpg: Signatur vom Fr 11 Jun 2010 02:11:50 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: FALSCHE Signatur von "Hauke Laging <hauke@laging.de>" ec:2 02:12:44 hl@inno:~/tmp start cmd:> gpg --verify test.html.all.sig test.html test2.html gpg: Signatur vom Fr 11 Jun 2010 02:11:50 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
Signierte Dateien kann man nur dann verwenden, wenn die Zielapplikation weiß, was das ist (z.B. ein PGP-fähiger Mailclient). Abgetrennte Signaturen lassen sich dagegen immer problemlos verwenden. Auf diese Weise kann man beispielsweise Webseiten signieren. Mit dem Ergebnis von --sign und --clearsign kann ein Browser nichts anfangen, aber man kann eine angetrennte Signatur erzeugen und verlinken. Man speichert dann die Webseite (als z.B. openpgp.html) und die Signatur (als z.B. openpgp.html.sig) und prüft dann die Gültigkeit der Signatur.
--sign erzeugt eine "binäre" Signatur, also eine Datei, die sowohl die Nutzdaten als auch die Signatur enthält und die man nicht problemlos mit einem normalen Editor lesen kann (weil sie – jedenfalls im Signaturteil – nichtdruckbare Zeichen enthält). Wenn man die Signatur prüfen will, muss man die gesamten Daten auspacken. --clearsign eignet sich für Textdateien (und Ausschnitte davon). Das Ergebnis kann normal mit einem Editor gelesen werden:
echo hello world | gpg --clearsign
oder mit einer Datei, die den Text, also hier "hello world" enthält:
gpg --clearsign hello_world.txt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello world -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQFMBAEBAgA2BQJMEXtrLxpodHRwOi8vd3d3LmhhdWtlLWxhZ2luZy5kZS9vcGVu cGdwL3BvbGljeS5odG1sAAoJEFug+LU6QDJRiggH/2j23/ZzIOEoqjMWrcMbsI8/ Kfr7ikjIgrb1NfD+vVeDe7txQaDDN+/qKl18gPwNR4fjpVdg4gEmarFZ31R9bCJC i1VtFTbRIdV5OXDpQ+vqYkG8x6AP6kOyUY6bEec8HKLD2M2FbBPgMjUMZ/d1hGlS +ps5Pz1CutS1QsHn5lnRltvxsf8Fez3oJs811kq49gOd3YFkJycCGXBkRHM0OQcF 0NVwUSxDGKOlbQCDsCSPeTQo119MrC5u2bqs6svWQTiregHzUWsW93VA/fhZnX6j 956GMxoj4o6zDK8ZXbrClBBhywdwxcSxm8CGqFvGJQAggmYLpuBonsVTH6SWM1E= =HCbr -----END PGP SIGNATURE-----
Bei dem Kommandoaufruf habe ich --local-user ECCB5814 weglassen können, weil diese ID in der Konfigurationsdatei ~/.gnupg/gpg.conf-2 mit der Option default-key als Standard festgelegt ist. Dasselbe gilt für --recipient und encrypt-to.
Es gibt auch Editoren mit GnuPG-Unterstützung. Bei denen erstellt man einfach den zu signierenden (oder zu verschlüsselnden) Text und ruft dann die entsprechende Funktion auf. Man erhält dann das Ergebnis im Editorfenster. gpa (Gnu Privacy Assistant) und kgpg (Linux/kde) haben einen eigenen Editor. Kleopatra bietet die Funktion über den Umweg der Bearbeitung der Zwischenanlage.
Man kann für eine Datei Signaturen mehrerer Schlüssel erzeugen und gemeinsam abspeichern. Das kann man einerseits erreichen, indem --local-user mehrfach angegeben wird, und andererseits, indem mehrere Signaturdateien zusammenkopiert werden (das funktioniert sowohl bei Textsignaturen als auch bei binären).
start cmd:> cat test.html.1.sig test.html.2.sig > test.html.beide.sig ec:0 02:06:10 hl@inno:~/tmp start cmd:> gpg --verify test.html.beide.sig test.html gpg: Signatur vom Fr 23 Jul 2010 02:01:45 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>" gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html gpg: Signatur vom Fr 23 Jul 2010 02:01:45 CEST gpg: mittels RSA-Schlüssel 0xBB8A54D2 gpg: Korrekte Signatur von "Test Key (Demo) <test@key.inv>" gpg: alias "Neue UID (nach der Signierung hinzugefügt) <test2@key.inv>" gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html
Prinzipiell kann man Daten sowohl erst signieren und dann verschlüsseln als auch erst verschlüsseln und dann signieren. gpg unterstützt aber nur den ersten Weg direkt. Auf diese Weise wird nicht enthüllt, wer die Daten signiert hat. Das mag in speziellen Fällen relevant sein. Für Virenscanner ist es dagegen ein Alptraum. Wenn man verschlüsselte Daten signieren möchte, muss man gpg zweimal aufrufen, erst für die Verschlüsselung und dann zur Signierung der verschlüsselten Datei:
start cmd:> gpg --sign test.html.gpg ec:130 02:54:02 hl@inno:~/tmp start cmd:> gpg --output /dev/null test.html.gpg.gpg gpg: Signatur vom Fr 11 Jun 2010 02:53:49 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
Das --output /dev/null unterdrückt die Ausgabe der Daten.
Beim Prüfen einer Signatur prüft man eigentlich gleich zwei Dinge:
Passt die Signatur zu den Daten?
Wird dem Schlüssel vertraut?
Eine korrekte Signatur eines nicht verifizierten Schlüssels sollte man im allgemeinen als wertlos betrachten.
start cmd:> gpg --verify test.html.ECCB5814.sig test.html gpg: Signatur vom Mo 21 Jun 2010 22:43:21 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>" gpg: alias "Hauke Laging <mailinglisten@hauke-laging.de>" gpg: alias "Hauke Laging <mail@hauke-laging.de>" gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html
Es gibt zwei Möglichkeiten für technische Fehler bei der Signaturprüfung:
Die Signatur selber kann beschädigt worden sein. GnuPG erkennt dies:
start cmd:> gpg --verify test.html.ECCB5814mod.sig test.html gpg: Prüfsummenfehler; 5d4714 - 2e894d gpg: Keine Signatur gefunden gpg: Die Signatur konnte nicht überprüft werden.
Die Daten können beschädigt worden sein (bzw. Daten und Signatur falsch kombiniert worden sein):
start cmd:> gpg --verify test.html.ECCB5814.sig test.mod.html gpg: Signatur vom Mo 21 Jun 2010 22:43:21 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: FALSCHE Signatur von "Hauke Laging <hauke@laging.de>"
Es liegt in der Natur von kryptografischen Hashwerten, dass es unmöglich ist zu sagen, ob es sich um eine komplett falsche Datei handelt oder z.B. in einer Textdatei nur ein Leerzeichen ergänzt wurde.
Damit überprüft werden kann, ob eine Signatur korrekt ist, wird der öffentliche Schlüssel benötigt:
start cmd:> gpg --verify test.html.0CBF5012.sig test.html gpg: Signatur vom Do 26 Mai 2011 20:05:09 CEST gpg: mittels DSA-Schlüssel 0x0CBF5012 gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
Wenn die Signatur korrekt ist, kann immer noch der Schlüssel unverifiziert sein:
start cmd:> gpg --verify test.html.0CBF5012.sig test.html gpg: Signatur vom Do 26 Mai 2011 20:05:09 CEST gpg: mittels DSA-Schlüssel 0x0CBF5012 gpg: Korrekte Signatur von "testkey gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur! gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört. Haupt-Fingerabdruck = 1B52 3527 31F9 417D 5CBB 42F5 FEA6 4E07 0CBF 5012
Wie die diese Meldung loswerden, steht im Abschnitt über Schlüsselbeglaubigung.
Den folgenden Optionen begegnet man kaum einmal, aber auch sie haben ihren Sinn.
Eine digitale Signatur ist zunächst mal nur ein technischer Wert, dessen eindeutiger Aussagegehalt sich darauf beschränkt, dass der Signierende im Besitz des privaten Schlüssels und der signierten Daten (ganz genau: zumindest ihres Hashwerts) war. Auch wenn man unterstellt, dass der Signierende der legitime Besitzer des Schlüssels war, weiß man noch nicht, was diese Signatur zu bedeuten hat; vielleicht wollte der Signierer die Datei bloß gegen unerkannte Veränderungen sichern oder (für jemand anderen) bestätigen, dass sie zu einem bestimmten Zeitpunkt existiert hat. Man kann zweierlei tun, um dem Prüfer einer Signatur deren Interpretation zu erleichtern: Man kann die Information in eine zweite Datei packen und dann die Daten und diese Hilfsdatei gemeinsam signieren (die können dann auch nur gemeinsam geprüft werden, siehe die Signaturbeispiele oben). Die andere Möglichkeit, die sich vor allem für allgemein gültige Hinweise (wie bei der Zertifizierung von Schlüsseln) eignet, ist ein (Online-)Dokument, auf dessen URL von der Signatur aus verwiesen wird. Sinnvoll ist das natürlich nur, wenn das Dokument selber signiert ist. Bei Webseiten kann man das mit einem Link auf die abgretrennte Signatur (--detach-sign) der Datei realisieren.
Eine policy URL wird der Signatur mittels der Option --sig-policy-url URL angefügt. Die kann man sich, wenn alle Signaturen so einen Hinweis erhalten sollen, in die Konfigurationsdatei schreiben. Wenn man dieselbe URL für Schlüsselzertifizierungen und Datensignaturen verwendet, kann man statt --cert-policy-url und --sig-policy-url auch --set-policy-url verwenden.
Man kann, in speziellen Fällen mag das sinnvoll sein, eine Signatur mit einem Ablaufdatum versehen, etwa für eine Art Ausweis (dann muss das Ablaufdatum nicht in den signierten Daten untergebracht werden) oder Signaturen, die regelmäßig erneuert werden sollen. Dies geht mit der Option --ask-sig-expire. Die gewünschte Gültigkeitsdauer wird dann von gpg abgefragt.
start cmd:> gpg --ask-sig-expire --detach-sign --local-user eccb5814 test.html [...] start cmd:> gpg --verify test.html.sig test.html gpg: Signatur vom Fr 23 Jul 2010 01:23:00 CEST gpg: mittels RSA-Schlüssel 0x3A403251 gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>" gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html gpg: Diese Signatur verfällt am Mo 02 Aug 2010 01:23:00 CEST.
Man kann über die Option --sig-notation quasi beliebige Zusatzinformationen in einer Signatur unterbringen. Da ich dies bisher nicht gemacht habe, kann ich das nur der Vollständigkeit halber als Hinweis erwähnen, ohne darauf weiter einzugehen.
Schlüssel ziehen genauso wie Passwörter ihren Wert daraus, dass sie den bösen Jungs nicht bekannt sind. Dafür, dass sich das nicht ändert, sollte man sorgen. Das große Problem ist, dass wir unseren Rechnern nicht vertrauen können. Für alle relevanten Betriebssysteme und Internet-Anwendungen werden ständig Sicherheitslücken gefunden (und gestopft). Man kann nie sicher sein, dass ein normaler Rechner nicht gerade von Schadsoftware kompromittiert ist. Schadsoftware hat unter normalen Umständen alle Rechte des Benutzers, sie kann also alle Dateien lesen, auf die der Benutzer Zugriff hat. Spätestens wenn es dieser Schadsoftware gelingt, durch Ausnutzen von Sicherheitslücken in privilegierter Software (Kernel, grafische Oberfläche, Systemdämonen) höhere Rechte zu erlangen, dann kann sie im Regelfall auch Tastatureingaben mitlesen. Es kann also jederzeit passieren, dass der eigene Schlüssel samt Passphrase in die Hände eines Angreifers gelangt.
Auch wenn Schlüssel kompromittiert werden können, sind sie nützlich, denn meistens sind sie nicht kompromittiert. Gehen wir einfach mal davon aus. :-) Das liegt natürlich auch daran, dass Schlüssel bisher wenig verbreitet sind und es sich nicht lohnt. Jagd auf sie zu machen.
Sicherheit schafft man dadurch, dass man den Schutz der Schlüssel ihrer Bedeutung anpasst. Schlüssel, die triviale Absenderfälschungen bei E-Mails verhindern sollen (als Spamschutz), muss man nicht aufwendig schützen. Auch schlecht geschützte Schlüssel stellen für viele Störenfriede eine quasi unüberwindliche Hürde dar.
Wirklich wichtige Aktionen sind normalerweise selten; deshalb kann man ihren Aufwand erhöhen und dadurch den Schutz verbessern. Das mag die Signierung wichtiger Verträge oder die Zertifizierung eines Schlüssels (eines eigenen Unterschlüssels oder des Hauptschlüssels von jemand anderem) sein. Dafür kann man dann ein sicheres System booten (etwa Knoppix ohne Hardware für einen Internetzugang, also Netzwerkkabel raus) und nur auf diesem den wertvollen Schlüssel verwenden.
Den eigenen Schlüssel zu schützen ist nicht das einzige Problem. Man will außerdem, dass keine nichtautorisierten Signaturen erzeugt werden und ebensolche Entschlüsselungen stattfinden. Wie kann das passieren, ohne dass einem der Schlüssel geklaut wird? Auf zweierlei Art:
unbemerkte Nutzung sicherer Schlüssel
Wenn man eine Smartcard verwendet, kommt der Angreifer zwar nicht an den Schlüssel selber heran, aber er kann ihn benutzen, wenn er die Kontrolle über den Rechner hat. Solange die Smartcard im Leser steckt, entschlüsselt sie (die g10-Smartcard 2.0) munter alles, was man ihr vorwirft. Für Signaturen kann man dies unterbinden.
Unterschieben von Daten
Man weiß ja bei komplexen dokumenten letztlich nicht, was man signiert. Man hat eine Datei, etwa ein Office-Dokument. Man will wissen, was man signiert und öffnet die Datei deshalb mit der Office-Software. Wenn der Rechner kompromittiert ist (was auch erst durch das Öffnen der Datei passieren kann!), dann hat man nicht mehr die Gewissheit, dass einem auch das angezeigt wird, was in dem Dokument steht. Für Angriffe auf einzelne Opfer kann man Virenscanner leicht überwinden. Ein cleverer Angreifer würde dann noch die Schaddatei gegen eine harmlose mit dem gewünschten Inhalt austauschen, so dass man (jedenfalls mit der erzeugten Signatur) nicht einmal nachweisen kann, dass einem eine manipulierte Datei vorgelegt wurde. Auch gegen so etwas kann man sich schützen: Erst signieren, Signatur vom Rechner entfernen, dann erst die Datei öffnen. Und dann noch mal von der DVD booten und ein anderes Programm zur Anzeige verwenden (rettet einen nicht, wenn beide Programme den angegriffenen Code gemeinsam nutzen, etwa beim Umgang mit Bildern). Und dann auf sichere Weise die Signatur zerstören, wenn einem der angezeigte Dateiinhalt nicht gefällt. Dies mag an den Haaren herbeigezogen erscheinen. Es soll aber auch nur für das Problem sensibilisieren, dass echte Sicherheit auch mit großem Aufwand kaum zu bekommen ist.
Auf einem kompromittierten System muss der Angreifer sich nicht mal die Mühe machen, die komplizierte Office-Software zu manipulieren. Es reicht, dass er andere Daten an die Smartcard schickt, als angezeigt werden. Beim Onlinebanking gibt es als Schutz davor Kartenleser mit Display. Das funktioniert aber nur deshalb, weil sich der Inhalt von Kontotransaktionen mit wenig Text komplett darstellen lässt. Das ist nicht einmal bei längeren Textdateien praktikabel.
Smartcards sind ein weitgehend sicherer Schutz für Schlüssel. Eine Smartcard ist ein kleiner Computer. Man schreibt den Schlüssel rein, aber sie rückt ihn nicht mehr heraus. Man kann den Schlüssel nur noch über die Smartcard verwenden. Entsprechend sicher (sowohl im Sinne von Verfügbarkeit als auch im Sinne von Schutz) sollte man das Backup des Schlüssels verwahren. Man schreibt die zu signierenden oder zu entschlüsselnden Daten in die Smartcard und sie liefert die gewünschten Daten zurück. Wenn man an die Schlüssel heranwill, muss man die Smartcard mit einer Art Elektronenmikroskop zerlegen. Das kostet einen siebenstelligen Betrag pro Schlüssel.
Smartcards schützen die Schlüssel vor unbefugter Verwendung dadurch, dass man nach jedem "Einschalten" der Smartcard (auch konfigurierbar: bei jeder Signatur) eine PIN eingeben muss. Nach drei Fehlversuchen braucht man die Admin-PIN. Nach drei Fehlversuchen für diese brennt sich die Karte durch.
Hohe Sicherheit entsteht nur dann, wenn man die PIN konsequent nur am Kartenleser eingibt und nicht am PC, denn der PC könnte kompromittiert sein, ein Angreifer könnte die PIN mitlesen. Das Setzen der PIN ist leider bisher nicht über einen Kartenleser möglich, sondern nur über den PC. Paranoide sollten deshalb für das Setzen der PIN von einem sicheren Medium booten.
Smardcards erlauben den schmerzarmen Einsatz von Schlüsseln in unsicheren Umgebungen. Allerdings muss man sich darüber im Klaren sein, dass nur der Schlüssel selber geschützt wird; sein Missbrauch wird nicht allein durch die Verwendundung einer Smartcard unterbunden.
Meines Wissens kann man derzeit nur eine Smartcard mit GnuPG (für OpenPGP-Schlüssel) verwenden, nämlich diese hier (ein dazu passendes Lesegerät). Es gibt die Smartcard-Hardware auch mit USB-Anschluss (aber ohne PIN-Pad), so dass man keinen Kartenleser mit sich herumschleppen muss.
Die Karten gibt es für etwa 15 €, einen Kartenleser mit PIN-Pad für etwa 50 €. Auch der Cryptostick kostet etwa 50 €.
Die technischen Probleme beim Schutz von Schlüsseln wurden schon erwähnt. In der Praxis mindestens gleichbedeutend ist aber das Verständnisproblem. Man kann Schlüssel zertifizieren und Daten signieren und verschlüsseln. Aber das ist ja nur Technik. Was bedeutet das? Wenn man mit verschlüsselten oder signierten Daten konfrontiert wird, hat man demgegenüber irgendeine Haltung. Auch wenn man selber Daten verschlüsselt oder signiert, verbindet man damit eine Änderung der Haltung ihnen gegenüber. Man muss an dieser Stelle sehr aufpassen, keine falschen Schlüsse zu ziehen.
Eine Signatur bedeutet erst mal nur, dass jemand Zugriff auf den zugehörigen geheimen Schlüssel hatte und sich entschieden hat, ihn zu benutzen, sowie dass die signierten Daten nicht verändert wurden.
Die beiden wichtigsten Fragen in diesem Zusammenhang sind:
Wie sicher verwahrt der Besitzer seinen Schlüssel? Dazu gehört auch: Wie sicher ist die Umgebung, in der er ihn einsetzt?
Was will er mit seiner Signatur aussagen?
Es hat wenig Sinn, die eigenen Gewohnheiten auf andere zu übertragen, denn es gibt keinen allgemeinen Konsens über den Einsatz von Schlüsseln. Für rechtsgültige digitale Unterschriften gibt es eine klare Vorgabe (Namen druntersetzen (was immer das heißen mag), qualifizierte Signatur erzeugen), aber für den Einsatz von OpenPGP ist das unerheblich, da damit auf absehbare Zeit keine qualifizierten Signaturen erzeugt werden können.
Wenn man einer Signatur vertraut, dann vertraut man
dem Willen des Unterzeichners, seinen Schlüssel und seine Signaturen ordentlich zu handhaben
dem gemeinsamen Verständnis, was in der fraglichen Situation ordentlich
ist
seiner technischen Kompetenz, das zu tun
seiner Disziplin (und im Moment der Unterschrift vorhandenen Hard- und Software-Ausstattung), das zu tun
und der technischen Sicherheit des Signatursystems (typischerweise das kleinste Problem).
Es gibt Leute (wie den Autor dieses Textes), die fast alles signieren, was sie so verfassen und verschicken. Das hat, nach Meinung erfahrener OpenPGP-Nutzer, aber auch Nachteile. Das Argument ist, dass damit eine Allerwelts-E-Mail eine Bedeutung bekomme, die sie typischerweise nicht habe. Diese Fraktion signiert nur solche Dokumente, deren Bedeutung dadurch herausgehoben werden soll, und das auch nur nach entsprechend sorgfältiger Prüfung. Wenn man sich dieses Problems bewusst ist, kommt man zum nächsten: Woher soll man wissen, in welche Gruppe jemand fällt?
In engem Zusammenhang mit dem Einsatzzweck eines Schlüssels steht seine Sicherheit. Ein Schlüssel, der sehr oft verwendet wird, ist natürgemäß im allgemeinen weniger sicher als einer, der nur selten und gezielt eingesetzt wird. Wenn ich alle meine E-Mails signiere, dann muss ich den Schlüssel auf dem System verfügbar (oder jedenfalls von diesem System aus zugänglich) haben, auf dem ich Mails schreibe. Das ist üblicherweise das System, auf dem man Mails liest. Das stellt eine relevante obere Grenze für die Sicherheit dar. Selbst die Verwendung einer Smartcard rettet einen dabei nicht, weil die nur verhindert, dass einem der Schlüssel geklaut wird, nicht aber, dass man andere Daten signiert, als man signieren möchte. Das kann einem allerdings immer noch auffallen, wenn man den nötigen Aufwand treibt.
Wenn man Signaturen erzeugen will, die wirklich verlässlich sein sollen, dann sollte man sich mehrere Schlüssel zulegen, damit man einen auf die Erzeugung verlässlicher Signaturen beschränken und entsprechend besser schützen kann. Wie schützt man einen Schlüssel (oder besser, weiter gehend: die Verlässlichkeit einer Signatur)?
Man schützt den Schlüssel selber.
Das heißt, man verwahrt ihn auf Offlinemedien, idealerweise auf einer Smartcard. Man schützt ihn mit einer guten Passphrase (und vielen Interationen, siehe -s2k-count).
Man setzt den Schlüssel nur auf einem sicheren System ein.
Also etwa einem von DVD gebooteten System. Dieses Spiel kann man immer weiter treiben: Woher bekommt man ein sicheres Bootmedium? Wie stellt man sicher, dass dieses Medium nicht manipuliert/ausgetauscht wurde? Kann man der Hardware vertrauen? Das größte Risiko diesbezüglich dürfte sein, dass Tastatureingaben mitgelesen (und gespeichert) werden.
Man signiert nur "ungefährliche" Daten.
Wir signieren vom Verständnis her nicht in erster Linie eine Datei. Was interessiert uns eine Datei? Wir signieren das, was uns am Bildschirm angezeigt oder ausgedruckt wird; also das, was wir für den Inhalt der Datei halten. Wenn das System, auf dem die Datei angezeigt wird, kompromittiert ist, haben wir keine Kontrolle darüber, was wir signieren. Selbst ohne Softwareangriffe kann es zu Problemen kommen. Komplexe Dokumente können auf unterschiedliche Art angezeigt werden. Notizen in einer Textverarbeitung werden nicht angezeigt oder nicht beachtet. Makros sind womöglich deaktiviert, verändern aber den Inhalt. Browser stellen komplizierte Webseiten unterschiedlich dar, binden in der Anzeige womöglich externe Inhalte ein (die nicht signiert werden, sondern nur der Verweis auf sie). Außer bei Softwareangriffen sollten diese Probleme allerdings reproduzierbar sein, so dass man sich hinterher immer noch aussichtsreich darüber streiten kann, was man denn nun eigentlich unterschrieben hat.
Wenn man paranoid ist, erzeugt man brisante Signaturen nur auf einem von einem sicheren Medium gebooteten System, das (hardwaremäßig!) keinerlei Netzzugang hat. Wenn es um komplexe Dokumente geht (also um solche, die man sich nicht nur mit einem Editor in der Konsole anschaut), dann erzeugt man als erstes die Signatur, speichert die aber nicht in dem System, sondern auf einem Medium, das man dann von dem System trennt; etwa einem USB-Stick. Diese Signatur kann man für den Fall der Fälle natürlich auch verschlüsseln. ;-) Danach schaut man sich das Dokument an und entscheidet, ob man es signieren will. Diese Sichtung führt man dann am besten mit unterschiedlicher Software auf unterschiedlichen Systemen durch. Natürlich immer nur nach dem Booten von einem sicheren Medium... Möglich ist auch, den Inhalt des Dokuments in ein zweites, nach Möglichkeit technisch einfacheres Dokument zu kopieren (also etwa in eine Textdatei) und nur beides zusammen zu signieren, damit man auf die sichere Variante verweisen kann. Was der Empfänger davon hält, ist natürlich eine andere Frage. Grundsätzlich erscheint es sinnvoll, bedeutsame Dokumente, die signiert werden sollen, in einem einfachen Format zu erstellen (z.B. HTML ohne Code).
Man kann Fehleinschätzungen leicht dadurch vermeiden, dass man für jeden erkennbar macht, was der eigene Maßstab ist (für jeden Schlüssel einzeln). Man sollte deshalb (idealerweise schon vor der Schlüsselerzeugung) aufschreiben, wofür dieser Schlüssel dient (und wofür nicht!), mit welchem Aufwand er vor unberechtigtem Zugriff geschützt wird und in welcher Umgebung er eingesetzt wird. Insbesondere sollte vermerkt werden, nach welchen Kriterien man andere Schlüssel zertifiziert (ggf. Unterschiede für die Zertifizierungslevel (--ask-cert-level) 2 und 3). Diese Richtlinie veröffentlicht man dann im Internet. Das hat natürlich nur dann einen Wert, wenn man sie auch signiert. Wenn man sie ohne Ablaufdatum signiert (--ask-sig-expire), darf man die Richtlinie für diesen Schlüssel nicht mehr ändern (allenfalls noch verschärfen).
Woher kennt man die Signaturrichtlinie eines Schlüssels? Man kann mit den Optionen --cert-policy-url, --sig-policy-url und (für deren Anzeige man allerdings --list-options show-policy-urls bzw. --verify-options show-policy-urls benötigt, sinnvollerweise in der Konfigurationsdatei) die URL des Dokuments in die jeweilige Signatur schreiben.
Leider stehen im Normalfall Schlüssel und das Dokument der Richtlinie in einer Kreisbeziehung: Das Dokument behauptet, dass der Schlüssel hochsicher sei, und diese Behauptung wird nun mit der Signatur des Schlüssels abgesichert, der üblicherweise nur so sicher ist, wie das Dokument behauptet? Schwierig. Ein (zu recht) unsicherer Schlüssel könnte geklaut werden; damit könnte dann eine Signaturrichtlinie signiert werden, die behauptet, dass der Schlüssel quasi in einem Bankschließfach liege. Wie soll man dieses Problem lösen? Dadurch, dass die Richtlinie immer zusammen mit dem Schlüssel signiert wird. Man lässt sich nicht nur den Fingerprint des Schlüssels bestätigen, sondern auch den des Richtliniendokuments (z.B. mit gpg --print-md SHA1 policy.html, gerne auch mit einem besseren Hash) und signiert es dann selber. Wenn man einen Schlüssel über das web-of-trust verifiziert und ihm mehr als ein minimales Sicherheitsniveau attestieren will, sollte man von allen für die Verifizierung des Schlüssels verwendeten Schlüsseln eine Signatur für die Richtline haben.
Es gäbe übrigens die viel elegantere Möglichkeit, über standardisierte signature notations (--sig-notation und --cert-notation im Zusammenspiel mit --list-options show-notations bzw. --verify-options show-notations) die relevanten Angaben direkt in den Schlüssel bzw. die Signatur zu schreiben. Der verfasser regt dies ebenso regelmäßig wie erfolglos auf der GnuPG-Mailingliste an. Der Haupteinwand scheint zu sein, dass sich ja auch heute schon niemand um die saubere Verifizierung von Schlüsseln und Signaturen kümmere, deshalb sei es schlecht investierter Aufwand, diesen Teil zu verbessern.
E-Mail dürfte die mit Abstand häufigste (aktive) Verwendung von OpenPGP sein (passiv haben jedenfalls die Linuxer u.Ä. bei der Softwareverteilung (Onlineupdates) damit zu tun). Wie schmerzfrei das ist, hängt sehr davon ab, welches Mailprogramm man verwendet. Webmail kann man dafür mehr oder weniger vergessen.
Das größte Problem im Zusammenhang mit PGP und E-Mail ist der Dreck, den Microsoft unter dem Namen Outlook (in allen Variationen) unters Volk kippt und dreist als Mailprogramm bezeichnet. Aber da Windows grundsätzlich nicht von Privatanwender genutzt wird und auch Outlook nicht für diese Zielgruppe gedacht ist und sinnvolle Lösungen Microsoft sowieso widerstreben, unterstützt dieses tolle Produkt vom Marktführer auch nach inzwischen 13 Jahren immer noch nicht den für Privatanwender maßgeblichen Standard. Aber der ist ja in Open-Source-Software implementiert, damit kommt Microsoft halt nicht klar.
Richtig Glück hat, wer das KDE-Programm (Linux) KMail verwendet, denn dafür hat das BSI mal die GnuPG-Integration bezahlt. Für alle(?) anderen FOSS-Programme gibt es Add-ons, siehe meine Download-Linkliste. Hier gibt es Infos zu Thunderbird.
Das Hauptproblem ist, dass Outlook nicht einmal normale Textmails korrekt anzeigt, wenn sie signiert sind. Outlook hält dann den Text für ein Attachment. Und zeigt die eigentliche Signatur natürlich als zweites Attachment, was den normalen Empfänger verwirrt.
Es gibt zwei Möglichkeiten, PGP mit E-Mails zu verwenden, Inline-PGP und MIME. Inline-PGP schreibt das PGP-Drumherum in den normalen Mailtext. Für Benutzer von Mailprogrammen, die PGP nicht kennen, sieht das zwar komisch aus, aber sie haben direkten Zugriff auf den Text. Bei der Verwendung von MIME verstecken brauchbare Mailprogramme das PGP-Drumherum und zeigen z.B. durch Einfärbung an, welche Teile der Mail signiert und/oder verschlüsselt sind. Attachments kann man auf direktem Weg nur mit MIME verschicken. Natürlich kann man außerhalb eines Mailprogramms eine Datei verschlüsseln und/oder signieren und das Ergebnis per Mail verschicken. Möglich, aber (für beide Seiten) unkomfortabel.
Hier sind einige Probleme von Inline-PGP erläutert (allerdings auf Englisch).
Diese Seite ist noch nicht fertig.