PGP-Workshop

aus PUG, der Penguin User Group
Wechseln zu: Navigation, Suche

PGP ist ein Verfahren zum Verschlüsseln und Signieren von Daten mit asymmetrischen (geheimen und öffentlichen) Schlüsseln.

Beim Verschlüsseln werden Daten mit dem öffentlichen Schlüssel eines oder mehrerer Empfänger verschlüsselt. Dieser kann die verschlüsselten Daten dann mit seinem eigenen geheimen Schlüssel entschlüsseln und somit lesen.

Beim Signieren wird der umgekehrte Weg beschritten: Der Absender der Daten erstellt mit seinem eigenen geheimen Schlüssel eine Signatur, die Dritte anhand des öffentlichen Schlüssels des Absenders auf Echtheit überprüfen können.

Verschlüsselung und Signatur können miteinander kombiniert werden.

Dieser Artikel betrachtet PGP ausschließlich aus Anwendersicht. Grundlagen zu Verschlüsselungsalgorithmen sind an anderer Stelle besser und fundierter nachzulesen.

PGP? GnuPG? gpg? Was hat das zu bedeuten?

Wenn wir PGP sagen, ist damit der OpenPGP-Standard gemeint. Eine Implementation dieses Standards ist das freie Softwarepaket GnuPG, es gibt aber auch kommerzielle Produkte, die ihn unterstützen. GnuPG wird auf dem Computer als Programm namens gpg installiert.

Die Sicherheit von PGP beruht immer auf den folgenden Komponenten:

  • Geheimer Schlüssel, geschützt durch die Passphrase
  • Öffentlicher Schlüssel
  • Fingerprint
  • Schlüssel-Signaturen

Geheime und öffentliche Schlüssel werden identifiziert durch:

  • Schlüsseltyp (Heute RSA, bis Mitte der 2000er Jahre auch DSA und ELG, mehr dazu s.u. in den weiterführenden Quellen)
  • Schlüssellänge (1024, 2048, 4096 Bit)
  • Schlüssel-ID (Kurz mit 4 Byte: 0x4a76 2535, lang mit 8 Byte: 0xa381 1bd6 4a76 2535)
  • Fingerprint (20 Byte: 6825 0d1a e439 dc87 0573 5703 a381 1bd6 4a76 2535)

Die kurze Schlüssel-ID war lange Zeit als Merkmal gebräuchlich um Schlüssel "eindeutig" zu identifizieren. Auf Grafikkarten ab den 2010er Jahren lassen sich jedoch in wenigen Sekunden Schlüssel mit gewünschten Schlüssel-IDs berechnen. Am besten werden Schlüssel heute anhand des Fingerprint identifiziert.

Das Schlüsselpaar und der Umgang damit

Der geheime und öffentliche Schlüssel werden immer paarweise generiert. Es gilt:

  • Der öffentliche Schlüssel "schließt" das Schloß zur verschlüsselten Nachricht.
  • Nur der geheime Schlüssel und die richtige Passphrase können es wieder öffnen.

Welchen Vorteil hat dieses komplizierte Konstrukt? Ganz einfach: Wenn zum Ver- und Entschlüsseln der selbe Schlüssel benutzt würde, wäre es von enormer Wichtigkeit, diesen Schlüssel auf einem sicheren Weg zum Kommunikationspartner zu bringen. Würde ein Dritter Kenntnis über den Schlüssel bekommen, könnte er alle damit verschlüsselten Nachrichten einfach entschlüsseln.

Der öffentliche Schlüssel ist jedoch nicht geheim, denn er kann das Schloss zwar zuschließen (die Nachricht verschlüsseln), nicht jedoch wieder aufschließen (die Nachricht entschlüsseln). Man kann ihn auf seine Webseite setzen, auf einen PGP-Keyserver laden, es gibt nichts, was man an ihm geheimhalten müsste. Abgesehen natürlich von der üblicherweise im Schlüssel enthaltenen Mailadresse, für die die üblichen Risiken im Hinblick auf SPAM gelten.

