Pretty Good Privacy Verschlüsselung und Authentizitätskontrolle. seyecon IT-Consulting e.k., Volkmar Seifert

Transkript

1 Pretty Good Privacy Verschlüsselung und Authentizitätskontrolle seyecon IT-Consulting e.k., Volkmar Seifert 14. Juni 2005

2

3 Inhaltsverzeichnis 1. Einführung Was ist Pretty Good Privacy? Warum Kryptographie? Konzepte der Kryptographie Grundsatz der Kryptographie Symmetrische Verschlüsselung Asymmetrische (Public-Key) Verschlüsselung Hybride Verschlüsselung Digitale Signaturen PGP im Einsatz Der Gnu Privacy Guard Was ist GnuPG? GnuPG Grundlagen Schlüsselgeneration Die Widerrufurkunde Schlüsselaustausch Exportieren öentlicher Schlüssel Importieren öentlicher Schlüssel Ver- / Entschlüsselung von Dokumenten Signieren von Dokumenten Die Klartextsignatur (--clearsign) Die abgetrennte Signatur (--detach-sig) Daten und Signatur komprimiert kombiniert (--sign) mit GnuPG Mozilla Thunderbird / Enigmail Die Installation Die Grundkonguration Die Pro-Konto-Konguration Die tägliche Verwendung Die Schlüsselbundpege Microsoft Outlook PGP Desktop / PGP Universal A. Der GPG-Agent 35 B. Verzeichnisse, Index 37 Copyright 2005 seyecon IT-Consulting 3

4 Inhaltsverzeichnis Inhaltsverzeichnis 4 Copyright 2005 seyecon IT-Consulting

5 1. Einführung Grundgesetz Artikel 10, Absatz 1: Das Briefgeheimnis sowie Post- und Fernmeldegeheimnis sind unverletzlich. Eckpunkte der deutschen Kryptopolitik, verabschiedet vom deutschen Bundeskabinett am 2. Juni 1999: Der Einsatz kryptographischer Verfahren ist von auÿerordentlicher Bedeutung für eine eziente technische Kriminalprävention. Dies gilt sowohl für die Gewährleistung der Authentizität und der Integrität des Datenverkehrs wie auch für den Schutz der Vertraulichkeit Was ist Pretty Good Privacy? Pretty Good Privacy, oder abgekürzt PGP, wurde 1991 von Phil Zimmermann als proprietäres Werkzeug zur Verschlüsselung von Daten geschrieben. Aus diesem Werkzeug hat sich über die Jahre hinweg OpenPGP als nicht-proprietäres Protokoll zur Verschlüsselung von s entwickelt, einem IETF 1 -Standard. Es gibt heutzutage verschiedene Implementationen des PGP-Standards, die beiden bekanntesten sind PGP selbst, dass als kommerzielles Werkzeug von der PGP Corporation vertrieben wird, und GnuPG 2, welches als Teil des Gnu-Projektes 3 unter der Gnu GPL 4 als OpenSource-Produkt frei erhältlich und einsetzbar ist. Sowohl mit PGP als auch mit GnuPG lassen sich aber nicht nur s verschlüsseln und/oder signieren, sondern auch beliebige andere Daten Warum Kryptographie? Die Kryptographie, die Wissenschaft der Verschlüsselung, gewährleistet die Vertraulichkeit, Integrität und Authentizität von Daten. Hierbei ist es irrelevant, ob die Daten in zum Beispiel Dateiform vorliegen, oder aber eine direkte Kommunikation darstellen. Wer heutzutage per Post etwas verschickt, verwendet für gewöhnlich Briefumschläge - gleichgültig ob etwas vertrauliches, wichtiges verschickt wird, oder einfach nur eine Glückwunschkarte. Desweiteren würde niemand auf die Idee kommen, eine Rechnung per Postkarte zu schicken, selbst wenn der Platz ausreichend wäre. Fragt man nach dem Warum, so bekommt man im Regelfall die Antwort weil es niemanden etwas angeht, was ich verschicke. Man beruft sich implizit und ohne sich dessen unbedingt bewusst zu sein auf den Artikel 10, Absatz 1 des Grundgesetzes - dem Briefgeheimnis. Verschickt man nun über das Internet eine , die ja auch ein Brief ist, so geschieht das, wenn man nicht entsprechende Vorkehrungen getroen hat, immer unverschlüsselt. Das Briefgeheimnis kann somit nicht gewahrt werden, und praktisch jeder Mensch auf diesem Planeten wäre theoretisch in der Lage, die versendete zu lesen. 1IETF: Internet Engineering Task Force, eine Gemeinschaft, die sich mit der technischen Entwicklung des Internets beschäftigt. 2GnuPG: Gnu Privacy Guard, Siehe auch Abschnitt 2.1.1, Seite 11. 3Gnu Projekt: Ein 1984 gegründetes Projekt zur Erstellung eines freien UNIX-Systems. Nähere Informationen unter 4Gnu GPL: Gnu General Public License Copyright 2005 seyecon IT-Consulting 5

6 1.3. KONZEPTE DER KRYPTOGRAPHIE KAPITEL 1. EINFÜHRUNG Fragt man hier danach, warum die Mails unverschlüsselt versendet werden, so lautet die Antwort ich verschicke nichts so wichtiges. Das interessante dabei ist, dass bei normaler konventioneller Briefpost selbst das unwichtigste durch einen Briefumschlag geschützt wird, ohne das darüber nachgedacht wird, bei s aber darauf verzichtet wird. Cracker 5, an die für gewöhnlich gedacht wird, wenn es um den Schutz und die Sicherheit von Daten geht, sind aber im Falle von s gar nicht das einzige, vor dem sich geschützt werden sollte. Auch vor korrupten Systemadministratoren, vor allem aber vor planmäÿigem Eindringen in die Privatsphäre durch staatliche Organe wie zum Beispiel Geheimdienste sollte man sich schützen. Es gibt noch einen Punkt, bei dem die Kryptographie zum Tragen kommt, und dieser Teil hat etwas mit der Glaubwürdigkeit der eigenen Person zu tun: Der Schutz von Integrität und Authentizität der Daten. Die Kryptographie kommt nicht nur dann zur Anwendung, wenn es darum geht, zum Beispiel einen Text derart zu verändern, dass nur noch ein ausgewählter Kreis von Leuten in der Lage ist, diesen Text wieder zu lesen, sondern sie kommt auch zur Anwendung, wenn Daten überprüft werden sollen. In den letzten Jahren kommt es immer häuger vor, dass Viren, Würmer und Trojaner sich selbsttätig über das Internet verbreiten, indem sie sich von befallenen Rechnern aus per weiterverschicken. Hierzu lesen diese Programme die Adressbücher der Mailprogramme aus, um sich dann als ein beliebiger Absender an beliebige Empfänger aus dieser Liste zu verschicken. Verwenden die Absender, wenn sie wirkliche s verschicken, aber eine sogenannte digitale Signatur, so wird diese an die Mail angehängt, wenn der Benutzer hierzu die Authorisation gibt. Ein Virus kann solch eine Authorisation nicht geben, auÿerdem versucht er direkt die Mail zu versenden, ohne das Mailprogramm des Benutzers. Die Folge ist, das eine Virus-versendete Mail solch eine Signatur nicht enthalten kann - der Empfänger kann sofort sehen, dass diese Mail nicht authentisch ist. Die Mail kann sofort gelöscht werden, und somit keinen Schaden mehr anrichten Konzepte der Kryptographie Grundsatz der Kryptographie Ein gutes Verschlüsselungsverfahren legt seinen Schwerpunkt nicht auf die Geheimhaltung des verwendeten Algorithmus, sondern auf die Geheimhaltung der verwendeten Schlüssel. Anders formuliert, sollte es völlig ohne Bedeutung sein, den Algorithmus zu kennen, solange der Schlüssel unbekannt ist. Beruht aber die gesamte Sicherheit allein auf dem verwendeten Schlüssel, so ist es äuÿerst wichtig, dass der Schlüssel nicht mit verfügbaren Mitteln erratbar sein darf. Daraus wiederum folgt, dass die Anzahl der möglichen Schlüssel (Schlüsselraum oder key space genannt) möglichst groÿ sein muÿ. Heutige Computer können sehr schnell Schlüssel erraten. Deshalb ist in den heutigen Verschlüsselungsverfahren die Schlüsselgröÿe auch von äuÿerster Wichtigkeit. Ein Verfahren mit für heutige Verhältnisse kleinem Schlüsselraum ist zum Beispiel die DES- Verschlüsselung 6. Dieses Verfahren verwendet eine Schlüssellänge von 56 Bit, und hat somit einen Schlüsselraum von 2 56 = verschiedenen möglichen Schlüsseln. Das erscheint im ersten Moment sehr groÿ, doch wurde der 1999 in einem Wettbewerb gesuchte DES-Schlüssel innerhalb von 22 Stunden und 15 Minuten gefunden. Hierbei wurden in Zusammenarbeit von einer speziell entwickelten Maschine und einem Netzwerk aus ca Computern mehr als 245 Milliarden Schlüssel pro Sekunde im Brute-Force-Verfahren 7 getestet. Man kann davon ausgehen, das heutzutage jeder Computer innerhalb von wenigen Tagen einen DES-Schlüssel nden kann. 5Cracker: Person, die vorsätzlich und mit böser Absicht in fremder Rechnersysteme eindringt. Gegenteil von Hacker. Siehe auch RFC DES: Data Encryption Standard, wurde in den 1970ern entwickelt. Wegen starker Einussnahme seitens der NSA war dieser Algorithmus lange Zeit sehr umstritten. 7Bei diesem Verfahren wird mit brachialer Gewalt jede einzelne Möglichkeit des Schlüsselraums getestet bis der richtige Schlüssel gefunden ist. 6 Copyright 2005 seyecon IT-Consulting

