Wie man Gnu­PG sich­er ver­wen­den kann

In der Praxis hängt es von verschiedenen Umständen ab, ob Ihnen die Verwendung von Verschlüsselung mehr Privatheit, Sicherheit oder Anonymität garantieren kann.

  1. Versuchen Sie in den Besitz einer Kopie unseres öffentlichen Schlüssels zu gelangen, die sehr sicher echt ist.
  2. Verschlüsseln Sie niemals auf einem Rechner der online ist; speichern Sie auf einem solchen Rechner niemals private Schlüssel.
  3. Falls Sie im Besitz eines privaten Schlüssels sind, nehmen Sie diesen immer mit (bspw. auf einem USB-Stick).
  4. Vermeiden Sie die Verwendung eines Rechners der aus irgendeinem Grund verwanzt sein könnte, auch wenn sich dieser offline befindet.
  5. Wenn Sie eine Antwort haben wollen inkludieren Sie ihren öffentlichen Schlüssel in die Nachricht.
  6. Um anonym zu bleiben können Sie eine Wegwerf­email­adresse über Tor verwenden.
  7. Sagen Sie uns, daß Sie diese Richtlinien eingehalten haben.
  8. Die heikelsten Informationen können eine Zerstörung des privaten Schlüssels nach lesen der Nachricht erforderlich machen.

Als erstes müssen Sie zuschauen an eine authentische Kopie unseres öffentlichen gpg-Schlüssels zu gelangen i.e. an die Datei elws.pubkey.asc. Versuchen Sie die Datei über verschiedene Computer und Netzwerk­verbindungen herunterzuladen, welche unter Kontakt / Impressum auf unserer Hauptseite verlinkt ist; am besten auch über Tor: Booten Sie einen Computer sauber von CD/DVD und führen Sie dort soetwas wie torsocks wget http://www.elstel.org/auxil/elws.pubkey.asc aus. Verwenden Sie für Tor entweder eine Tails-DVD oder versichern Sie sich mit netstat -atupn, daß kein ssh-Daemon oder ähnlich schädliche Programme laufen, bevor Sie sich mit dem Netz verbinden. Prüfen Sie alle heruntergeladenen Schlüsseldateien auf Gleichheit. Da online Rechner kompromittiert sein können, nehmen Sie ihre Kopie eines öffentlichen Schlüssels nicht auf einen solchen mit, sondern vergleichen Sie besser offline oder verwenden Sie einen Read-Only/Nur-Lesen USB Stick dafür. Sie können auch über Telephon nach dem Fingerabdruck des Schlüssels fragen, obwohl auch das kein Allheilmittel ist, denn Telephonanrufe können gleich wie Internet­verbindungen umgeleitet und abgehört werden. Stellen Sie sicher, daß Sie nicht Ihr persönliches Telephon verwenden sondern besser das Telephon eines Freundes von einem Freund. Das ist deshalb wichtig, weil Sie nicht wissen werden, ob Sie gerade die tatsächliche Seite elstel.org oder nur eine NSA-Spiegelseite von elstel.org besuchen. Zusätzlich können Sie versuchen unseren öffentlichen Schlüssel über einen der folgenden Schlüsselserver zu erreichen: hkps://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net, hkp[s]://subkeys.pgp.net[:11371], keys.gnupg.net, pgp.mit.edu:11371, keyserver.ubuntu.com, pool.sks-keyserver.net, obwohl wir nicht garantieren können, daß die dort verfügbaren Schlüssel aktuell sind, was ein wesentlicher Nachteil ist. Nur aktuelle Schlüssel dürfen verwendet werden. Der 'keyserver' kann auch in ~/.gnupg.dirmngr.conf eingestellt werden.

