Keysigning-Party 2005: Unterschied zwischen den Versionen
(→Was muss ich <u>nach</u> der Keysigning-Party machen?) |
|||
Zeile 170: | Zeile 170: | ||
=== Informationen zu Keysigning Partys === | === Informationen zu Keysigning Partys === | ||
* http://www.cryptnet.net/fdp/crypto/gpg-party.html | * http://www.cryptnet.net/fdp/crypto/gpg-party.html | ||
+ | |||
+ | [[Kategorie: Veranstaltungen der Freitagsrunde]] |
Version vom 26. Januar 2005, 02:28 Uhr
Wir planen demnächst eine PGP Keysigning Party durchzuführen. Diese Seite soll der Planung dieser Veranstaltung dienen und einige Informationen zu PGP, dem Prinzip des Web-of-Trust und dem Ablauf des Keysignings dienen.
Inhaltsverzeichnis
Einführung
TODO
Problemstellung
- Man mag den Gedanken nicht, dass der Inhalt der Emails wie bei einer Postkarte von jeder Zwischenstation gelesen werden kann
- Man muss jemandem ein Passwort zuschicken
- Ein Dokument X soll einem Geschäftspartner P zugestellt werden, ohne dass Fremde den Inhalt erkennen können.
- Die Geschäftsleitung möchte eine Anweisung X an die Mitarbeiter geben, wie in Zukunft in bestimmten Situationen gehandelt werden soll. Es muss sicher sein, dass die Geschäftsführer A und B die Absender sind und nicht der unzufriedene Mitarbeiter U.
- Man möchte der Überwachung nach der neuen TKÜV entgehen...?
PGP/GPG
Funktionsweise
Bei PGP/GPG verden zwei grundsätzlich verschiedene Verschlüsselungsverfahren miteinander kombiniert, die symmetrische und die asymetrische Verschlüsselung. Das Ergebnis ist dann eine sogenannte hybride Verschlüsselung.
Bei der symmetrischen Verschlüsselung wird zum Verschlüsseln wie zum Entschlüsseln der selbe Schlüssel verwendet. Diese Verfahren sind sehr schnell und eignen sich sehr gut, um große Datenmengen zu verschlüsseln. Leider muss man dazu eine Möglichkeit finden, dem Empfänger neben den Daten auch den Schlüssel zukommen zu lassen, ohne dass andere ihn abfangen können. Beispiele sind AES, Blowfish. siehe auch Wikipediaeintrag
Bei der asymetrischen Verschlüsselung existieren zwei unterschiedliche Schlüssel, ein öffentlicher, mit dem Daten verschlüsselt werden können und ein privater, mit dem die Daten wieder entschlüsselt werden können. Über ein mathematisches Verfahren ist dabei sichergestellt, dass die Daten nur mit dem geheimen Schlüssel wieder entschlüsselt werden können. Der Vorteil liegt in der Möglichkeit, jedem den öffentlichen Schlüssel zukommen zu lassen, jedoch ist das Verfahren so rechenaufwändig, dass es zum Verschlüsseln großer Datenmengen nicht brauchbar ist. Beispiele: RSA, ElGamal. siehe auch Wikipediaeintrag
Beide Verfahren werden nun verbunden, so dass die Vorteile vereint werden können: Schnelligkeit beim Ver- und Entschlüsseln sowie Sicherheit bei der Schlüsselübergabe: Zunächst wird ein Zufälliger Session-key erzeugt, mit dem dann die geheimen Daten symetrisch verschlüsselt werden. Dieser Schlüssel wird nun mit dem öffentlichen Schlüssel des Empfängers asymetrisch verschlüsselt, und ihm zusammen mit den (verschlüsselten) Daten zugestellt. Der Empfänger entschlüsselt mit seinem geheimen Schlüssel den Session-Key und kann damit die eigentlichen Daten entschlüsseln.
Praxis
Warnhinweise
TODO
- Schlüssel kann nie wieder von einem Keyserver entfernt werden
- Revokation Zertifikate
- Ablaufdaten
- Kommentare mit Bedacht wählen, könnten peinlich werden wenn der Arbeitgeber einen Keyserver aufsucht...
- Namen sind Schall und Rauch: Einfach mal nach Bill Gates auf Keyservern suchen...
Erzeugen eines Schlüssels
TODO:
- gpg --gen-key -<Einzelne Schritte, hier zeigen?
- Schlüssellänge
- Revokation Zert. erstellen
Veröffentlichen des Schlüssels
- Hochladen aus gpg: gpg --keyserver subkeys.pgp.net --send-keys 0xEIGENE_KEYID
- Copy&Paste in Webinterface
- LDAP ?
Suchen nach Schlüsseln
- gpg: gpg --keyserver subkeys.pgp.net --search-keys Streibelt
- Webinterface
Praxis für Experten
Mehrere User IDs
TODO:
- Gründe
- Handling
- Anleitung
Photo-IDs
- Nachteil: Schlüssel wird irsinnig groß! -> kleines Schwarzweis Bild nehmen!
- Vorteil: Zusätzliches Identifikationsmerkmal, dass sich nicht wie eine Email so schnell ändert...
TODO:
- Anleitung
Mehrere Subkeys
TODO
Web of Trust
Bei einem Web of Trust, wörtlich: Netz des Vertrauens, geht man davon aus, daß es nicht möglich ist, mit jedem Beteiligten die Digitalen Schlüssel auszutauschen. Entweder weil kein persönlicher Kontakt möglich ist oder weil sich die Gruppe der Beteiligten laufend ändert. Ein Beispiel sind die Entwickler des Debian-Projektes. Es handelt sich hier um mehrere Tausend Personen, die über die gesamte Welt verstreut leben.
Diese Gruppe möchte auf sicherer Weise miteinander kommunizieren und die Emails signieren oder verschlüsseln. Um dies zu erreichen tauschen die Entwickler bei jedem persönlichen Treffen ihre öffentlichen Schlüssel aus und signieren den Schlüssel des anderen.
So hat Person A einen öffentlichen Schlüssel, der von B und C und D signiert ist. E ist ein neuer Entwickler, der nur einen Schlüssel hat, der von B und D signiert ist.
Nun erhält A eine signierte Email von E.
A kann nun anhand des ihm noch unbekannten Schlüssels nicht definitiv sagen, daß die Email wirklich von E kommt, da es noch nicht zu einem persönlichen Treffen gekommen ist und jeder einen Schlüssel mit E's Namen erstellen und verteilen kann.
A sieht aber, daß der Schlüssel von B und D signiert wurde und kann nun davon ausgehen, daß die Email zumindest wirklich von E stammt, da mindestens 2 weitere Mitglieder des Web of Trust die Authentizität bestätigen. A wird den öffentlichen Schlüssel von E jedoch trotzdem erst bei einer persönlichen Begegnung unterzeichnen und damit für seine Echtheit (Authentizität) bürgen.
Der Kern dieses 'Web of Trust' ist die Vertauenswürdigkeit der beteiligten Personen. Jeder Teilnehmer muß sich sicher sein, daß die anderen nicht leichtfertig mit dem Signieren fremder Schlüssel umgehen sondern gewissenhaft prüfen, ob der andere derjenige ist, für den er sich ausgibt.
Key Signing Parties
TODO Bei Keysigning Parties kommen nun eine Anzahl von Personen zusammen, die jeweils prüfen, ob der Inhaber eines Schlüssels in seinem Schlüssel korrekte Angaben zu Emailadresse und Person gemacht hat. Dabei kommt es zu n! Begegnungen - das ganze kann also etwas dauern.
Organisatorisches
TODO
Wann und wo findet die Keysigning Party statt?
Der Termin steht noch nicht fest, die Raumfrage wird entschieden, wenn die Anzahl der Teilnehmer fest steht. Bei wenig Teilnehmer können wir sie im FR 5046 durchführen.
Wer organisiert das ganze?
Was muss ich vor der Keysigning-Party machen?
- Erzeuge Dir ein PGP-Schlüsselpaar, wenn noch keins vorhanden ist (gpg --gen-key)
- Schicke Deinen öffentlichen Schlüssel an den PGP-Keyserver http://subkeys.pgp.net (gpg --keyserver subkeys.pgp.net --send-keys 0xEIGENE_KEYID) [optional, jeder bekommt ihn im Keyring von der Freitagsrunde]
- Schicke uns bis zum XX.XX.2005 eine Mail mit Deinem Schlüssel an keysigning@freitagsrunde.org (gpg --armor --export 0xEIGENE_KEYID > EIGENE_KEYID.asc)
- Solltest Du den Termin verpasst haben, bereite für jeden Teilnehmer einen Papierstreifen vor, auf dem die Ausgabe von gpg --fingerprint --show-key 0xEIGENE_KEYID abgedruckt ist.
- Lade nach dem XX.XX.2005 + 7 Tage den Keyring aller eingesandten Schlüssel von http://docs.freitagsrunde.de/keysigning/ sowie die Liste aller Teilnehmer mit Fingerprints von http://docs.freitagsrunde.de/keysigning/ herunter.
- Drucke die Textdatei aus, z.B. Doppelseitig, 2 Seiten A5 pro Seite A4 (man a2ps)
- Bilde mit gpg --print-md sha1 ksp-fr05.txt und gpg --print-md md5 ksp-fr05.txt die Prüfsummen über die Teilnehmerliste und trage sie im Ausdruck gut lesbar ein.
Was muss ich zur Keysigning-Party mitbringen?
- Geduld
- noch mehr Geduld und Ruhe
- einen (zuverlässigen) Stift
- Den Ausdruck der Teilnehmerliste mit fingerprints und Prüfsummen
- (im Winter) warme Jacke und Hose...
Wie läuft die Keysigning Party ab?
Zu Beginn der Party werden als Erstes die MD5 und SHA1 Prüfsummen über die Ausgedruckten Teilnehmerlisten verglichen. Dazu werden die Prüfsummen vom Organisator etwa an eine Tafel geschrieben. Stimmen die selbst generierten Prüfsummen mit denen der anderen überein, kann man davon ausgehen, dass alle Teilnhmer eine aktuelle Liste als Grundlage benutzen.
Danach (etwa 10 Minuten nach dem offiziellen Beginn...) wird begonnen, laut und vernehmlich alle Anwesenden und AnwesendInnen zu fragen, ob die Fingerprints Ihrer Schlüssel auf dem Ausdruck korrekt sind. Jeder markiert dann auf seinem Ausdruck den Eintrag 'Fingerprint OK'. Dazu ist allgemein Ruhe und Konzentration bei allen gefordert.
Ist dieses Procedere abgeschlossen, stellen sich alle in der Reihenfolge des Ausdrucks in eine Lange Reihe auf. [sollte man das im Freien vorhaben ist bitte auf passendes Wetter und genügend Licht zu achten...]
Nun geht jeweils der/die Erste der Reihe nacheinander an allen TeilnehmerInnen vorbei und zeigt ein Ausweisdokument vor. Jeder Teilnehmer markiert bei Übereinstimmung das Feld 'ID OK' auf seinem Ausdruck. Danach stellt sich der/diejenige an das Ende der Schlange um selbst die ID der anderen zu überprüfen.
Hat jemand versäumt, den Schlüssel rechtzeitig einzuschicken stellt er sich zu Beginn an das Ende der Schlange und hält für jeden Teilnehmer einen Schnipsel Papier mit einem Ausdruck von 'gpg --fingerprint --list-key KEY_ID' bereit. Diesen gibt er an alle weiter, wenn er an der Reihe ist die Schlange abzulaufen, und zeigt parallel dazu ein Ausweisdokument vor.
Es empfiehlt sich dringend danach alle Key-Ids auf dem Ausdruck durchzustreichen, bei denen nicht beide Felder abgehakt sind!
Was muss ich nach der Keysigning-Party machen?
Eigentlich ganz einfach:
Alle Schlüssel unterschreiben, bei denen Du die ID und der Inhaber den Fingerprint des Schlüssels geprüft hat.
Es gibt aber (natürlich) ein paar Fallstricke:
- Du übersiehst, dass Du die ID nicht geprüft hast, weil nach 1 Stunde Unterschreiben die Aufmerksamkeit doch nachlässt. Also am besten mit wachem Geiste alle Schlüssel fett durchstreichen, bei denen eines der Felder leer ist, oder bessser mit Textmarker diejenigen markieren, bei denen beide Felder angekreuzt sind.
- Jemand möchte nicht, dass sein Schlüssel auf einen Keyserver hochgeladen wird (er befürchtet z.B. schlicht SPAM).
- Du signierst einen Schlüssel mit zugehöriger Emailadresse, bei der zwar der Name (z.B. Peter Müller) stimmt, die Emailadresse (Peter_Mueller@fbi.com) jedoch nicht.
- Der Schlüssel hat mehrere Unter-IDs mit unterschiedlichen Emailadressen
- Es sind plötzlich 200 Teilnehmer geworden und Du willst nicht 2 Wochen lang nur Schlüssel signieren.
Für einige dieser Probleme gibt es Lösungen in Form von Shellscripten, für andere in Form von Kaffee.
Erstere funktionieren etwa so: Jeder Schlüssel wird zerlegt, so dass die einzelnen User-Ids getrennt vorliegen. Das script signiert jede der User-Ids einzeln und schickt den Signierten Schlüssel in verschlüsselter Form an die angegebene Emailadresse.
Damit ist sichergestellt das die Emailadressen alle funktionieren, der Schlüssel nur vom Inhaber entschlüsselt werden kann und dieser selbst entscheiden kann ob der den Schlüssel hochladen möchte. Importiert der Empfänger den Schlüssel dann in gpg, werden die Signaturen wieder zusammengeführt.
Aber vorsicht: nicht blind den gesamten Keyring unterschreiben!
Durch die Verwendung von agpg unter Linux muss man das Kennwort übrigens nur einmal eintippen, auch wenn dies für Paranoiker nicht geeignet ist, da der Schlüssel dann lange Zeit unverschlüsselt im RAM liegt. (Aber ob 200 mal Eintippen sicherheitstechnisch besser ist, sei dahingestellt)
Weblinks
Keyserver
für gpg:
- keyserver hkp://subkeys.pgp.net (verschiedene Hosts per Loadbalancer)