Wie man GnuPG sicher verwenden 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.
Wir schlagen die folgenden Richtlinien für die sichere Kommunikation über Email oder das Schützen jedweder anderer Dokumente vor. Bitte befolgen Sie die untenstehenden Anweisungen und Richtlinien genau, wenn Sie uns eine verschlüsselte Nachricht zukommen lassen wollen.

  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 Wegwerfemailadresse ü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 estellnb.pubkey.asc. Versuchen Sie die Datei über verschiedene Computer und Netzwerkverbindungen 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/estellnb.pubkey.asc aus. Prüfen Sie alle heruntergeladenen Schlüsseldateien auf Gleichheit. 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 Internetverbindungen 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. Wenn Sie sich über https verbinden und das Zertifikat unseres Hostingproviders akzeptiert haben, dann wissen Sie lediglich, daß Sie sich jedesmal mit derselben Seite verbinden, nicht aber genau mit welcher. Das mag bereits ein entscheidender Vorteil sein, da Überwachungs- und Geheimdienste den Verkehr zu einer Seite nicht mit einer 100%igen Verläßlichkeit umleiten können. Zusätzlich können Sie versuchen unseren öffentlichen Schlüssel über einen der folgenden Schlüsselserver zu erreichen: keys.gnupg.net, pgp.mit.edu:11371, keyserver.ubuntu.com, pool.sks-keyserver.net, subkeys.pgp.net:11371, 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.

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. 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 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. Leider beschreiben wir hier die Benutzung von Chipkartenlesern nicht und setzen voll und ganz auf Ihre Eigenverantwortung.

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.

Bevor Sie Ihre Nachricht absenden, denken Sie darüber nach, ob es ein Nachteil sein kann, wenn eine überwachende Instanz oder ein Geheimdienst weiß, wer mit wem kommuniziert hat. Sie haben die Möglichkeit Ihre Nachricht über eine temporäre Wegwerfemailadresse, wie jene die unter TorVPN gelistet sind, über Tor zu versenden. Wählen Sie ein oder zwei Emailprovider von der Liste und machen Sie im Tor-Netzerk nichts anderes als Ihre verschlüsselte Nachricht über diese Provider abzusenden. Je kürzer Sie sich im Tor-Netz aufhalten desto geringer die Wahrscheinlichkeit gecrackt zu werden. Nutzer des Tor-Netzwerks sind häufig Angriffen von Diensten wie dem NSA ausgesetzt und können zurückverfolgt werden, sobald sie angegriffen worden sind. Das Einzige was ihre Anonymität in einem solchen Fall retten kann, ist wahrscheinlich Whonix. Es versetzt den Tor-Client in eine virtuelle Maschine. Wird diese kompromittiert stört das Ihre Anonymität nicht. Das einzige praktische Problem mag sein, daß keine sauberen Boot-CDs für Whonix verfübar sind. Gleichfalls würden wir zu einer echten OSS Virtualisierungslösung d.h. qemu raten, da es für entsprechende Dienste ungleich einfacher ist Schwachstellen in geschäftlich erzeugte oder gar proprietäre Software einzubauen.

Zuletzt aber nicht minder wichtig sagen Sie uns welche Sicherheitsmaßnahmen Sie eingehalten haben, als Sie ihre Nachricht erstellt und versendet haben. Welche Sicherheitsmaß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.

Letztlich verwenden auch wir unsere privaten Schlüssel nicht für immer. Alle ihre Nachrichten können von Geheimdiensten oder einer anderen Partei solange gespeichert werden, bis diese in den Besitz Ihres privaten Schlüssels kommt und dann alles aber auch alles entschlüsseln! Wir versuchen genau das zu vermeiden, indem wir unsere privaten Schlüssel regelmäßig für immer vernichten zumindest dann, wenn wir Nachrichten erhalten, die uns hinreichend schützenswürdig erscheinen oder wenn wir in eine Situation gekommen sind, in der wir unseren privaten Schlüssel nicht hinreichend schützen konnten. Wir können weniger schützenswürdige Nachrichten auch für längere Zeit zusammen mit unserem privaten Schlüssel speichern. Neue öffentliche Schlüssel werden anzunehmenderweise mit dem vorhergehenden privaten Schlüssel signiert um es für Sie einfacher zu machen die Herkunft des neuen Schlüssels festzustellen. Jedoch mag es eine unzureichende Maßnahme sein eine solche Signatur zu überprüfen, da auch jene Partei, die anzunehmenderweise in den Besitz des privaten Schlüssels gelangt ist, dann einen signierten Folgeschlüssel erzeugen kann; wir glauben also, daß dies nur sehr begrenzt Sinn macht. Sie sollten in diesem Fall besser bei Punkt eins neu anfangen. Zurückgenommene Schlüssel werden zusammen mit dem neuen Schlüssel unter «Kontakt» gelistet werden. Sie sollten Ihre eigenen privaten Schlüssel gleich handhaben; jedenfalls solange Sie mit uns kommunizieren wollen.