7 KAPITEL 1. EINFÜHRUNG 1.3. KONZEPTE DER KRYPTOGRAPHIE Andere Verfahren, wie zum Beispiel der patentierte IDEA-Algorithmus verwenden zur Verschlüsselung einen Schlüsselraum von 128 Bit. Das ergibt = Möglichkeiten, was das Finden eines Schlüssels auf längere Zeit vorerst zumindest über Verfahren wie Brute-Force unmöglich macht. Beide gerade erläuterten Verschlüsselungsverfahren gehören zu der sog. symmetrischen Verschlüsselung. Sie wird im folgenden genauer erklärt Symmetrische Verschlüsselung Bei der symmetrischen Verschlüsselung werden zum Ver- und Entschlüsseln der Daten derselbe Schlüssel verwendet. Zwei Parteien, die über symmetrische Verschlüsselung miteinander kommunizieren wollen müssen sich vor der Kommunikation über einen Schlüssel einigen und diesen gegebenenfalls auf die eine oder andere Art und Weise austauschen. Der Absender verschlüsselt sodann die zu übermittelnden Daten mit Hilfe dieses Schlüssels und überträgt sie. Der Empfänger benutzt nun den Schlüssel um die Daten zu entschlüsseln. Dieses Prinzip ist die älteste Form der Verschlüsselung und ist schon bei den Römern bekannt gewesen. Die Hauptschwierigkeit der symmetrischen Verschlüsselung besteht im Austausch der Schlüssel. Im Allgemeinen ist es für einen Angreifer deutlich leichter, den richtigen Schlüssel selbst abzufangen, als zu versuchen per Brute-Force-Methode den richtigen Schlüssel zu erraten. Auÿerdem gibt es noch das Problem der Anzahl der insgesamt verwendeten Schlüssel. Wollen n Leute miteinander verschlüsselt kommunizieren, ohne das irgendein anderer die Kommunikation abhören kann, so müssen insgesamt n(n 1) 2 Schlüssel verwendet (zum Beispiel 45 Schlüssel, wenn n = 10). Aus diesem Grund kam man auf andere Verfahren: Asymmetrische Verschlüsselung Asymmetrische (Public-Key) Verschlüsselung Die asymmetrische, oder Public Key Verschlüsselung greift genau die beiden Punkte auf, die bei der symmetrischen Verschlüsselung die Hauptschwierigkeiten darstellen. Bei der asymmetrischen Verschlüsselung gibt es kein Sicherheitsrisiko beim Schlüsselaustausch, und es gibt nur n Schlüssel, wenn n Leute miteinander kommunizieren wollen. Die Realisation geschieht darüber, dass es nicht einen Schlüssel für die Kommunikation gibt, sondern zwei, also ein Schlüsselpaar. Der eine Schlüssel ist der öentliche Schlüssel. Dieser öffentliche Schlüssel des Empfängers wird zum Verschlüsselung von Nachrichten verwendet. Dieser wiederum kann derart verschlüsselte Nachricht nur mit seinem zweiten, geheimen Schlüssel wieder entschlüsseln. Der Absender braucht nur eine Kopie des öentlichen Schlüssels des Empfängers zu besitzen, und mit diesem lässt sich lediglich entschlüsseln bzw. die Authentizität von Nachrichten des Anderen verwenden, nicht aber zum Entschlüsseln. Man löst hiermit nicht nur das Problem der Einigung auf einen Schlüssel, sondern auch das Risiko eines Schlüsseldiebstahls beim Austausch. Die Eigenschaft des geheimen Schlüssels, als einziger die empfangene Nachricht entschlüsseln zu können, ist auch der Grund für den reduzierten Bedarf im Umlauf bendlicher Schlüssel. Die asymmetrische Verschlüsselung basiert auf sogenannten Falltür-Algorithmen (engl. Trapdoor- Algorithms), und Einweg-Prüfsummen (engl. One-Way-Hashes). Bei diesen Algorithmen handelt es sich um Funktionen, die leicht zu berechnen sind, aus deren Ergebnis die Herleitung der Ursprungswerte jedoch praktisch unmöglich ist. Es ist zum Beispiel sehr leicht, zwei Primzahlen zu multiplizieren, um eine Nicht-Primzahl zu erhalten - aber eine Nicht-Primzahl in Ihre Primfaktoren zu zerlegen ist äuÿerst schwer. Auf diese Weise funktionieren Einweg-Prüfsummen. Die Falltür-Algorithmen arbeiten recht ähnlich, haben jedoch eine Möglichkeit der Umkehr: Ist ein Teil der Informationen bekannt, lässt sich die Umkehrfunktion berechnen. Für das Beispiel mit den zwei Primzahlen bedeutet es, dass man bei Kenntnis des Ergebnisses und Kenntnis eines der Primfaktoren sehr leicht den anderen errechnen kann. Copyright 2005 seyecon IT-Consulting 7

8 1.3. KONZEPTE DER KRYPTOGRAPHIE KAPITEL 1. EINFÜHRUNG Stark vereinfacht kann man also folgendes sagen: Beruht ein Verfahren auf der Bildung einer Zahl aus Primfaktoren, so enthält der öentliche Schlüssel eine aus zwei sehr groÿen Primfaktoren zusammengesetzte Zahl. Diese Zahl wird dann vom Verschlüsselungsalgorithmus zum Verschlüsseln der Nachricht verwendet. Der Entschlüsselungalgorithmus benötigt nun die Kenntnis der Primfaktore um die Verschlüsselung wieder aufheben zu können. Da der geheime Schlüssel einen der beiden Faktoren enthält, kann dieser vom Entschlüsselungsalgorithmus zur Ermittlung des zweiten und dann anschlieÿend zur Entschlüsselung verwendet werden. Fehlt der geheime Schlüssel aber, ist es praktisch unmöglich, die Daten je wieder zu entschlüsseln. Auch bei der asymmetrische Verschlüsselung beruht die Sicherheit des Verfahrens auf dem Schlüssel. Die Gröÿe des Schlüssels gibt auch hier wieder ein Maÿ für die Sicherheit des Systems. Vergleiche zwischen Schlüsselgröÿen symmetrischer Verfahren mit denen asymmetrischer Verfahren kann man allerdings nicht ziehen, um Rückschlüsse über die relative Sicherheit der beiden Verfahren gegeneinander ziehen zu können. Bei einer Verschlüsselung mit einem symmetrischen Verfahren und einem Schlüssel von 128 Bit muss der Angreifer Schlüssel durchprobieren, um den richtigen Schlüssel zu nden. Bei einem Brute-Force-Angri auf eine Public-Key-Verschlüsselung mit einem Schlüssel von Beispielsweise 512 Bit Gröÿe, muÿ der Angreifer eine in 512 Bit kodierte (also bis zu 155 Dezimalstellen umfassende) Nicht-Primzahl in Ihre Primfaktoren zerlegen. Je nach Verschlüsselung ist der Rechenaufwand also auch deutlich unterschiedlich. Reichen derzeit bei symmetrischen Verschlüsselungsalgorithmen Schlüsselgröÿen von Bit aus, werden bei asymmetrischen Verfahren, angesichts der heutigen Verfahren zur Faktorisierung groÿer Zahlen, für die meisten Zwecke öentliche Schlüssel von Bit Gröÿe empfohlen, in militärischen oder anderen Hochsicherheitsbereichen werden sogar bis zu 4096 Bit und mehr verwendet Hybride Verschlüsselung Die hybride Verschlüsselung nutzt beide gerade vorgestellten Verschlüsselungsverfahren - die symmetrische zum Verschlüsseln der Daten, und die asymmetrische zum Verschlüsseln des symmetrischen Schlüssels. Der Grund hierfür liegt darin, dass die asymmetrische Verschlüsselung zwar weniger Risiken beim Austausch der Schlüssel birgt, dafür aber weitaus aufwendiger in der praktischen Anwendung ist. Symmetrische Verschlüsselungssysteme sind hier einfach performanter. Hybride Systeme sind natürlich nur so stark wie ihre schwächste Komponente. Ist der symmetrische Schlüssel von einem Angreifer erst einmal gefunden, so ist die ganze Verschlüsselung hinfällig. Aus diesem Grund wird der symmetrische Schlüssel bei hybriden Systemen als Sitzungsschlüssel jeweils beim Verschlüsseln der Daten durch einen Zufallsgenerator neu erzeugt, und über Verschlüsselung mit dem asymmetrischen Schlüssel den symmetrisch verschlüsselten Daten beigefügt. Somit müsste ein Angreifer für jede so verschlüsselte Nachricht bzw. Datei den Schlüssel erneut ermitteln - was die Angreifbarkeit drastisch senkt Digitale Signaturen Die digitale Signatur, auch digitale Unterschrift genannt, hat zwei Aufgaben: Zum einen soll sie als Äquivalent zur handschriftlichen Unterschrift in der digitalen Kommunikation fungieren, und zum anderen soll sie die tatsächliche Authentizität und Integrität des Dokumentes sicherstellen. In diesem zweiten Punkt ist die digitale Signatur der Handschriftlichen überlegen - sie kann nicht gefälscht werden, und durch Prüfsummen, die Bestandteil einer digitalen Unterschrift sind, ist die Unversehrtheit eines digitalen Dokuments verizierbar. Digitale Signaturen wären ohne die Kryptographie nicht möglich, denn wie schon geschrieben, sind Prüfsummen über das jeweils zu unterzeichnende Dokument fester Bestandteil dieser digitalen Unterschriften. Ebenso muÿ gewährleistet sein, dass eine digitale Signatur weltweit einmalig ist. Voraussetzungen, die nur die Kryptographie mit ihren verschiedenen Verfahren und Möglichkeiten erfüllen kann. Im Abschnitt 1.3.3, Seite 7 sind bereits Einweg-Prüfsummen im Zusammenhang 8 Copyright 2005 seyecon IT-Consulting