Nun, wenn Sie im Besitz einer authentischen Kopie unseres öffentlichen Schlüssels sind gilt es eine Reihe an Vorkehrungen zu beachten, damit die Verschlüsselung nicht nutzlos oder schädlich ist. Als erstes dürfen Sie Ihre Nachrichten nie auf einem Rechner verfassen, der online ist, wenn diese später verschlüsselt werden sollen. Jeder mit dem Internet verbundene Rechner kann innerhalb von Sekunden kompromittiert und gerootet werden, sobald Sie nur Ihren Webbrowser oder Ihr Emailprogramm öffnen. Noch schlimmer haben alle PCs umgefähr seit 2008 eine Komponente die sich Intel ME (Management Extension) nennt. Diese ist eigentlich für die Fernwartung gedacht, kann aber durch entsprechende Sicherheitslücken von Geheimdiensten benutzt werden um sich auf jedem beliebigen Rechner einzuloggen (mehr dazu hier). Verwenden Sie also einen eigenen offline-Rechner, der am besten von einer sauberen Boot-CD oder DVD gebootet wird, um ihre Nachrichten zu erstellen; löschen Sie die Originalnachricht aus dem RAM oder mit shred von Disk; kopieren Sie die verschlüsselte Nachricht bestehend aus einfachem Text (keine anderen Dateiformate!) auf einen USB-Stick und bringen Sie diese zu einem Computer mit Zugriff aufs Netz. Am besten schauen Sie, daß das Netzwerkkabel auf ihrem Offline-Rechner abgesteckt ist und der Wifi-Treiber beim Booten geblacklistet worden ist. Das ist so wichtig, weil wir darauf vertrauen müssen, daß Ihre Nachricht nicht schon am Ort des Absenders abgefangen worden ist.

Wenn Sie auf Ihre Nachricht eine Antwort erhalten wollen, verpacken Sie bitte Ihren öffentlichen Schlüssel in die Nachricht. Wir wollen uns darin sicher sein, daß unsere Antwort tatsächlich an den Urheber dieser Nachricht geht und an niemand anders; wir werden Ihren öffentlichen Schlüssel folglich nicht aus dem Web herunterladen. Erzeugen Sie Ihren privaten Schlüssel (oder besser gesagt ein Schlüsselpaar bestehend aus öffentlichem und privaten Schlüssel) auf einem sauberen offline-Rechner und speichern Sie ihn auf einem USB-Stick oder einer SDCard mit Nur-Lesen Schalter zur späteren Verwendung. Nehmen Sie ihren privaten Schlüssel immer mit. Lassen Sie ihn niemals zuhause liegen. Geheimdienste wissen aufgrund Ihres Mobiltelephons genau wann Sie zuhause sind und können Ihre Wohnung jederzeit betreten, um an den privaten Schlüssel zu gelangen. Ihre Haustür aufzusperren stellt dabei kein Problem dar, denn es gibt sog. Universalschlüssel, wie sie auch auf Flughäfen verwendet werden um Ihr Gepäck zu durchsuchen, die jedes physiche Schloß sperren. Es ist sehr schwer wenn nicht gar unmöglich einen Verlust Ihres privaten Schlüssels zu erkennen, denn er kann wie jede andere Art von Daten einfach kopiert werden. Chipkartenleser können einen Ausweg aus diesem Dilemma bieten, denn man müßte die ganze Chipkarte stehlen um an den privaten Schlüssel zu gelangen.

Falls Sie bereits aus irgendeinem Grund, ob er Ihnen bekannt sein mag oder nicht, von einem Geheimdienst überwacht werden, versuchen Sie sicherzustellen, daß ihre Geräte entwanzt sind. Sie sollten beispielsweise wissen, daß der NSA Lieferungen von LaptopComputern regelmäßig abfängt, sodaß Hardware, die unter Ihrem Namen bestellt ist, bereits manipuliert bei Ihnen ankommen kann. Der beste Ausweg mag da noch ein DesktopComputer sein, bei dem man das Mainboard und alle verbauten Komponenten immer sehen kann; Notebooks sind nur schwer zu zerlegen und es ist unmöglich das jedesmal zu machen, wenn man sein Notebook irgendwo liegen läßt. Unerklärliche Fehler auf einem Rechner, die auf einem anderen Rechner mit dem genau gleichen Setup nicht reproduzierbar sind, können auf beschädigte oder manipulierte Hardware hindeuten. Man denke daran, daß solche Manipulationen oft nur schwer zu sehen sind, etwa durch eine Größenänderung Ihrer USB-Anschlüsse.

Zuletzt aber nicht minder wichtig sagen Sie uns welche Sicherheits­maßnahmen Sie eingehalten haben, als Sie ihre Nachricht erstellt und versendet haben. Welche Sicherheits­maßnahmen gerechtfertigt sind entscheiden Sie aufgrund Ihres individuellen Bedrohungsszenarios und aufgrund der Schützenswürdigkeit Ihrer Nachricht. Nichtsdestotrotz erachten wir die Verschlüsselung auf online-Rechnern oder das Speichern von privaten Schlüsseln auf Rechnern, die zum Webbrowsen verwendet werden, als eine Sauerei, weil es eine Sicherheit vortäuscht, die in der Tat nicht gegeben ist. Eine der schlimmsten Fehler im Bereich der Computersicherheit ist es auf eine Sicherheit zu vertrauen, die nicht gegeben ist. Senden Sie uns Ihre Nachricht im Klartext oder befolgen Sie zumindest ein paar minimaler Vorkehrungen, damit die Verschlüsselung auch wirksam ist.