Beachten Sie auch, daß wir grundsätzlich Anonymität beim Erhalt von Software, Hardware und Schlüsseln als die bessere Sicherheitsmaß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/estellnb.pubkey.asc > also: gpg --keyserver xy.net --recv-key / --send-key email/key-id >       gpg --armor --export yz.pubkey.asc

oder: > tor-resolve key.gnupg.net > torsocks gpg --key-server 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 file nicht mehr direkt über cmp mit estellnb.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 estellnb.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 estellnb.pubkey.asc > gpg --fingerprint > gpg --list-keys > gpg --output mymessage.txt.gpg --encrypt --armor --recipient estellnb@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.

> gpg --gen-key > gpg --armor --export maxmustermman.pubkey.asc > chmod 444 maxmustermann.pubkey.asc; > gpg --armor --export-secret-keys /media/usbstick/maxmustermann.privkey.asc; > 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.

Wenn Sie eine längere Korrespondenz vorhaben oder einfach nur in beide Richtungen kommunizieren wollen, sollten Sie Ihre Nachrichten zusätzlich signieren. Dies sagt aus, daß sie tatsächlich im Besitz des privaten Schlüssels sind, daß also die Nachricht wirklich von Ihnen kommt. Das ist insbesondere dann wichtig wenn beide Kommunikationspartner ihre öffentlichen Schlüssel frei lesbar zur Verfügung stellen. Beachten Sie bitte auch, daß für den Signierschlüssel keine laxeren Bedingungen bezüglich der Sicherheit gelten, wie dies im sog. «Web of Trust» bisweilen manchmal vorgeschlagen wird. Beide Schlüssel sollten immer zusammen ausgetauscht werden.