9 KAPITEL 1. EINFÜHRUNG 1.3. KONZEPTE DER KRYPTOGRAPHIE mit der asymmetrischen Verschlüsselung erläutert worden. Diese Funktionen kommen bei digitalen Unterschriften wieder zum Einsatz, denn bei diesen Prüfsummen handelt es sich um Funktionen, die zu einem Text eine eindeutige Summe ermitteln können, die nur dieser eine Text ergeben kann. Anders ausgedrückt kann es zu einer ermittelten Prüfsumme keinen zweiten Text geben, da die Funktion sonst die notwendigen Voraussetzungen nicht erfüllen würde. Desweiteren darf es nicht oder nur mit gröÿtem Aufwand möglich sein, aus der Prüfsumme wieder den Text herzustellen. Beispiele für solche Prüfsummen-Algorithmen sind zum Beispiel SHA-1 8 und RIPEMD Es wird hier die Prüfsumme eines Dokumentes als Unterschrift verwendet. Eine Prüfung der Unterschrift erfolgt einfach durch nochmalige Berechnung der Prüfsumme und anschlieÿenden Vergleichs zwischen neuberechneter Prüfsumme und der dem Dokument beiliegenden. Bei Übereinstimmung ist das Dokument authentisch. Diese Methode hat natürlich einen kleinen Schönheitsfehler: Hat ein Angreifer Zugri auf Dokument und Prüfsumme gleichzeitig, was bei s ja dadurch gegeben ist, dass die Prüfsumme als Anhang mitgeliefert wird, kann der Angreifer natürlich das Dokument verändern, die Prüfsumme neuberechnen lassen und austauschen. So würde es niemandem auallen, da die mitgelieferte Prüfsumme ja stimmt. Auÿerdem ist so auch keine personenbezogene Unterschrift gegeben, nur eine inhaltsbezogene. Wird nur das Dokument verschlüsselt, und die Unterschrift nicht, könnte ein Angreifer eine falsche Prüfsumme mitschicken, um einen Vergleich bewusst scheitern zu lassen. Verschlüsselt man nun Dokument und Unterschrift über ein hybrides Verfahren, d.h. benutzt der Unterzeichner seinen privaten Schlüssel zum Unterschreiben, hat das den Haken, das zum einen, wäre es sicher, die Unterschrift gar nicht nötig wäre, und zum anderen es eben von vornherein gar nicht sicher sein kann, da der symmetrische Sitzungsschlüssel vom öentlichen, also für jeden zugänglichen Schlüssel entschlüsselbar ist. Somit wäre der Angreifer wieder in der Lage, sowohl Dokument wie auch Unterschrift auszutauschen, und im Namen des Versenders zu verschicken. Wenn all die Methoden aber nun so unsicher sind, wie geht es dann wirklich? In der täglichen Praxis von s wird nur für die Unterschrift ein asymmetrisches Verfahren benutzt. Der geheime Schlüssel des Unterzeichners wird verwendet, um die Unterschrift zu erzeugen. So ist es möglich, über den öentlichen Schlüssel die Unterschrift zu verizieren. Das Dokument selbst kann wahlweise verschlüsselt oder unverschlüsselt geschickt werden, je nach Bedarf und Laune. Verändert nun jemand das Dokument, so fällt die Prüfung negativ aus. Da aber die Unterschrift mit dem privaten Schlüssel erzeugt wurde, ist sie nicht ersetzbar - sie wäre nicht mehr über den öentlichen Schlüssel prüfbar, es würde auch hier also zu einem negativen Ergebnis bei der Verikation kommen. Es gibt auch Public-Key-Verfahren 10 zum Unterschreiben von Dokumenten. Der Unterzeichner verschlüsselt das Dokument dabei mit seinem privaten Schlüssel. Dieses kann dann mit dem öentlichen Schlüssel wieder entschlüsselt werden. Der Unterschied hierbei liegt darin, dass allein das Dokument verschlüsselt wird, es wird keine explizite Unterschrift mitgeliefert. Dieses Verfahren besitzt alle für die Prüfsummenfunktionen genannten Voraussetzungen zur digitalen Signierung, ist aber in der Praxis sehr langsam und aufwendig, weshalb es eher selten zum Einsatz kommt. 8SHA: Secure Hash Algorithm. Es gibt verschiedene Varianten dieses Algorithmus, die jeweils verschieden groÿe Hash-Werte (Prüfsummen) erzeugen. Dieser Algorithmus kam im Februar 2005 in Verruf, als eine Gruppe von chinesischen Wissenschaftlern veröentlichte, eine Kollision im SHA-1 und SHA-0 gefunden zu haben. Ihr sei es gelungen den Aufwand zur Kollisionsberechnung von 2 80 auf 2 69 zu reduzieren. Da aber dies erstens immer noch eines äuÿerst hohen Rechenaufwands bedarf, der Angrie in der Praxis derzeit sinnlos werden lässt, und zweitens nicht der vollständige SHA verwendet wurde (es wurde auf das sog. Padding, das Auüllen von Zeichenfolgen mit Bits, verzichtet), ist diese Nachricht derzeit als nicht kritisch einzustufen. Dem tatsächlichen SH-Algorithmus konnten bislang noch keine Kollisionen nachgewiesen werden. 9RIPEMD-160: Race Integrity Primitives Evaluation Message Digest, kryptographische Hash-Funktion mit 160 Bit Prüfsumme. Entwickelt von Hans Dobbertin, Antoon Bosselaers und Bart Preneel. Erstmals 1996 veröentlicht. 10RSA ist zum Beispiel ein solches asymmetrisches Verschlüsselungsverfahren, benannt nach seinen Erndern Ronald L. Rivest, Adi Shamir und Leonard Adleman. Copyright 2005 seyecon IT-Consulting 9

10 1.3. KONZEPTE DER KRYPTOGRAPHIE KAPITEL 1. EINFÜHRUNG 10 Copyright 2005 seyecon IT-Consulting

11 2. PGP im Einsatz 2.1. Der Gnu Privacy Guard Was ist GnuPG? Der Gnu Privacy Guard, kurz GnuPG oder GPG genannt, ist ein freies Software-Projekt. Frei bezeichnet hier nicht die Tatsache, dass GnuPG kostenlos ist, sondern vielmehr die Philosophie, die dahinter steckt. Freie Software im Sinne des GNU-Projektes, von dem GnuPG ein Teil ist, meint vor allem folgende vier Punkte: Freiheit, ein Programm für jeden beliebigen Zweck zu verwenden (kommerziell, privat, gemeinnützig...) Freiheit, Kopien eines Programms beliebig an jeden, der es brauchen kann weiter zu verteilen, und so zu helfen. Freiheit, die Funktionsweise eines Programms zu studieren, und gegebenenfalls das Programm, oder Teile davon nach eigenen Bedürfnissen anzupassen, und eventuell sogar in eigenen Programmen zu verwenden. Freiheit, ein Programm zu erweitern und zu verbessern, und diese Veränderungen der Allgemeinheit wieder zugänglich zu machen, damit alle etwas davon haben. Die letzten beiden Punkte setzen vollen Zugri auf den Quellcode voraus, der also oen sein muss. Aus diesem Grund hat sich der Begri OpenSource für diese Form von Software durchgesetzt. Gerade im Bereich der Kryptographie ist die Verfügbarkeit des Quellcodes ein wichtiger Punkt. Natürlich ist ein Produkt dadurch, dass der Quellcode nicht oen ist, nicht automatisch schlechter, aber die Kontrolle auf mögliche Schwächen, seien sie konzeptionell im Design oder einfach nur in der Implementation, ist hier nur durch eine sehr beschränkte Anzahl von Leuten möglich - im Gegensatz zu Software, deren Quellcode oen liegt, und die jeder anschauen und kontrollieren kann. Die PGP Corporation hat den Quellcode für das kommerzielle Produkt PGP - obwohl es eben nicht frei im Sinne von kostenlos ist - aus genau diesem Grunde auch oengelegt. Es gibt eine Variante des Produktes PGP Universal, die sogar der Gnu GPL unterliegt. GnuPG ist eine Implementation des OpenPGP-Protokolls. Es dient zum Verschlüsseln von Daten aller Art, wobei die wohl Häugste Einsatzform im Signieren und Verschlüsseln von s besteht. GnuPG selbst ist ein Kommandozeilen-Programm, d.h. es hat keine grasche Benutzeroberäche. Es wird entweder durch sogenannte Frontends, oftmals in Form von Plugins für Mailprogramme, oder direkt von der Kommandozeile (auch Shell genannt) aufgerufen und gesteuert. In den folgenden Abschnitten wird die Verwendung von GnuPG zur Erstellung von Schlüsseln direkt von der Kommandozeile aus erklärt. Die Verwendung von Frontends folgt im Abschnitt 2.2, Seite GnuPG Grundlagen Wenn man mit GnuPG arbeitet, so wird im gewöhnlichen Alltag durch grasche Benutzerober- ächen die meiste Arbeit stark vereinfacht. Dennoch ist es wichtig, ein Programm wie GnuPG Copyright 2005 seyecon IT-Consulting 11

12 2.1. DER GNU PRIVACY GUARD KAPITEL 2. PGP IM EINSATZ auch ohne grasches Frontend bedienen zu können, weil es immer vorkommen kann, dass die gerade benötigte Funktion von der verwendeten graschen Benutzeroberäche nicht unterstützt wird. Daher werden in diesem Abschnitt die wichtigsten Befehle von GnuPG auf der Kommandozeile erklärt Schlüsselgeneration Bevor an ein Arbeiten mit GnuPG im Sinne von Verschlüsselung oder Signierung zu denken ist, braucht man einen Schlüssel, mit dem diese Arbeiten dann durchgeführt werden können. Dieser Schlüssel muss von von jedem Benutzer selbst generiert werden. Er wird dann von GnuPG im sogenannten Schlüsselbund (englisch key ring) gespeichert. GnuPG verwendet den hybriden Ansatz zur Verschlüsselung von Daten. Somit wird pro Benutzer ein Schlüsselpaar generiert. Genaugenommen werden in den meisten Fällen sogar zwei Schlüsselpaare erstellt, ein DSA-Schlüsselpaar zur Signierung, und ein ElGamal 1 -Schlüsselpaar zur Verschlüsselung. Die Erzeugung eines Schlüssels mit GnuPG erfolgt über die Option --gen-key: bash$ gpg --gen-key gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? Mit GnuPG können verschiedene Schlüssel für unterschiedliche Verfahren erzeugen. Die Standardoption (engl. default) ist die Erzeugung eines DSA-Schlüssels zur Signierung, und gleichzeitig die Erzeugung eines untergeordneten ElGamal-Schlüssels zur Verschlüsselung. Dies ist Option 1 im Text-Dialog. Option 2 bietet die Möglichkeit einen reinen DSA-Schlüssel zu erzeugen, der nur zur Erstellung von Unterschriften (daher sign only) dient, und Option 3, über die Taste 5 anwählbar damit man es nicht versehentlich auswählt, bietet die Möglichkeit einen nur für Signierungen verwendbaren RSA-Schlüssel zu erzeugen. Generelle Empfehlung an dieser Stelle ist, die Standard-Option auszuwählen. Es ist später jederzeit möglich, einen weiteren Schlüssel zum Schlüsselbund hinzuzufügen. Gibt man hier nun 1 ein, und drückt auf die Eingabetaste, so erscheint die nächste Frage: DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Zum einen erfährt man an dieser Stelle, dass die Schlüsselgröÿe für den DSA-Schlüssel feste 1024 Bit beträgt, und man diese Gröÿe auch nicht ändern kann, und zum anderen, das der ElGamal- Schlüssel (ELG-E key) zwischen 1024 und 4096 Bit groÿ sein darf. Der Wert in den Klammern (2048) ist der Standardwert den GnuPG vorschlägt. Es ist durchaus empfehlenswert diesen Wert zu verwenden, wenngleich derzeit 1024 Bit auch noch eine akzeptable Gröÿe darstellen. Es liegt im eigenen Ermessen, welche Gröÿe hier gewählt wird, nur sollte man sich darüber bewusst sein, dass die Gröÿe des ElGamal-Schlüssels sowohl für die Dauer der Erzeugung des Schlüssels, die Dauer 1ElGamal: 1985 von Taher El Gamal entwickeltes asymmetrisches Verschlüsselungsverfahren das auf dem mathematischen Problem des diskreten Logarithmus beruht. Siehe hierzu Elgamal-Kryptosystem 12 Copyright 2005 seyecon IT-Consulting