Beachten Sie auch, daß wir grundsätzlich Anonymität beim Erhalt von Software, Hardware und Schlüsseln als die bessere Sicherheits­maßnahme sehen als das sogenannte «Web of Trust», das es an jedem beliebigen Punkt infiltriert werden kann. Kaufen Sie die CD/DVD, die Sie zum Booten eines sauberen Systems verwenden, an einem Zeitungskiosk. Kein mutmaßlciher Horcher und kein Geheimdienst können alle an einem Zeitungsstand verkauften Exemplare verseuchen, da dies sofort auffallen würde. Es ist fast immer der Fall, daß bestimmte Individuen, ob sie es wissen oder nicht, in das Visier von Geheimdiensten geraten. Anonym zu bleiben heißt in den meisten Fällen auch sicher zu bleiben: Außer Benutzer des Tor-Netwerks, die regelmäßig von verschiedenen Diensten angegriffen werden, oder Benutzer, die sich bloß darüber informieren wollen, wie man verschlüsselt oder anonym bleibt. Benutzer wie Sie, die gerade diesen Text gelesen haben. Beachten Sie, daß Sie durch Lesen dieses Textes bereits unter Verdacht stehen können. Das ist kein schlechter Scherz.

Es folgt eine Kurzreferenz wie Sie gpg verwenden können. Sie möchten vielleicht auch noch andere Informationsquellen nutzen:

> /usr/sbin/tor & > torsocks wget http://www.elstel.org/auxil/elws.pubkey.asc > also: gpg --keyserver xy.net --recv-key / --send-key email/key-id >       gpg --output yz.pubkey.asc --armor --export yz@email.org

oder: root> tor-resolve keys.gnupg.net root> torsocks/torify gpg --keyserver 130.206.1.8 --recv-key 0x9981E39D

Es sollte dabei egal sein welchen Keyserver man verwendet, da sich diese normalerweise untereinander regelmäßig synchronisieren. Der so gewonnene Schlüssel kann aber nach einem --armor --export email nicht mehr direkt über cmp mit elws.pubkey.asc verglichen werden, da noch zusätzliche Signaturen von anderen Personen dranhängen können. Hat man hingegen deren gpg Schlüssel wäre dies aber umgekehrt ein potentieller Vorteil für die Sicherstellung Authentizität von elws.pubkey (siehe Web of Trust).

Booten Sie jetzt auf Ihrem Offline-Rechner neu (Es kann sein, daß Sie ihren Wireless-Adapter hierzu blacklisten müssen.).

> gpg --import elws.pubkey.asc > gpg --fingerprint > gpg --list-keys > gpg --output mymessage.txt.gpg --encrypt --armor --recipient elws@elstel.org mymessage.txt ( armor creates an ascii-output which can be sent via email. )

Der sog. Fingerprint ist ein Hashwert anhand dessen Sie überprüfen können, ob Ihre Kopie des öffentlichen Schlüssels echt ist. Das ist insbesondere dann von Nutzen, wenn Sie entweder den Fingerprint direkt und persönlich beispielsweise auf einer Visitenkarte erhalten haben, oder wenn das Ihre einzige Möglichkeit ist zwei Kopien des selben Schlüssels zu vergleichen, weil diese sich wie gesagt durch angehängte Signaturen unterscheiden können (siehe Keyserver).

Wenn Sie eine Antwort auf Ihre Nachricht erhalten wollen erzeugen Sie am besten auch einen 4096bit RSA Schlüssel. Es ist am besten wenn Sie den gleichen Algorithmus mit der gleichen Bittiefe verwenden: Eine Kette ist so stark wie ihr schwächstes Glied. Wir schlagen vor einen Schlüssel ohne Paßwort, der kein automatisches Ablaufdatum, hat zu erzeugen. Keylogger sind schnell installiert und ein Paßwort gibt da nicht mehr Sicherheit.

> gpg --full-generate-key > gpg --list-secret-keys > gpg --edit-key C824B271CAEDF21BE9A28B785CA6AA8CBE270325 gpg> showpref gpg> setpref TwoFish AES SHA512 SHA384 SHA256 SHA224 BZIP2 gpg> save

