Sichere eMail mit OpenPGP und S/MIME
Dass das Internet systembedingt unsicher ist, hat sich in aller Regel herumgesprochen. Daten durchlaufen von der Quelle bis zum Ziel zahlreiche Server und Systeme, an denen die Daten, abgegriffen und/oder manipuliert werden können. Persönliche und vertrauliche Daten können so einfach Dritten in die Hände fallen, die mit grosser krimineller Energie versuchen an diese Daten zu kommen.
Inwieweit staatliche Stellen den Datenverkehr abhören, protokollieren und abgreifen und zu manipulieren bzw. zensieren versuchen, weiss
- keiner so genau und
- was mit den gewonnen Daten angestellt wird, wird sich niemand öffentlich sagen trauen.
Tja, das war Stand der Dinge vor 2013, denn was bisher in den Bereich der Spekulation fiel,
findet nun Bestätigung durch die Erkenntnisse des Whistleblowers Edward Snowden zu den Projekten PRISM aus den USA und TEMPORA aus England.
Seit Jahren werden unschuldige Bürgerinnen und Bürger von staatlichen Institutionen unter Generalverdacht gestellt und überwacht! Regierungen scheuen keinen Aufwand um in die Privatsphäre unschuldiger Bürgerinnen und Bürger einzudringen, Daten auszulesen und auszuwerten!
Was lernen wir aus dieser Tatsache? Unsere Kommunikation ist nach besten Wissen und Gewissen, so zu gestalten, damit andere unsere Daten nicht mitlesen und manipulieren können. Ferner ist sicherzustellen, dass Empfänger vertrauen können, dass Informationen tatsächlich von dem versandt wurden, von dem wir glauben, diese zu bekommen.
Hierzu greifen wir auf asymmetrische Verschlüsselungstechniken zurück, die wir entweder mit OpenPGP oder S/MIME realisieren können.
Für die vertrauliche und gesicherte Kommunikation mit mir, einfach PGP oder S/MIME nutzen! Mein S/MIME-Userzertifikat und auch mein mein PGP-Key kann man z.B. einfach auf einen der folgenden Seiten
auffindbar. Einfach auf einem der beiden Seiten nach meiner eMail-Adresse michael@nausch.org suchen!
Das ganze Thema wurde bei mehreren Infoabenden/Stammtischen der Piratenpartei am 02.12.2009, 04.07.2013 sowie am 05.09.2013 einem interessierten Teilnehmerkreis erklärt (Quellen in einer höheren Auflösung gibt es beim Author auf Anfrage).
Aktuell überarbeitete Version 3: KV Ebersbergversion
OpenPGP versus S/MIME
Bei beiden asymetrischen Verschlüselungsverfahren, ob nun OpenPGP oder S/MIME, sollte man grundsätzlich das Verfahren verinnerlichen. Was ist nun das Prinzip einer asymetrischen Verschlüsselung und wie unterscheidet es sich von der sysmetrischen?
Bei einer symetrischen Verschlüsselung haben beide Kommunikationspartner den gleichen Schlüssel und können mit Hilfe dieses Keys jeweils die Daten ver- und auch wieder entschlüsseln. Das ist nicht sonderlich rechenintensiv, hat aber einen entscheidenden Haken: Wie kommen beide Kommunikationspartner an den Schlüssel? Auf dem gleichen Kommunikationsweg den Schlüssel zur Kommunikation auszutauschen ist nicht sonderlich intelligent - auch wenn z.B. ein großer Möchtegern-VoIP-Anlagenhersteller, dies genau so unsinnigerweise macht und meint, dass sei besonders toll ;) .
Im Gegensatz zur symetrischen Verschlüsselung nutzt die asymetrischen Verschlüsselung ein Schlüsselpaar aus zwei Teilen, einem privaten oder öffentlichen Schlüssel. Dabei ist es im Grunde egal, welcher Teil veröffentlich wird, Hauptsache der als privat definierte, wird entsprechend so behandelt und der Nutzer hält diesen mit allen Mitteln privat - sprich sein Eigentum und nur ihm zugänglich.
Diese beiden Schlüssel sind durch mathematische Eigenschaften so miteinander verwoben, dass gilt:
- Was mit dem öffentlichen Schlüssel verschlüsselt wurde, ist nur mit dem privaten zu entschlüsseln.
- Mit dem öffentlichen Schlüssel codierte Inhalte lassen sich mit dem öffentlichen Schlüssel nicht mehr entschlüsseln.
- Daten die mit dem privaten Schlüssel codiert wurden, lassen sich mit dem öffentlichen Schlüssel öffnen. So kann eine Prüfsumme einer Nachricht mit dem privaten Schlüssel versehen werden. Der Empfänger kann dann die codierte Prüfsumme entschlüsseln und mit der eigenen erstellten Prüfsumme vergleichen und somit feststellen, ob die Daten manipuliert wurden. Man nennt dies auch Signieren.
Die Frage ist bei der ganzen Sache allerdings, wie können wir wissen, ob der öffentliche Schlüssel auch wirklich zu dem gehört, den wir meinen?
Bei dieser Gretchenfrage unterscheiden sich nun die beiden Verfahren OpenPGP und S/MIME. Bei OpenPGP verwendet man das sogenannte Web of Trust, bei dem sich die einzelnen Teilnehmer gegenseitig als vertrauenswürdige Kommunikationspartner einstufen. Dazu signieren Sie nach erfolgter Überprüfung mehrerer Daten, den öffentlichen Schlüssel des Kommunikationspartners, mit dem eigenen private Key. Darüber hinaus kann man auch anderen Teilnehmern soweit vertrauen, dass man von deren signierte Schlüssel als vertrauenswürdig akzeptiert. Eine genaue Beschreibung des Web of Trust findet man im übrigen bei Wikipedia. Beim alljährlichen VDR Camp finden unter anderem auch Keys Signing Sessions statt, deren Ablauf hier beschrieben ist.
Bei S/MIME sieht das etwas anders. Hier kommen X.509-Zertifikate zum Einsatz, wie man sie bei SSL-geschützten Webanwendungen her kennt. Genauso wie diese, werden S/MIME-Zertifikate von Trustcentern ausgestellt - wie z.B. CAcert. Ein solches Zertifikat entsteht, wenn das Trustcenter nach Überprüfung der Anmeldedaten den öffentlichen Schlüssel des Antragstellers mit dem privaten Schlüssel der Zertifizierungsstelle signiert. Der öffentliche Schlüssel, versehen mit dieser Signatur, bildet dann das X.509-Zertifikat.
OpenPGP in der Praxis
Installation von GnuPG
Bei der Basisinstallation unseres Betriebssystems wir GnuPG bereits mit installiert, so dass wir uns um eine gesonderte Installation keine großen Gedanken machen müssen. Mittels rpm -iql könne wir ansehen, was uns GnuPG alles mitbringt und wo die einzelnen dateien abgespeichert wurden.
# rpm -iql gnupg Name : gnupg Relocations: (not relocatable) Version : 1.4.5 Vendor: CentOS ... ... Size : 4696623 License: GPL Signature : DSA/SHA1, Mo 09 Mär 2009 02:45:48 CET, Key ID a8a447dce8562897 URL : http://www.gnupg.org/ Summary : Ein GNU-Dienstprogramm für sichere Kommunikation und Datenspeicherung. Description : GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and creating digital signatures. GnuPG has advanced key management capabilities and is compliant with the proposed OpenPGP Internet standard described in RFC2440. Since GnuPG doesn't use any patented algorithm, it is not compatible with any version of PGP2 (PGP2.x uses only IDEA for symmetric-key encryption, which is patented worldwide). /usr/bin/gpg /usr/bin/gpg-zip /usr/bin/gpgsplit /usr/bin/gpgv /usr/bin/lspgpot /usr/lib/gnupg /usr/lib/gnupg/gpgkeys_curl /usr/lib/gnupg/gpgkeys_finger /usr/lib/gnupg/gpgkeys_hkp /usr/lib/gnupg/gpgkeys_ldap /usr/share/doc/gnupg-1.4.5 /usr/share/doc/gnupg-1.4.5/AUTHORS /usr/share/doc/gnupg-1.4.5/BUGS /usr/share/doc/gnupg-1.4.5/COPYING /usr/share/doc/gnupg-1.4.5/ChangeLog /usr/share/doc/gnupg-1.4.5/DETAILS /usr/share/doc/gnupg-1.4.5/HACKING /usr/share/doc/gnupg-1.4.5/INSTALL /usr/share/doc/gnupg-1.4.5/NEWS /usr/share/doc/gnupg-1.4.5/OpenPGP /usr/share/doc/gnupg-1.4.5/PROJECTS /usr/share/doc/gnupg-1.4.5/README /usr/share/doc/gnupg-1.4.5/THANKS /usr/share/doc/gnupg-1.4.5/TODO /usr/share/doc/gnupg-1.4.5/samplekeys.asc /usr/share/gnupg /usr/share/gnupg/FAQ /usr/share/gnupg/faq.html /usr/share/gnupg/options.skel /usr/share/info/gpg.info.gz /usr/share/info/gpgv.info.gz /usr/share/locale/be/LC_MESSAGES/gnupg.mo /usr/share/locale/ca/LC_MESSAGES/gnupg.mo /usr/share/locale/cs/LC_MESSAGES/gnupg.mo /usr/share/locale/da/LC_MESSAGES/gnupg.mo /usr/share/locale/de/LC_MESSAGES/gnupg.mo /usr/share/locale/el/LC_MESSAGES/gnupg.mo /usr/share/locale/en@boldquot/LC_MESSAGES/gnupg.mo /usr/share/locale/en@quot/LC_MESSAGES/gnupg.mo /usr/share/locale/eo/LC_MESSAGES/gnupg.mo /usr/share/locale/es/LC_MESSAGES/gnupg.mo /usr/share/locale/et/LC_MESSAGES/gnupg.mo /usr/share/locale/fi/LC_MESSAGES/gnupg.mo /usr/share/locale/fr/LC_MESSAGES/gnupg.mo /usr/share/locale/gl/LC_MESSAGES/gnupg.mo /usr/share/locale/hu/LC_MESSAGES/gnupg.mo /usr/share/locale/id/LC_MESSAGES/gnupg.mo /usr/share/locale/it/LC_MESSAGES/gnupg.mo /usr/share/locale/ja/LC_MESSAGES/gnupg.mo /usr/share/locale/nb/LC_MESSAGES/gnupg.mo /usr/share/locale/pl/LC_MESSAGES/gnupg.mo /usr/share/locale/pt/LC_MESSAGES/gnupg.mo /usr/share/locale/pt_BR/LC_MESSAGES/gnupg.mo /usr/share/locale/ro/LC_MESSAGES/gnupg.mo /usr/share/locale/ru/LC_MESSAGES/gnupg.mo /usr/share/locale/sk/LC_MESSAGES/gnupg.mo /usr/share/locale/sv/LC_MESSAGES/gnupg.mo /usr/share/locale/tr/LC_MESSAGES/gnupg.mo /usr/share/locale/zh_CN/LC_MESSAGES/gnupg.mo /usr/share/locale/zh_TW/LC_MESSAGES/gnupg.mo /usr/share/man/man1/gpg.1.gz /usr/share/man/man1/gpg.ru.1.gz /usr/share/man/man1/gpgv.1.gz /usr/share/man/man7/gnupg.7.gz
Schlüsselgenerierung
Im Zuge der Schlüsselgenerierung, kann der öffentliche Schlüssel auf einem Keyserver, z.B. http://keyserver.nausch.org hochgeladen werden.
Doch Achtung! Solange man noch am experimentieren ist und sich noch nicht genau sicher ist, was man tut, sollte man keine Upload vornehmen! Denn befindet sich erst einmal ein Key auf dem Server, kann dieser nicht mehr gelöscht werden, sondern lediglich für ungültig erklärt werden.
Die Erzeugung des Schlüsselpaares wir mit dem Befehl gpg --gen-key gestartet. Die Fragen beantwortet man gemäß der eigenen Vorstellung(en)
$ gpg --gen-key
gpg (GnuPG) 1.4.5; Copyright (C) 2006 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.
gpg: Verzeichnis `/home/django/.gnupg' erzeugt
gpg: Neue Konfigurationsdatei `/home/django/.gnupg/gpg.conf' erstellt
gpg: WARNUNG: Optionen in `/home/django/.gnupg/gpg.conf' sind während dieses Laufes noch nicht wirksam
gpg: Schlüsselbund `/home/django/.gnupg/secring.gpg' erstellt
gpg: Schlüsselbund `/home/django/.gnupg/pubring.gpg' erstellt
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) DSA and Elgamal (default)
(2) DSA (nur signieren/beglaubigen)
(5) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 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) 0
Schlüssel verfällt nie
Ist dies richtig? (j/N) j
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Ihr Name ("Vorname Nachname"): Michael Nausch
Email-Adresse: django@omni128.de
Kommentar:
Sie haben diese User-ID gewählt:
"Michael Nausch <django@omni128.de>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen.
Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
.+++++++++++++++.+++++.++++++++++++++++++++.+++++++++++++++..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++.>+++++..................................+++++
Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
+++++...+++++.++++++++++..++++++++++..++++++++++.++++++++++.+++++.......+++++.++++++++++...+++++.+++++++++++++++.+++++.++++++++++..+++++..++++++++++...........++++++++++.++++++++++..+++++..+++++.+++++++++++++++>+++++...+++++.++++++++++++++++++++.+++++..+++++.++++++++++>.+++++>...+++++.>+++++.........+++++^^^
gpg: /home/django/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: key 0CC2A7BA marked as ultimately trusted
Öffentlichen und geheimen Schlüssel erzeugt und signiert.
gpg: "Trust-DB" wird überprüft
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/0CC2A7BA 2009-04-27
Schl.-Fingerabdruck = A6FD 1BE7 6A94 4544 1073 BFDB 73E9 9A2A 0CC2 A7BA
uid Michael Nausch <django@omni128.de>
sub 4096g/8FE37004 2009-04-27
Inhalt der Schlüsselringe
Nach der Erstellung der Erstellung des Schlüsselpaares befinden sich im Verzeichnis .gnupg zwei Dateien, nämlich secring.pgp und pubring.pgp.
$ ll .gnupg/
insgesamt 32 -rw------- 1 django django 9207 27. Apr 21:55 gpg.conf -rw------- 1 django django 1678 27. Apr 22:04 pubring.gpg -rw------- 1 django django 1678 27. Apr 22:04 pubring.gpg~ -rw------- 1 django django 600 27. Apr 22:04 random_seed -rw------- 1 django django 1842 27. Apr 22:04 secring.gpg -rw------- 1 django django 1280 27. Apr 22:04 trustdb.gpg
Im ersten Schlüsselring secring.pgp befindet sich der oder die privaten Schlüssel und im pubring.pgp alle öffentlichen, auch die von Dritten. Verwendet man GnuPG zum ersten Mal, befindet sich in beiden Schlüsselringen nur jeweils ein Schlüssel. Den Inhalt des privaten Schlüsselringes erfährt man mittels gpg --list-secret-keys.
$ gpg --list-secret-keys
/home/django/.gnupg/secring.gpg ------------------------------- sec 1024D/0CC2A7BA 2009-04-27 uid Michael Nausch <django@omni128.de> ssb 4096g/8FE37004 2009-04-27
Der Inhalt des öffentlichen keyrings zeigt gpg --list-keys.
$ gpg --list-keys
/home/django/.gnupg/pubring.gpg ------------------------------- pub 1024D/0CC2A7BA 2009-04-27 uid Michael Nausch <django@omni128.de> sub 4096g/8FE37004 2009-04-27
Bei einem „produktiven Schlüsselring“ werden entsprechend alle Schlüssel im öffentlichen Schlüsselbund angezeigt:
$ gpg --list-keys
/home/bigchief/.gnupg/pubring.gpg --------------------------------- pub 1024D/2384C849 2009-03-30 uid Michael Nausch <michael@nausch.org> uid Michael Nausch (aka BigChief) <bigchief@omni128.de> uid Michael Nausch (aka Django) <django@nausch.org> sub 4096g/D239B202 2009-03-30 pub 1024D/81EBD929 2007-11-23 uid Sebastian Schubert (SpaceNet AG) <ssc@space.net> sub 2048g/CC15DA69 2007-11-23 pub 1024D/0DE59D7A 2007-11-16 uid Thomas Keil <thomas@weblizards.de> sub 4096g/C77D03BC 2007-11-16 pub 1024D/C3B26780 2007-11-11 [expires: 2011-11-10] uid Peer Heinlein -- Heinlein Professional Linux Support GmbH <p.heinlein@heinlein-support.de> sub 4096g/DE228890 2007-11-11 [expires: 2011-11-10] pub 1024D/4C016DE0 2008-01-02 uid Marco Scholl (Email) <mail@marco-scholl.de> uid Marco Scholl (Ubuntu-Launchpad) <ubuntu@marco-scholl.de> uid [jpeg image of size 2556] sub 2048g/38C3B14C 2008-01-02 pub 1024D/CBBEBF26 2008-07-30 uid Bernd Goetter (dh5is) <routerman@gmx.net> uid [jpeg image of size 3176] sub 2048g/E46E82C6 2008-07-30 pub 1024D/E9E5F528 2009-03-28 [expires: 2011-03-28] uid Robert Fuhge <fuhge@web.de> sub 2048g/31EC58B6 2009-03-28 [expires: 2011-03-28] pub 2048D/DEA1DF01 2008-10-26 uid Dieter Hametner (for VDR related emails) <dh+vdr@gekrumbel.de> uid Dieter Hametner (Dieter Hametner) <dh@gekrumbel.de> sub 4096g/866FC4B5 2008-10-26 pub 1024D/FDB5AACC 2009-04-04 [expires: 2014-04-03] uid Carsten Presser (cpresser) <c@rstenpresser.de> sub 2048g/AEFC9365 2009-04-04 [expires: 2014-04-03] pub 1024D/A2C9DB22 2002-10-12 uid Udo Richter <udo.richter@gmx.de> uid Udo Richter <udo_richter@gmx.de> sub 1024g/E0D6A337 2002-10-12 pub 1024D/AEDAA642 2008-03-03 uid Tobias Grimm <tobias.grimm@e-tobi.net> uid Tobias Grimm <tg@e-tobi.net> uid Tobias Grimm <vdr@e-tobi.net> uid Tobias Grimm <etobi@debian.org> uid Tobias Grimm <debian@e-tobi.net> uid Tobias Grimm <tobias@e-tobi.net> sub 2048g/5979DD9D 2008-03-03
Rückruf-Zertifikat
Sollte ein Bösewicht die Datei secring.pgp mit dem privaten Schlüssel in seine Finger kriegen, kann er mit dem Schlüssel nur etwas anfangen, wenn er dessen Passphrase kennen sollte. Sollte man jedoch in die Bredullie kommen, einen Schlüssel für ungültig zu erklären, da z.B. die Festplatte abgeraucht ist, oder man schlichtweg die Passphrase vergessen hat, so muss man entsprechend vorbereitet sein.
Hierzu erstellen wir uns nun ein Revocation Certificate1). Da wir hierzu den privaten Schlüssel, wie auch die Passphrase benötigen, erklärt, warum wir uns genau jetzt darüber Gedanken machen (müssen). Dieses Revocation Certificate muss an einem besonderen streng geheimen Ort aufbewart werden, da damit könnte ein Angreifer, den Key seines Opfers unwiederbringlich zurückziehen und dies ohne jegliche weitere Sicherung oder Passphraseabfrage. Wir Schreiben das Zertifikat also ab!
O.K. erst einmal wird mit gpg --gen-revoke key-ID das Zertifikat erzeugt. Zuerst ermitteln wir uns aber die entsprechende Key-ID:
$ gpg --list-sigs
/home/django/.gnupg/pubring.gpg ------------------------------- pub 1024D/C591B828 2009-04-28 uid Michael Nausch <django@omni128.de> sig 3 C591B828 2009-04-28 Michael Nausch <django@omni128.de> sub 4096g/7662A515 2009-04-28 sig C591B828 2009-04-28 Michael Nausch <django@omni128.de>
Anschließend erzeugen wir das Rückrufzertifikat:
$ gpg --gen-revoke C591B828
sec 1024D/C591B828 2009-04-28 Michael Nausch <django@omni128.de> Create a revocation certificate for this key? (y/N) y Grund für den Widerruf: 0 = Kein Grund angegeben 1 = Hinweis: Dieser Schlüssel ist nicht mehr sicher 2 = Schlüssel ist überholt 3 = Schlüssel wird nicht mehr benutzt Q = Abbruch (Wahrscheinlich möchten Sie hier 1 auswählen) Ihre Auswahl? 3 Geben Sie eine optionale Beschreibung ein. Beenden mit einer leeren Zeile: > Dies war nur ein Demonstrationsschlüssel! > Grund für Widerruf: Schlüssel wird nicht mehr benutzt Dies war nur ein Demonstrationsschlüssel! Is this okay? (y/N) y You need a passphrase to unlock the secret key for user: "Michael Nausch <django@omni128.de>" 1024-bit DSA key, ID C591B828, created 2009-04-28 Ausgabe mit ASCII Hülle erzwungen Widerrufszertifikat wurde erzeugt. Bitte speichern Sie es auf einem Medium welches sie wegschliessen können; falls Mallory (ein Angreifer) Zugang zu diesem Zertifikat erhält, kann erIhren Schlüssel unbrauchbar machen. Es wäre klug, dieses Widerrufszertifikat auch auszudrucken und sicher aufzubewahren, falls das ursprüngliche Mediumnicht mehr lesbar ist. Aber Obacht: Das Drucksystem kann unter Umständen eine Kopie anderen Nutzern zugänglich machen. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: A revocation certificate should follow iHIEIBECADMFAkn3UoUsHQNEaWVzIHdhciBudXIgZWluIERlbW9uc3RyYXRpb25z c2NobMO8c3NlbCEACgkQSKXk5sWRuCi3QQCVGAy0rN55BUGgFVH5I0EepgcjfgCf ey5WP/BwgqyyIx/VPweiJAFUREE= =m1aK -----END PGP PUBLIC KEY BLOCK-----
Den Zertifikatsblock speichern wir dann in einer Textdatei an einem sicheren Ort ab.
$ vim revocation.crt
Soll nun der Schlüssel zurückgezogen werden, so braucht man lediglich die Datei revocation.crt in den öffentlichen Schlüsselbund pubring.pgp zu importieren. GnuPG erkennt nun das Rückrufzertifikat für einen der Schlüssel handelt und hängt des diesem ohne weitere Sicherheitsabfrage an.
$ gpg --import revocation.crt
gpg: key C591B828: "Michael Nausch <django@omni128.de>" revocation certificate imported gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: neue Schlüsselwiderrufe: 1 gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
Anschließend können wir uns den Inhalt des öffentlichen schlüsselringes anzeigen lassen:
$ gpg --list-sigs C591B828
pub 1024D/C591B828 2009-04-28 [revoked: 2009-04-28] rev C591B828 2009-04-28 Michael Nausch <django@omni128.de> uid Michael Nausch <django@omni128.de> sig 3 C591B828 2009-04-28 Michael Nausch <django@omni128.de>
Beim Schlüssel mit der ID C591B828 sehen wir nun am Zeilenanfang ein rev, welches uns anzeigt, dass dieser Schlüssel zurückgezogen (revoked) wurde. Anschließend läd man den Schlüssel auf einen Keyserver.
Export des private Keys
Will man seinen privaten Schlüssel von einem Rechner auf einen vertrauenswürdigen weiteren Rechner transferieren, gehen wir wie folgt vor.
Als erstes holen wir uns die Key-ID des Schlüssels, den wir exportieren möchten.
$ gpg --list-secret-keys
/home/django/.gnupg/secring.gpg ------------------------------- sec 1024D/1F0471F12384C849 2009-03-30 uid Michael Nausch <michael@nausch.org> uid Michael Nausch (aka BigChief) <bigchief@omni128.de> uid Michael Nausch (aka Django) <django@nausch.org> ssb 4096g/8088CA80D239B202 2009-03-30
Anschließend exportieren wir den gewünschten private-Key, in unserem Beispiel ist dies die ID 1F0471F12384C849.
$ gpg --export-secret-key --armor 1F0471F12384C849 > 1F0471F12384C849-secret.asc
Die Datei 1F0471F12384C849-secret.asc enthält nun den private key und wir können diese Datei sichern, oder auf einen Zielrechner/Device kopieren.
Export des public Keys
in eine Datei
Um einen Schlüssel an einen Freund direkt auszuhändigen, oder um den öffentlichen Schlüssel auf einer Homepage zu veröffentlichen, ist es notwendig den public Key zu exportieren. Hierzu benutzen wir den Befehl gpg – export –armor keyID > public-key.asc
$ gpg --export --armor 2384C849 > public-key.asc
$ cat public-key.asc
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQGiBEnRHRIRBACR8Tm9jHPJ9RGkJA9OAPB/SrR7/5h/ho96yCuiZvlHRZJgRnZo 6nl1psT4I4ILY787KPi757P9CnXIVcFR6BJtfg5rwR9xUDSWRj2jqx3XWvSscqaz 4MEcrY1T4m9GHNrQi/O/bydiX8ugiBy55UaimsRnqU3AT7+k8aSCz9Q1ewCg7LIt FpkkXnKGL+XFvEeaUqoYI/0EAIaGymU2Y7Cd3vq6jCl8qswjxnHzGiaowro0GeOH TR78pksJD+mF3PqDBI3PCVI0PFitPsRCKEchAJuWmEXf0TEHOFquG6LtDGTfeapu OE/CCCGFyd/KTH7BU/n/h2EBex/+tcdyaWN/g0OUkoXz3N1i9wocTWvraVgKwxpL 4E/hA/9UEtkDb1kDFn/6vAxJTAllkPvRBH9s4qX3jxE9VXjBF75ElN+uvIM9wWM0 RxjP3HaNXwSbRr+KZA2A6fpYbJnE/17LZ1DpQm9F8H6n3cf/nTD7GXZdznUsu7YV vGcU63Kx1qhNLPCEphLI42TBgLuqR1f8kEAtSfFKgmQ73QeK2rQjTWljaGFlbCBO YXVzY2ggPG1pY2hhZWxAbmF1c2NoLm9yZz6IYwQTEQIAIwIbAwYLCQgHAwIEFQII AwQWAgMBAh4BAheABQJJ0R8EAhkBAAoJEB8EcfEjhMhJGiUAoJt5VLDVwRjL7M21 CGOojLl0xucNAKCiFgBJvMVJfGldqu3m9f1OeWZbTohGBBARAgAGBQJJ12PAAAoJ EKcOoZ9MAW3gG24AoICAaUlcCJBWC/M4UTFxJ2eQ788EAJ9jQEP8ftKFMx+kNA1K /MFAFvH274hGBBARAgAGBQJJ2kDsAAoJEPcYDSau2qZC2RkAnjBl0Yf1Mzu8vJZg 3N4Q2A7efl0aAJ9kMtlSjWwPg2xwrKx18+CEik/5VIhGBBARAgAGBQJJ2lMOAAoJ ED/Dkkv9tarMcqgAoNQgUWKqZaSDCzKp37ln4U50tCFOAKDsYHMPF2NGROIjpuzi j4qV4CjYWYhGBBARAgAGBQJJ27NKAAoJEIRjxf/Lvr8mkksAoMy2weW2gyJ+kDbW phjPgFlSfnEHAJ9GL5ZWFDsa2ThupL+2nA0GuqTQ5ohWBBARCwAGBQJJ2oG8AAoJ EB/fNUveod8B2fEA4LPjBK67s++8EprA8nSdyXTMgw3lPPAwRxWi0OQA4KB3P2Xo tezVEYj/JvOuuHbP70Kh+zNRRw8/QVm0M01pY2hhZWwgTmF1c2NoIChha2EgQmln Q2hpZWYpIDxiaWdjaGllZkBvbW5pMTI4LmRlPohgBBMRAgAgBQJJ0R6nAhsDBgsJ CAcDAgQVAggDBBYCAwECHgECF4AACgkQHwRx8SOEyEmTgwCgiAIzkeiY+QVEZ5s1 4BrMyyyJhG8AoI7IH18iOH8K1FZGcOqhbs6nRGHiiEYEEBECAAYFAknXY8AACgkQ pw6hn0wBbeADGQCfRPq7TAvuCQHBVQo8/r3JNC004agAn1XqvOD2Zv70gM5IgIft AUtP2U6+iEYEEBECAAYFAknaQOwACgkQ9xgNJq7apkL1oACeNjg0+DOHWq3ouNb9 rrt+Qqu0/IsAnA+KM383QqdbbSc5RlhgykPUL2G7iEYEEBECAAYFAknaUw4ACgkQ P8OSS/21qsxN8wCggM/ypa06JlHtj61TSv2u7SIzXM0An1JLmON0BTzseRmzMCEE TBZCM5IWiEYEEBECAAYFAknbs08ACgkQhGPF/8u+vyYRqACdE9urnI7qIDCwWHbg 1LG+9vzf+84AnjLiQv1Jd5sA9B2v13ztrKl6/kzLiFYEEBELAAYFAknagbwACgkQ H981S96h3wHy5ADgj3GrZ9u7UfC4XNECO6w8mjvf0QLi/AtfN9XqPgDffPmS08he 7xk1gvYM+hzm7IU6Dv+DN3hU/QbcKbQvTWljaGFlbCBOYXVzY2ggKGFrYSBEamFu Z28pIDxkamFuZ29AbmF1c2NoLm9yZz6IYAQTEQIAIAUCSdEe0gIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJEB8EcfEjhMhJa9cAoNiV37wAheLKJxUN9Ui+cjJI vt0MAKC80k4tO7Oa0E3nO6Qbq3Cu/i/6eohGBBARAgAGBQJJ12PAAAoJEKcOoZ9M AW3gq4EAnAoBXyI9HNhBNbhB/sBPmCNEgBEtAKCl9krifoij25l3wmb9X6FUdXzY N4hGBBARAgAGBQJJ2kDsAAoJEPcYDSau2qZCqN4AoIawtaQoHX8dkon96WeOZhql 7VZiAJ9a4kdk2OU1H8JOl5gLDHTaQfgfEohGBBARAgAGBQJJ2lMOAAoJED/Dkkv9 tarMdTAAoKFSc2Jw6M+wZCNc/fZEj6jqqHSAAJ4soecklyB3piOV+AruhmRe8R0f DYhGBBARAgAGBQJJ27NPAAoJEIRjxf/Lvr8m4ZoAnjWuo4zN50J3OVizMaQYDbYH g7K3AJ93Qe8isJhUYzChdanLTi4KNPwo/4hWBBARCwAGBQJJ2oG8AAoJEB/fNUve od8BLqkA31GEhEnkOep/6qnYL2OOWjYJydEBpj+oTbe4KuMA4J5puTM6tvdkp9e4 F2jcc+6xDKNMegBZug/1Rby5BA0ESdEdkhAQAMs80NMTiH+JMV5u9ieTpuvv/kZV vJvrEUTBZ46YygbHvgkdkaG5APAsuxryRUxXNQpH8kacMdolOrPdUmpqLAs1zuq7 pFtalXwYAbdl0jZJsM1zfpx4FJ0ExRY3fviQrapAsrfd95p9Zz6yLHE6OPhKdVyU pi2VVAFvaLir7nmyNFCjwfaPC5cDUoDHfuHpnEXC4p3YEmynK8ySjSktMt+T6A1C l2zjGq4gdf/SqxDEGOZzHPrTx6Dbb69h9xzS6CqPllvMKfjck2MovZCOBq29cI1l LS8dT2smLWUwiVsxCn9mfqQg1u3SQhrfcGHlhzKvFdPY0aN7cILOCPUedBWQL5Wk tnoF+GTPDfhOsvhuOTnrCz8TcZwwkZqH16jCV/oFCKvmg5fv/FzoZhn26trihn9Y UtfTmJlpcjjKUQEeDhDyX6F7vKyhv5XfHCZ+cnSa+YUJze8DoL9eqJmaT6zzvbT5 mn90yPJFvaoiXslYlY7DdjKW85S8Al1VQJLEvS03Kdaz2pqUWOPkYLJ8VCxNQLKe lLqkcEHXeYukpmBP2eQT/jDsGpaziZiT96xZQppg53tWrAdRoZetnlL8/Nc/husm JN/U/Pv9/mNd4dutk/OpJmQOLPM6WZ0ZKOx3V7NdXd1bFAaIkwchAPxoEvfZ6ZZN R4ts9kAHSP9//w8vAAMHD/9/GqSZ7BqpcVtTDhoZfrb4sr/auORxepxJIWWmYFs+ dTGHzuPup7Rzj8O0eTOFvv1Fqzek4IXJBNDR/ulHiFbOTLbQ7fTVvIH/HQN7ZsiB zpj91C1alZVO69nSPw6O5QIpSnqx+azXLmdtsjv77trtuAa2tvJWI1Bv3KcIzm3e gSXcSeVpSmSU3R45FuaCR4G2D3iv7nb8S2FokalJC0A32A9aiGb+TFgXTno7UAcm g+yF+7/VFqDQi9jlMjCKgUGsj6yM8cxDpiL292Iqstx3/WFpc82a0pBZwh0aKruV fwToO7hLenSLvNIVXcSDG3wvWREHqosScnXCO0gln6XGOj5VSHJ+T4mUBK4v/GyI 2DWFCkqufpz/tzu39Cf2/aF6kHSu+y3dypSQ4CTbaAkOP32SGN2c2zPL6R6HzFh6 kA3qgtSfwa4cwYvf3U1wSyZQOp3DQLgJ+FbPkX8KLA4wQ+FkApsKZXoQoLMcf4WF BxhQJnagtFajAt+HMP0C/5Kmk4qJuAV5YDWAdwxWAdxkMbeYiAm4GfkrxikEC6sU jloprzxctT2HwFEA8kSyN86tTv1qnphYleBgblOeP4HM1H07iKBjIF34Gvo1+K3Z J7QHgUluxQK2KD3WSakCzvSqHr/au5fvzm4wnY1EvqLwC0qXbrI7vJLz4rkpEhNt RYhJBBgRAgAJBQJJ0R2SAhsMAAoJEB8EcfEjhMhJjvUAn0PyyXdK714eWa8dQUmd 36efmnu7AJ9yr+km06Z7BdZ1z8AOfNJdwpp0vg== =gen/ -----END PGP PUBLIC KEY BLOCK-----
auf einen Keyserver
Den zuvor exportierten public key können wir nun in einem WEB-Formular auf einem Keyserver manuell eintragen. Oder wir exportieren diesen direkt aus dem öffentlichen Schlüsselring:
$ gpg --keyserver keyserver.nausch.org --send-key 2384C849
gpg: sending key 2384C849 to hkp server keyserver.nausch.org
Um nun nicht jedesmal den Keysever manuell angeben zu müssen, hinterlegen wir diesen in der Konfigurationsdatei ~/.gnupg/gpg.conf.
$ vim ~/.gnupg/gpg.conf
... # Djangos bevorzugter Keyserver, eingetragen am 28.04.2009 keyserver keyserver.nausch.org
Nunmehr reicht ein:
$ gpg --send-key 2384C849 gpg: sending key 2384C849 to hkp server keyserver.nausch.org
Import eines public Keys
Beim Revocation Certifikat haben wir bereits die Importfunktion genutzt. Genauso funktioniert im Übrigen der Import eines fremden public Keys.
$ gpg --import friendly-user.asc
Genau so geht dies natürlich direkt von einem Keyserver aus.
$ gpg --recv-key 57548dcd
Schlüsseleditor
Zum Editieren eines Schlüssel, so z.B. zum Ergänzen von weiteren User-IDs (eMail-Adressen) oder zum Festlegen des Vertrauenswertes oder zum Beglaubigen (Signieren) von Schlüsseln nutzen wir den Schlüsseleditor. Diesen rufen wir auf über gpg –edit-key keyID.
$ gpg --edit-key 2384C849
gpg (GnuPG) 1.4.5; Copyright (C) 2006 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.
Geheimer Schlüssel ist vorhanden.
pub 1024D/2384C849 created: 2009-03-30 expires: niemals usage: SC
trust: uneingeschränkt Gültigkeit: uneingeschränkt
sub 4096g/D239B202 created: 2009-03-30 expires: niemals usage: E
[ultimate] (1). Michael Nausch <michael@nausch.org>
[ultimate] (2) Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ultimate] (3) Michael Nausch (aka Django) <django@nausch.org>
Befehl> help
quit Menü verlassen
save speichern und Menü verlassen
help Diese Hilfe zeigen
fpr show key fingerprint
list Schlüssel und User-IDs auflisten
uid User-ID N auswählen
key select subkey N
check check signatures
sign sign selected user IDs [* see below for related commands]
lsign sign selected user IDs locally
tsign sign selected user IDs with a trust signature
nrsign sign selected user IDs with a non-revocable signature
adduid Eine User-ID hinzufügen
addphoto Eine Foto-ID hinzufügen
deluid delete selected user IDs
addkey add a subkey
addcardkey add a key to a smartcard
keytocard move a key to a smartcard
bkuptocard move a backup key to a smartcard
delkey delete selected subkeys
addrevoker Einen Widerrufschlüssel hinzufügen
delsig delete signatures from the selected user IDs
expire change the expiration date for the key or selected subkeys
primary flag the selected user ID as primary
toggle toggle between the secret and public key listings
pref Liste der Voreinstellungen (für Experten)
showpref Liste der Voreinstellungen (ausführlich)
setpref set preference list for the selected user IDs
keyserver set the preferred keyserver URL for the selected user IDs
notation set a notation for the selected user IDs
passwd Die Passphrase ändern
trust Den "Owner trust" ändern
revsig revoke signatures on the selected user IDs
revuid revoke selected user IDs
revkey revoke key or selected subkeys
enable enable key
disable disable key
showphoto show selected photo IDs
clean compact unusable user IDs and remove unusable signatures from key
minimize compact unusable user IDs and remove all signatures from key
* The `sign' command may be prefixed with an `l' for local signatures (lsign),
a `t' for trust signatures (tsign), an `nr' for non-revocable signatures
(nrsign), or any combination thereof (ltsign, tnrsign, etc.).
Befehl> quit
eMail-Adressen bei einem PGP/GPG-Schlüssel hinzufügen bzw entfernen
hinzufügen
Zu einem bestehendem Schlüsselpaar, lassen weitere eMail-Adressen hinzufügen. Hierzu lassen wir uns erst einmal alle secret-keys ausgeben.
$ gpg --list-secret-keys
/home/django/.gnupg/secring.gpg ------------------------------- sec 1024D/1F0471F12384C849 2009-03-30 uid Michael Nausch <michael@nausch.org> uid Michael Nausch (aka BigChief) <bigchief@omni128.de> uid Michael Nausch (aka Django) <django@nausch.org> ssb 4096g/8088CA80D239B202 2009-03-30
In diesem Beispiel haben wir nur einen privaten Schlüssel im Schlüsselbund. Zum Anfügen einer Adresse wählen wir zuerst den gewünschten key aus.
$ gpg --edit-key 1F0471F12384C849
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub 1024D/1F0471F12384C849 erzeugt: 2009-03-30 verfällt: niemals Aufruf: SC
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 4096g/8088CA80D239B202 erzeugt: 2009-03-30 verfällt: niemals Aufruf: E
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2) Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3) Michael Nausch (aka Django) <django@nausch.org>
Befehl>
Da wir eine weitere eMail an den Schlüssel anfügen wollen, teilen wir dies dem Programm durch die eingabe der Option adduid mit.
Befehl> adduid
Wir werden nun nach dem Namen, eMail-Adresse und Kommentar gefragt.
Ihr Name ("Vorname Nachname"): Django
Email-Adresse: django@mailserver.guru
Kommentar:
Sie haben diese User-ID gewählt:
"Django <django@mailserver.guru>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden?
Nach Bestätigung der Daten durch Eingabe von F werden wir nach der bestehenden Passphrase unseres Schlüssels gefragt.
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren. Benutzer: "Michael Nausch <michael@nausch.org>" 1024-Bit DSA Schlüssel, ID 1F0471F12384C849, erzeugt 2009-03-30
Im Speicher wurde nun eine weitere User-ID bzw. eMail-Adresse zu einem bestehenden private key hinzugefügt. Damit die Daten dauerhaft auf die Platte geschrieben werden, schließen wir unseren Bearbeitungsvorgang mit dem Befehl save ab.
Befehl> save
löschen
Wie zuvor beim Hinzufügen eines Schlüssels, lassen wir uns erst alle secret-keys eines Schlüsselbundes ausgeben, wenn wir eine eMailadresse bei einem Schlüssel entfernen wollen.
$ gpg --list-secret-keys
/home/django/.gnupg/secring.gpg ------------------------------- sec 1024D/1F0471F12384C849 2009-03-30 uid Michael Nausch <michael@nausch.org> uid Michael Nausch (aka BigChief) <bigchief@omni128.de> uid Michael Nausch (aka Django) <django@nausch.org> uid Django <django@mailserver.guru> ssb 4096g/8088CA80D239B202 2009-03-30
In diesem Beispiel haben wir nur einen privaten Schlüssel im Schlüsselbund. Zum Löschen einer Adresse wählen wir zuerst den gewünschten key aus.
$ gpg --edit-key 1F0471F12384C849
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub 1024D/1F0471F12384C849 erzeugt: 2009-03-30 verfällt: niemals Aufruf: SC
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 4096g/8088CA80D239B202 erzeugt: 2009-03-30 verfällt: niemals Aufruf: E
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2) Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3) Michael Nausch (aka Django) <django@nausch.org>
[ uneing.] (4) Django <django@mailserver.guru>
Befehl>
Mit dem Befehl uid wählen wir nun diejenige User-ID aus, die wir löschen möchten.
Befehl> uid 4
pub 1024D/1F0471F12384C849 erzeugt: 2009-03-30 verfällt: niemals Aufruf: SC
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 4096g/8088CA80D239B202 erzeugt: 2009-03-30 verfällt: niemals Aufruf: E
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2) Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3) Michael Nausch (aka Django) <django@nausch.org>
[ uneing.] (4)* Django <django@mailserver.guru>
An dem Sternchen * hinter der UID-Nummer sehen, wir welche ID ausgewählt wurde. Nun können wir mit dem Befehl deluid die gewählte UID löschen.
Befehl> deluid
Wir werden nun gefragt, ob wir dies wirklich wünschen.
Diese User-ID wirklich entfernen? (j/N) j
Dies e Frage bestätigen wir mit der Eingabe von j.
pub 1024D/1F0471F12384C849 erzeugt: 2009-03-30 verfällt: niemals Aufruf: SC
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 4096g/8088CA80D239B202 erzeugt: 2009-03-30 verfällt: niemals Aufruf: E
[ uneing.] (1). Michael Nausch <michael@nausch.org>
[ uneing.] (2) Michael Nausch (aka BigChief) <bigchief@omni128.de>
[ uneing.] (3) Michael Nausch (aka Django) <django@nausch.org>
Auch hier müssen wir die Änderung mit dem Befehl save abspeichern. Zur Sicherheit frägt uns aber das Programm, falls wir diesen schritt vergessen haben sollten.
Befehl> quit
Änderungen speichern? (j/N) j
Schlüsseldaten Aktualisieren
In Regelmäßigen Abständen ist es zweckmäßig und angeraten, die Schlüssel im lokalen Schlüsselspeicher zu aktualisieren. Somit kann festgestellt werden, ob z.B. Schlüssel noch aktuell oder zurückgerufen worden sind.
Im einfachsten Fall machen wir das mit Hilfe einer GUI oder eben auf der Konsole mit dem Aufruf /usr/bin/gpg –refresh-key.
# /usr/bin/gpg --refresh-key
gpg: 18 Schlüssel werden per hkp://keyserver.nausch.org aktualisiert gpg: fordere Schlüssel 7C03FC4F von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 8B7684D4 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 81EBD929 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 0DE59D7A von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel C3B26780 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 4C016DE0 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel CBBEBF26 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel E9E5F528 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel DEA1DF01 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel FDB5AACC von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel A2C9DB22 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel AEDAA642 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 2840C708 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 65D0FD58 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel CD9EC0A8 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 3A4B0B6A von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel 581A98A1 von hkp-Server keyserver.nausch.org an gpg: fordere Schlüssel D4827E51 von hkp-Server keyserver.nausch.org an gpgkeys: key 126AAB0159C57820F3FE773EB27468897C03FC4F not found on keyserver gpg: Schlüssel 8B7684D4: "Klaus Tachtler (klaus) <klaus@tachtler.net>" nicht geändert gpg: Schlüssel 81EBD929: "Sebastian Schubert (SpaceNet AG) <ssc@space.net>" nicht geändert gpg: Schlüssel 0DE59D7A: "Thomas Keil <thomas@weblizards.de>" nicht geändert gpg: Schlüssel C3B26780: "Peer Heinlein -- Heinlein Professional Linux Support GmbH <p.heinlein@heinlein-support.de>" nicht geändert gpg: Schlüssel 4C016DE0: "Marco Scholl (Ubuntu-Launchpad) <ubuntu@marco-scholl.de>" nicht geändert gpg: Schlüssel CBBEBF26: "Bernd Goetter (dh5is) <routerman@gmx.net>" nicht geändert gpg: Schlüssel E9E5F528: "Robert Fuhge <fuhge@web.de>" nicht geändert gpg: Schlüssel DEA1DF01: "Dieter Hametner (Emails mit Piraten Partei) <dh+piraten@gekrumbel.de>" nicht geändert gpg: Schlüssel FDB5AACC: "Carsten Presser (cpresser) <c@rstenpresser.de>" nicht geändert gpg: Schlüssel A2C9DB22: "Udo Richter <udo.richter@gmx.de>" nicht geändert gpg: Schlüssel AEDAA642: "Tobias Grimm <tobias.grimm@e-tobi.net>" nicht geändert gpg: Schlüssel 2840C708: "dirk astrath <dastrath@gmx.de>" nicht geändert gpg: Schlüssel 65D0FD58: "CA Cert Signing Authority (Root CA) <gpg@cacert.org>" nicht geändert gpg: Schlüssel CD9EC0A8: "Thomas KÜHNE" nicht geändert gpg: Schlüssel 3A4B0B6A: "ValiDOM (valid until 2013-12-31) <vali@validom.de>" nicht geändert gpg: Schlüssel 581A98A1: "Joel HATSCH <home@joel-hatsch.net>" nicht geändert gpg: Schlüssel D4827E51: "Joel HATSCH <home@joel-hatsch.net>" nicht geändert gpg: Anzahl insgesamt bearbeiteter Schlüssel: 17 gpg: unverändert: 17
Grafische Benutzeroberflächen für GnuPG
Natürlich muss man nicht hardcore-mäßig auf der Konsole alle die vorgenannten Befehle auf der Konsole absetzen. Sowohl KDE als auch Gnome bringen recht komfortable und leistungsstarke GUI2) mit.
Beide Programme sind soweit selbsterklärend, so dass eine weitere Beschreibung hier nicht notwendig ist.
Signieren und Ver-/Entschlüsseln von Dateien
Signieren
Zum Signieren einer Datei, also dem Beglaubigen einer Datei mit einer digitalen Unterschrift, existieren mehrere Möglichkeiten. Wir legen uns einfach eine Testdate mit dem aktuellen Datum an.
$ ddate > Testdatei
$ cat Testdatei
Today is Pungenday, the 45th day of Discord in the YOLD 3175
Mit gpg --sign Dateiname erzeugen wir die Signatur, kompremieren die Originaldatei und schreiben beides in Binärformat in eine neue Datei.
$ gpg --sign Testdatei
You need a passphrase to unlock the secret key for user: "Michael Nausch <michael@nausch.org>" 1024-bit DSA key, ID 2384C849, created 2009-03-30
Diese Datei liegt zwar im Binärformat aber keineswegs verschlüsselt vor.
$ cat Testdatei.gpg
������$(�R�Q���'��$ΐ�⒔Ē�L��)�B�S+2�J��S�� ���TӒ
�T~��Kfqr~Q�Bf X*���E���ܔ�Þ��d
�|A�"��v�>O�r$W��j+{��束�
\����P��}�{x��-�� �
Dieses Vorgehen macht jedoch nur Sinn, wenn mit der Option --encrypt gleichzeitig die Datei verschlüsselt werden soll.
$ gpg --encrypt --sign -r 2384C849 Testdatei
You need a passphrase to unlock the secret key for user: "Michael Nausch <michael@nausch.org>" 1024-bit DSA key, ID 2384C849, created 2009-03-30
Will man die Daten per eMail verschicken so benutzt man die Option --armor.
$ gpg --sign --armor Testdatei
You need a passphrase to unlock the secret key for user: "Michael Nausch <michael@nausch.org>" 1024-bit DSA key, ID 2384C849, created 2009-03-30
Nun können wir uns die erstellte signierte Datei ansehen.
$ cat Testdatei.asc
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.5 (GNU/Linux) owGbwMvMwCQoz1L4UbnlhCfjGp8kzpDU4pKUxJLUTM/v6U9C8lMSKxUyixUCSvPS U/OAHB2FkoxUBRPTkgwFkFR+moJLZnFyflGKQmYeWCrS38dFwdjQ3JSrw56ZlQFk Csx8QaZZ0gxzuLxOLFrGsOrFpwOrXhWuv2v34D27O8P8Iu/gXfcYvQ9+EfTwv1H5 ZnX3/S/LAQ== =G1f3 -----END PGP MESSAGE-----
Soll die Originaldatei zusammen mit der Signatur in der erzeugten Datei stehen, so verwendet man die Option --clearsign.
$ gpg --clearsign --armor Testdatei
You need a passphrase to unlock the secret key for user: "Michael Nausch <michael@nausch.org>" 1024-bit DSA key, ID 2384C849, created 2009-03-30
Die erzeugte Testdatei.asc enthält dann:
$ cat Testdatei.asc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today is Pungenday, the 45th day of Discord in the YOLD 3175 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFJ92i4HwRx8SOEyEkRAjwHAJsFNjNZmdXHYNA0cs+hv1cj0JhH5wCfSB2r qljC/6inruZdj0BX2zwoBRI= =smHj -----END PGP SIGNATURE-----
Mit gpg --verify können wir die Signatur der datei überprüfen:
$ gpg --verify Testdatei.asc
gpg: Signature made Di 28 Apr 2009 22:36:08 CEST using DSA key ID 2384C849 gpg: Good signature from "Michael Nausch <michael@nausch.org>" gpg: aka "Michael Nausch (aka BigChief) <bigchief@omni128.de>" gpg: aka "Michael Nausch (aka Django) <django@nausch.org>"
Als letzte Variante gibt es dann noch die entkoppelte Signatur. Auch hier kann mittels der Option --armor die Ausgabe in lesbaren Format erzwungen werden. Andernfalls würde die Signatur in binärer Form erzeugt werden.
$ gpg --detach-sign --armor Testdatei
You need a passphrase to unlock the secret key for user: "Michael Nausch <michael@nausch.org>" 1024-bit DSA key, ID 2384C849, created 2009-03-30
In der nun erzeugten Datei ist nur noch die Signatur enthalten.
$ cat Testdatei.asc
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBJ92rnHwRx8SOEyEkRArFEAJ9YUv8YvCj63rh3f/MGmD1O+9PyAwCfQhfu nDMDrNa7OKWXMjcuXPLLKr4= =FYiz -----END PGP SIGNATURE-----
Wir verändern nun zu Testzwecken den Inhalt der Testdatei - wir fügen ein Zeichen ein.
$ vim Testdatei
Today is Pungenday, the 45th day of Discord in the YOLD 3175!
Und überprüfen nunmehr die Signatur der Testdatei, was natürlich postwendend als BAD signature angeprangert wird.
$ gpg --verify Testdatei.asc Testdatei
gpg: Signature made Di 28 Apr 2009 22:55:18 CEST using DSA key ID 2384C849 gpg: BAD signature from "Michael Nausch <michael@nausch.org>"
Wurde die Signatur verändert so fällt dies sofort auf:
$ gpg --verify Testdatei.asc Testdatei
gpg: Prüfsummenfehler; 3a1dd4 - 1588b3 gpg: [don't know]: indeterminate length for invalid packet type 2 gpg: no signature found gpg: Die Unterschrift konnte nicht überprüft werden. Denken Sie daran, daß die Datei mit der Unterschrift (.sig oder .asc) als erster in der Kommandozeile stehen sollte.
Verschlüsseln
Verschlüsselt wird jeweils mit dem Public Key des Empfängers, daher geben wir die KeyID beim Verschlüsseln mit der Option -r an.
$ gpg --encrypt --armor -r 4C016DE0 Testdatei
Ohne den Schalter –armor wird die Datei im Binärformat gespeichert.
$ gpg --encrypt -r 4C016DE0 Testdatei
Entschlüsseln
Zum Entschlüsseln nutzen wir die Option --decrypt; da auf den privaten schlüsselbund zugegriffen wird, ist die Passphrase mit anzugeben.
$ gpg --decrypt Testdatei.asc > neue_Testdatei
You need a passphrase to unlock the secret key for
user: "Michael Nausch <michael@nausch.org>"
4096-bit ELG-E key, ID D239B202, created 2009-03-30 (main key ID 2384C849)
gpg: verschlüsselt mit 4096-Bit ELG-E Schlüssel, ID D239B202, erzeugt 2009-03-30
"Michael Nausch <michael@nausch.org>"
S/MIME in der Praxis
Nachdem wir uns im vorliegenden Kapitel mit den theoretischen Grundlagen befasst haben, widmen wir uns im nachfolgendem Kapitel dem Umgang mit S/MIME in der Praxis.
GPF CryptoStick in der Praxis
Im folgendem Kapitel widmen wir uns im Detail dem CryptoStick der German Privacy Foundation und das im Detail unter CentOS 6.x.
django