13 KAPITEL 2. PGP IM EINSATZ 2.1. DER GNU PRIVACY GUARD der Verschlüsselungen beim Versenden von s, und für die Gröÿe der Signatur, die an die angehängt wird, von Bedeutung ist: Je gröÿer der Schlüssel, desto mehr Zeit wird benötigt, und desto gröÿer wird auch die Signatur - aber auch desto kleiner die Wahrscheinlichkeit, dass in absehbarer Zeit der Schlüssel von etwaigen Angreifern gefunden werden kann. Für die weitere Demonstration werden die vorgeschlagenen 2048 Bit zugrundegelegt, wobei diese Gröÿe auf die weiteren Dialoge keinen Einuss hat. Ist die Frage nach der Schlüsselgröÿe also beantwortet, fragt GnuPG nach einem eventuellen Verfallsdatum des Schlüssels. Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Als Vorschlag wird die Option key does not expire, also Schlüssel läuft nie ab angeboten, die auch für die meisten Einsatzfälle ausreichen ist. Schlüssel können, wenn sie nicht mehr gelten sollen, widerrufen werden, gleichgültig ob ein Verfallsdatum existiert oder nicht. Verwendet man ein Verfallsdatum, so muss nach Ablauf dieses Datums ein neuer Schlüssel generiert werden. Auÿerdem sollten alle, die über eine Kopie des öentlichen Schlüssels verfügen, davon in Kenntnis gesetzt werden, dass ein neuer Schlüssel existiert. Dies kann unter Umständen Schwierigkeiten bereiten. Gibt man der Frage eine Antwort, also entweder eine Zahl - mit oder ohne einen Buchstaben (w, m oder y) dahinter, oder eben die 0, dann bestätigt GnuPG dies, und fragt danach dann ob das so korrekt sei (bei folgender Ausgabe wurde 0 eingegeben): Key does not expire at all Is this correct? (y/n) Dies ist im Normallfall über y zu bejahen. Im Falle eines n wie no bzw. Nein, was bei dieser Frage übrigens die Standardantwort wäre, fragt GnuPG erneut, wann der Schlüssel verfallen soll. Nach die Frage schlieÿlich positiv beantworten worden ist, verlangt GnuPG eine reale Benutzerkennung zur Identikation des Schlüssels. Die Frage dazu sieht so aus: You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: Hier ist nun der richtige, persönliche Name anzugeben. Als Beispiel wird im Folgenden der Vorschlag von GnuPG Heinrich Heine verwendet. Hat man den Namen eingegeben, fragt GnuPG nach der Adresse, und danach nach einem optionalen Kommentar, der zwischen dem Namen und der Adresse, wie oben gezeigt, eingefügt wird. Hat man diese Punkte eingegeben, zeigt GnuPG die Benutzerkennung, und fragt noch einmal nach, ob man damit zufrieden ist, oder noch etwas ändern möchte. Ist dies der Fall, ist der entsprechend eingeklammerte Buchstabe zu drücken, und die Option ist dann änderbar. Danach erfolgt wieder die Abfrage, bis man mit O für Okay bestätigt. Bei Q wie Quit wird GnuPG ohne Schlüsselerstellung beendet. Hat man Okay gedrückt, so fragt GnuPG nach einer Passphrase, dem Passwort für den Schlüssel. Dieses muss mit äuÿerster Paranoia gewählt, aber dennoch für sich selbst einfach zu merken sein. Es muss zu komplex sein, um durch Angreifer erraten werden zu können. Dieses Passwort kann ein kompletter Satz sein, es kann aber auch eine sinnlose Ansammlung von Zeichen, Zahlen Copyright 2005 seyecon IT-Consulting 13

14 2.1. DER GNU PRIVACY GUARD KAPITEL 2. PGP IM EINSATZ und Buchstaben sein, zum Beispiel nfda)34/34bkshja/34aöd$a0js4. Dies kann sich zwar niemand merken, aber es wäre äuÿerst sicher - wäre es nicht hier abgedruckt. Es darf aber auch ein Satz sein wie Donnerstags ist es immer kälter wie drauÿen, da es Nachts dunkler ist als drinnen.. Auch hier gilt natürlich, dass dieser Satz, nachdem er hier abgedruckt ist, nicht mehr sicher ist. Erschweren kann und sollte man das Finden des Passwortes natürlich noch durch Rechtschreibfehler und falsche Groÿ-/Kleinschreibung sowie dubioser Interpunktion, da dies die Verwendung von Wörterbüchern bei Brute-Force-AttackenB sinnlos werden lässt. Dieses Passwort wird immer benötigt, wenn der private Schlüssel zum Einsatz kommt - also bei jeder , die verschlüsselt erhalten wird, und bei jeder , die signiert bzw. verschlüsselt wird. Hat man das Passwort einmal eingetippt, so muss man es aus Sicherheitsgründen wiederholen, um Tippfehler auszuschlieÿen, die den Schlüssel später unbrauchbar werden lieÿen. Danach geht die Generation des Schlüssels los. Man kann GnuPG helfen, einen besonders sicheren Schlüssel zu generieren, indem man auf der Tastatur wie wild herumtippt, dazu die Maus bewegt und intensive Festplattenoperationen im Hintergrund laufen lässt. Diese Operationen beeinussen den Zufallsgenerator im Prozessor in Bezug auf Erzeugung von unterschiedlichen zufälligen Zahlen. Während der Schlüsselerzeugung werden besonders unterschiedliche Zahlen ohne Zusammenhang zueinander benötigt, so dass es von groÿer Wichtigkeit ist, dass der Zufallsgenerator diese so auch liefert. Es werden nun viele Punkte, Plus-Zeichen und andere Symbole auf dem Bildschirm erscheinen, die den Prozess der Schlüsselerzeugung darstellen. Ist die Generation abgeschlossen, sieht die Anzeige ungefähr so aus: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy > <.+++++> >+++++< >+++++< <.+++++> We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy > > >+++++.< ^^^ gpg: key 994F5F06 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024D/994F5F Key fingerprint = 599B 1D02 7B A64 79A3 CD81 A F 5F06 uid Heinrich Heine <h.heine@seyecon.de> sub 2048g/927BDFA bash$ 14 Copyright 2005 seyecon IT-Consulting

15 KAPITEL 2. PGP IM EINSATZ 2.1. DER GNU PRIVACY GUARD Ab diesem Zeitpunkt ist der Schlüssel einsatzbereit. Von nun an können mit Hilfe dieses Schlüssels Dateien und s verschlüsselt und/oder signiert werden Die Widerrufurkunde Das Erste, was man mit einem neu erzeugten Schlüssel tun sollte, ist seine Widerrufurkunde (englisch Revocation Certicate) zu erstellen. Vergisst man das Passwort, wird der Schlüssel kompromittiert oder geht verloren, so kann durch die Widerrufurkunde der Schlüssel generell für ungültig erklärt (widerrufen) werden. Widerrufene öentliche Schlüssel sind nach wie vor noch zur Überprüfung von Signaturen einsetzbar, der geheime Schlüssel ist nur noch zum entschlüsseln von Nachrichten einsetzbar. Verschlüsselt oder signiert werden kann mit einem einmal widerrufenen Schlüssel nichts mehr. Ein einmal erfolgter Widerruf ist unumkehrbar. Mit dem folgenden Befehl lässt sich eine Widerrufurkunde zum oben erzeugten Schlüssel generieren, und in der Datei revocation_cert.asc abspeichern: bash$ gpg --output revocation_cert.asc --gen-revoke 994F5F06 Alternativ kann man statt der Schlüssel-ID (994F5F06) auch einen Teil der Benutzer-ID, zum Beispiel die -Adresse angeben: bash$ gpg --output revocation_cert.asc --gen-revoke Lässt man die Option --output revocation_cert.asc weg, so wird die Urkunde auf der Standardausgabe, also der Shell ausgegeben. Sie ist theoretisch auch ausdruckbar, und kann über entsprechende Shell-Akrobatik direkt von der Erzeugung an den Drucker gegeben werden, aber am einfachsten ist es, sie in Form einer Datei auf einem sicheren Medium, zum Beispiel einer CD-ROM aufzubewahren. Dieser Datenträger darf natürlich niemandem in die Hände gelangen, da hierüber der Schlüssel nutzlos gemacht werden könnte. Eine Möglichkeit zur Aufbewahrung ist zum Beispiel ein Tresor oder ein Bankschlieÿfach. Eine 3,5 Diskette eignet sich hierfür nicht, da ihre Lebensdauer und Zuverlässigkeit in Puncto Datensicherheit nicht besonders hoch sind Schlüsselaustausch Die wichtigste Vorraussetzung zur verschlüsselten bzw. signierten Kommunikation ist der Austausch der öentlichen Schlüssel. Tauscht man diese nicht aus, kann man die Verschlüsselung nur zur Absicherung der eigenen Daten, nicht aber zu Kommunikation mit anderen verwenden. Hierzu gibt es eine Vielzahl von Möglichkeiten: Die einfachste Möglichkeit ist die, dass man seinen Schlüssel auf einen sogenannten Schlüsselserver (Keyserver) hochlädt. Von diesem kann dann jeder Teilnehmer einer Kommunikation die öentlichen Schlüssel der anderen Teilnehmer herunterladen, und in den eigenen Schlüsselbund einfügen. Danach kann verschlüsselt kommuniziert werden, und mögliche Signaturen können veri- ziert werden. Desweiteren gibt es die Möglichkeit, seinen öentlichen Schlüssel in eine Datei zu exportieren, und auf dem Dateisystem abzulegen. Man kann diese dann direkt per an ausgewählte Empfänger verschicken, oder auf einem Website zum Herunterladen bereitstellen. Man selbst muss natürlich, bevor eine Kommunikation mit anderen auf verschlüsselte Weise führen kann, ebenfalls deren öentliche Schlüssel besitzen, und im eigenen Schlüsselbund führen. Hierzu muss man den jeweiligen öentlichen Schlüssel importieren - entweder von einem Schlüsselserver oder aus einer Datei, die man auf irgendeine Weise erhalten hat Exportieren öentlicher Schlüssel Exportieren des öentlichen Schlüssels auf einen allgemeinen Schlüsselserver: Diese Variante entspricht der Philosophie von PGP am meisten: Man stellt aller Welt über eine vereinheitlichte Copyright 2005 seyecon IT-Consulting 15

16 2.1. DER GNU PRIVACY GUARD KAPITEL 2. PGP IM EINSATZ Schnittstelle seinen öentlichen Schlüssel zur Verfügung, so daÿ jeder von einem selbst signierte s auf Authentizität überprüfen, und verschlüsselte Nachrichten an einen selbst schicken kann. Bei GnuPG erreicht man diese Exportvariante durch die Kommandozeilen-Option --send-keys. bash$ gpg --send-keys 994F5F06 gpg: sending key 994F5F06 to hkp server random.sks.keyserver.penguin.de bash$ Hierzu muss allerdings in der GnuPG-Kongurationsdatei ein enstprechender Server konguriert sein. Exportieren des öentlichen Schlüssels in eine Datei: Über die Kommandozeilen-Option --export lässt sich ein bestimmter Schlüssel oder auch der ganze Schlüsselbund in eine Datei exportieren. InVerbindung mit der Option --armor lässt sich die Datei dann auch problemlos über s verteilen. Gibt man folgenden Befehl ein: bash$ gpg --armor --export -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.1 (GNU/Linux) [...] -----END PGP PUBLIC KEY BLOCK----- bash$ so bekommt man eine Menge Zeilen von aneinander gereihten Zahlen und Buchstaben ausgegeben - der öentliche Schlüssel in ASCII-Armor. So kann man damit zunächst einmal nicht viel anfangen. Man könnte ihn nun per Copy 'n Paste in einen Editor einfügen und in eine Datei speichern, doch geht das auch leichter, und zwar durch Umleitung der Standardausgabe für den gpg-befehl: bash$ gpg --armor --export h.heine@seyecon.de > hheine.asc bash$ Dieser Befehl erzeugt eine Datei namens hheine.asc im aktuellen Verzeichnis. Daher ist es wichtig, darauf zu achten, in welchem Verzeichnis man sich gerade in der Shell bendet. Die Datei enthält exakt dasselbe, was der Befehl ohne die Umleitung > hheine.asc vorher am Bildschirm ausgegeben hat. Diese Datei kann man nun auf einem Website zum Herunterladen für die Allgemeinheit veröffentlichen, per verteilen, oder aber selbst von Hand auf einen Schlüsselserver hochladen. Unter der Adresse die auf die Adresse vkd/getwelcomescreen.event weiterleitet, ndet man direkt ein Formular das Schritt für Schritt erklärt, wie man seinen Schlüssel hochladen kann. Es spielt dabei keine Rolle, auf welchen Keyserver man seinen Schlüssel nun genau hochlädt, da sich die Keyserver untereinander synchronisieren. Dies kann zuweilen etwas dauern. Dieser Server funktioniert leider nicht direkt in zusammenarbeit mit GnuPG, sondern erfordert zwingend die Verwendung eines Webbrowsers Importieren öentlicher Schlüssel Importieren öentlicher Schlüssel von einen allgemeinen Schlüsselserver: So, wie man mit GnuPG Schlüssel an Schlüsselserver senden kann, kann man natürlich auch welche herunterladen. Der GnuPG-Kommandozeilenoption hierzu lautet --recv-keys <key-id>, die Ausgabe sieht nach einem erfolgreichen Import so aus: 16 Copyright 2005 seyecon IT-Consulting