Sie sollten ihre Chiffrier-Algorithmus Einstellungen für den neuen Schlüssel ändern, sobald Sie diesen erzeugt haben. Wir empfehlen TwoFish zur Verwendung als symmetrischen Algorithmus. Wannimmer Sie mit einem assymetrischen Verfahren verschlüsseln wird die eigentliche Nachricht nochimmer symmetrisch verschlüsselt, da dies viel schneller ist. Nur der symmetrische Schlüssel selbst wird mithilfe der assymetrischen Kryptogrpahie chiffriert. TwoFish ist ein Algorithmus, den Bruce Schneier erfunden hat. TwoFish hat es bis zur Endauswahl in der letzten Runde des Advanced Encryption Standard - Wettstreites geschafft. Allerdings glauben wir, daß die letztendliche Wahl des NIST (National Institute of Standards and Technology) für AES nicht optimal war (Rijndael). Das deshalb, weil Regierungs­organisationen nicht nur selbst ein Interesse an sicherer Verschlüsselung haben, sondern auch daran die Verschlüsselung anderer zu brechen. Es gibt keine bekannte Attacke gegen TwoFish, während bereits verschiedene Methoden für AES diskutiert wurden. Es gibt bekannte kryptoanalytische Angriffe auf AES-256 (Schlüssellänge 256bit), welches aufgrund der speziellen Eigenschaften des Algorithmuses weniger sicher als AES-128 sein könnte (Lesen Sie hierzu diesen Artikel.). Beachten Sie, daß wir TwoFish bei setpref vor AES (was effektiv für AES-128 steht) aufgeführt haben, sodaß dies die Standardauswahl bei der Verschlüsselung an diesen geheimen Schlüssel ist. Leider wird TwoFish nicht standardmäßig zu den erlaubten Algorithmen hinzugefügt, sodaß ein --cipher-algo twofish auf der Kommandozeile meistens nicht weiterhilft. Bei der Kompression haben wir bzip2 gewählt, welches einerseits besser komprimiert als gzip und andereseits einige asserts (Prüfung von Konsistenz­bedingungen) hat, sodaß eine Infektion mit Malware durch das Auspacken schwieriger zu realisieren sein sollte. Grundsätzlich verbessert aber Kompression die Verschlüsselung, da komprimierte Daten eine höhere Entropie haben i.e. weniger redundant strukturiert sind und daher weniger Angriffspunkte zum Brechen der Verschlüsselung bieten.

> gpg --output maxmustermman.pubkey.asc --armor --export maxmustermman@email.org > chmod 444 maxmustermann.pubkey.asc; > gpg --output /media/usbstick/maxmustermann.privkey.asc --armor --export-secret-keys; > chmod 400 /media/usbstick/maxmustermann.privkey.asc; ( you may also touch and chmod the file first; chmod also the .cpio ) > or: find ~/.gnupg | cpio -H crc -o >/media/usbstick/maxmustermann.gnupg.cpio >     cpio -tdv </media/usbstick/maxmustermann.gnupg.cpio > at a later bootup use: cpio -idvu </media/usbstick/maxmustermann.gnupg.cpio … > gpg --output amassage.txt --decrypt amassage.txt.gpg

--armor ist notwendig sobald Sie eine Nachricht drucken oder als Email versenden wollen, da es die entstehenden Binärdaten in eine ascii-/ zeichenbasierte Form bringt.

> gpg --output mymsg.txt.signed --personal-digest-preferences SHA512 [--local-user elws@elstel.org] --clearsign mymsg.txt > später: gpg --verbose --verify mymsg.txt.signed

Sie können Ihre Nachricht somit zuerst signieren und dann verschlüsseln. Auch könnten Sie eine von Ihnen signierte Nachricht einfach nur öffentlich lesbar zur Verfügung stellen, wenn Sie anderen Benutzern nur mehr Sicherheit darin geben wollen, daß die Nachricht auch wirklich von Ihnen stammt (Email-Absender können leicht gefälscht werden von jedem der das SMTP Protokoll kennt). gpg fügt dabei einfach einen SignaturTrailer an Ihre Nachricht an. Vergessen Sie nicht darauf, den SHA-512 oder SHA-256 Algorithmus zum Signieren anzugeben, da sonst unter Umständen noch der alte unsichere SHA-1 zum Einsatz kommen kann. Die Schlüsselnummer oder stattdessen auch die zum Schlüssel gehörige Emailaddresse kann über --local-user oder -u angegeben werden, falls mehrere Schlüssel zum Signieren bereitstünden.

