1.1 Was genau ist eine Keysigning-Party?
Eine Keysigning-Party ist ein Treffen von Leute, die das PGP-Verschlüsselungssystem verwenden, mit der Absicht, die Schlüssel dieser Leute gegenseitig zu signieren. Keysigning-Partys dienen dem Zweck, das Web-of-Trust zu einem größeren Grad auszudehnen. Keysigning-Partys bieten ebenfalls großartige Möglichkeiten, die politischen und sozialen Fragen rund um starke Kryptographie, individuelle Freiheiten, individuelle Souveränität und sogar zur Implementierung von Verschlüsselungstechnologien oder vielleicht über zukünfige Arbeit an freier Verschlüsselungs-Software zu diskudieren.
Keysigning ist die Tätigkeit, einen öffentlichen Schlüssel und eine User-ID-Kennung, die an den Schlüssel angehängt ist, digital zu signieren. Keysigning wird durchgeführt, um prüfen zu können, dass eine gegebene User-ID und der öffentliche Schlüssel tatsächlich dem Wesen gehört, dem der Schlüssel zu gehören scheint und der durch die User-ID-Kennung vertreten wird.
Sie können Ihren eigenen Schlüssel und eine zugehörige Kennung des Schlüssel signieren, oder den öffentlichen Schlüssel und eine zugehörige öffentliche Schlüssel-Kennung eines anderen Wesens.
Auf eine bestimmte Art bestätigen Schlüsselsignaturen öffentliche Schlüsse. Sie sind ein Vermerk der Gültigkeit eines öffentlichen Schlüssels und der zugehörigen Kennung durch Dritte. Dies ist die Art, über die die Schlüsselsignaturen das Web-of-Trust aufbauen.
Ein Web-of-Trust ist ein Begriff, der die Vertrauensbeziehungen zwischen einer Gruppe von Schlüsseln beschreibt. Eine Schlüsselsignatur ist eine Verknüpfung, oder falls es Ihnen lieber ist, ein Strang im Web-of-Trust. Diese Verknüpfungen werden Trust Paths (Vertrauenspfade) genannt. Vertrauenspfade können in beide Richtungen verlaufen, oder nur in eine. Das ideale Web-of-Trust ist eines, indem jeder mit jedem anderen in beiden Richtungen verbunden ist. Als Effekt vertraut jeder darauf, dass jeder Schlüssel tatsächlich seinem Besitzer gehört. Man kann sich das Web-of-Trust als die Summe aller Vertrauenspfade vorstellen, oder der Verknüpfungen, zwischen allen schlüsselbesitzenden Parteien. Als ein visuelles Beispiel hier eine Grafik eines Web-of-Trust, zu dem ich gehöre.
1.4 Können Sie mir ein Beispiel über die Anwendung von Keysignaturen geben?
Zum Beispiel, nehmen wir an, dass Alice und Bob PGP-Schlüssel mit GPG erstellen und eine PGP-Keysigning-Party abhalten. Auf der Party prüfen Alice und Bob die Schlüssel-Informationen der anderen und signieren die Schlüssel deren später. GPG signiert in der Voreinstellung automatisch den öffentlichen Schlüssel jedes Paars, das es generiert, mit dem entsprechenden privaten Schlüssel. Daher haben Alice und Bob jeder nun zumindest zwei Signaturen, die bestätigen, dass ihr Schlüssel zu ihnen gehört. Alicds Schlüssel wurde von Alice selbst und Bob signiert, und Bobs Schlüssel wurde von Bob selbst und Alice signiert. Später treffen Alice und Bob Cathy. Cathy erstelle ein Schlüsselpaar und erzählt Alice und Bob, dass sie ihnen ihren Schlüssel schickt. Alice mag Cathy nicht und will nicht, dass Bob verschlüsselte Gespräche mit ihr austauscht. Sowohl Alice als auch Cathy erstellen PGP-Schlüssel und behaupten, dass diese Cathy gehören. Sie schicken sie beide an Bob. Beide Schlüssel haben eine Signatur, die Signatur des entsprechenden privaten Schlüssels. Bob weiss nicht, welcher Schlüssel wirklich Cathy gehört. Cathy hört, dass Bob zwei Schlüssel erhalten hat, und verdächtigt Alice. Cathy ist nun böse und wünscht sich, Informationen zu bekommen, die sie gegen Alice verwenden kann. Um diese Informationen zu erhalten, muss Cathy die verschlüsselten Gespräche zwischen Alice und Bob verstehen. Um dies zu tun, entschließt Cathy, eine E-Mail von Alice an Bob zu fälschen, in der sie behauptet, dass Alice neue Schlüssel erstellt hat. In die gefälschten E-Mail fügt Cathy Alices "neuen" öffentlichen Schlüssel ein (der eigentlich ein von Cathy generierter gefälschter Schlüssel ist). Jedoch weiss Bob sicher, dass dies ein Trick ist, da selbst obwohl Bob nun zwei Schlüssel für Alice hat, einer der Schlüssel von mehreren Leuten signiert wurde (ihm selbst und Alice), was bestätigt, dass er tatsächlich Alice gehört, wärend der andere Schlüssel - Cathys gefälschter Schlüssel - nur seine eigene Signatur enthält.
Das eben genannte Beispiel ist sehr vereinfacht und die Dinge können viel komplizierter als hier liegen. Sie können die PGP FAQs oder ein gutes Buch über PGI für weitere Informationen und eine detailiertere Erklärung durchlesen. Das genannte Beispiel erklärt klar die Grundzüge des Schlüsselsignierens und seinen Wert. Cathy war es wegen der Verbindungen im Web-of-Trust zwischen Bob und Alice nicht möglich, ein falsches Schlüsselpaar für Alice einzubringen.
Jedoch garantieren Signaturen und das Web-of-Trust keine vertrauenswürdige Schlüssel. Zum Beispiel, wenn Bob und Alice Cathy zum ersten mal treffen, nehmen wir an, dass Donald, ein Freund von Cathy, dabei war. Donald könnte gefälsche Schlüsselpaare für Alice und Bob erstellt haben, beide mit seinem Schlüssel signieren und beide Schlüsselpaare mit dem anderen Paar signieren, was zu drei Signaturen auf jedem Schlüssel führt, und diese an Cathy schicken. Cathy wäre mit einer Reihe von schlechten Schlüssel und Signaturen konfrontiert. Wie können Schlüsselsignaturen dabei helfen, solch einen Angriff zu vermeiden? Nehmen wir an, dass alle beteiligten Personen die Schlüssel über einen Keyserver austauschen. Falls Cathy auf dem Keyserver nach Alice und Bobs Schlüssel sucht, würde sie zwei finden, sowohl für Alice als auch für Bob. Falls Alice und Bob zwanzig Schlüsselsignaturen auf der Keysigning-Party gesammelt haben, ist es offensichtlich, dass Cathy eher dem öffentlichen Schlüssel vertrauen kann, der zwanzig mal signiert wurde als jenem, der nur dreimal signiert wurde. Cathy sollte aufgrund der Existenz des zusätzlichen öffentlichen Schlüssel wissen, dass etwas im Busch ist - und dadurch genauer auf das Datum der Erstellung und das Web-of-Trust hinter den öffentlichen Schlüsseln schauen. Die zwanzig Schlüssel von den Party-Signaturen sollten alle zwanzig mal oder öfter signiert sein und weit auseinanderliegende Erstellungszeiten haben, höchstwahrscheinlich wurden alle Schlüssel, die Alice und Bobs Schlüssel signiert haben, ebenfalls von anderen Schlüsseln signiert. Das wäre nicht der Fall, falls Donald zwanzig gefälscht Schlüsselpaare und ein gefälschtes Web-of-Trust erstellt hätte.
1.5 Warum sollte ich meine eigenen Keysigning-Partys abhalten?
Es gibt drei primäre Gründe, so viele Keysigning-Partys abzuhalten, wie es Ihnen möglich ist.
Zuerst, und wahrscheinlich am wichtigsten, sollten Sie soviele Keysigning-Partys wie möglich abhalten, um das Web-of-Trust zu erweitern. Je tiefer und straffer verbunden das Web-of-Trust ist, desto schwieriger ist es zu bezwingen. Dies ist von spezieller Bedeutung für die Freie Software Gemeinschaft, sowohl für Entwickler als auch für Benutzer. Die Mitglieder der Gemeinschaft vertrauen der PGP-Technologie, die Integrität ihrer Softwarepakete, der Sicherheitsgutachten und Ankündigungen kryptographisch zu schützen. Die Stärke und Robustheit des Web-of-Trust ist direkt proportional zu der Stärke des Schutzes, die PGP der Gemeinschaft bietet.
Zum zweiten helfen Keysigning-Partys anderen, sich mit der Sicherheitskultur auseinanderzusetzen und ermutigt sie, ein Verständnis für PGP und verwandte starke Kryptographie-Technologien zu entwickeln. Um den Nutzen von starker Kryptographie zu erhalten, müssen die Leute starke Kryptographie verwenden, und sie richtig einsetzen.
Schlussendlich helfen Keysigning-Partys dabei, Gemeinschaften zu bilden. Sie helfen Technikern, die anderen zu treffen kennenzulernen, abseits vom Netz, und wichtige Fragen wie zivile Freiheiten, Kryptographiegesetze und Internetbeschänkungen zu diskudieren. Diskussionen sind wichtig, da Diskussionen nicht nur der erste Schritt sind, sondern ebenfalls der Schritt vor dem Handeln. Während ich dieses Dokument schreibe, gibt es nicht sehr viele komplexe Webs-of-Trust in der Welt. Falls Sie daran arbeiten, ein Web-of-Trust in ihrem Umgebung zu erstellen, ist es wahrscheinlich, dass die ersten Teilnehmer an diesem Web die Leiter und politischen Gründer der Internetgemeinschaft in ihrem Bereich sind. Sie sind die Personen, die entscheiden können, sichere starke krypthographische Technologien und Protokolle in die lokale Infrastruktur einzubauen, falls sie sich dafür entscheiden. Die Integration solcher Technologie und Protokollen könnte Dinge wie die Carnivore-System-Technologie des FBI undurchführbar machen und sie daher in Frage stellen.
Es ist nicht sehr schwierig, eine Keysigning-Party zu organisieren und zu koordinieren. Jedoch hat der Koordinator neben den üblichen Aufgaben wie dem Einladen der Leute, die Wahl eines Ortes und das Ansetzen der Zeit einige weitere keysigning-spezifische Verpflichtungen. Diese beinhalten üblicherweise das Herstellen einer Schlüssel-Liste für jeden Teilnehmer und die Ermittlung der Struktur der Party.
2.2 Wie sollte die Party strukturiert sein?
Es gibt zwei primäre Arten, wie eine PGP-Keysigning-Party strukturiert sein kann -- zentralsiert oder dezentralisiert. Der beste Ansatz zum Keysigning kann aus der Anzahl der Personen eruiert werden, die teilnehmen, und der Athmosphäre des Ortes, an dem die Party stattfindet. Die grundsätzlichen Voraussetzungen für die Party sind, dass die Teilnehmer sowohl die Schlüssel als auch die Identität von jedem anderen prüfen können. Wenn diese beiden Voraussetzungen erfüllt sind, kann der Koordinator die beiden Arten auch variieren.
Eine zentralisierte Party wäre eine organisiertere Angelegenheit, die gut bei wenig bis durchschnittlich vielen Leuten funktioniert. Die Teilnehmer würden ihre Schlüssel-Informationen an den Koordinator schicken, der sie zu einer Liste zusammenstellen würde. Jeder Teilnehmer würde beim Ankommen bei der Party eine Kopie der Schlüssel-Liste erhalten. Jeder Teilnehmer würde dann vom Koordinator aufgerufen werden. Der Teilnehmer würden dann seinen Schlüssel-Fingerprint mit dem auf dem ausgedruckten Zettel vom Koordinator vergleichen. Falls der Teilnehmer sicher ist, dass sein Schlüssel der gleiche wie der Schlüssel auf dem Zettel ist, würde der Teilnehmer den Fingerprint laut vorlesen, damit die anderen Party-Teilnehmer sichergehen können, dass sie den richtigen passenden Fingerprint besitzen. Falls sie tatsächlich den richtigen passenden Fingerprint haben, haken sie ihn auf dem Zettel ab. Dies ist notwendig um sicher zu gehen, dass der Koordinator keinen Fehler beim Erstellen des Zettels gemacht hat oder keinen Zettel mit gefälschten Schlüssel-Informationen an einen oder mehrere Teilnehmer übergeben hat. Nachdem jeder den Schlüssel des Teilnehmers abgehakt hat, ruft der Koordinator den nächsten Teilnehmer auf, und so weiter. Nachdem alle Schlüssel geprüft wurden, werden die Teilnehmer und der Koordinator ersucht, sich in einer einzelnen langen Reihe aufzustellen und ihren Ausweis vor sich zu halten. Die Person am Anfang der der Reihe geht die Reihe ab und prüft den Ausweis von jeder Person. Falls deren Ausweis in Ordnung ist und die Person, die die Reihe abschreitet, den Schlüssel der Person am Anfang der Party beim Bestätigen der Schlüssel abgehakt hat, wird dieser Schlüssel ein zweitesmal abgehakt. Wenn ein Schlüssel zweimal abgehakt wurde, kann er signiert werden.
Auf einer dezentralisierten Party wäre grundsätzlich jeder auf sich selbst gestellt. Von den Teilnehmern wird erwartet, dass sie sich formlos vermischen und andere Teilnehmer finden, deren Schlüssel sie noch nicht signiert haben. Wenn sie sich treffen, bestätigen sie den Schlüssel auf der Liste des anderen und prüfen gegenseitig die Ausweise. Dezentralisierte Partys erlauben es viel mehr Leuten, einfach teilzunehmen, aber haben auch den Nachteil, dass sich einige Teilnehmer einfach nicht treffen und gegenseitig die Schlüssel fürs spätere Signieren bestätigen können. Auf einer dezentralisierten Party ist für den Koordinator wichtig, jeden zu ermutigen sicher zu gehen, dass sie sich mit jedem anderen zur Schlüssel-Prüfung getroffen haben. Während eine Liste von Schlüsseln und Fingerprints für eine dezentralisierte Party nicht notwendigerweise erstellt werden muss, ist es trotzdem eine gute Gewohnheit.
Zentralisierte Partys bieten sich gut für Konferenzen während dem Essen an, formlose ruhige Treffen bei jemanden zu Hause oder in einem Restaurant, usw. Dezentralisierte Keysigning-Partys sind viel praktischer für Partys, die eine große Anzahl von Leuten umfasst, in einer Bar oder an einem anderem lauten Ort stattfindet, oder Partys, an denen besonders rabiate und schwer kontrollierbare Geeks teilnehmen.
Je größer die Party ist, desto besser. Sie können ihre Party auf der lokalen LUG-Mailing-Liste ankündigen, auf andern Computer-bezogenen Listen in ihrer Umgebung, auf der Sie eingetragen sind, selbst als Werbung in der Tageszeitung oder als Presseaussendung.
Wenn Sie erst damit begonnen haben, das Web-of-Trust in ihrer Umgebung aufzubauen, ist es eine gute Idee, andere aktive PGP-Benutzer zur Beteiligung zu überreden, da diese höchstwahrscheinlich in Zukunft ihre eigenen Keysigning-Partys abhalten werden. Gute Wege, um solche Leute zu finden, ist es, mit den Leuten zu sprechen, die E-Mails mit PGP-Signaturen an Listen schicken, die Sie lesen, oder indem Sie das Keyserver-Netzwerk nach Schlüsseln mit E-Mail-Adressen durchsuchen, die auf ihre Umgebung hindeuten. Zum Beispiel E-Mail-Adressen, die in der Domäne einer Universität oder großen Firma liegen, die aus ihrer Umgebung ist, ergeben häufig eine große Anzahl von interessanten Partys.
Hier ein paar Beispiel-Ankündigungen:
2.4 Die Schlüssel-Liste generieren
Falls Sie eine Party-Struktur wählen, bei der die Teilnehmer eine Liste der Schlüssel von jedem Teilnehmer der Party benötigt, muss der Koordinator eine solche Liste generieren. Diese Liste sollte in einem Format ähnlich diesem zusammengestellt sein:
| Schlüssel-ID | Besitzer | Schlüssel-Fingerprint | Größe | Typ | Schlüssel-Infos passen? | Besitzer-ID passt? |
|---|---|---|---|---|---|---|
| 992A4B3F | V. Alex Brennen <vab@cryptnet.net> | 0EC8 B0E3 052D FC4C 208F 76EB FA92 0973 992A 4B3F | 1024 | DSA |
Ich hab ein Perl-Skript geschrieben, das ein HTML-Dokument im Stil der oben angeführten Tabelle aus einem gpg-Keyring erstellt. Das Perl-Skript zum Erstellen einer Keysigning-Party-Schlüssel-Liste ist zu den Bedingungen der GNU General Public License (GPL) verfügbar.
Eine Kopie der Schlüssel-Liste sollte dann für jeden der Leute ausgedruckt werden, die an der Keysigning-Party teilnehmen. Der Koordinator kann die Kopien der Liste selbst ausdrucken, oder er kann die Liste oder den Ort der Liste im Web an die Anwesenden zum selber ausdrucken mailen.
2.5 Das resultierende Web-of-Trust abbilden
Nichts zieht das Interesse der Leute so sehr an wie farbenreiche Grafiken. Deswegen kann eine Grafik des Web-of-Trust in ihrer Umgebung, während Sie es aufbauen, dabei helfen, die Leute dazu zu motivieren, um selbst teilzunehmen, wie auch jedem einen klaren Eindruck davon zu vermitteln, was erreicht wurden, wenn die Dinge voranschreiten.
Sie können sehr leicht eine Grafik von allen Schlüsseln und Signaturen in ihrem Web-of-Trust erstellen, indem Sie diese Informationen in eine dot-Datei konvertieren, mit der dann ein Grafik-Programm wie dot oder neato gefüttert werden kann. Ein Perl-Skript, das die Schlüssel und Signaturen in einem Keyring in eine Datei im dot-Format konvertiert, wurde von Darxus geschrieben und ist ebenfalls zu den Bedingungen der GPL verfügbar. Um das Web-of-Trust graphisch darzustellen, müssen Sie Darxus' sig2dot.pl Skript und das graphviz Paket von AT&T Research herunterladen. Es dürfte Ihnen nicht gelingen, ein Web-of-Trust mit mehr als ein paar hundert Knoten wegen der benötigten Speichermenge zu erstellen, die solch eine Berechnung benötigt.
Anleitungen zur graphischen Abbildung des Web-of-Trust in einem gpg-Keyring sind im sig2dot.pl Skript enthalten, oder können auf der Debian-Keyring Grafik-Seite gefunden werden. Auch hierzu ein Link, um einen Graph eines Web-of-Trust anzusehen, der mit dem sig2dot.pl Skript und dem neato Graphik-Programm erstellt wurde. Weitere Informationen sind auf der Debian-Keyring Grafik-Seite zu finden.
3.1 Zusammenfassung der Rolle eines Teilnehmers
3.2 Was man zur Party mitbringen soll
3.3 Was man nicht mitbringen soll
3.4 Wieso Sie keinen Computer mitbringen sollten
Sie sollten keinen Computer auf die Party mitbringen, da das Ersetzen von Programmen oder Systemveränderungen ein einfacher Weg ist, um das PGP-System zu beeinträchtigen.
Falls jemand einen mobilen Computer mitbringt, und jeder diesen Computer dazu verwendet, um die Schlüssel der anderen auf der Party zu signieren, weiss niemand, ob auf dem Rechner ein Programm läuft, das die Tastatureingaben mitschreibt, eine veränderte Version von GPG, dem Linux-Kernel oder eine speziell veränderte Tastatur verwendet wird, wobei all dies dazu verwendet werden kann, um die Geheimschlüssel jener zu erfassen, die den Computer verwenden.
Die Verwendung eines Computers auf der Party würde Sie auch viel einfacheren Angriffen aussetzen wie dem Schulter-Surfen, oder komplexere Angriffe wie zum Beispiel die Erstellung eines schwachen Geheimschlüssels oder selbst die Infiszierung mit Viren, die ihr GPG-Programm modifizieren, um zukünftige Geheimschlüssel diskret zu verteilen.
3.5 Ihr Schlüsselpaar erstellen
Der Vorgang des Erstellens eines Schlüsselpaars ist ziemlich einfach. Im
Grunde müssen Sie nur gpg --gen-key aufrufen. Jedoch empfehle
ich, dass Sie ebenfalls ein Widerruf-Zertifikat für ihren Schlüssel
erstellen, falls Sie jemals den Zugriff auf ihren Geheimschlüssel
verlieren (d.h., wenn Sie ihr Mantra oder ihren Geheimschlüssel selbst
verlieren). Die Anweisungen, um ein Widerruf-Zertifikat zu erstellen, ist
in Abschnitt 3.9 dieses Dokuments zu finden.
Die Schritt-für-Schritt-Anweisungen unterhalb wurden in Hinblick auf praktische Anwendung und hinreichende Sicherheit geschrieben. Zum Beispiel:
Einige Leute mögen es als bequem empfinden, all diese Sicherheitsvorkehrungen wegzulassen. Falls Sie zum Beispiel einen Laptop oder einen Homecomputer besitzen, auf dem Sie all ihre E-Mails lesen, mag es bequem sein, ihren Schlüssel auf der Festplatte dieses Computers zu speichern. Es mag für Sie ebenfalls bequem sein, ein Schlüsselpaar zu generieren, das nie abläuft, das Sie zur Identifikation und für die meiste Kommunikation verwenden - und dann zusätzliche Schlüsselpaare für extrem sensible Kommunikation generieren (falls Sie solche vornehmen). Nochmals, die unten angeführte Schritt-für-Schritt Anleitung wurde mit den Gedanken über beste Sicherheitspraktiken geschrieben. Sie müssen sie nicht befolgen, sie müssen nur ein Schlüsselpaar generieren. Falls Sie jedoch auf der anderen Seite ein extrem paranoider Sicherheitsfreak wie ich sind, wird Ihnen das Befolgen der unten angeführten Anweisungen temporär jenes schnell flüchtigen Gefühl der Ruhe geben, das Sie im Augenblick so sehr fühlen müssen.
Die Schritt-für-Schritt-Anweisungen unterhalb wurden mit den Gedanken an beste Sicherheitsvorkehrungen (starke Paranoia) geschrieben. Zum Beispiel:
1) Gehen Sie zu www.gnupg.org und laden die neueste Version von gnupg herunter: gnupg-x.x.x.tar.gz
Warnung: Vergewissern Sie sich, dass Sie zumindest Version 1.0.6 von GnuPG verwenden. Versionen vor 1.0.6 hatten zumindest ein bedeutendes Sicherheitsproblem.
2) Prüfen Sie die PGP-Signatur und die MD5-Prüfsumme des GnuPG-Archivs
bash$ gpg --verify gnupg-x.x.x.tar.gz.sig gnupg-x.x.x.tar.gz
bash$ md5sum gnupg-x.x.x.tar.gz
3) Extrahieren Sie das Archiv, konfigurieren es, übersetzen es und installieren Sie es:
bash$ tar xvzf gnupg-x.x.x.tar.gz
bash$ cd gnupg-x.x.x
bash$ ./configure
bash$ make
bash$ su
bash# make install
bash# exit
bash$ cd
Falls Sie den Rechner, auf dem Sie GnuPG verwenden, mit anderen teilen, möchten Sie gpg wahrscheinlich setuid root setzen, damit es sicheren Speicher verwenden kann. Falls Sie sich dafür entscheiden, sollten Sie Vorkehrungen treffen wie das Prüfen des Archivs mit der MD5-Signatur und der PGP-Signatur, um sicher zu gehen, dass Sie kein trojanisches Pferd installieren.
4) Besorgen Sie sich eine Diskette, auf der Sie den Schlüssel speichern werden, und formatieren Sie sie.
bash$ /sbin/mkfs.ext2 /dev/fd0
4a) Mounten Sie die Diskette und erstellen Sie ein Verzeichnis für ihre Schlüssel darauf, das Ihnen gehört:
bash$ mount /mnt/floppy
bash$ mkdir /mnt/floppy/.gnupg
Und falls notwendig (abhängig vom fd0-Zugriff auf ihrem System):
bash$ chown <ihre_uid>:<ihre_gid> /mnt/floppy/.gnupg
4b) Erstellen Sie einen symbolischen Link von ihrem Home-Verzeichnis auf die Diskette.
bash$ ln -s /mnt/floppy/.gnupg .gnupg
5) Erstellen Sie ihre GnuPG-Schlüssel:
bash$ gpg --gen-key
5a) Wählen Sie den Schlüsseltyp, den Sie wünschen - die Voreinstellung passt.
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) DSA und ElGamal (voreingestellt)
(2) DSA (nur signieren/beglaubigen)
(5) RSA (nur signieren/beglaubigen)
Ihre Auswahl? <return>
5b) Wählen Sie ihre Schlüsselgröße: 2048
Das DSA-Schlüsselpaar wird 1024 Bit haben.
Es wird ein neues ELG-E Schlüsselpaar erzeugt.
kleinste Schlüssellänge ist 768 Bit
standard Schlüssellänge ist 1024 Bit
größte sinnvolle Schlüssellänge ist 2048 Bit
Welche Schlüssellänge wünschen Sie? (1024) 2048<return>
5c) Wählen Sie die Lebensdauer des Schlüssels: 5 Jahre ist brauchbar.
Die verlangte Schlüssellänge beträgt 2048 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 5y<return>
Key verfällt am Mon 31 Mär 2008 08:18:12 CEST
Ist dies richtig? (j/n) j<return>
5d) Geben Sie ihren Namen und die E-Mail Adresse(n) ein...
Ihr Name ("Vorname Nachname"): Test Benutzer<return>
E-Mail-Adresse: test@existiert.nicht<return>
Kommentar:
Sie haben diese User-ID gewählt:
"Test Benutzer <test@existiert.nicht>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F<return>
5e) Wählen Sie ein Mantra. Sie müssen ein gutes wählen. Es sollte lang und sehr schwer zu erraten sein. Es sollte etwas sein, das Sie nicht vergessen werden. Falls Sie ihr Mantra vergessen können Sie ihren Schlüssel nicht wiederherstellen.
5f) Bewegen Sie die Maus, drücken einige Tasten, möglicherweise aktualisieren Sie die locatedb im Hintergrund oder rufen ein großes find auf. GPG liest von /dev/random, um etwas Zufälligkeit für ihre Schlüsselgenerierung zu erhalten. /dev/random wird zum Teil von Interrupts gefüllt.
6) Modifizieren Sie ihren Schlüssel, wenn Sie wünschen. Falls Sie zum Beispiel mehrere E-Mail-Adressen besitzen und diese alle als gültig in ihrem Schlüssel aufgeführt haben wollen:
bash$ gpg --list-secret-keys
/home/test/.gnupg/secring.gpg
------------------------------
sec 1024D/12C03930 2003-04-02 Test Benutzer <test@existiert.nicht>
ssb 2048g/6A253071 2003-04-02
asgard$ gpg --edit-key 12C03930
Befehl> help
Befehl> adduid
[...]
Befehl> save
7) Schicken Sie ihren Schlüssel an den Keyserver:
bash$ gpg --keyserver <keyserver> --send-key <Ihre_Key_ID>
Sie sollten eine Erfolgsmeldung wie diese sehen:
gpg: Senden an `<keyserver>' erfolgreich (status=200)
3.6 Ihren öffentlichen Schlüssel an einen Keyserver schicken
Es ist hierbei wichtig zu bemerken, dass einige Leute glauben, dass das Geheimhalten ohres öffentlichen Schlüssels ihrer verschlüsselten Kommunikation einen zusätzlichen Grad an Sicherheit verleiht. Das ist deswegen wahr, da in einen Keyserver eingebrochen werden kann oder dieser kompromitiert werden kann, um einen falschen öffentlichen Schlüssel zurückzuliefern, wenn diese abgefragt wird. Desweiteren kann es sein, dass der Schlüssel auf einem öffentlichen Keyserver nicht die aktuellste Version des Schlüssels hat. Zum Beispiel könnten zusätzliche Signaturen hinzugefügt worden sein, die sich noch nicht verbreitet haben oder auf noch keinen Keyserver hochgeladen wurden. Es ist ebenfalls wahr, da der öffentliche Schlüssel eines Schlüsselpaar für bestimmte Arten der Angriffe gegen das Public Key Kryptographiesystem benötigt wird, das PGP verwendet. Während viele Leute erwarten, dass der Erfolg dieser Angriffe bei vernünftigen Schlüsselgrößen so sehr unwahrscheinlich sind, dass es keine Rolle spielt, wenn der öffentliche Schlüssel verteilt wird, stärkt das Geheimhalten des öffentlichen Schlüssels tatsächlich das Schlüsselpaar.
Ich empfehle es nicht, ihren öffentlichen Schlüssel geheim zu halten, da es andere entmutigt, PGP bei ihrer Kommunikation mit Ihnen zu verwenden. Um das Problem der Möglichkeit eines kompromitierten oder kaputten Keyservers anzugehen, der einen ungültigen Schlüssel zurückliefert, können Sie Schritte unternehmen, um selbst keine Nachrichten zu erhalten, die mit ungültigen Schlüsseln verschlüsselt sind, wie das Veröffentlichen ihres Schlüssel-Fingerprints in ihrer .signature Datei oder auf ihrer Webseite. Um das Anliegen des Angriffes ihres Schlüsselpaars durch öffentlich verfügbare öffentliche Schlüssel anzugehen, würde ich sagen, falls die Stärke ihres Schlüsselpaars ein sehr starkes Anliegen für Sie ist oder Sie wirklich Paranoid bezüglich der Geheimhaltung ihrer Kommunikation sind, sollten Sie für jede Kommunikation zusätzliche Schlüsselpaare generieren (die in einigen Stunden oder Tagen ablaufen) und den öffentlichen Schlüssel dieser Schlüsselpaare mittels verschlüsselter Kommunikation mit den Personen austauschen, mit denen Sie sich unterhalten werden.
Falls Sie ihren Schlüssel nicht auf einem öffentlichen Keyserver haben wollen, sollten Sie diesen Schritt überspringen, und stattdessen ihren öffentlichen Schlüssel an den Keysigning-Party-Koordinator mit einer Mitteilung verschicken, dass Sie ihren Schlüssel nicht auf einem öffentlichen Keyserver haben wollen. Der Koordinator kann dann die Informationen ihres öffentlichen Schlüssels extrahieren und ihren Schlüssel an die anderen Teilnehmer mittels verschlüsselter E-Mail weiterleiten, oder auf anderem Weg, gemeinsam mit einem Hinweis, dass der Schlüssel nach dem Signieren an seinen Eigentümer zurückgeschickt werden soll, statt ihn auf einen Keyserver hochzuladen.
3.7 Ein Widerruf-Zertifikat erstellen
Dies ist ein optionaler Schritt.
Die Erstellung und Speicherung eines Widerruf-Zertifikats erlaubt es Ihnen, ihren öffentlichen Schlüssel zu widerrufen, selbst falls Sie den Zugriff auf ihren privaten Schlüssel durch eine Kompromitierung, eine Beschlagnahmung, ein vergessenes Mantra oder einen Medium-Fehler verloren haben. Falls Sie die Möglichkeit haben wollen, ihren öffentlichen Schlüssel zu widerrufen, wenn Sie keinen Zugriff auf ihren privaten Schlüssel haben, sollten Sie ein Widerruf-Zertifikat und es an einem sicheren und geschützten Ort speichern. Sie sollten ebenfalls eine Kopie ihres Widerruf-Zertifikats ausdrucken, damit es eingegeben und verwendet werden kann, falls auf dem Medium, auf dem es gespeichert ist, ein Fehler auftritt.
Falls ihr Widerruf-Zertifikat kompromitiert wurde, ist es der Person möglich, die ihr Widerruf-Zertifikat kompromitiert hat, das Zertifikat in Umlauf zu bringen und dadurch den Schlüssel zu deaktivieren. Jedoch wird es der Person nicht möglich sein, ihren geheimen Schlüssel durch den Zugriff auf ihr Widerruf-Zertifikat zu kompromitieren. Deshalb wird es ihr nicht möglich sein, gefälschte Signaturen zu generieren, Nachrichten zu entschlüsseln, die mit ihrem Schlüsselpaar generiert sind, oder anderweitig sichselbst als der Besitzer ihres Schlüsselpaars ausgeben. Da die einzige negative Auswirkung der Kompromitierung eines Widerruf-Zertifikats das Deaktivieren ihres Schlüsselpaars ist, ist es eine üblicherweise sichere und gute Sache, dies zu tun.
Abschnitt 3.9 enthält weitere Informationen über das Widerrufen eines Schlüssels.
Der GnuPG-Befehl, um ein Widerruf-Zertifikat zu generieren, ist:
bash$ gpg --output revcert.asc --gen-revoke <Ihre_Key_ID>
9) Schicken Sie ihre Informationen per E-Mail an den Koordinator und erzählen Sie ihm, dass Sie zur Key-Signing-Party erscheinen werden. Der unten angeführte Befehl wird die Informationen anzeigen, die Sie an den Koordinator schicken sollten, falls Sie einen Keyserver benutzen. Sie können dann diese Informationen in einer verschlüsselten E-Mail-Nachricht an den Koordinator schicken.
bash$ gpg --fingerprint <Ihre_Key_ID>
10) Unmounten Sie die Diskette und werfen Sie aus:
bash$ umount /mnt/floppy
Beachten Sie: Sie können die Diskette als zusätzliche Sicherheit mit sich herumtragen, oder Sie können sie in einem Safe, einer verschlossenen Tischlade usw. aufbewahren. Sie wollen ihr .gnupg-Verzeichnis, das ihre Schlüssel enthält, NICHT an einem Ort aufbewahren, der über das Internet erreichbar ist.
11) Erscheinen Sie auf der Party.
3.8 Andere Schlüssel signieren
Schritt 1: Besorgen Sie sich eine Kopie des Schlüssels
Üblicherweise werden Sie über einen Keyserver arbeiten. Falls Sie jedoch
einen Schlüssel signieren, der nicht auf einem Keyserver verfügbar ist,
können Sie den Schlüssel einfach mit gpg --import importieren.
Falls Sie mit einem Keyserver arbeiten, wird der folgende Befehl den
Schlüssel vom Keyserver in ihren öffentlichen Keyring herunterladen.
bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
Falls Sie einen Lese-Fehler erhalten, bedeutet es, dass der Keyserver überlastet ist. Versuchen Sie es bitte in ein paar Sekunden erneut.
Schritt 2: Fingerprint und Prüfung des Schlüssels
bash$ gpg --fingerprint <Key_ID>
GPG wird den Fingerprint des Schlüssels mit <Key_ID > ausgeben (der Schlüssel, den Sie gerade heruntergeladen haben). Vergleichen Sie den Fingerprint mit der Prüfliste, die Sie auf der Party erhalten haben. Beachten Sie: Vergleichen Sie den Fingerprint auf ihrer Prüfliste nicht mit dem Fingerprint auf der Webseite, da der Server Ihnen nicht den selben Schlüssel schicken muss, den es auf der Webseite anzeigt.
Schritt 3: Signieren Sie den Schlüssel
bash$ gpg --sign-key <Key_ID>
Falls Sie mehrere private Schlüssel besitzen, können Sie angeben, welcher ihrer privaten Schlüssel den öffentlichen Schlüssel der anderen Person signieren soll:
bash$ gpg --default-key <zu_verwendender_Schlüssel> --sign-key <Key_ID>
Falls Sie Probleme beim Umgang mit RSA-Schlüssel haben, verwenden Sie wahrscheinlich eine alte Version von GnuPG. Ältere Versionen als 1.0.3 von GnuPG enthalten keine RSA-Unterstützung. Beachten Sie: Sie müssen eventuell eine ältere Version deinstallieren, falls ihre Distribution über die Paketverwaltung installiert hat. Sie können die Version, die Sie ausführen, wie folgt prüfen:
bash$ gpg --version
Schritt 4: Schicken Sie den signierten Schlüssel retour oder laden Sie ihn hoch
Falls Sie mit einer Person arbeiten, die ihren Schlüssel nicht auf einem öffentlichen Keyserver haben will, sollten Sie an diesem Punkt deren signierten Schlüssel auf deren bevorzugte Weise an sie zurückschicken - üblicherweise per verschlüsselter E-Mail. Sie sollten einen öffentlichen Schlüssel nicht ohne der Erlaubnis des Schlüsselbesitzers an einen Keyserver schicken. Das Verbreiten eines öffentlichen Schlüssels reduziert leicht die Sicherheit eines Schlüsselpaars und es wird daher als unhöflich angesehen, einen Schlüssel weiter zu verbreiten, als es der Besitzer wünscht.
Höchstwahrscheinlich arbeiten Sie mit einem Keyserver. Falls dies der Fall ist, können Sie den signierten Schlüssel zurück an den Keyserver wie folgend schicken:
bash$ gpg --keyserver <keyserver> --send-key <Key_ID>
Sie sollten eine Erfolgsmeldung wie die folgende sehen:
gpg: Senden an `<keyserver>' erfolgreich (status=200)
Gratulation, die Signatur auf dem Schlüssel der anderen Person ist nun beendet und ihre Signatur wurde in deren öffentlichen Schlüssel eingearbeitet. Ein Vertrauenspfad wurde erstellt.
3.9 Ihr Schlüsselpaar widerrufen
Falls Sie vermuten, dass ihr geheimer Schlüssel kompromitiert wurde, sollten Sie ihren öffentlichen Schlüssel unverzüglich widerrufen. Das Widerrufen eines Schlüssels funktioniert durch das Hinzufügen einer Widerruf-Signatur auf dem öffentlichen Schlüssel. Das Widerrufen eines Schlüssels schlägt vor, dass ein Schlüssel nicht mehr gültig (sicher) ist und nicht verwendet werden sollte. Wenn ein Widerruf-Zertifikat angewendet wird, kann es nichtmehr zurückgenommen werden.
Da Ihr PGP-Schlüssel an Leute verteilt (sprich verbreitet) wird, anstatt von einer zentralen Stelle jedesmal verteilt wird, wenn darauf zugegriffen wird, müssen Sie ihr Widerruf-Zertifikat auf die selbe Art verteilen oder verbreiten, wie Sie ihren öffentlichen Schlüssel verbreitet haben. Die Verbreitung des Widerruf-Zertifikats auf die selbe Art wie die Verbreitung ihres öffentlichen Schlüssels bedeutet üblicherweise, das Widerruf-Zertifikat in das Keyserver-Netzwerk hochzuladen. Falls Sie ihren öffentlichen Schlüssel aus Sicherheitsgründen nicht hochgeladen haben, möchten Sie ihr Widerruf-Zertifikat jedoch trotzdem auf den Keyserver hochladen. In diesem Mall können Sie einen Kompromiss zwischen der geringe Reduktion der Sicherheit, die durch das Veröffentlichen ihres öffentlichen Schlüssels ensteht, und der Sicherheitseinbuße ziehen, die dadurch entsteht, wenn jeman möglicherweise nicht bemerkt, dass ihr Schlüssel widerrufen wurde.
Als Wiederholung hier der Befehl, um ein Widerruf-Zertifikat zu erstellen:
bash$ gpg --output revcert.asc --gen-revoke <Ihre_Key_ID>
Falls Sie eine Idee darüber haben, wie und wann ihr Schlüssel kompromitiert wurde, und Sie ein Widerruf-Zertifikat währen der Schlüssel-Erstellung generiert haben, wollen Sie wahrscheinlich trotzdem ein neues Widerruf-Zertifikat erstellen, um ihr Schlüsselpaar zu erstellen. Dies ist der Fall, da der OpenPGP-Standard es Ihnen erlaubt, einen Grund anzugeben, warum Sie ihr Schlüsselpaar widerrufen, und sogar ein freies Text-Kommentar für den Grund des Widerrufs anzugeben. Die Verbreitung eines Widerruf-Zertifikats mit dieser Art der Information ist wahrscheinlich nützlicher und zu bevorzugen gegenüber der Verbreitung eines allgemeinen Widerruf-Zertifikats während der Schlüssel-Generierung.
Schlüssel – Ein oder mehrere Datenteile, die im Ver- und Entschlüsselungsprozess verwendet werden.
Schlüssel-Fingerprint – Ein in PGP verwendeter Wert, um einen Schlüssel zu identifizieren, der durch eine Prüfsumme des Schlüsselmaterials erstellt wird.
Schlüsselpaar – Bei einer Kryptographie mit öffentlichem Schlüssel besteht ein Schlüsselpaar aus dem öffentlichen und dem privaten, oder auch geheimen, Schlüssel, die zusammengehören.
Keyring – Eine Sammlung von Schlüsseln. Am häufigsten wird dieser Begriff in Verbindung mit PGP verwendet, wenn ein Keyring aus einer Sammlung von einem oder mehreren Schlüsselpaketen besteht.
Keyserver – Ein System, dass Schlüsselmaterial in einer Datenbank speichert. Diese Server können von Benutzern abgefragt werden, die sich den öffentlichen Schlüssel eines Empfängers besorgen wollen, mit dem sie zuvor noch keinen Kontakt hatten.
Keysigning-Party – Ein Zusammentreffen von Personen, die das PGP-Verschlüsselungssystem verwenden, mit dem Zweck, es diesen Personen zu ermöglichen, die öffentlichen Schlüssel der anderen zu signieren. Keysigning-Partys dienen dem Verschlüsselungssystem, um das Web-of-Trust zu vergrößern.
OpenPGP – Ein offener Standard, der eine Version des PGP-Sicherheitssystems definiert.
Pretty Good Privacy [PGP] – Von Phil Zimmermann entwickelte Datenschutz-Software, die eine Verschlüsselung mittels öffentlichem Schlüssel, ein Standard-Paket- und -Schlüsselformat und ebenfalls auch eine symmetrische Verschlüsselung enthält.
Öffentlicher Schlüssel – Bei einer Kryptographie mittels öffentlichem Schlüssel ist dies der Schlüssel eines Schlüsselpaars, der weitergegeben wird.
Öffentlicher Keyring – Ein Keyring bestehend aus öffentlichen Schlüsseln. Dieser Begriff wird am häufigsten in Verbindung mit PGP verwendet.
Radix – Eine Methode des Verschlüsselns von Daten, damit er über einen Kanal übertragen werden kann, der nur 8bit-Zeichen unterstützt. Zum Beispiel kann solch ein Kanal eine E-Mail oder das Usenet sein.
Geheimer Schlüssel – Bei der Kryptographie mittels öffentlichem Schlüssel ist dies der Schlüssel eines Schlüsselpaars, der geheim gehalten wird.
Geheimer Keyring – Eine Sammlung von geheimen Schlüsseln. Dieser Begriff wird am häufigsten in Verbidnung mit PGP verwendet, wo es eine Sammlung von geheimen Schlüsselpaketen bezeichnet.
Vertrauenspfad (Trust Path) – Ein Pfad, durch den das Vertrauen von einer Person zu einer anderen erweitert wird. In PGP ist dies eine Vertrauensverbindung zwischen zwei öffentlichen Schlüsseln.
Web-of-Trust – Die Sammlung von Signaturen auf Schlüsseln und den daraus resultierenden Vertrauenspfaden in einem benutzerbezogenen Vertrauensmodell, das eine Authentifizierung bietet. Insgesamt die Vertrauensbeziehungen zwischen einer Gruppe von Schlüsseln.
5.1 Liste von öffentlichen Keyservern
5.2 Links zu verwandten Dokumenten
5.6 Bilder von Keysigning-Partys
Copyright (c) 2000 - 2003 V. Alex Brennen.
Hiermit ist die Erlaubnis erteilt, dieses Dokument zu den Bedingungen der GNU Free Documentation License, Version 1.1 oder jeder neueren von der Free Software Foundation veröffentlichten Version zu kopieren, verteilen und/oder zu verändern.
Dieses Dokument ist auf http://www.cryptnet.net/fdp/crypto/gpg-party.html zu finden.
Version 1.0.0, 2000.10.01 Erstes Release.
Version 1.0.1, 2000.10.03 Format-/Schreib-Änderungen, private öffentliche Schlüssel Informationen.
Version 1.0.2, 2000.12.07 HTML (schlechter Link) Behebung.
Version 1.0.3, 2001.01.14 Vereinfachungs-Überarbeitung, Grafiken, Keyserver Sicherheits-/Etikette-Informationen, Perl-Code, Ankündigungsbeispiele, zusätzliche Materialien und allgemeine Änderungen.
Version 1.0.4, 2001.06.21 Widerruf-Informationen hinzugefügt: 3.5, 3.9. RFC Infos hinzugefügt: 4.4. Keyserver-Listen und Website-Links aktualisiert.
Version 1.0.5, 2003.03.24 Wörterverzeichnis hinzugefügt: 4. Bilder hinzugefügt: 5.5 Kleine Korrekturen, zusätzliches Material, und Formatierungsänderungen.
Version 1.0.6, 2003.03.24 Neuer Inhalt: Zimmermann-Sassaman-Methode, Brennen-Methode. Allgemeine Dokumentationssäuberung.
Version 1.0.7, 2003.05.07 Deutsche Übersetzung hinzugefügt.
Version 1.0.8, 2003.05.09 Abschnitt 5.3 Verwandte Programme hinzugefügt.
Version 1.0.9, 2003.11.20 Spanische und italienische Übersetzungen hinzugefügt.
Version 1.1.0, 2003.11.26 Übersetzung ins traditionelle Chinesische hinzugefügt.
Dieses Dokument ist zur Zeit nur in den folgenden Sprachen verfügbar:
[en] Englisch (Lokaler Spiegel)
[de] Deutsch (Lokaler Spiegel)
[es] Spanisch (Lokaler Spiegel)
[it] Italienisch (Lokaler Spiegel)
[zh-TW] Traditionelles Chinesisch (Lokaler Spiegel)
[si] Slowenisch (Lokaler Spiegel)
Falls Ihnen eine Übersetzung bekannt ist oder Sie das Dokument in eine andere Sprache übersetzen wollen, informieren Sie mich bitte davon, damit ich die übersetzten Versionen verbreiten oder verlinken kann.
V. Alex Brennen (Primärer Autor)
Darxus (Grafiken-Code (sig2dog.pl & sigtrace.pl))
Bostjan Muller (Slowenische Übersetzung)
Gerfried Fuchs (Deutsche Übersetzung)
Alex Bergonzini (Spanische Übersetzung)
Cristian Rigamonti (Italienische Übersetzung)
chihchun clotho fetag Jedi kcwu pwchi winfred (Übersetzung ins traditionelle Chinesisch)