17 KAPITEL 2. PGP IM EINSATZ 2.1. DER GNU PRIVACY GUARD bash$ gpg --recv-keys 994F5F06 gpg: requesting key 994F5F06 from hkp server subkeys.pgp.net gpg: key 994F5F06: public key "Heinrich Heine imported gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Total number processed: 1 gpg: imported: 1 bash$ Hier wurde der Schlüssel mit der Key-ID 994F5F06, der in Abschnitt , Seite 12 erzeugt und in exportiert wurde, neu in ein Schlüsselbund importiert. Diese Beispiel geht davon aus, dass der Schlüssel vorher nicht im Schlüsselbund war. Hat sich der Schlüssel schon im Schlüsselbund befunden, so schaut GnuPG nach, ob sich an dem Schlüssel etwas geändert hat, übernimmt diese Änderungen dann gegebenenfalls, oder lässt den Schlüssel andernfalls unverändert. Der Import muss nicht zwingend über die Key-ID laufen, man kann hier auch zum Beispiel die -Addresse desjenigen angeben, dessen Schlüssel man importieren möchte - die ist für gewöhnlich bekannter. Die Option --refresh-keys schaut für alle sich im Schlüsselbund bendlichen Schlüssel auf dem Schlüsselserver nach Aktualisierungen nach. Importieren öentlicher Schlüssel aus Dateien: Einen Schlüssel über eine Datei zu importieren erfolgt bei GnuPG über die Kommandozeilenoption --import <datei>. GnuPG erwartet hierbei eine ASCII 2 -Datei wie sie in exportiert wurde. Folgendes Beispiel importiert die Datei hheine.asc in ein Schlüsselbund: bash$ gpg --import hheine.asc gpg: key 994F5F06: public key "Heinrich Heine <h.heine@seyecon.de>" imported gpg: Total number processed: 1 gpg: imported: 1 bash$ Auch diese Beispiel geht wieder davon aus, dass der Schlüssel vorher nicht im Schlüsselbund war. Hat sich der Schlüssel schon im Schlüsselbund befunden, so schaut GnuPG nach, ob sich an dem Schlüssel etwas geändert hat, übernimmt diese Änderungen dann gegebenenfalls, oder lässt den Schlüssel andernfalls unverändert. Über die in angebene Adresse ( bzw pgp.com/vkd/getwelcomescreen.event) kann man solche Dateien erhalten Ver- / Entschlüsselung von Dokumenten Die Verschlüsselung von Dokumenten mit GnuPG erfolgt ebenso einfach, wie der Im- und Export von Schlüsseln. Für den Fall der Versendung per ist die Option --armor ratsam, da sie aus den binären Daten, die durch die Verschlüsselung entstehen reine ASCII-Daten macht, mit denen das -Protokoll besser arbeiten kann 3. Auf der Kommandozeile hat man verschiedene Möglichkeiten, einen Text mit Hilfe von GnuPG zu verschlüsseln. Das einfachste ist, GnuPG mit der Option --encrypt un dem Namen der zu verschlüsselnden Datei aufzurufen. Die Option --encrypt ist mit der Option --sign kombinierbar, 2ASCII: American Standard Code for Information Interchange. Reine Textdateien werden oft ASCII-Dateien genannt, wenn sich die in ihnen enthaltenen Zeichen rein auf die ersten 128 Zeichen des ASCII-Zeichensatzes beschränken. Daher rührt auch die Datei-Endung.asc der Schlüsseldateien. 3 s dürfen per Denition nur Textdaten enthalten, daher müssen binäre Daten vor der Versendung umgewandelt werden, was eine Vergröÿerung der zu versendenden Datenmenge in nicht unbeträchtlichem Maÿe bedeutet. Dies ist in der Reduktion des Zeichensatzes von 8 Bit (256 Zeichen) auf 6 Bit (64 Zeichen) begründet, sowie der Tatsache, dass die Umwandlung verlustfrei sein muss. Copyright 2005 seyecon IT-Consulting 17

18 2.1. DER GNU PRIVACY GUARD KAPITEL 2. PGP IM EINSATZ wodurch eine signierte und verschlüsselte Datei erzeugt wird. --sign ist auch ohne --encrypt aufrufbar. Dies wird in Abschnitt 2.1.5, Seite 19 genauer behandelt. Beispiel: bash$ gpg --armor --encrypt demo.txt You did not specify a user ID. (you may use "-r") Current recipients: Enter the user ID. End with an empty line: v.seifert@seyecon.de Current recipients: 4096g/ E "Volkmar Seifert <v.seifert@seyecon.de>" Enter the user ID. End with an empty line: bash$ In diesem Beispiel wird die Datei demo.txt mit dem öentlichen Schlüssel mit der Benutzer-ID v.seifert@seyecon.de verschlüsselt, und kann nur von dem Besitzer des dazugehörigen geheimen Schlüssels wieder entschlüsselt werden. GnuPG legt die verschlüsselte Version in einer Datei ab, die den Originaldateinamen (samt Endung) enthält, der um ein.asc erweitert ist. In dem obigen Beispiel ist das dann also demo.txt.asc. Lässt man die Option --armor weg, so endet die von GnuPG erzeugte Datei nicht auf.asc, sondern auf.gpg, und enthält die verschlüsselten Daten in binärer Form. Die Entschlüsselung von Dokumenten mit GnuPG erfolgt analog zur gerade erklärten Verschlüsselung - die Option heisst statt --encrypt nur eben --decrypt. Wurde die Option sign verwendet, wird an dieser Stelle nicht nur entschlüsselt, sondern auch die Unterschrift überprüft. Passt die Unterschrift zum Text und zum Schlüssel, so wird entschlüsselt und das Ergebnis auf der Standardausgabe (die Komanndozeilenoberäche in diesem Fall) ausgegeben. Will man das Ergebnis in einer Datei geschrieben haben, empehlt sich die Option --output (kann mit -o abgekürzt werden), die vor --decrypt stehen muss, und von dem Zieldateinamen gefolgt wird. Die Option armor braucht bei der Entschlüsselung nicht mit angegeben zu werden, GnuPG erkennt dies automatisch. Beispiel: bash$ gpg -o demo.txt --decrypt demo.txt.asc.enc You need a passphrase to unlock the secret key for user: "Volkmar Seifert <v.seifert@seyecon.de>" 4096-bit ELG-E key, ID E, created (main key ID 51FA35CD) gpg: encrypted with 4096-bit ELG-E key, ID E, created "Volkmar Seifert <v.seifert@seyecon.de>" bash$ Hier wurden die entschlüsselten Daten gleich direkt in die Datei demo.txt geschrieben, ohne das auf dem Bildschirm die Daten ausgegeben wurden. Bevor natürlich entschlüsselt werden kann, muss zunächst einmal der geheime Schlüssel durch die Passphrase freigegeben werden, wie im Beispiel (Zeile user:) ersichtlich. War die Datei ebenfalls signiert, so erscheinen, bei entsprechender Übereinstimmung, zusätzlich noch folgende zwei Zeilen: gpg: Signature made Wed Jun 8 10:48: CEST using DSA key ID 51FA35CD gpg: Good signature from "Volkmar Seifert <v.seifert@seyecon.de>" 18 Copyright 2005 seyecon IT-Consulting

19 KAPITEL 2. PGP IM EINSATZ 2.1. DER GNU PRIVACY GUARD Signieren von Dokumenten Dokumente können auf verschiedene Arten signiert werden: Mit einer Klartextsignatur (--clearsign) Mit einer abgetrennten Signatur (--detach-sig) Mit Kombination aus komprimierten Daten und der Signatur in einer Datei (--sign) Da bei einer Signierung immer der eigene geheime Schlüssel verwendet wird, ist hier natürlich jedes Mal die entsprechende Passphrase notwendig Die Klartextsignatur (--clearsign) Diese Variante kombiniert die Daten in ihrer Ursprungsform mit der Signatur in einer Datei. Dies ist dann sinnvoll, wenn Empfänger auch ohne Überprüfung der Signatur (und somit ohne Extraktionsmöglichkeit) die Daten lesen können sollen. Diese Variante empehlt sich vor allem für ASCII-Dateien, und kann z.b. für s eingesetzt werden. bash$ gpg --clearsign demo.txt You need a passphrase to unlock the secret key for user: "Volkmar Seifert <v.seifert@seyecon.de>" 1024-bit DSA key, ID 51FA35CD, created bash$ In diesem Beispiel legt GnuPG eine Datei namens demo.txt.asc an. Man kann den Zieldateinamen auch durch die Option -o <dateiname> verändern. Diese Datei enthält den Text der Datei demo.txt und die Signatur. Die Datei sieht in etwa so aus: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ein kleiner Demotext -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) [...] -----END PGP SIGNATURE----- Der Teil Zwischen den ersten beiden Zeilen und der Zeile -----BEGIN PGP SIGNATURE----- enthält den signierten Text. Dieser Teil iesst bei der Überprüfung ein, wenn etwas vor der Zeile -----BEGIN PGP SIGNED MESSAGE----- oder nach der Zeile -----END PGP SIGNATURE----- steht, so wird es ignoriert Die abgetrennte Signatur (--detach-sig) Diese Variante empehlt sich beim Einsatz mit binären Daten, zum Beispiel für die Überprüfung der Korrektheit von Programmen, die man zum Herunterladen anbietet. Hierbei wird eine separate Datei angelegt, die nur die Signatur enthält. Diese kann dann in Verbindung mit der Originaldatei dazu verwendet werden, die Originaldatei zu überprüfen. Diese Variante legt, wenn man GnuPG keine weitere Option mitgibt, eine separate Datei mit der der Endung.sig an (Dateinamensaufbau siehe Abschnitt 2.1.4, Seite 17). Diese Datei enthält die Signatur in binärer Form. Verwendet man zusätzlich die Option --armor, so endet der Dateiname auf.asc, und die Datei beinhaltet die Unterschrift in ASCII-Form. Dies ist die empfohlene Variante, da die meisten Protokolle im Internet auf Text optimiert sind, und die ASCII-Form ausserdem unter den PGP- Implementationen die kompatibelste Repräsentation darstellt. Copyright 2005 seyecon IT-Consulting 19