> gpg --output mymsg.txt.signed --personal-digest-preferences SHA512 [--local-user estellnb@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 estellnb@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 OnlineVerschlüsselung

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-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 OnlineVerschlü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

Wenn Sie einmal gpg auch auf einem Computer verwenden wollen, der mit dem Internet verbunden ist, so empfehlen wir Ihnen dringend die Nutzung einer gpg-fähigen SmartCard. Die Karten, welche die FSFE (Free Software Foundation Europe) ihren Mitgliedern gratis zur Verfügung stellt, wären ein Beispiel und können verhindern, daß Ihr privater Schlüssel gestohlen werden kann. Um so eine Karte in Gebauch zu nehmen werden Sie als erstes ein KartenLeseGerät i.e. einen SmartCardReader brauchen. Weiters müssen Sie pcscd (PC secure card daemon) zusätzlich zu gpg2 installieren. So getan werden Sie sich für den täglichen Gebrauch eigentlich bloß obige zwei Kommandos zusätzlich merken müssen. Trotzdem viele Anleitungen im Netz herumschwirren, die Sie dazu verleiten wollen eine Kopie ihres geheimen Schlüssels getrennt von ihrer Karte aufzuheben, müssen wir Ihnen strengstens von einem solchen Vorgehen abraten. Wenn nämlich jemand anders Ihr BackupMedium finden sollte, hat er plötzlich Vollzugriff auf ihren Schlüssel, ohne daß Sie eine Ahnung davon bekommen würden. Das ist zweifelsohne, das Schlimmste was passieren kann. GnuPG nicht zu verwenden ist besser als andere mit einem kompromittierten Schlüssel in falscher Sicherheit zu wiegen. Generieren Sie bloß wie oben beschrieben ein Revocation Certificate, das Ihren Schlüssel auf Wunsch unschädlich machen kann, und heben Sie es an einem sicheren Platz auf. Falls Sie Ihre Karte wirklich einmal verlieren, brauchen Sie dieses nur zu veröffentlichen. Anschließend müssen Sie allen Ihren Freunden Ihren neuen Schlüssel zuspielen. Bedenken Sie auch, daß Geheimdienste über sog. universelle Schlüssel verfügen, mit denen Sie Ihr Haus jederzeit betreten können, wenn Sie einmal nicht da sein sollten (etwas, daß sich einfach über die Ortung ihres MobilTelephons feststellen läßt.). Eine weitere zusätzliche interessante Funktion von gpg-Karten ist, daß man sich darüber auch via SSH authentizieren kann.

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üsselungsKarten 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 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 estellnb.privkey
gpg: keyring `/home/amnesia/.gnupg/secring.gpg' created
gpg: key 9981E39D: secret key imported
gpg: key 9981E39D: public key "Elmar Stellnberger (…) <estellnb@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 Signationsechtheit 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 estellnb@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)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <estellnb@elstel.org>

 gpg> trust
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <estellnb@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)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <estellnb@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 Signaturechtheit 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 Signaturechtheit anzeigt. Nach einem erneuten --edit-key Kommando und einem gpg> list wird gpg nämlich eine ultimative Signaturechtheit (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üsselungsalgorithmus (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üsselungskarte 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üsselungskarte 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.

Es gibt noch ein paar anderer Dinge, die Sie vielleicht wissen sollten. Als erstes müssen Sie alle zur Kommunikation verwendeten öffentlichen Schlüssel selbst signieren, wenn Sie nicht wollen, daß GnuPG beim Entschlüsseln signierter Nachrichten dauernd Warnungen ausspuckt. Wenden Sie ein --edit-key auf dem öffentlichen Schlüssel ihres Kommunikationspartners an, geben Sie fpr ein, prüfen Sie den Fingerabdruck gegen und benutzen Sie letzendlich sign um die Gültigkeit dieses Schlüssels zu bestätigen. Grundsätzlich sollten Sie keinen Schlüssel signieren, solange Sie nicht davon überzeugt sind, daß der Besitzer verantwortungsvoll damit umgeht und daß Sie eine authentische Kopie davon besitzen. Sie können ja auch den Fingerabdruck bei jeder Entschlüsselung manuell überprüfen. Zumindest sollten Sie einen öffentlichen Schlüssel nicht in signierter Form wieder auf einen Schlüsselserver hochladen, wenn Sie nicht glauben, daß dieser sicher verwendet werden kann. Sobald Sie einmal einen öffentlichen Schlüssel signiert haben, wird nämlich ihre Signatur mit jedem --export, das Sie auf diesen Schlüssel anwenden, ebenfalls exportiert. Sie können dies für eine eigene spätere Benutzung anstreben oder dann wenn Sie überzeugt sind, daß ihre Kopie des Schlüssel authentisch ist und dieser von seinem Besitzer sicher verwendet wird. Wenn Sie das nicht wollen können Sie ihre eigene Signatur von einem Schlüssel mit delsig jederzeit vor dem Export entfernen.

Zuguterletzt wäre da noch eine Fähigkeit von GnuPG zu nennen, die sich „user id management” oder BenutzerKennungsVerwaltung nennt. Eine Benutzer-ID gehört immer zum Hauptschlüssel und kann mehrere Verwendungsmö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 (Signationsechtheit). Das ist eine anerkannte Praxis.

Denken Sie nun an folgendes Szenario: Sie haben gerade mit info@eff.org kommuniziert und sind jetzt einem eigenen Ansprechpartner, der seinen eigenen GnuPG Schlüssel hat, zugewiesen worden. Wenn Sie jetzt volles Vertrauen in die Korrektheit und Echtheit der Signaturen der Info-Abteilung von EFF haben, können Sie dem info@eff.org Schlüssel über --edit-key ein entsprechendes trust Level zuweisen. Wenn jetzt der Schlüssel ihres Ansprechpartners mit dem info@eff.org Schlüssel signiert worden ist und Sie zuvor den info@eff.org Schlüssel schon signiert haben, stellt GnuPG eine Vertrauenskette von Ihrem Schlüssel über info@eff.org zu Ihrem Ansprechpartner her. Sie brauchen also den Schlüssel Ihres Ansprechpartners nicht mehr erneut überprüfen und selbst signieren, wenn Sie volles Vertrauen in die Signationsechtheit von info@eff.org haben. Beachten Sie, daß eine solche Vertrauenskette nur --max-cert-depth Schritte lang sein kann. Natürlich ist dies eine schwächere Garantie als wenn Sie den Schlüssel Ihres Ansprechpartners selbst direkt überprüfen, weil die ganze Kette zusammenbricht sobald nur einer der teilnehmenden Schlüssel komprommitiert worden ist. Vertrauen Sie niemandes signierten Schlüsseln („Signationsechtheit”) vollständig, wenn Ihre Sicherheitsbedarf kritisch ist.

Deswegen gibt man der Singaturechtheit anderer Teilnehmer meistens auch nur eine «marginale» Vertrauensebene. 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 Unvertrauenswü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üsselungskarten, welche ausschließlich zur sicheren Authentifikation beispielsweise über SSH verwendet werden, sind natürlich wiederum eine andere Geschichte.