> or: gpg --output mymsg.txt.gpg --encrypt --sign --personal-digest-preferences SHA512 --armor --recipient elws@elstel.org mymsg.txt > später: gpg [--output mymsg.txt] --verbose --decrypt mymsg.txt.gpg

Umgekehrt können Sie auch beide Schritte recht einfach kombinieren. gpg gibt dann beim Entschlüsseln als zusätzliche Meldung aus, daß es die Authentizität des Absenders verifiziert hat. Das --verbose Flag zeigt dabei die verwendeten Hash-Algorithmen (SHA-512/256) und die RSA-Schlüssellängen (bspw. 3072 oder 4096) an. Wir bevorzugen es eher beide Schritte zu trennen.

Für die einmalige Abgabe von Material ist das Signieren zwar auch interessant aber nicht so wichtig, ja möglicherweise sogar unerwünscht oder schädlich. Hierfür brauchen Sie selbst überhaupt keinen Schlüssel generieren, sondern Sie brauchen vor dem Verschlüsseln Ihrer Nachricht nur unseren öffentlichen Schlüssel (pubkey) zu importieren. Vielleicht darf der Absender ja nicht direkt bekannt werden.

gpg-SmartCards, ~/.gnupg/gpg.conf und Online­Verschlüs­selung

Sobald Sie gpg das erste mal verwenden, wird es eine Datei mit dem Namen ~/.gnupg/gpg.conf erzeugen (und dafür evtl. eine unter /etc/skel/.gnupg/ gespeicherte Vorlage heranziehen). Es sollte sich auszahlen einen Blick auf diese Datei zu werfen, da man diese nicht nur für Einstellungen wie dem default-key, dem standardmäßig verwendeten Schlüssel, verwenden kann, sondern, da man hier jede lange Option, die auch auf der Kommandozeile funktioniert, angeben kann. Das spart viel Tipparbeit und im Falle von --personal-digest-preferences eliminiert es auch ein Sicherheitsrisiko, falls Sie einmal auf diese Option vergessen sollten. Schauen Sie sich doch einmal folgendes Exzerpt aus unserer gpg.conf an:

default-key 02530C63 charset utf-8 personal-cipher-preferences TwoFish AES128 personal-digest-preferences SHA512 group online = 02530C63 group offline = 9981E39D

Einen «default-key» zu haben ist nützlich, damit Sie nicht jedesmal beim Signieren den zu verwendenden Schlüssel mit --local-user angeben müssen. Die «group» Option ist ebenfalls interessant, da diese es erlaubt einen Alias (auch: Synonym) für einen bekannten Schlüssel zu definieren (eine Liste aller verfügbaren Schlüssel gibt es via gpg --list-keys). Wenngleich die Emailadresse einer der meist benutzten, automatisch verfügbaren Aliase für die Schlüssel-ID ist, so kann die «group» Option doch nützlich sein, wenn man entweder einen noch kürzeren Alias haben will oder falls es mehrere Schlüssel, welche dieselbe Emailadresse benutzen, gibt (Selbst eine einzige Person kann zwei Schlüssel benutzen, einen für die Online­Verschlüsselung und einen weiteren offline.). personal-digest-preferences sollte auf SHA-256 oder SHA-512 gestellt werden um die Benutzung des unsicheren SHA-1 zu meiden. Schließlich ist es noch sinnvoll utf-8 als Standardzeichensatz für Metadaten zu setzen (der Zeichensatz der verschlüsselten Nachrichten wird durch diese Einstellung nicht tangiert; er bleibt über Ver- und Entschlüsselungen hinweg unverändert.). Utf-8 ist heute der Standardzeichensatz wie er von fast allen bekannten Distributionen per default verwendet wird.

> gpg --card-status > gpg --card-edit gpg> help