20 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ bash$ gpg --armor --detach-sign demo.txt You need a passphrase to unlock the secret key for user: "Volkmar Seifert <v.seifert@seyecon.de>" 1024-bit DSA key, ID 51FA35CD, created bash$ Dieses Beispiel legt eine digitale Signatur in ASCII-Repräsentation mit Namen demo.txt.asc an. Ihr Inhalt sieht ungefähr so aus: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) [...] -----END PGP SIGNATURE----- Sie enthält also im Prinzip den zweiten Teil der Datei aus dem obigen Beispiel Daten und Signatur komprimiert kombiniert (--sign) Mit dieser Option schreibt GnuPG sowohl die Daten wie auch die Signatur in binärer Form in eine gemeinsame Datei. Über die Zusatzoption --armor kann diese Datei im ASCII-Format geschrieben werden, die Daten darin sind jedoch nur über eine Extraktion, die natürlich den öentlichen Schlüssel des Senders erfordert, zugänglich. Diese Option ist mit der Option --encrypt kombinierbar. Wie bei der Verschlüsselung wird bei dieser Form der Signierung eine Datei mit der Endung.gpg angelegt, wenn die Option --armor nicht angegeben wird, die Daten in der Datei liegen in binärer Form vor. Eine Datenextraktion erfolgt - wie bei der Verschlüsselung - über die Option decrypt. Sinnvollerweise wird diese Option zusammen mit der Option output bzw. -o verwendet, um die extrahierten Daten direkt in eine Datei zu schreiben. GnuPG gibt sie sonst - wie bei der Entschlüsselung von Daten schon beschrieben - direkt auf der Standardausgabe, in diesem Fall also der Shell, aus. Dies ist vor allem bei Binärdaten weder erwünscht noch vorteilhaft. bash$ gpg --armor --sign demo.txt You need a passphrase to unlock the secret key for user: "Volkmar Seifert <v.seifert@seyecon.de>" 1024-bit DSA key, ID 51FA35CD, created bash$ Hier wird die Datei demo.txt direkt in die Unterschrift eingebettet und als ASCII-formatierte Datei unter dem Namen demo.txt.asc abgelegt. Diese Datei kann nun auf die gewünschte Weise weitergegeben werden. Folgendes Beispiel zeigt, wie aus der gerade erzeugten Datei wieder die Ausgangsdatei extrahiert werden kann. Hierbei erfolgt automatisch eine Überprüfung der Signatur: bash$ gpg -o demo.txt --decrypt demo.txt.asc gpg: Signature made Thu Jun 9 13:02: CEST using DSA key ID 51FA35CD gpg: Good signature from "Volkmar Seifert <v.seifert@seyecon.de>" bash$ mit GnuPG Nach dem nun der Einsatz von GnuPG auf der Kommandozeile für die wichtigsten Befehle erklärt wurde, ist es Zeit, zum Haupteinsatzgebiet von GnuPG, dem Verschlüsseln und Signieren von 20 Copyright 2005 seyecon IT-Consulting

21 KAPITEL 2. PGP IM EINSATZ MIT GNUPG s überzugehen. Dies erfolgt natürlich nicht auf Kommandozeilenebene, sondern aus dem Mailclient heraus über entsprechende Schnittstellen. Für alle wichtigen Mailclients ist die Einbindung von GnuPG durch Plugins möglich. An dieser Stelle werden Mozilla Thunderbird mit dem Plugin Enigmail und Microsoft Outlook einem Plugin der Firma G-Data erläutert. Beide Plugins sind kostenlos erhältlich und einsetzbar Mozilla Thunderbird / Enigmail Enigmail ist ein plattformunabhängiges Plugin fuer Mozilla Mail, Netscape Mail, und Mozilla Thunderbird. Es setzt die erfolgreiche Installation von GnuPG voraus. Unter der Internetaddresse kann man sich die jeweilig aktuelle Version herunterladen, und dann im entsprechenden Mailclient installieren. Die Prozedur ist bei allen drei genannten identisch, da sie sich eigentlich nur im Namen, ein wenig im Aussehen, und im Lieferumfang unterscheiden: Der Netscape Mailclient ist im Netscape Browserpaket enthalten, ebenso wie der Mozilla Mailclient im Mozilla Browserpaket enthalten ist. Mozilla Thunderbird ist die Auskopplung des Mozilla Mailclients aus dem Browserpaket, und somit ein eigenständiges Projekt geworden. Da die Installation und die Bedienung eben überall identisch ist, wird im folgenden Text stellvertretend der Thunderbird verwendet Die Installation des Plugins erfolgt nach dem Herunterladen des Plugins durch Önen des Menüs Tools (dt. Werkzeuge) im Thunderbird. Dort wird die Option Extensions (dt. Erweiterung) ausgewählt. Es önet sich ein Dialog, in dem die aktuell installierten Plugins aufgelistet werden (Abbildung 2.1). Sind noch keine Plugins installiert, so ist die Liste leer. Unter der Liste sind mehrere Schalt- ächen. Die ganz linke lautet Install. Abbildung 2.1.: Thunderbird Extensions Fenster Hier draufklicken. Es önet sich ein Dialog, in dem man nun die heruntergeladene Datei suchen und mit OK installieren lassen kann. Man wird an dieser Stelle unter Umständen gefragt, ob man das wirklich installieren will, möglicherweise mit dem Hinweis, dass das Plugin nicht zertiziert sei. Diesen Hinweis kann man ignorieren und einfach OK bzw. Ja / Yes anklicken. Ist das Plugin installiert, muss der Thunderbird neu gestartet werden. Ab diesem Zeitpunkt ist das Plugin einsatzbereit. Copyright 2005 seyecon IT-Consulting 21

22 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Die Grundkonguration erfolgt über das neu von Enigmail in den Thunderbird eingefügte Menü Enigmail. Über dieses Menü (siehe Abbildung 2.2) ist alles erreichbar, was mit Enigmail zu hat. Es ist auch im Fenster zum Schreiben der vorhanden, wobei dort dann die oberen (in der Abbildung grauen) Einträge des Menüs angepasst sind, und Einstellmöglichkeiten beinhalten, die besagen, ob Enigmail die aktuelle Mail beim Versenden signieren und / oder verschlüsseln soll. Abbildung 2.2.: Das Enigmail-Menü Über die Option Preferences (dt. Einstellungen) kann man das Grundverhalten und grundlegende Einstellungen von Enigmail verändern. Diese Option önet ein Dialogfenster, in dem man unter anderem die Möglichkeit hat, Enigmail so einzustellen, dass es jede zu versendende signiert, jede zu versendende , wenn ein öentlicher Schlüssel vorhanden ist, verschlüsselt, in welchem Format die Mail dann versendet werden soll (PGP/Mime ist hier empfehlenswert, weil dies die kompatibelste Option ist), und - was natürlich das Wichtigste überhaupt ist - wo Enigmail GnuPG ndet, um die Operationen auch durchführen zu können. Das Einstellungsfenster ist in einzelne Karteikarten, auch Tabs genannt, unterteilt. Im folgenden werden diese Tabs einzeln nacheinander genauer erläutert. Basic (Abbildung 2.3): Hier werden die Grundeinstellungen von Enigmail festgelegt. GnuPG executable path: Hier muss der Pfad zur GnuPG Programmdatei (gpg oder gpg.exe) angegeben werde. Eine Erleichterung zur Suche ist durch die Schaltäche Browse direkt daneben gegeben, hierüber kann die Datei durch einen gewöhnlichen, auch von anderen Programmen bekannten Dateisuch-Dialog der Pfad entsprechend ausgewählt werden. Beispiel für Windows: c:\programme\gnupg\gpg.exe Beispiel für Linux: /usr/bin/gpg oder /usr/local/bin/gpg Additional parameters for GnuPG: Diese Option kann im Normalfall leer gelassen werden. Hier können benutzerspezische Einstellungen an GnuPG eingetragen werden, die das Verhalten von GnuPG direkt beeinussen. Dies ist nur Benutzern zu empfehlen, die sich 22 Copyright 2005 seyecon IT-Consulting

23 KAPITEL 2. PGP IM EINSATZ MIT GNUPG zuvor intensiv mit GnuPG auseinander gesetzt haben, und genau wissen, welche Parameter hier sinnvoll sind. Passphrase settings: Abbildung 2.3.: Enigmail-Konguration: Tab Basic Remember passphrase for... minutes idle time: Für die hier eingestellte Zeit in Minuten merkt sich Enigmail das Passwort des verwendeten Schlüssels. Das Merken erfolgt durch Halten des Passwortes im Arbeitsspeicher. Es wird nicht von Enigmail auf die Festplatte geschrieben. Dies bedeutet, dass Enigmail dass Passwort nach Ablauf der Zeit oder aber beim Beenden von Thunderbird wieder vergisst, je nachdem, was eher zutrit. No passphrase for user: Hat man seinem Schlüssel kein Passwort gegeben (nicht gut), oder verwendet man einen sog. GPG-Agent (siehe Kapitel A, Seite 35), so kann man durch Aktivieren dieser Option Enigmail so kongurieren, dass es nicht weiter danach fragt. Keyserver(s): Diese Option gibt die Schlüsselserver an, die für Enigmail zur Verfügung stehen sollen. Hier kann man im Normalfall die Standardeinstellungen lassen, bzw. die Einstellungen aus Abbildung 2.3 übernehmen. Werden hier mehrere Server angegeben, so sind diese durch Verwendung von Kommata zu trennen. Die Angabe der Server folgt dem normalen Muster eines URL: protokoll://server:port, doch ist diese genaue Angabe in den seltesten Fällen notwendig. Im Normalfall reicht die Angabe des Servernamens mit Domäne, also zum Beispiel random.sks.keyserver.penguin.de. Hier wird dann automatisch nach einem verwendbaren Protokoll gesucht. Die Reset-Schaltäche: Diese Schaltäche setzt alles auf die Standardwerte zurück, wenn man einmal Einstellungen getroen hat, die nicht Vorteilhaft waren, man sich aber nicht mehr an die richtigen Einstellungen erinnert. So erhält man zumindest eine wieder funktionierende Grundkonguration, von der aus man seine eigenen Anpassungen entsprechend wieder vornehmen kann. Copyright 2005 seyecon IT-Consulting 23

24 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Sending (Abbildung 2.4): In diesem Tab stellt man das Standardverhalten von Enigmail beim Versenden von s ein. Encrypt to self: Diese Option bewirkt, dass Enigmail zusätzlich zur Verschlüsselung der ausgehenden mit dem öentlichen Schlüssel des Empfängers die auch noch mit dem eigenen Schlüssel verschlüsselt wird, bevor sie im Ordner für versendete Mail abgelegt wird. Dies bedeutet, dass zum Lesen dieser Mails diese wieder entschlüsselt werden müssen, was Enigmail aber im Normalfall automatisch macht. Es wird nur, falls notwendig, nach dem Passwort vorher gefragt. Always trust user ID: Normalerweise kann nur mit Schlüsseln vertraut werden, die einen bestimmten Vertrauensstatus haben. Schlüssel, denen nicht explizit vertraut wird (muss speziell für jeden neu importierten Schlüssel gemacht werden). Mit dieser Option können alle Schlüssel, unabhängig vom Vertrauensstatus verwendet werden. Abbildung 2.4.: Enigmail-Konguration: Tab Sending Always conrm before sending: Ist diese Option aktiv, so wird bei jedem Versenden einer ein Dialog angezeigt, in dem zu bestätigen ist, dass die Mail verschlüsselt wird, und in der der Schlüssel, der zur Verschlüsselung verwendet wird, ausgewählt werden kann. Die diese Auswahl auch schon implizit über die Empfängeradressen getroen wird, kann durch Deaktivieren dieser Option dieser Dialog unterdrückt werden. Rewrap signed HTML text before sending: Diese Option sollte aktiviert werden, wenn s im HTML-Format per Inline PGP (siehe , Option never use PGP/MIME), versendet werden, da es sonst zu ungültigen Signaturen kommen kann. Die HTML-Mail kann dann allerdings unter Umständen anders ausschauen, als ursprünglich getippt. Allow empty subject: Verschickt man mit dem Thunderbird eine Mail, die keine Betrezeile hat, so beschwert sich Thunderbird für gewöhnlich darüber. Diese Option verhindert das. Es ist aber generell nicht empfehlenswert, s ohne Betrezeile zu verschicken, da immer öfter Viren solch ein Verhalten verwenden, um den Empfänger der Mail dazu zu verführen, die Mail zu önen. 24 Copyright 2005 seyecon IT-Consulting

