Im ersten Teil dieser Serie ging es um die theoretische Grundlagen zu OpenPGP. Bevor wir loslegen, fehlt noch etwas praktisches Rüstzeug, sozusagen einige Werkzeuge und Begriffe, die ich kurz – allerdings mit Fokus auf die Windows-Welt – vorstellen möchte.
Wie verifiziere ich die Echtheit von Downloads? Wie benutze ich die Konsole – und was ist das überhaupt? Das Wissen wird später helfen, die Einrichtung von OpenPGP besser zu verstehen und bewerkstelligen zu können.
Dieser Artikel ist Teil der Serie "OpenPGP im Berufsalltag". Du möchtest auch die anderen Artikel lesen? Hier geht es zur Übersicht.
Auch unter Windows und auch in 2018 ist die Nutzung der Kommandozeile für bestimmte Aufgaben sinnvoll. Es ist einfach schneller und man bekommt direkteres Feedback. Glücklicherweise ist sie nicht schwer zu erlernen. Für den täglichen Umgang mit E-Mails gibt es natürlich ausgereifte grafische Lösungen.
Windows enthält zwei eingebaute Kommandozeilen: Die PowerShell und cmd.exe.
Wir werden cmd.exe benutzen, die sogenannte Eingabeaufforderung (engl. Command Prompt), auch Konsole genannt.
Aufrufen kann man diese über WIN+R → Eingabe cmd → <Enter> oder über das Startmenü.
Einige Konfigurationseinstellungen des Betriebssystems befinden sich in sogenannten Umgebungsvariablen. Das sind Schlüssel-Wert-Paare, die entweder nur für einen bestimmten oder für alle Benutzer (systemweit) sichtbar sind. Der Schlüssel windir enthält beispielsweise auf meinem Rechner den Wert C:\Windows.
Mit dem Kommandozeilen-Befehl set lassen sich alle für den aktuellen Nutzer sichtbaren Paare ausgeben.
Umgebungsvariablen lassen sich folgendermaßen bearbeiten:
Mit den letzten Windows-Updates kam eine Abkürzung zu den eigenen Variablen hinzu:
Windows-Taste → Eingabe "Umgebungsvariablen" → Umgebungsvariablen für dieses Konto bearbeiten.
Gibt man auf der Kommandozeile Befehle ein, sucht Windows im Hintergrund nach einem passenden Programm. Wenn ich z. B. gpg eingebe, sucht Windows nach dem Programm gpg.exe.
Wo überall gesucht wird, steht u. a. in der Umgebungsvariable Path [engl. für (Such-)Pfad]. Die Variable enthält eine mit Semikolon getrennte Liste von Verzeichnissen, in denen gesucht wird, beispielsweise C:\Windows;C:\Programme.
Will man neue Verzeichnisse aufnehmen, muss man diese also anhängen, z. B.:C:\Windows;C:\Programme;C:\MeinVerzeichnis.
Aber Vorsicht: Die Änderung wird auf der Kommandozeile erst nach Neustart der Konsole wirksam.
Langsam wird es ernst. Die aktuelle Version von gpg4win kann online herunter geladen. Aber halt: Bevor man mit der Installation fortfährt, sollte geprüft werden, ob die Datei den erwarteten Inhalt hat und von einer vertrauenswürdigen Quelle stammt. Dadurch wird sichergestellt, dass man keine Schadsoftware an Land gezogen hat. Das sollte heutzutage für jeden Download ausführbarer Dateien gemacht werden.
Für viele Downloads gibt es eine Seite oder Datei mit Integritätsinformationen. Das können u. a. Zertifikatsinformationen, Datei-Hashes, oder PGP-Signaturen sein. Bei gpg4win gibt es dazu eine Übersichtsseite.
Ein Zertifikat kommt meist zusammen mit digital signierten Dateien. Das bedeutet: Eine Datei ist digital unterschrieben worden. Die Unterschrift wurde von einer vertrauenswürdigen Stelle, einer Zertifizierungseinrichtung, englisch Certification Authority (CA), mittels eines Zertifikats beglaubigt. Unterschriften und Zertifikate sind mathematisch eng mit dem Download verzahnt und können darin eingebaut sein. Dadurch fallen Manipulationen an Unterschriften oder Dateien schnell auf.
Woher aber weiß Windows, welcher Zertifizierungsstelle und damit, welcher Unterschrift zu trauen ist? Kurz: Die Menge vertrauenswürdiger Stellen ist öffentlich einsehbar und wird von den "großen" Internetfirmen und öffentlichen Gremien abgestimmt. Microsoft pflegt den Stand dann entsprechend in Windows ein und aktualisiert diesen. Ähnlich funktioniert es bei anderen Betriebssystemen. Unter Windows kann man die Korrektheit einer ausführbaren Datei recht einfach prüfen:
Für nicht Windows-spezifische Inhalte (Videos oder PDFs können ebenfalls Schadcode enthalten) gibt es noch eine andere Möglichkeit, Downloads zu prüfen: Hash-Codes. Ein Hash-Code ist eine Zahl, die aus einer Datenmenge, z. B. aus einer Datei, berechnet werden kann. Hash-Codes werden oft zusammen mit Downloads veröffentlicht. Führt man die Berechnung lokal nochmals durch und erhält die gleiche Zahl, ist der Download "echt".
Winzige Änderungen an der Datei führen zu einer großen Änderung im Hash-Code – Manipulationen fallen so schnell auf. Aus diesem Grund werden solchermaßen genutzte Hash-Codes auch als Prüfsummen (eng. Checksum) bezeichnet.
Ein Problem von Hash-Codes ist, dass unterschiedliche Dateien in seltenen Fällen die gleiche Prüfsumme erzeugen können. In diesem Fall spricht man von einer Kollision. Je einfacher es ist, Kollisionen zu erzeugen, desto einfacher ist es für einen Angreifer, eine gefälschte Datei anzubieten, die zu einem korrekten Hash-Code eines vertrauenswürdigen Anbieters führt.
SHA1, SHA256 und MD5 sind Bezeichnungen für unterschiedliche Verfahren zur Berechnung solcher Codes. Für uns ist der wichtigste Unterschied dieser Verfahren die Kollisionssicherheit. MD5 gilt als sehr unsicher, d. h. Kollisionen lassen sich vergleichsweise einfach erzeugen. Bei SHA1 ist es ebenfalls recht einfach, SHA256 gilt im Moment als recht sicher.
Wie überprüft man nun die Codes? Ich benutze unter Windows eine der folgenden Möglichkeiten:
sha1sum, sha256sum und md5sum – Unter Unix-Betriebssystemen gängige Tools, die unter Windows z. B. über die git-bash verfügbar sind.Angenommen, die zu prüfende Datei liegt im Download-Verzeichnis des Users, dann versuchen wir es mit dieser Eingabe:
cd C:\Users\<USER>\Downloads
certutil gpg4win-4.0.4.exe -hashfile SHA256
Das Ergebnis sieht dann wie folgt aus:
C:\Users\mosig_user\Downloads>certutil -hashfile gpg4win-4.0.4.exe SHA256
SHA256-Hash von gpg4win-4.0.4.exe:
a750608969a075f132da31f538231ac3a2d3538e3eec8e8603d1573284745d0e
CertUtil: -hashfile-Befehl wurde erfolgreich ausgeführt.
certutil unterstützt die Hashalgorithmen MD2, MD4, MD5, SHA1, SHA256, SHA384 und SHA512.
Man lädt und installiert git-bash. Angenommen, die zu prüfende Datei liegt im Download-Verzeichnis des Users, dann sieht die Eingabe folgendermaßen aus:
cd ~/Downloads # Die Tilde ~ steht für das Nutzerverzeichnis sha256sum gpg4win-4.0.4.exe
Das ergibt:
mosig_user@T1000 MINGW64 ~/Downloads $ sha256sum gpg4win-4.0.4.exe a750608969a075f132da31f538231ac3a2d3538e3eec8e8603d1573284745d0e *gpg4win-4.0.4.exe
Sind MD5- und SHA1-Codes verfügbar, kann eine Überprüfung beider Summen ausreichend sein, obwohl die Verfahren einzeln genommen unsicher sind. Die Manipulation einer Datei, so dass Kollisionen für zwei Summen und zwei Verfahren gleichzeitig erzielt werden, dürfte zu aufwendig für die meisten Angreifer sein.
Aus Sicherheitsgründen ist es besser, die Hashverfahren SHA256 oder SHA512 zu nutzen.
Weil bereits kleine Manipulationen große Änderungen an der Summe verursachen, reicht meist die optische Prüfung der 4-8 ersten und letzten Zeichen. Doch Vorsicht: Natürlich kann dieses Vorgehen ein Sicherheitsrisiko sein!
Mit den Unix-Tools ist es möglich, die Überprüfung der Summen zu automatisieren. Dazu sei auf sha256sum --help verwiesen.
Im ersten Teil erwähnte ich, dass PGP nicht nur für E-Mails einsetzbar ist. Die Prüfung von Downloads auf Echtheit ist ein gutes Beispiel dafür. Genau wie bei E-Mails, kann man auch für beliebige andere Daten Signaturen erstellen und prüfen, z. B. für Downloads.
Auch PGP-Signaturen sind digitale Unterschriften. Allerdings sind diese nicht von einer Zertifizierungsstelle beglaubigt. Sie können mit dem öffentlichen Schlüssel des Absenders überprüft werden. Entscheidend ist, wie viel Vertrauen man in diesen Schlüssel hat. Weiß man, dass er wirklich dem Anbieter gehört, ist alles okay. Kann man dies aber nicht zweifelsfrei feststellen, könnte selbst eine richtige Signatur nichts wert sein, da sie von jemandem erstellt wurde, der nur vorgibt, der Anbieter zu sein. Deshalb ist es wichtig, die Quelle für Schlüssel-ID, Schlüssel und Signatur zu prüfen und sich von deren Echtheit zu überzeugen.
Dazu lädt man die zum Download gehörige Signaturdatei herunter und legt sie in dasselbe Verzeichnis. Für gpg4win-3.1.1.exe ist das beispielsweise gpg4win-3.1.1.exe.sig. Ich greife hier etwas vorweg und nehme an, PGP wäre bereits installiert. Eine PGP-Signatur kann man dann mit gpg auf der Konsole prüfen:
cd C:\Users\<USER>\Downloads gpg --verify gpg4win-3.1.1.exe.sig gpg4win-3.1.1.exe
Man erhält folgende Ausgabe:
C:\Users\mosig_user\Downloads>gpg --verify gpg4win-3.1.1.exe.sig gpg4win-3.1.1.exe gpg: Signatur vom 05/03/18 13:11:15 Mitteleuropäische Sommerzeit gpg: mittels RSA-Schlüssel 13E3CE81AFEA6F683E466E0D42D876082688DA1A gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel gpg: Signatur vom 05/03/18 13:11:25 Mitteleuropäische Sommerzeit gpg: mittels DSA-Schlüssel 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
Die Prüfung der Signatur schlug also fehl. Warum?
gpg machen:gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 13E3CE81AFEA6F683E466E0D42D876082688DA1A 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8
Damit werden die Schlüssel importiert:
C:\Users\mosig_user\Downloads>gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 13E3CE81AFEA6F683E466E0D42D876082688DA1A 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: key 0x7CBD620BEC70B1B8: 121 Beglaubigungen wegen fehlender Schlüssel nicht geprüft gpg: Schlüssel 0x7CBD620BEC70B1B8: Öffentlicher Schlüssel "Intevation File Distribution Key <distribution-key@intevation.de>" importiert gpg: key 0x42D876082688DA1A: 72 Beglaubigungen wegen fehlender Schlüssel nicht geprüft gpg: Schlüssel 0x42D876082688DA1A: Öffentlicher Schlüssel "Intevation File Distribution Key <distribution-key@intevation.de>" importiert gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: Tiefe: 0 gültig: 2 signiert: 0 Vertrauen: 0-, 0q, 0n, 0m, 0f, 2u gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2019-01-28 gpg: Anzahl insgesamt bearbeiteter Schlüssel: 2 gpg: importiert: 2
Jeder Schlüssel kommt mit Beglaubigungen durch andere OpenPGP-Teilnehmer. Diese lassen sich mit den öffentlichen Schlüsseln dieser Teilnehmer nachvollziehen.Diese Schlüssel werden aber nicht mit importiert, daher werden die Beglaubigungen beim Import nicht geprüft.
Jetzt können wir es noch einmal versuchen:
C:\Users\mosig_user\Downloads>gpg --verify gpg4win-3.1.1.exe.sig gpg4win-3.1.1.exe gpg: Signatur vom 05/03/18 13:11:15 Mitteleuropõische Sommerzeit gpg: mittels RSA-Schlüssel 13E3CE81AFEA6F683E466E0D42D876082688DA1A gpg: Korrekte Signatur von "Intevation File Distribution Key <distribution-key@intevation.de>" [unbekannt] gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur! gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört. Haupt-Fingerabdruck = 13E3 CE81 AFEA 6F68 3E46 6E0D 42D8 7608 2688 DA1A gpg: Signatur vom 05/03/18 13:11:25 Mitteleuropõische Sommerzeit gpg: mittels DSA-Schlüssel 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: Korrekte Signatur von "Intevation File Distribution Key <distribution-key@intevation.de>" [unbekannt] gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur! gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört. Haupt-Fingerabdruck = 61AC 3F5E E4BE 593C 13D6 8B1E 7CBD 620B EC70 B1B8
Die Signatur ist also korrekt. Die dazugehörige Warnung kann man hier ignorieren. Sie bestätigt nochmals den Umstand, dass der öffentliche Schlüssel technisch nicht nachweisbar dem Anbieter des Downloads gehört und auch keine vertrauenswürdige Beglaubigung existiert.
Ausblick
Das war recht viel Information. Das Schöne ist, dass wir jetzt alle Grundlagen beisammen haben, um in den nächsten Teilen zügig voran kommen zu können. Als nächstes werden wir uns mit der Einrichtung von gpg4win und der Schlüsselgenerierung beschäftigen.