Was uns betrifft, so verwenden wir unsere gpg-SmartCard nur zusammen mit einer speziell gesicherten Online Workstation, die von einem USB-Stick gebootet wird, den wir immer bei uns haben. Dort verwenden wir zum Internetzugriff ausschließlich ein ftps-Programm sowie einen WebBrowser, bei dem wir alle StandardZertifikate entfernt haben. Das einzige dort installierte SicherheitsZertifikat für den Zugriff über https stammt von unserem HostingProvider und wurde mit Tor sowie DANE verifiziert (Ein mit gpg gesichertes Email an den Hoster tut es normalerweise auch.). Graphische EmailProgramme haben bekannterweise ihre eigenen, zusätzlichen Sicherheitsrisiken und werden deshalb von uns nicht verwendet. SmartCards nur in einer halbwegs gesicherten Umgebung zu verwenden ist deshalb so wichtig, weil sonst der Angreifer alles im Klartext lesen kann, sobald Sie entschlüsseln. Verschlüsselungs­Karten könenn ja nur gegen den Diebstahl des geheimen Schlüssels schützen (solange Sie sich nicht entscheiden ein „Backup” dieses anzulegen; dann bringt Ihnen nämlich Ihre Karte so gut wie nichts.). Das gute an der SmartCard ist ja eben, daß man den geheimen Schlüssel zwar hinauf, nicht aber herunterladen kann. Falls Sie ihre Karte nur zum Signieren verwenden, können Sie dies durchaus auch auf einer kompromittierten Maschine machen, solange Sie sich den aktuellen Stand des SignaturZählers jedesmal notieren und prüfen, daß keine ungewollte Signatur je davon erzeugt worden ist. Vergegenwärtigen Sie sich, daß Ihr PIN auf einem Online-Rechner leicht in fremden Besitz gelangen kann: 1x cracken und Keylogger installieren reicht; - und Sie werden das wahrscheinlich nicht einmal mitbekommen. Den PIN dauernd ändern ist auch keine Lösung, da Sie eben nicht wissen wann ein Einbruch erfolgt sein kann (die Log-Dateien werden Ihnen nicht weiterhelfen) und da sich die Karte von selbst zerstört wenn Sie den PIN mehrmals falsch eingeben.

Eine wichtige Information bei der Verwendung von gpg-Karten ist, daß diese wie in unserem Fall leider normalerweise nur den geheimen Schlüssel speichern, sodaß Sie sich unbedingt ein Backup für den öffentlichen Schlüssel anlegen müssen! Der öffentliche Schlüssel enthält zusätzliche Informationen, die zwar vom geheimen Schlüssel auf der Karte signiert, aber nicht Teil dieses sind.

Web of Trust

Obwohl wir hier einige Vorgehensweisen, so wie sie oft in Zusammenhang mit dem Web of Trust gebracht werden und dort durchaus etabliert sind, kritisiert haben, so ist es immer noch wichtig zu wissen was das Web of Trust überhaupt ist und welche Verfahren in diesem Zusammenhang sicher sind und welche wohl nicht. Unsere Kritik richtet sich denn hauptsächlich gegen die Verwendung von unsicher gespeicherten, unsicher benutzt und gehandhabten Hauptschlüsseln (master keys) zum Signieren, die schon zu lange im Umlauf sind um noch als sicher gelten zu können. Nichtsdestoweniger kann es in einigen Fällen sehr nützlich sein auf Schlüssel zu vertrauen, die jemand anderer für uns signiert und damit als authentisch und hoffentlich auch richtig verwendet gekennzeichnet hat; vor allem dann wenn wir selbst nicht so einfach an eine authentische Kopie dieses Schlüssels gelangen können.

Beginnen wir mit etwas ganz einfachem. Nehmen wir an Sie haben sich dazu entschlossen ihren vorher auf ein sicheres Wechselmedium gespeicherten privaten Schlüssel über --import zu importieren anstatt gleich die ganze gnupg Datenbank mit cpio gesichert zu haben um sie dann wiederherzustellen. Jetzt weiß GnuPG nicht, daß der gerade importierte private Schlüssel wirklich zu Ihnen gehört und daß es diesem auch wirklich vertrauen kann. Das wird zum Problem, sobald Sie Signaturen überprüfen wollen (Ver- und entschlüsseln geht bereits direkt nach dem Import.).