25 KAPITEL 2. PGP IM EINSATZ MIT GNUPG Allow owed text (RFC 2646): owed text, zu Deutsch Fliesstext, ist ein Text ohne feste Zeilenumbrüche. Die Zeilen werden bei solchen Mails vom Mailclient dort umgebrochen, wo das Fenster zu Ende ist. Diese Form von Text kann in Verbindung mit OpenPGP zu Problemen führen, je nachdem, was der Empfänger für einen Mailclient verwendet. Diese Option, wenn nicht aktiv, verhindert, dass Mails als Fliesstext verschickt werden. Bei Nicht- Fliesstext-Mails wird nach dem 76. Zeichen einer Zeile ein fester Zeilenumbruch im DOS-Stil (CR/LF = Carriage Return / Line feed) eingefügt. Es ist empfehlenswert, diese Option nicht zu aktivieren. Key selection (Abbildung 2.5): Dieses Tab legt das Standardverhalten von Enigmail für die Schlüsselauswahl beim Versenden von s fest. Es können immer nur Schlüssel verwendet werden, die im Schlüsselbund vorhanden sind. Normal Key Selection: Diese Option dient zur normalen Schlüsselauswahl über den Empfänger der . Es kann nur eine der drei Optionen ausgewählt werden. Never display OpenPGP key selection dialog: Ist diese Option aktiv, so fragt Enigmail niemals danach, welcher Schlüssel verwendet werden soll. Kann der Empfänger keinem der Schlüssel im Schlüsselbund zugeordnet werden, obwohl die Option Encrypt if possible aktiv ist, so wird diese als nicht verschlüsselbar eingestuft, und nicht verschlüsselt abgeschickt. Signaturen sind hiervon natürlich nicht betroen, da diese über den eigenen Schlüssel laufen. Display selection when necessary: Aktiviert man diese Option, und sagt, dass eine zu versendende zu verschlüsseln ist, so wird der Schlüsselauswahldialog angezeigt, sollte kein dem Empfänger zuortenbarer Schlüssel im Schlüsselbund aundbar sein, um eine manuelle Auswahl zu ermöglichen. Always display selection: Diese Option besagt Enigmail, den Auswahldialog mit der Liste der Schlüssel im Schlüsselbund immer anzuzeigen, wenn eine Mail verschlüsselt werden soll, auch wenn der passende Schlüssel gefunden und zugeordnet werden konnte. Abbildung 2.5.: Enigmail-Konguration: Tab Key selection Copyright 2005 seyecon IT-Consulting 25

26 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Use Key Selection Rules: Diese Optionen entscheiden darüber, ob und wie die empfängerbasierten Schlüsselauswahlregeln verwendet werden sollen, und ob ein Dialog angezeigt werden soll, wenn für die ausgehende keine Regel deniert ist. Disabled: Die empfängerbasierten Schlüsselauswahlregeln werden nicht verwendet Dene rules manually: Es werden die vom Anwender denierten Regeln angewendet, aber es wird nicht für Regeln zu unbekannten Empfängern gefragt. Prompt for every unknown recipient: Es werden die vom Anwender denierten Regeln angewendet, und für jeden unbekannten Empfänger wird ein Dialog (der Editor für empfängerbasierte Schlüsselauswahlregeln) zur Regelerstellung geönet. Die Schaltäche Dene Rules... : Önet den Editor für empfängerbasierte Schlüsselauswahlregeln. PGP / MIME (Abbildung 2.6): PGP/MIME ist ein durch die RFC 3156 denierter Standard der die Verschlüsselung von Anhängen zusammen mit dem normalen -Körper (der normale -Text), sowie von HTML-Mails und besonderen Zeichensätzen erlaubt. Er ist dem verbreiteteren sogenannten Inline PGP-Standard deutlich überlegen, wird bisher aber leider nur von einer begrenzten, wenngleich stetig wachsenden Zahl von Clients unterstützt. Abgesehen von Enigmail unterstützen noch folgende Mailclients diesen Standard (diese Liste erhebt keinen Anspruch auf Vollständigkeit): Apple Mail, Evolution, KMail, Mulberry, Sylpheed und The Bat!. -Clients, die keine PGP-Unterstützung haben, haben weder mit Inline-PGP noch mit PGP/MIME Probleme. Mails in diesen Clients können, wenn sie nur signiert sind, ohne Schwierigkeiten gelesen werden, und die Anhänge können problemlos gespeichert werden. Verschlüsselte Mails sind mit Mailclients ohne PGP-Unterstützung natürlich überhaupt nicht lesbar. Abbildung 2.6.: Enigmail-Konguration: Tab PGP/MIME Never use PGP/MIME: Erzwingt die Verwendung von Inline-PGP. Mails, die signiert und/oder verschlüsselt werden, werden niemals in PGP/MIME versendet. Allow to use PGP/MIME: Fragt vor der Versendung einer zu verschlüsselnden und/oder zu signierenden nach, ob PGP/MIME oder Inline-PGP verwendet werden soll. Dies ist die Standardeinstellung. 26 Copyright 2005 seyecon IT-Consulting

27 KAPITEL 2. PGP IM EINSATZ MIT GNUPG Always use PGP/MIME: Erzwingt die Verwendung von PGP/MIME, und versendet s, die zu signieren und/oder zu verschlüsseln sind immer im PGP/MIME Format, niemals als Inline-PGP. Hash algorithm: Über diese Option kann der zur Signierung zu verwendende Hash-Algorithmus bestimmt werden. SHA1 ist der derzeit kompatibelste Algorithmus, und ist auch hier die Standardvoreinstellung, es können aber auch noch die Algorithmen MD5 und RIPEMD-160 ausgewählt werden. Advanced (Abbildung 2.7): Hier werden erweiterte Einstellmöglichkeiten angeboten, die verschiedenste Verhaltensweise von Enigmail beeinussen. Encrypt if replying to encrypted message: Unabhängig von den sonstigen Voreinstellungen für das -Konto sorgt diese Option dafür, dass bei Antworten auf oder Weiterleitung von verschlüsselten Nachrichten ebenfalls die Verschlüsselung aktiviert wird. Do not add Enigmail comment in OpenPGP signature: Für gewöhnlich fügt Enigmail eine Kommentarzeile in OpenPGP-verschlüsselte bzw. -signierte Nachrichten, die auf die Verwendung von Enigmail, GnuPG und Thunderbird hinweist. Diese Option verhindert den Kommentar. Treat '' as signature separator: Für gewöhnlich gilt das doppelte Minuszeichen als Separator zwischen dem eigentlichen -Text und der normalen -Textsignatur (die nichts mit einer digitalen Signatur zu tun hat!), und sorgt beim Thunderbird wird für eine hellgraue Darstellung des nach dem folgenden Textes. GnuPG aber ersetzt beim beim digitalen Signieren Zeilen die mit - anfangen mit einem, um dem OpenPGP-Standard zu gehorchen. Dies betrit natürlich auch die eben beschriebene Separatorzeile, die somit ungültig wird. Die Aktivierung dieser Option (Standardeinstellung) sorgt dafür, das sowohl dem OpenPGP-Standard gehorcht wird, aber die Separatorzeile weiterhin ihre Gültigkeit behält. Abbildung 2.7.: Enigmail-Konguration: Tab Advanced Copyright 2005 seyecon IT-Consulting 27