Der geheime Schlüssel dagegen ist der Schlüssel zur Entschlüsselung der Daten, und zum Erstellen von Signaturen. Er muss auf dem eigenen PC geheim gehalten werden und wird zusätzlich mit einer Passphrase, also einem optimalerweise aus mehreren Wörtern bestehenden Kennwort, geschützt, für den Fall, daß doch eine unbefugte Person Zugriff auf ihn erlangt.

Ein Schlüsselpaar wird unter GnuPG mit der Option --gen-key erzeugt: 

$ gpg --gen-key
...
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) DSA und ElGamal (voreingestellt)
   (2) DSA (nur signieren/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1
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)
Die verlangte Schlüssellänge beträgt 1024 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) 14
Key verfällt am Do 10 Mär 2005 18:30:58 CET
Ist dies richtig? (j/n) j

Sie benötigen eine User-ID, um Ihren Schlüssel eindeutig zu machen; das
Programm baut diese User-ID aus Ihrem echten Namen, einem Kommentar und
Ihrer E-Mail-Adresse in dieser Form auf:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Ihr Name ("Vorname Nachname"): Test user
E-Mail-Adresse: justtesting@pug.invalid
Kommentar: Schlüssel zu Vorführzwecken
Sie benutzen den Zeichensatz `iso-8859-1'
Sie haben diese User-ID gewählt:
    "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"

Ä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.
...
pub  1024D/7FFDC3F3 2005-02-24 Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>
  Schl.-Fingerabdruck = 0CFD 32E9 8849 4866 92A7  8C2A D896 1462 7FFD C3F3
sub  1024g/638CE9C8 2005-02-24 [verfällt: 2005-03-10]

Einen Schlüssel anschauen kann man sich mit der Option --list-keys: 

$ gpg --list-keys justtesting@pug.invalid
pub  1024D/7FFDC3F3 2005-02-24 Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>
sub  1024g/638CE9C8 2005-02-24 [verfällt: 2005-03-10]

Überprüfung von Schlüsseln per Fingerprint

Der öffentliche Schlüssel kann nun also auf beliebigem Weg übertragen werden, während der geheime Schlüssel auf dem eigenen PC verbleibt. Wenn jemand Daten verschlüsseln will, benutzt er dafür den öffentlichen Schlüssel des Empfängers und versendet die verschlüsselten Daten, die der Empfänger mit seinem geheimen Schlüssel entschlüsseln kann. Falls der Empfänger Sicherheit darüber braucht, dass die Daten wirklich vom richtigen Absender kommen, signiert der Absender zusätzlich die Daten mit seinem geheimen Schlüssel. Diese Signatur kann der Empfänger mit dem öffentlichen Schlüssel des Absenders prüfen.

Woher kann der Absender aber wissen, dass er seine Daten wirklich mit dem echten Schlüssel des Empfängers verschlüsselt? Und woher weiß der Empfänger, dass die Daten wirklich vom echten Absender signiert wurden? Schließlich könnte ein Angreifer, der die Daten mitlesen will, ja einfach ein Schlüsselpaar mit dem Namen des Empfängers generiert haben, die verschlüsselte Mail abfangen und auf diese Weise entschlüsseln. Und, einfacher noch, er könnte ein Schlüsselpaar mit dem Namen des Absenders generiert haben, und unter dessen Namen unterschreiben.

Eine Lösung dafür wäre, dass man sich persönlich trifft und bei dieser Gelegenheit Datenträger mit den öffentlichen Schlüsseln austauscht. Oft ist dies jedoch aus verständlichen Gründen so nicht möglich.

An dieser Stelle kommt der Fingerprint (Fingerabdruck) ins Spiel. Der Fingerprint ist eine 20 Byte lange Zahlenfolge, die für jeden Schlüssel unterschiedlich ist. Hat man den öffentlichen Schlüssel über einen unsicheren Weg erhalten, kann man z.B., wenn man die Stimme des jeweils anderen schon kennt, telefonisch den Fingerprint überprüfen. Man kann sich aber z.B. auch persönlich treffen, sich gegenseitig ausweisen und Visitenkarten austauschen, auf die der Fingerprint aufgedruckt ist. Viele Zeitschriften drucken die Fingerprints ihrer Redaktion auch im Impressum ab.

Den Fingerprint eines Schlüssels kann man sich mit der Option --fingerprint ansehen: 

$ gpg --fingerprint justtesting@pug.invalid
pub  1024D/7FFDC3F3 2005-02-24 Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>
  Schl.-Fingerabdruck = 0CFD 32E9 8849 4866 92A7  8C2A D896 1462 7FFD C3F3
sub  1024g/638CE9C8 2005-02-24 [verfällt: 2005-03-10]

Überprüfung von Schlüsseln per Signatur

Wenn keine Möglichkeit gegeben ist, die Echtheit des öffentlichen Schlüssels telefonisch oder bei einem persönlichen Treffen sicherzustellen, besteht noch eine weitere Möglichkeit. Vielleicht hat man ja einen gemeinsamen Bekannten, der den Schlüssel schon einmal überprüft hat, oder der Schlüssel ist von einer Zertifizierungsstelle (Certificate Authority (CA)), wie z.B. der [Heise-CA] signiert, deren Schlüssel man auf seine Echtheit überprüft hat.

Die Signaturen unter einem Schlüssel kann man sich mit der Option --list-sigs ansehen: 

$ gpg --list-sigs justtesting@pug.invalid
pub  1024D/7FFDC3F3 2005-02-24 Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>
sig 3       7FFDC3F3 2005-02-24   Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>
sig 3       5619E37D 2005-02-24   Martin Schmitt <mas@scxx.de>
sub  1024g/638CE9C8 2005-02-24 [verfällt: 2005-03-10]
sig         7FFDC3F3 2005-02-24   Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>

Bei den zusätzlich angezeigten Signaturen handelt es sich um die Selbstsignaturen des Schlüssels, die an dieser Stelle nicht besprochen werden sollen.

Signieren von Schlüsseln

Es ist möglich, den Schlüssel eines Benutzers mit dem eigenen Schlüssel zu signieren und somit gegenüber dritten gewissermaßen für die Echtheit des Schlüssels zu "bürgen". Dies sollte jedoch nur geschehen, nachdem die Echtheit des Schlüssels und die Identität des Inhabers genau überprüft wurden. Hierzu gehören die Überprüfung der Identität (z.B. über den Personalausweis) und entweder die sichere Übertragung des Schlüssels, z.B. indem er auf einer Diskette mitgebracht wird, oder der Abgleich des vom Inhaber mitgebrachten Fingerprint, falls der Schlüssel auf einem unsicheren Weg, z.B. per Mail oder Web übertragen wurde.

Nachdem eine solche Signatur erfolgt ist, kann der Schlüssel mit der hinzugefügten Signatur exportiert und an seinen Inhaber zurück übergeben werden, damit dieser zukünftig diese Signatur mit herausgeben kann.

Eine exportierbare Signatur wird über die Kommandos erstellt, die von GnuPG mittels --edit-key bereitgestellt werden: 

$ gpg --edit-key justtesting@pug.invalid
...
pub  1024D/7FFDC3F3  erstellt: 2005-02-24 verfällt: 2005-03-10 Vertrauen: u/u
sub  1024g/638CE9C8  erstellt: 2005-02-24 verfällt: 2005-03-10
(1). Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>

Befehl> sign
...
Wie genau haben Sie überprüft, ob der Schlüssel, den Sie jetzt beglaubigen
wollen, wirklich der o.g. Person gehört?
Wenn Sie darauf keine Antwort wissen, geben Sie "0" ein.

   (0) Ich antworte nicht.Daten entschlüsseln (Voreinstellung)
   (1) Ich habe es überhaupt nicht überprüft.
   (2) Ich habe es flüchtig überprüft.
   (3) Ich habe es sehr sorgfältig überprüft.

Ihre Auswahl? ('?' für weitere Informationen): 3
Sind Sie wirklich sicher, daß Sie vorstehenden Schlüssel mit Ihrem
Schlüssel beglaubigen wollen: "Martin Schmitt <mas@scxx.de>" (5619E37D)

Ich habe diesen Schlüssel sehr sorgfältig überprüft.
...
Befehl> save

Lokale Signaturen

Bei der lokalen Signatur handelt es sich um einen Sonderfall. Sie erfolgt ausschließlich auf dem lokalen System, so dass der Schlüssel aus Sicht der PGP-Applikation als vertrauter Schlüssel geführt wird. Die lokale Signatur kann nicht exportiert werden und hat somit nicht den "Bürgschaftscharakter" der regulären Signatur.

Eine lokale Signatur wird ebenfalls über die Kommandos erstellt, die von --edit-key bereitgestellt werden: 

$ gpg --edit-key justtesting@pug.invalid
pub  1024D/7FFDC3F3  erstellt: 2005-02-24 verfällt: 2005-03-10 Vertrauen: u/u
sub  1024g/638CE9C8  erstellt: 2005-02-24 verfällt: 2005-03-10
(1). Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>

Befehl> lsign
...
Wie genau haben Sie überprüft, ob der Schlüssel, den Sie jetzt beglaubigen
wollen, wirklich der o.g. Person gehört?
Wenn Sie darauf keine Antwort wissen, geben Sie "0" ein.

   (0) Ich antworte nicht.Daten entschlüsseln (Voreinstellung)
   (1) Ich habe es überhaupt nicht überprüft.
   (2) Ich habe es flüchtig überprüft.
   (3) Ich habe es sehr sorgfältig überprüft.

Ihre Auswahl? ('?' für weitere Informationen): 3
Sind Sie wirklich sicher, daß Sie vorstehenden Schlüssel mit Ihrem
Schlüssel beglaubigen wollen: "Martin Schmitt <mas@scxx.de>" (5619E37D)

Die Unterschrift wird als nicht exportfähig markiert werden.
...
Befehl> save

Vertrauen festlegen

Wie weit GnuPG einem Schlüssel im Hinblick auf von ihm signierte Schlüssel trauen soll, wird mittels der Option --edit-keys und dort mit dem Befehl trust festgelegt: 

$ LANG=de_DE gpg --edit-key 7FFDC3F3
...
> trust
pub  1024D/7FFDC3F3  erstellt: 2005-02-24 verfällt: 2005-04-13 Vertrauen: -/f
sub  1024g/638CE9C8  erstellt: 2005-02-24 verfällt: 2005-04-13
(1). Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>

Bitte entscheiden Sie, in wieweit Sie diesem User zutrauen,
Schlüssel anderer User korrekt zu prüfen (durch Vergleich
mit Lichtbildausweisen, Vergleich der Fingerabdrücke aus
unterschiedlichen Quellen ...)?

 1 = Weiß nicht so recht
 2 = Nein, ihm traue ich NICHT
 3 = Ich vertraue ihm marginal
 4 = Ich vertraue ihm vollständig
 5 = Ich vertraue ihm absolut
 m = Zurück zum Menü

Um einen signierten Schlüssel für echt zu halten, sind in der Standardkonfiguration von GnuPG drei Unterschriften von je einem Schlüssel erforderlich, dem man "marginal" vertraut, oder eine Unterschrift von einem Schlüssel, dem man "vollständig" vertraut.

Die Stufe 2 ("traue ihm nicht") ist für Schlüssel gedacht, von deren Inhabern man weiß, dass sie es mit dem Signieren fremder Schlüssel nicht so genau nehmen (z.B. die Identität nicht oder nicht ausreichend prüfen), die Stufe 5 ("absolut") ist dem eigenen Schlüssel vorbehalten, bei dem man auch im Besitz des geheimen Schlüssels ist.

Anwendung

Verschlüsseln

Das Verschlüsseln von Dateien erfolgt über die Option --encrypt oder kurz -e. Zusätzlich muss beim Verschlüsseln mittels der Option --recipient oder -r der Empfänger angegeben werden, dessen öffentlicher Schlüssel für die Verschlüsselung verwendet werden soll: 

$ gpg -e -r justtesting@pug.invalid geheim.txt

Beim Verschlüsseln erfolgen keinerlei Rückfragen durch GnuPG, da zum Verwenden eines öffentlichen Schlüssels keine Passphrase erforderlich ist. Das Produkt dieser Verschlüsselung befindet sich anschließend in der Binärdatei geheim.txt.gpg.

Ist dieses binär gespeicherte Ergebnis der Verschlüsselungsergebnis für einen bestimmten Einsatzzweck nicht brauchbar, kann man GnuPG mittels der Option --armor oder -a dazu auffordern, die Daten in einen ASCII-Armor (vergleichbar z.B. mit uuencode) zu verpacken: 

$ gpg -a -e -r justtesting@pug.invalid geheim.txt

Beim Verschlüsseln als ASCII-Armor entsteht eine Datei geheim.txt.asc im bekannten PGP-Format: 

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.4 (GNU/Linux)

hQEOA/+M/iVjjOnIEAQAlVlXgZnjWZcQy+AfanGqfl4R+RU3jEn859SSfoKCxq9o
q6i6Lpw/FADLSmA0T4W8DHvKg+HnAG8qqtHK4NafEJVQ9Z3SspZtz33uFX+kUTtE
VN981NQVy77HQe80qYiLkyd1D+IaWLepAAEtR5Jd79NokQIzPIYCu9zntaIkTDwE
AJib/1bvbVwEzkOueiKiwlnRLZ3FsyFY7W9MjddBTuMmJru21SZaQiMojQeRwmKj
tHKdJySS5lTPerm7Eb6kFajrKMH5mE2PeJboAJg6DVZOxsGqPxq86vigJ7HzLlP5
IZ3+B86E61hofKCPI3biyHmYhhvta9GfDLuk+sEpbv4+0koBhg1MPGLWB53nKAyn
FPt6+HdDadWv91g0I41OOZ78ShxY4saQs+i1FfTr0A06c+mi6t7+P2uuP6yhA+t5
QgUBLLCwGomsO08Grg==
=zewj
-----END PGP MESSAGE-----

Die Verschlüsselung kann gleichzeitig mit den öffentlichen Schlüsseln mehrerer Empfänger erfolgen, die über die Mehrfachnennung von -r angegeben werden können.

Entschlüsseln

Hat man eine verschlüsselte Datei erhalten, erfolgt ihre Entschlüsselung, indem sie ohne weitere Optionen an GnuPG übergeben wird: 

$ gpg geheim.txt.gpg

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"
1024-Bit ELG-E Schlüssel, ID 638CE9C8, erzeugt 2005-02-24 (Hauptschlüssel-ID 7FFDC3F3)

gpg: verschlüsselt mit 1024-Bit ELG-E Schlüssel, ID 638CE9C8, erzeugt 2005-02-24
      "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"


Signatur erstellen

Beim Signieren handelt es sich um eine "Unterschrift", die man mit dem eigenen geheimen Schlüssel leistet. Diese kann von jedermann überprüft werden, der Kenntnis vom öffentlichen Schlüssel hat und diesen auf seine Echtheit überprüft hat.

Mehrere Arten von Signaturen sind möglich. Am gängigsten sind die beiden folgenden Arten.

Zum einen können Texte eine Klartext-Signatur erhalten, bei der ein PGP-Block im bekannten Format entsteht, innerhalb dessen sowohl der Text im lesbaren Format erhalten bleibt, als auch die Signatur enthalten ist: 

$ echo 'Das ist die reine Wahrheit!' > test.txt
$ gpg --clearsign test.txt

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"
1024-Bit ELG-E Schlüssel, ID 638CE9C8, erzeugt 2005-02-24 (Hauptschlüssel-ID 7FFDC3F3)

Das Ergebnis, die Datei test.txt.asc enthält den signierten Text im PGP-Block: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Das ist die reine Wahrheit!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCQ+TP2JYUYn/9w/MRApevAJ9tSivpQPbV9Kxe+D2BjWnvyM3z3wCdFGe+
zD/QkkWbrl0mHXZU1fiej2M=
=XOCa
-----END PGP SIGNATURE-----

Eine weitere Variante wird i.d.R. benutzt, um beim Download von Software sowohl die Integrität als auch die Echtheit der der heruntergeladenen Daten sicherzustellen. Diese abgetrennte ("detached") Signatur, die mit der Option -b oder --detach-sign erstellt werden kann, wird dabei als separate Datei zum Download angeboten, die wie folgt erstellt wird: 

$ gpg -b meindownload-1.0-beta3.tar.gz

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"
1024-Bit ELG-E Schlüssel, ID 638CE9C8, erzeugt 2005-02-24 (Hauptschlüssel-ID 7FFDC3F3)

Dabei entsteht die Datei meindownload-1.0-beta3.tar.gz.sig, die die Signatur in binärer Form enthält.

Eine als ASCII-Armor codierte Signatur kann wie üblich mit der Option -a oder --armor erstellt werden: 

$ gpg -a -b meindownload-1.0-beta3.tar.gz

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"
1024-Bit ELG-E Schlüssel, ID 638CE9C8, erzeugt 2005-02-24 (Hauptschlüssel-ID 7FFDC3F3)

Das Ergebnis ist die Datei meindownload-1.0-beta3.tar.gz.asc: 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCQ+fG2JYUYn/9w/MRAoLkAJ93SOvmdfO69uK6NUaOo46a49j6GACfcFnp
4jyw7L1CqlWiNKDvuXbCFyU=
=iXss
-----END PGP SIGNATURE-----

Signatur überprüfen

Wie eben besprochen, gibt es zwei grundlegende Arten von Signaturen. Zum einen die Inline-Signatur, bei der Nutzdaten und Signatur zusammen in einer Datei enthalten sind, und die abgetrennte Signatur, die in einer zusätzlichen Datei mitgeliefert wird.

Egal, welche Art von Signatur vorliegt, es ist immer eine Datei mit der Endung .asc, .sig oder .gpg im Spiel:

  • .gpg sind Inline-Signaturen im Binärformat (oben nicht besprochen)
  • .asc sind Inline- oder abgehängte Signaturen im ASCII-Armor
  • .sig sind abgetrennte Signaturen im Binärformat

Um eine Signatur zu überprüfen, benötigt man zum einen die Datei mit der Signatur und bei abgetrennten Signaturen die signierte Datei im selben Verzeichnis: 

$ ls -l meindownload-1.0-beta3.tar.gz*
-rw-r--r-- 1 martin martin 654003 2005-03-25 11:26 meindownload-1.0-beta3.tar.gz
-rw-r--r-- 1 martin martin    189 2005-03-27 21:30 meindownload-1.0-beta3.tar.gz.asc

Die Überprüfung wird einfach durchgeführt, indem die Signaturdatei an GnuPG übergeben wird: 

$ gpg meindownload-1.0-beta3.tar.gz.asc
gpg: Signature made So 27 Mär 2005 21:30:13 CEST using DSA key ID 7FFDC3F3
gpg: Good signature from "Test user (Schlüssel zu Vorführzwecken) <justtesting@pug.invalid>"

Die Datei hat also eine authentische Signatur. Was ist jedoch los, wenn eine Meldung wie die folgende auftaucht? 

$ gpg openssh-3.9p1.tar.gz.sig
gpg: Signature made Tue Aug 17 14:55:13 2004 CEST using DSA key ID 86FF9C48
gpg: Good signature from "Damien Miller (Personal Key) <djm@mindrxx.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3981 992A 1523 ABA0 79DB  FC66 CE8E CB03 86FF 9C48

Hier wird zwar bestätigt, dass die Signatur gültig ist ("Good Signature"), aber gleichzeitig wird gewarnt, dass der Schlüssel, der zur Überprüfung der Signatur verwendet wurde, nicht auf seine Echtheit überprüft wurde. Hiermit wären wir wieder bei den zu Anfang genannten Verfahren zur Überprüfung von Schlüsseln gelandet.

Leider leider gibt es oft keine vernünftige Möglichkeit, den genannten Schlüssel auf seine Echtheit zu überprüfen. Man kann sich in Fällen wie diesem nur darauf verlassen, dass nicht unentdeckt und über Jahre hinweg mit einem falschen Schlüssel signierte OpenSSH-Pakete auf FTP-Servern liegen.

Die Zeit danach

Passphrase vergessen

Wenn die Passphrase des geheimen Schlüssel vergessen wird (z.B. durch lange Nichtbenutzung), gibt es keine Möglichkeit, sie wiederherzustellen. Eine Möglichkeit um dies zu verhindern, besteht darin, an einem sicheren Ort (z.B. Bankschließfach) eine Kopie des Schlüsselpaars aufzubewahren, die als Backup verwendet werden kann. Dies ist jedoch nicht in jedem Fall empfehlenswert, z.B. beim Risiko der Strafverfolgung, oder wenn das Schließfach im Todesfall geöffnet wird.

Wurde beim Generieren des Schlüssels ein Verfalldatum angegeben, verliert er mit diesem Datum seine Gültigkeit. Soll er bereits vorzeitig seine Gültigkeit verlieren, kann im vorhinein ein Revocation Certificate generiert werden. Beim Exportieren dieses "Revokers" z.B. auf einen Keyserver wird der Schlüssel dort als "Revoked" und damit als ungültig markiert.

Geheimen Schlüssel gelöscht

Wenn die letzte Kopie des geheimen Schlüssel gelöscht wurde, kann entweder auf das Verfalldatum des öffentlichen Schlüssel gewartet werden, oder man hat irgendwo eine Kopie eines Revocation-Certificate, die verwendet werden kann, um den Schlüssel zurückzuziehen. Im schlimmsten Fall tut es auch ein Ausdruck des Revokers, der bei Datenverlust eingetippt oder per OCR in den Rechner eingelesen werden kann. Mit diesem Revoker kann der Schlüssel auf Keyservern für ungültig erklärt werden.

Verfalldatum ändern

Das Ändern des Verfalldatums ist über die Option --edit-key und das Kommando expire ohne weiteres möglich. Dabei ist darauf zu achten, dass alle Subkeys einzeln geändert werden müssen. Zwischen den Subkeys wird mit dem Kommando key gewechselt. Erst wenn bei allen Subkeys das neue Verfalldatum angezeit wird, war die Änderung erfolgreich.

Dieser Schlüssel ist leider kürzlich abgelaufen: 

$ gpg --list-key --verbose testkey@example.com
pub   1024D/B345D88D 2004-11-19 [expired: 2005-09-15] 
uid                  This is a test key <testkey@example.com>
sub   2048g/7CC1FF31 2004-11-19 [expired: 2005-09-15]

Also editiere ich einfach seine Gültigkeitsdauer... 

$ gpg --edit-key testkey@example.com

Command> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
...
Key is valid for? (0) 1y
Key expires at Sun Nov 19 04:47:47 2006 CET
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "This is a test key <testkey@example.com>"
1024-bit DSA key, ID B345D88D, created 2004-11-19

pub  1024D/B345D88D  created: 2004-11-19  expires: 2006-11-19  usage: CS
                     trust: ultimate      validity: ultimate
sub  2048g/7CC1FF31  created: 2004-11-19  expired: 2005-09-15  usage: E

[ultimate] (1). This is a test key <testkey@example.com>

Command> key 1

pub  1024D/B345D88D  created: 2004-11-19  expires: 2006-11-19  usage: CS
                     trust: ultimate      validity: ultimate
sub* 2048g/7CC1FF31  created: 2004-11-19  expired: 2005-09-15  usage: E 

[ultimate] (1). This is a test key <testkey@example.com>

Command> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
...
Key is valid for? (0) 1y
Key expires at Sun Nov 19 04:48:17 2006 CET
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "This is a test key <testkey@example.com>"
1024-bit DSA key, ID B345D88D, created 2004-11-19

pub  1024D/B345D88D  created: 2004-11-19  expires: 2006-11-19  usage: CS
                     trust: ultimate      validity: ultimate
sub* 2048g/7CC1FF31  created: 2004-11-19  expires: 2006-11-19  usage: E

[ultimate] (1). This is a test key <testkey@example.com>

Command> quit

Save changes? (y/N) y

Und das war's auch schon. Der einzige Fehler, den man machen kann, ist, zu vergessen, den/die Unterschlüssel ebenfalls zu bearbeiten.

Nun ist der Schlüssel wieder brauchbar: 

$ gpg --list-keys --verbose testkey@example.com
pub   1024D/B345D88D 2004-11-19 [expires: 2006-11-19]
uid                  This is a test key <testkey@example.com>
sub   2048g/7CC1FF31 2004-11-19 [expires: 2006-11-19]

Schlüssel vom Keyserver entfernen

Das Entfernen von Schlüsseln vom Keyserver ist i.d.R. nicht möglich. Abgelaufene und mittels eines Revoker zurückgezogene Schlüssel werden vom Keyserver weiterhin angezeigt und mit einer entsprechenden Markierung versehen. Das gleich gilt übrigens für das Zurückziehen von Signaturen unter fremden Schlüsseln. Diese werden auf dem Keyserver als "revoked" angezeigt.

GnuPG Hacks

Liste der Empfänger ermitteln

Beim Verschlüsseln von Daten für mehrere Empfänger gleichzeitig ist zu beachten, dass ein interessierter Empfänger den verschlüsselten Daten ansehen kann, wer die Empfänger dieser Daten waren. Dazu muss er lediglich seinem GnuPG vorgaukeln, es sei kein passender Schlüssel zum Entschlüsseln vorhanden und versuchen, die Daten zu entschlüsseln. GnuPG zeigt dann an, welche Schlüssel zum Verschlüsseln verwendet wurden: 

$ GNUPGHOME=/tmp gpg --no-default-keyring geheim.txt.asc
gpg: verschlüsselt mit ELG-E Schlüssel, ID 02E3AD2A
gpg: verschlüsselt mit ELG-E Schlüssel, ID 638CE9C8
gpg: Entschlüsselung fehlgeschlagen: Geheimer Schlüssel ist nicht vorhanden

Nach den Schlüssel-IDs kann dann z.B. auf einem PGP-Keyserver gesucht werden.

Dies lässt sich vermeiden, indem der Absender die Daten mit der Option --throw-keyids verschlüsselt. Den verschlüsselten Daten ist dann nicht mehr zu entnehmen, welche Schlüssel verwendet wurden. GnuPG auf Empfängerseite probiert dann automatisch alle vorhandenen geheimen Schlüssel aus, und entschlüsselt die Nachricht mit demjenigen, der passt.

Weiterführende Quellen

Software

Abgerufen von „https://www.pug.org/mediawiki/index.php?title=PGP-Workshop&oldid=9079“