amnesia@amnesia:~$ gpg --import elws.privkey
gpg: keyring `/home/amnesia/.gnupg/secring.gpg' created
gpg: key 9981E39D: secret key imported
gpg: key 9981E39D: public key "Elws. Starnight (…) <elws@elstel.org>" imported
gpg: key 9981E39D: public key "Elws. Starnight (…) <elws@elstel.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

Sie können dieses Problem ganz einfach umgehen, indem Sie gpg „ultimatives” Vertrauen in die Signations­echtheit ihres Schlüssels geben. Das würde bedeuten, daß GnuPG jedem Schlüssel, den sie mit Ihrem importierten privaten Schlüssel signiert haben, voll und ganz vertrauen kann. Das Signieren von Schlüsseln, die Ihres Wissens nach bekanntermaßen sicher verwendet werden können, ist eine richtige Praxis und unterdrückt Warnungen beim Entschlüsseln signierter Nachrichten. Ein Schlüssel kann erst dann als sicher erachtet werden, wenn er auch aus einer verlässlichen Quelle stammt, wenn Sie den Schlüssel aus verschiedenen Quellen gegengeprüft haben oder wenn Sie dessen Fingerabdruck ebenfalls aus verläßlicher Quelle bestätigt haben.

amnesia@amnesia:~$ gpg --edit-key elws@elstel.org
 gpg (GnuPG) 1.4.12; Copyright (C) 2012 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.
 Secret key is available.
  pub  4096R/9981E39D  created: 2015-01-10  expires: never       usage: SC
                       trust: unknown       validity: unknown
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>

 gpg> trust
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 Please decide how far you trust this user to correctly verify other users' keys
 (by looking at passports, checking fingerprints from different sources, etc.)
   1 = I don't know or won't say
   2 = I do NOT trust
   3 = I trust marginally
   4 = I trust fully
   5 = I trust ultimately
   m = back to the main menu
 Your decision? 5
 Do you really want to set this key to ultimate trust? (y/N) y
 pub  4096R/9981E39D  created: 2015-01-10  expires: never       usage: SC
                      trust: ultimate      validity: unknown
 sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 Please note that the shown key validity is not necessarily correct
 unless you restart the program.

 gpg> save
 Key not changed so no update needed. 

Beachten Sie, daß 4096R/9981E39 bedeutet, daß es sich um einen 4096 bit RSA Schlüssel handelt, dessen Hashwert nach dem Slash steht (die letzten sieben Stellen des Fingerabdrucks). Diesen Hash benötigen Sie immer dann, wenn Sie einen Schlüssel von einem Schlüsselserver herunterladen wollen. Die Emailadresse alleine bietet hierfür nicht genügend Informationen. In diesem Beispiel ändern wir das Vertrauen in die Signatur­echtheit unseres Schlüssels von unbekannt auf „ultimativ”. Lassen Sie sich nicht davon irritieren daß GnuPG im Moment eine unbekannte Gültigkeit (unknown validity) für unseren Schlüssel von ultimativer Signatur­echtheit anzeigt. Nach einem erneuten --edit-key Kommando und einem gpg> list wird gpg nämlich eine ultimative Signatur­echtheit (trust) und die darin miteingeschlossene ultimative Gültigkeit (validity) für das gerade importietre öffentliche/private Schlüsselpaar anzeigen. Der Editiermodus kann jederzeit mit save und quit verlassen werden. Letzteres fragt nach ob man Änderungen am Schlüssel auch wirklich speichern will.

Wie Sie sehen können hat GnuPG nicht bloß nur einen Hauptschlüssel zum Signieren für uns generiert (usage: SC, «sign, certify», Benutzbarkeit: signieren, zertifizieren) sondern auch gleich einen Unterschlüssel zum Verschlüsseln (usage: E, encrypt). Das ist auch die Voreinstellung für --gen-key (RSA und RSA). RSA ist ein gut bekannter und gut theoretisch fundierter und analysierter Verschlüsselungs­algorithmus (auch signieren möglich) basierend auf der Primfaktorzerlegung, dem Sie vertrauen können solange er richtig implementiert worden ist. Falls es mehrere Unterschlüssel geben sollte können Sie einen mit key Nummer auswählen, solange Sie im --edit-key Modus sind. Sie können einen Unterschlüssel mit enable zur Verwendung freischalten und mit disable wieder zurückziehen. Normalerweise, wenn Sie einen neuen Unterschlüssel mit addkey anlegen, werden Sie zuerst den vorhin verwendeten Unterschlüssel mit revkey dauerhaft aus dem Verkehr ziehen. Es gibt kaum einen Grund dafür zwei verschieden Unterschlüssel gleichzeitig zum Verschlüsseln zu verwenden. Je neuer der Teilschlüssel, desto sicherer und desto unwahrscheinlicher, daß ihn bereits jemand gestohlen hat.

Teilschlüssel können Sie zwar für immer aus dem Verkehr ziehen, aber niemals mehr endgültig löschen sobald sie auf einen Schlüsselserver hochgeladen worden sind. Leider ist es trotzdem notwendig auch den Hauptschlüssel von Zeit zu Zeit auszutauschen, vor allem dann wenn er nicht auf einer sicheren Verschlüsselungs­karte gespeichert ist, von wo er nicht mehr herausgeholt werden kann. Benutzen Sie gpg --output mykey.revoke.asc --gen-revoke my@email.dom um ein Rückrufzertifikat zu erstellen. Veröffentlichen Sie dieses sofort wenn notwendig. Den neuen Schlüssel können Sie später immer noch, am besten mit dem alten signiert, veröffentlichen. Das passwd Kommando kann darüberhinaus dazu verwendet werden, um das Kennwort, das zur Entschlüsselung und zum Signieren benötigt wird, zu ändern. Machen Sie das, nachdem Sie Ihre sichere Verschlüsselungs­karte in einen Onlinecomputer gesteckt haben (oder in irgendeinen anderen verdachtsweise kompromittierten Rechner). Ihre Tastenanschläge könnten aufgezeichnet worden sein. Da dies so einfach möglich ist könnten Sie sich evtl. auch dazu entscheiden gleich gar kein Paßwort zu benutzen (häufiges Ändern ist nicht praktikabel). Dann müssen Sie aber um so schneller sein, wenn Sie ihr Rückrufzertifikat bei Verlust der Karte veröffentlichen.

Zuguterletzt wäre da noch eine Fähigkeit von GnuPG zu nennen, die sich „user id management” oder Benutzer­Kennungs­Verwaltung nennt. Eine Benutzer-ID gehört immer zum Hauptschlüssel und kann mehrere Verwendungs­möglichkeiten und Emailadressen für diesen anzeigen. Wählen Sie eine Benutzer-ID mit uid Nummer aus, machen Sie sie mit primary zur vorrangigen Benutzer-ID, fügen Sie eine neue ID mit adduid hinzu und löschen Sie eine alte mit deluid.

Das waren jetzt alle grundlegenden GnuPG Kommandos die wir brauchen (mehr gibt es in der Unix man page bzw. in der Dokumentation von GnuPG). Kommen wir jetzt auf das Web of Trust zurück. Wir haben in der Einleitung erwähnt, daß wir Schlüsseln vertrauen schenken können, die von von uns bekannten Personen signiert worden sind, solange wir wissen, daß diese Personen nur gute Schlüssel signieren (Signations­echtheit). Das ist eine anerkannte Praxis.

Deswegen gibt man der Singatur­echtheit anderer Teilnehmer meistens auch nur eine «marginale» Vertrauens­ebene. In diesem Fall braucht man dann --marginals needed Anzahl Singaturen von anderen Personen bis GnuPG einen Schlüssel als sicher erachtet (Es gibt sogar eine --completes-needed Option für die Anzahl an Bestätigungen bei „vollem Vertrauen”). Das wäre kein übermäßiges Problem, wenn wir alle genug Zeit hätten öffentliche Schlüssel anderer Personen zu sammeln und zu bestätigen, mögen Sie jetzt denken. Jedoch sollte man auch zu alten Hauptschlüsseln nicht mehr vertrauen. Da hascht die Katze nach ihrem eigenen Schwanz; ein Grund warum das sog. Web of Trust in der Praxis nur halb so gut funktioniert wie in der Theorie. Der andere wahrscheinlich wesentlich gravierendere Grund für die Unvertrauens­würdigkeit des Web of Trust sind wohl die so weit verbreiteten schlechten Gewohnheiten im Umgang mit geheimen Schlüsseln, welche den hier gegebenen Anleitungen sehr grob widersprechen. Kaum jemand ist bereit den notwendigen Aufwand zu treiben, damit die Verschlüsselung letzten Endes dann nicht ihre Wirkung verfehlt. Eine sichere Karte zur Verschlüsselung, in der der geheime Schlüssel sicher gefangen ist, wäre also nur ein Teil der Lösung. An der Notwendigkeit Verschlüsselungen auf sauberen Offlinerechnern durchzuführen, kann eine solche Karte aber nichts ändern, da Nachrichten immer dann am leichtesten abzufangen sind, wenn diese noch im Klartext verfügbar sind. Verschlüsselungs­karten, welche ausschließlich zur sicheren Authentifikation beispielsweise über SSH verwendet werden, sind natürlich wiederum eine andere Geschichte.