28 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Use gpg-agent for passphrase handling: Standardmäÿig ruft Enigmail GnuPG mit der Option --no-use-agent auf. Dies bewirkt, dass GnuPG, gleichgültig seiner Konguration, auf die Verwendung eines GPG-Agenten verzichtet. Aktiviert man diese Option, wird GnuPG so aufgerufen, dass besagter Agent verwendet wird. Hier ist darauf zu achten, dass die Option No Passphrase for user im Tab Basic aktiviert wird, um Enigmail daran zu hindern, selbst nach dem Passwort zu fragen. Somit wird dann die gesamte Passwortbehandlung an den Agenten abgegeben, der dafür zuständig ist, das Passwort, wenn dem nicht schon so geschehen sein sollte, vom Benutzer abzufragen. Zum Thema GPG-Agent siehe auch Kapitel A, Seite 35 Do not use < and > to specify addresses (for Hushmail keys): Hushmail ist ein Anbieter OpenPGP via Web. Die von Hushmail generierten Schlüssel sind allerdings nicht vollständig mit OpenPGP kompatibel. Folgt man dem Standard, so sind E- Mail-Adressen von spitzen Klammern eingefasst (z.b. doch Hushmail ignoriert dies. Enigmail verlässt aber sich aus Sicherheitsgründen auf diese Klammern, doch muss dieses Verhalten für die Verwendung von Hushmail-Schlüsseln abgeschaltet werden. Die Aktivierung dieser Option verhindert die Einklammerung von -Adressen mit spitzen Klammern. Hide S/MIME Buttons/Menus: Diese Option wird nur in Mozilla Clients angezeigt, nicht aber im Thunderbird. Die S/MIME Optionen werden nach der Installation von Enigmail versteckt, um Verwirrung beim Benutzer zu vermeiden. Die Deaktivierung dieser Option bewirkt, dass die S/MIME Menüs und Schaltächen wieder angezeigt werden. Im Thunderbird wird diese Option deshalb nicht angezeigt, weil hier die Werkzeugleiste (Toolbar) durch den Benutzer entsprechend angepasst werden kann. Load MIME parts on demand (IMAP folders): Bei der Verwendung von IMAP- Ordnern kann es passieren, dass Nachrichten grösser 40kb nicht richtig entschlüsselt werden. Dies hängt damit zusammen, das der Thunderbird IMAP-Attachments erst auf Anforderung lädt, und nicht weiss, dass die verschlüsselte Nachricht eigentlich kein echter Anhang ist. Durch die Deaktivierung dieser Option werden PGP/MIME-Nachrichten trotz Verwendung von IMAP-Servern und ungeachtet ihrer Grösse immer richtig entschlüsselt Die Pro-Konto-Konguration Im Thunderbird ist es möglich, mehrere -Konten gleichzeitig zu verwalten und parallel zueinander zu verwenden. Wie aus dem bisherigen Text zu entnehmen ist, sind PGP-Schlüssel alle -Adressbezogen, gelten also nur für eine bestimmte -Adresse. Hat nun aber mehrere -Konten im Thunderbird, so ist es natürlich wichtig, zu dierenzieren, welches Konto nun welchen Schlüssel (man kann ja auch mehrere Schlüssel besitzen) verwenden soll. Aus diesem Grund gibt es noch eine Pro-Konto-Konguration, in der für jedes Konto individuell die OpenPGP- Unterstützung gewährt werden, und die für das jeweilige Konto gültigen Voreinstellungen getroen werden kann. Diese Pro-Konto-Konguration ist im Standard-Dialog Konto-Einstellungen enthalten. Dieser Dialog wird über Edit / Account Settings (Bearbeiten / Konto Einstellungen) aufgerufen. Die Abbildung 2.8 zeigt diesen Dialog mit der bereits ausgewählten OpenPGP-Einstellungsseite. 28 Copyright 2005 seyecon IT-Consulting

29 KAPITEL 2. PGP IM EINSATZ MIT GNUPG Abbildung 2.8.: Enigmail-Konguration: Pro-Konto Einstellungen Um überhaupt für ein Konto OpenPGP-Unterstützung durch Enigmail zu erhalten, muss die Option Enable OpenPGP support (Enigmail) for this identity aktiviert sein, die per Standardeinstellung deaktiviert ist. Diese Option betrit allerdings nur die aktive Nutzung von OpenPGP im Sinne von Verschlüsseln und Signieren. Die Entschlüsselung und Verkation von digitalen Signaturen erfolgt immer und unabhängig von den hier getroenen Einstellungen, da diese Operationen Kontenunabhängig erfolgen. Nach der Aktivierung dieser Option stehen die folgenden Optionen zur Verfügung: Use address of this identity to identify OpenPGP-Key: Diese Option kann verwendet werden, wenn man keine spezische Schlüssel-ID angeben möchte, sondern die -Adresse des Kontos zur Schlüsselidentikation verwenden möchte. Dies ist nur empfehlenswert, wenn man nicht mehrere Schlüssel mit gleichen -Adressen hat, was theoretisch möglich ist. Use specic OpenPGP key ID (0x1234ABCD): Über diese Option kann man einen ganz bestimmten Schlüssel zur Verwendung denieren. Weiss man seine Schlüssel-ID auswendig, so kann man sie in das Eingabefeld eingeben, ansonsten kann man sich den richtigen Schlüssel über die Schaltäche neben dem Eingabefeld aus dem Schlüsselbund heraussuchen. Es sind natürlich nur Schlüssel auswählbar, zu denen ein geheimer Schlüssel vorliegt. Bei der manuellen Angabe der Schlüssel-ID ist das Eingabeformat zu beachten: Da die Schlüssel-ID eine Zahl in hexadezimaler Repräsentation ist, also Zahlen von 1 bis 9 und Buchstaben von A bis F für Zahlen verwendert, um einen Zahlenraum von 1 bis 16 über nur eine einzige Zier abbilden zu können, muss der ID ein 0x (Null-X) vorangestellt werden. Copyright 2005 seyecon IT-Consulting 29

30 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Message Composition Default Options: Diese Optionen stellen das Verhalten von Enigmail für das Versenden von s über dieses Konto ein. Sign non-encrypted messages by default: Aktiviert man diese Einstellung, so werden alle nicht-verschlüsselten Nachrichten standardmäÿig bei Versendung signiert. Es ist daher äuÿerst empfehlenswert, diese Einstellung zu aktivieren, um eben auch die Authentizität von nicht-verschlüsselten s zu gewährleisten. Sign encrypted messages by default: Diese Einstellung veranlasst Enigmail, alle verschlüsselt zu versendenden s ebenfalls zu signieren. Diese Einstellung sollten ebenso wie die für nicht-verschlüsselte s immer aktiviert sein. Encrypt messages by default: Mit dieser Option versucht Enigmail jede zu versendende Mail zu verschlüsseln, solange ein öentlicher Schlüssel für den Empfänger im Schlüsselbund verhanden ist. Wie verfahren wird, wenn kein Schlüssel verfügbar ist, hängt von den in Abschnitt , Absatz Key selection erklärten Einstellungen ab. Send 'OpenPGP' Header: Diese Optionen ermöglichen das automatische mitsenden der Schlüssel-ID und einer Adresse, von der der öentliche Schlüssel des Versenders heruntergeladen werden kann, sie sind optional. Diese Informationen werden im -Header mitgesendet, und können von entsprechender OpenPGP-kompatibler Software ausgewertet werden. Send OpenPGP Key ID: Sendet die Schlüssel-ID des Absenders (also die eigene), die zum signieren dieser Mail verwendet wurde, mit. Send URL for key retrieval: Sendet eine URL mit, von der aus der öentliche Schlüssel heruntergeladen werden kann. Die Schaltäche Advanced (Erweitert) önet den Dialog für die Grundeinstellungen von Enigmail, die im Abschnitt , Seite 22 genauer erläutert werden Die tägliche Verwendung Die tägliche Verwendung des Plugins ist sehr einfach, intuitiv, und zum grössten Teil sogar transparent, also unsichtbar im Hintergrund. Über das sog. OpenPGP Key Management kann man Schlüssel generieren, diese auf vorkon- gurierte Schlüsselserver hochladen, von diesen wiederum andere Schlüssel herunterladen. Siehe hierzu auch Abschnitt , Seite 30. Die Signierung und Verschlüsselung wird transparent von Enigmail direkt beim Versenden durchgeführt, so denn es für die jeweilige erwünscht ist, und ein zum Empfänger der passender öentlicher Schlüssel im Schlüsselbund gefunden werden kann. Diese Zuordnung kann durch Regeln beeinusst werden, die man sich nach belieben anlegen kann. Signiert man seine ausgehenden s automatisch, ist das einzige, das zu tun ist, die Passwortabfrage korrekt zu beantworten. Je nachdem, wie Enigmail konguriert ist, kann diese Abfrage von Enigmail direkt bei jeder Signierung erfolgen, oder Enigmail merkt sich die Passphrase für einen bestimmten Zeitraum. Man kann Enigmail auch die Kontrolle über das Passwort entziehen, und an einen sogenannten Agent übertragen. Die hierzu notwendigen Einstellungen in Enigmail sind im Abschnitt , Seite 22 beschrieben. Auf Agenten selbst wird in Anhang A, ab Seite 35, genauer eingegangen Die Schlüsselbundpege Die Pege des Schlüsselbunds ist eine nicht ganz unwichtige Aufgabe. Hier gehören zum Beispiel das Importieren und Exportieren von Schlüsseln dazu, das Setzen von Vertrauensstati, und das Signieren von Schlüsseln. All diese Arbeiten können von Enigmail durchgeführt werden. Enigmail 30 Copyright 2005 seyecon IT-Consulting

31 KAPITEL 2. PGP IM EINSATZ MIT GNUPG stellt hierzu, ebenfalls über das Enigmail-Menü, das sog. OpenPGP Key Management zur Verfügung. Dies ist ein Dialogfenster, das parallel zum Thunderbird verwendet werden kann. Abbildung 2.9 zeigt den OpenPGP Key Manager. Abbildung 2.9.: Enigmail: OpenPGP Key Manager Hauptbestandteil des OpenPGP Key Managers ist die Liste, in der alle Schlüssel des Schlüsselbundes aufgeführt sind. Fett gedruckte Einträge haben als Typ pub/sec stehen, was bedeutet, dass zu diesen Schlüssel sowohl der öentliche wie auch der geheime Schlüssel zur Verfügung stehen. Die normal geschriebenen Einträge enthalten nur öentliche Schlüssel, weshalb dort unter Type auch nur pub steht. Desweiteren sieht man dieser Liste auch automatisch die Vertrauensstufe an. Schlüssel mit geheimem Schlüssel haben in der Regel den höchsten Vertrauensstatus ultimate. Steht nichts unter Calculated Trust oder unter Owner Trust, so wird dem Schlüssel derzeit überhaupt nicht vertraut, und er steht zu Verschlüsselung nur dann zur Verfügung, wenn die entsprechende Kongurationsoption so eingestellt ist, das Enigmail auch die Schlüssel verwenden darf, denen nicht vertraut wird. Die ersten beiden Spalten dürften recht selbsterklärend sein. Das Erzeugen von Schlüsseln über den OpenPGP Key Manager ist recht einfach. Im Menü gibt es ganz rechts einen Eintrag namens Generate. Diese Menü hat zwei Einträge, deren Verfügbarkeit sich danach richtet, ob ein Schlüssel mit geheimem Schlüssel in der Liste markiert ist, oder nicht. Die Einträge lauten New Key und Revocation Certicate. Die generellen Bedeutungen sind bereits in Abschnitt , Seite 12 behandelt worden, daher wird hier nun nur noch auf die Bedienung von Enigmail selbst eingegangen. Um einen neuen Schlüssel zu erzeugen, wählt man natürlich die Option New Key aus, woraufhin der in Abbildung 2.10 gezeigte Dialog erscheint. Die Auswahl der Identität für den neuen Schlüssel lässt sich direkt aus der Thunderbird-Identität erzeugen, und auch entsprechend in dem zu dieser Identität gehörenden Konto eintragen. Im folgenden werden die einzelnen Elemente des Dialogfensters detailliert erläutert. Copyright 2005 seyecon IT-Consulting 31

32 2.2. MIT GNUPG KAPITEL 2. PGP IM EINSATZ Abbildung 2.10.: Enigmail: Schlüsselerzeugung Account / User ID: Das Thunderbird-Konto, das als Identität für den Schlüssel hergenommen werden soll. Use generated key for selected identity: Konguriert die Pro-Konto-Einstellungen so, dass für das angebene Konto speziell dieser neu generierte Schlüssel verwendet wird. Passphrase No Passphrase: Diese Option sollte man prinzipiell nicht verwendent. Sie ermöglicht jedem, der auf irgendeine Weise Zugri auf den geheimen Schlüssel erhält, diesen zu verwenden - ohne jede Form von Schutz. Passphrase / Passphrase (repeat): In diese zwei Eingabefelder ist das das gewünschte Passwort, welches diesen Schlüssel schützen soll, einzutragen. Es muss aus Sicherheitsgründen zweimal eingegeben werden, damit sicher gestellt ist, dass das gewählte Passwort so absicht ist, und sich nicht zwischendurch versehentlich vertippt wurde. Die Darstellung der Zeichen des Passwortes erfolgt durch eine Maskierung mit Sternchen. Pro Zeichen wird ein Sternchen in die Eingabefelder geschrieben. Comment: Hier kann ein Kommentar erfolgen (z.b. (privat) oder (work) oder so etwas in der Art). Die Eingabe in dieses Feld ist optional, es kann auch freigelassen werden. Key Expires in / Key does not expire: Wenn man möchte, dass der Schlüssel ein Ablaufdatum hat, so kann man es hier eintragen. Die Bedeutung und die Konsequenzen von Ablaufdaten eines Schlüssels sind im Abschnitt , Seite 12, genauer beschrieben. Ist ein solches Ablaufdatum unerwünscht (empfohlene Vorgehensweise), so ist einfach die Option Key does not expire direkt daneben anzuklicken. 32 Copyright 2005 seyecon IT-Consulting