GnuPG Anleitung - Seite 5
Konfiguration und Optionen
GnuPG
Prinzipiell ist GnuPG ohne weitere Konfiguration über die Festlegung von Optionen in der gpg.conf GnuPG Konfigurationsdatei voll funktionsfähig. D. h. man kann sich eigene Schlüssel erstellen, fremde Schlüssel verwenden, verschlüsseln, entschlüsseln und signieren. GnuPG arbeitet ohne weitere Konfiguration mit einer Reihe von in GnuPG kodierten Voreinstellungen, legt die Schlüsselringdateien, die Vertrauens-Datenbankdatei und die random_seed Datei für Zufallswerte im GnuPG Heimatverzeichnis an.
Wenn jedoch z. B. ein Kryptomodul geladen werden muss, die von GnuPG genutzen Dateien an einem anderen Ort liegen sollen, die Nutzung eines bestimmten Verschlüsselungs- oder Hashalgorithmus gewünscht oder ein bestimmter Schlüsselserver regelmäßig angesprochen wird usw. ist das Editieren der gpg.conf und die Kenntnis der Bedeutung der Optionen wie auch ein tieferer Kenntnisstand über die kryptografischen Grundlagen unerlässlich.
Die gpg.conf wird von allen grafischen GnuPG Oberflächen ausgewertet. Die meisten Oberflächen bieten verständliche Elemente, mit denen wichtige Optionen in die gpg.conf gesetzt werden oder einen Editor, mit dem die gpg.conf direkt verändert werden kann.
Ist noch keine gpg.conf Datei vorhanden, wird die Datei einfach im GnuPG Heimatverzeichnis angelegt und danach mit einem Texteditor oder über die jeweilige grafische Oberfläche editiert.
Basis-Optionen
In der folgenden Tabelle sind alle Optionen aufgeführt, die allgemein und grundlegend für die Funktionsweise von GnuPG von Bedeutung sind. Weitere Optionen für andere Funktionen und spezielle Anwendungszwecke werden in den entsprechenden Kapiteln vorgestellt.
Option | Parameter | Erklärung |
---|---|---|
default-key | Schlüssel-ID | die Schlüssel-ID des eigenen Hauptschlüssels, der standardmäßig zum Signieren und Zertifizieren verwendet werden soll. Bei einem Hauptschlüssel zum Zertifizieren und einem Unterschlüssel zum Signieren, wird auch die Schlüssel-ID des Hauptschlüssel eingetragen, denn für das Signieren wechselt GnuPG automatisch zum Unterschlüssel. |
encrypt-to | Schlüssel-ID | bei der Verschlüsselung mit einem öffentlichen Schlüssel wird immer zusätzlich mit dem zweiten öffentlichen Schlüssel verschlüsselt, dessen Schlüssel-ID hier angegeben wird (Doppelverschlüsselung). Das kann der eigene Unterschlüssel sein, wenn man z. B. möchte, das jede E-Mail, die mit einem fremden, öffentlichen Schlüssel verschlüsselt wird, auch mit dem eigenen Schlüssel verschlüsselt wird, um die E-Mail zu einem späteren Zeitpunkt wieder selbst entschlüsseln zu können. |
default-recipient-self | [Schlüssel-ID] | der eigene Unterschlüssel (E) wird zum Verschlüsseln benutzt, wenn keine Angabe zum Schlüssel einer anderen Person an GnuPG übergeben wird. Stattdessen kann auch „default-recipient Schlüssel-ID“ verwendet werden, wenn ein bestimmter Unterschlüssel verwendet werden soll. |
hidden-encrypt-to | Schlüssel-ID | hat dieselbe Funktion wie encrypt-to mit dem Unterschied, dass die Schlüssel-ID des verwendeten Zweitschlüssels in Form von Schlüssel-ID: 0x0000000000000000 aufgenommen wird. Ein Angreifer, der nicht im Besitz des privaten Schlüssels ist, kann so nicht erfahren, an wen und mit welchem Schlüssel die Nachricht zusätzlich verschlüsselt wurde. Das gilt auch für den eigentlichen Nachrichtenempfänger, was zu Rückfragen führen kann. |
keyid-format | long | die Schlüssel-ID wird mit 16-Zeichen statt 8-Zeichen angezeigt, was die sichere bzw. eindeutige Anzeige und Auswahl von Schlüsseln erhöht, da die Möglichkeit bestehen könnte, dass zwei unterschiedliche Schlüssel die gleichen acht letzten Zeichen in der Schlüssel-ID aufweisen |
with-fingerprint with-subkey-fingerprint with-keygrip | bei der Ausgabe von Informationen zu einem Schlüssel werden immer die Fingerabdrücke und Keygrips des Hauptschlüssels und aller Unterschlüssel mit angezeigt | |
no-default-keyring | die Schlüsselringdateien im GnuPG Heimatverzeichnis werden nicht in die Liste der Schlüsselringe aufgenommen, so dass mit keyring die Schlüsselringe und der Ort für Schlüsselringe selbst definiert wird. Ohne die Option gibt es für GnuPG nur die pubring.kbx Schlüsselringdatei im GnuPG Heimatverzeichnis. | |
primary-keyring | /pfad/pubring.kbx | bei mehreren öffentlichen Schlüsselringdateien, die per keyring eingebunden wurden, werden neue Schlüssel immer in die hier angegebene, persönliche Schlüsselringdatei im Keybox-Dateiformat importiert und gespeichert. Zur Konvertierung in das Keybox-Dateiformat ändert man zuerst die Schlüsselring-Option in der gpg.conf und gibt dann in der Konsole ein: cd ~/.gnupg gpg --export-ownertrust > otrust.lst mv pubring.gpg pubring.backup gpg --import pubring.backup gpg --import-ownertrust otrust.lst Die privaten Schlüssel, die vom gpg-agent gemanaged werden, sind verschlüsselt in einzelnen keygrip.key Dateien im /pfad/private-keys-v1.d/ Verzeichnis gespeichert. Für private Schlüssel, die auf OpenPGP Smartcards gespeichert sind, enthalten die *.key Dateien nur Verweise auf die privaten Schlüssel auf der Smartcard. |
keyring | /pfad/datei.[gpg|kbx] | weitere Schlüsselringdatei(en) |
trustdb-name | /pfad/trustdb.gpg | Dateiname der Vertrauens-Datenbank |
auto-key-locate no-auto-key-locate | local,methode(n) | bei der Verschlüsselung an einen Empfänger mit einer E-Mail Adresse, die kein Bestandteil eines öffentlichen Schlüssels in Schlüsselringen ist, versucht GnuPG zuerst in lokalen („local“) Schlüsselringdateien und dann in Reihenfolge der angegebenen Methoden einen entsprechenden Schlüssel zu finden. Die zweite Option schaltet alle Methoden außer local ab. Methoden: cert (DNS CERT, RFC-4398) pka (Public Key Association (PKA) DNS TXT Record) dane (DANE-OpenPGP, RFC-7929) wkd (Web Key Directory) ldap (auf LDAP-Servern per LDAP-Protokoll) keyserver (OpenPGP-Schlüsselserver) |
auto-key-retrieve no-auto-key-retrieve | GnuPG speichert automatisch alle öffentlichen Schlüssel nach ihrer Suche mit den Methoden lt. auto-key-locate, wenn Signaturen überprüft werden und entsprechende Schlüssel im Schlüsselring fehlen. Die zweite Option schaltet den automatischen Erhalt ab. | |
agent-program dirmngr-program | /pfad/bin/gpg-agent /pfad/bin/dirmngr | Pfad und Dateiname zur gpg-agent und dirmngr Anwendung |
display-charset | utf-8 | Vom Betriebssystem verwendeter Zeichensatz |
utf8-strings | Argumente werden GnuPG in der Konsole als UTF8 Zeichenketten übergeben | |
force-mdc | für GnuPG < 2.2.8: Es wird immer mit einem Modification Detection Code (MDC) verschlüsselt, d. h. vom zum verschlüsselnden Klartext wird ein SHA-1 Hashwert gebildet, der in einem MDC-Paket gespeichert wird, das dem Klartext angefügt wird, bevor beide symmetrisch verschlüsselt werden („Symmetrically Encrypted Integrity Protected Data“). MDC dient dazu, Manipulationen durch Angreifer zu erkennen und bestimmte Angriffe zum Erhalt des Klartexts abzuwehren. Im günstigsten Fall geben Anwendungen, die GnuPG nutzen, nach Erkennung von Manipulationen entsprechende Warnmeldungen aus und brechen die Entschlüsselung ab. | |
armor | die Ausgabe von Signaturen und Geheimtexten erfolgt in ASCII kodiert und nicht als binäre Daten | |
no-comments | ASCII Signaturen und Geheimtexten wird keine Zeichenkette als Kommentar vorangestellt | |
no-emit-version | ASCII Signaturen und Geheimtexten wird keine GnuPG Versionsangabe vorangestellt | |
use-agent | wird ggf. unter Linux benötigt, wenn Skripte oder Anwendungen die Existenz der Option auswerten. Deshalb sollte man die Option setzen, auch wenn sie als „dummy option“ in der GnuPG man page gekennzeichnet ist |
GPG-Agent
Der GPG-Agent ist ein Daemon, der u. a. die privaten Schlüssel und den Passphrase-Zwischenspeicher verwaltet, in dem eine einmalig über das Pinentry Programm eingegebene Passphrase zur erneuten Verwendung gespeichert wird. Die Optionen für den GPG-Agent, die man manuell oder per GPA setzt, werden in der gpg-agent.conf Konfigurationsdatei im GnuPG Heimatverzeichnis gespeichert.
Konfiguration
- ~/.gnupg/gpg-agent.conf
default-cache-ttl n max-cache-ttl n no-allow-external-cache extra-socket none verbose debug-level expert log-file /pfad/gpg-agent.log pinentry-program /usr/local/bin/pinentry scdaemon-program /usr/local/bin/scdaemon
Basis-Optionen
Option | Parameter | Erklärung |
---|---|---|
default-cache-ttl max-cache-ttl | n n | eine Passphrase wird per default-cache-ttl für n Sekunden zwischengespeichert (Standard: 600 Sekunden). Bei erneutem Abruf innerhalb der Zeitspanne wird der Timer zurückgesetzt. Insgesamt wird eine Passphrase per max-cache-ttl maximal bis zu n Sekunden zwischengespeichert (Standard: 7200 Sekunden) |
no-allow-external-cache | Pinentry wird angewiesen, neben dem GnuPG-eigenen Passphrase-Cache keinen zusätzlichen Passphrase-Cache zu verwenden, der ggf. extern durch die Desktop-Umgebung bereit gestellt wird | |
ignore-cache-for-signing | Passphrases für Signieroperationen werden nicht aus dem Zwischenspeicher ausgelesen, sondern müssen immer eingegeben werden | |
extra-socket | none | falls man keinen Bedarf hat, mittels gpg von einem entfernten Rechner aus kryptografische Operationen mit dem lokalen GPG-Agent auszuführen |
verbose oder quiet | ausführliche oder minimale Ausgaben des GPG-Agent | |
debug-level log-file | Level /pfad/gpg-agent.log | um Probleme bzw. die Funktionalität von GPG-Agent zu untersuchen, kann man seine Ausgaben mit dem Level basic → advanced → expert → guru in einer Logdatei speichern lassen. Je höher der Level, desto umfangreicher die Debug-Ausgaben (Logrotation nicht vergessen). |
pinentry-program | /pfad/pinentry | die zu verwendende pinentry Variante zur Eingabe der Passphrase („PIN“) |
scdaemon-program | /pfad/scdaemon | der zur verwendende Smartcard Daemon, wenn OpenPGP Smartcards bzw. Hardware-Token eingesetzt wird |
keep-display | Anfragen zum Wechsel der DISPLAY Variable werden ignoriert | |
keep-tty | Anfragen zum Wechsel des Terminals werden ignoriert |
Ergänzungen
Passphrase-Zwischenspeicher leeren
Um alle Passphrases vor Ablauf der TTL-Zeitdauer aus dem Zwischenspeicher zu entfernen, sendet man das SIGHUP Signal an den GPG-Agent:
kill -SIGHUP oder -1 PID
Logrotation
- /etc/logrotate.d/gpg-userlogs
/pfad/dirmngr.log /pfad/gpg-agent.log /pfad/scdaemon.log { rotate 1 daily missingok notifempty compress create 0640 loginname gruppenname }
Dirmngr
Der dirmngr Daemon ist ein Zertifikats-Manager, der vor allem die Verwaltung und Prüfung von TLS bzw. S/MIME Zertifikaten, CRL-Listen und OSCP-Antworten übernimmt. Die Funktion ist auch von Bedeutung, wenn man mit OpenPGP Schlüsselservern TLS-verschlüsselt per HKPS-Protokoll kommuniziert. Darüber hinaus werden alle Aktionen (z. B. Schlüsselsuche) und Datenverbindungen mit Schlüsselservern vom dirmngr gemanaged. Die zentrale Rolle des dirmngr bzw. generelle Verwendung des dirmngr für den Datenverkehr mit Schlüsselservern soll die Kommunikation mit Schlüsselserver-Pools wie dem SKS verbessern und vereinfachen.
Konfiguration
Für den Betrieb des dirmngr ist es sinnvoll, im ~/.gnupg Verzeichnis einige Verzeichnisse und Dateien anzulegen, die der dirmngr erwartet und ihn über seine Konfigurationsdatei dirmngr.conf einzurichten.
mkdir ~/.gnug/{crls.d,extra-certs,trusted-certs} touch ~/.gnupg/ldapservers.conf touch ~/.gnupg/dirmngr.conf
- ~/.gnupg/dirmngr.conf
verbose log-file /pfad/dirmngr.log debug-level expert gnutls-debug expert disable-ldap disable-http # bei IPv4-only: disable-ipv6 ignore-ldap-dp nameserver IP-Adresse use-tor keyserver http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion/ keyserver hkps://keyserver.ubuntu.com # hkp-cacert /pfad/ca.pem
Erläuterung
Die keyserver Option gibt Protokoll und Adresse des Schlüsselservers an. Als Protokoll kann je nach Schlüsselserver hkp und hkps, ldap oder mailto verwendet werden. Siehe auch HKPS Schlüsselserver.
Mit installiertem Tor kann ein Schlüsselserver, der als versteckter Tor Onion Service eingerichtet ist (an der .onion TLD erkennbar), direkt mit use-tor im „Tor-Modus“ ohne torsocks verwendet werden. Läuft Tor nicht, wird der zweite Keyserver verwendet. Mit der nameserver Option kann die IP-Adresse eines bestimmten DNS-Servers oder Tor (mit DNSPort 53) angegeben werden, den GnuPG im Tor-Modus über Tor zur Namensauflösung des Schlüsselserver Domainnamens verwenden soll. Andernfalls wird der öffentliche DNS-Server von Google mit der IP-Adresse 8.8.8.8 über Tor angefragt.
Die hkp-cacert Option gibt den Pfad zum Root-CA Zertifikat des HKPS Schlüsselservers an, falls dessen Zertifikat von einer eigenen CA signiert wird. Andernfalls ist die Option unnötig und es wird der Root-CA Systemspeicher verwendet. Im reinen Tor-Modus ist die Option ebenfalls unnötig, da HKP statt HKPS und das Zertifikat des Schlüsselserver Tor-Dienstes verwendet werden. Wenn kein LDAP Schlüsselserver verwendet wird, benötigt man auch keine LDAP-Unterstützung (disable-ldap).
Abhängig vom System der Namensauflösung und Internetnutzung (z. B. lokale DNS- und HTTP-Proxys, DNS-Resolver, anonymisiert oder nicht usw.) kann es notwendig sein, eine andere Konfiguration zu wählen und folgende Optionen zu nutzen:
no-use-tor standard-resolver http-proxy host.domain.tld:port
Mit no-use-tor wird der Tor-Modus deaktiviert, standard-resolver erzwingt die Verwendung des Codes des DNS-Resolvers, der Standard des Systems ist und mit http-proxy kann man einen HTTP-Proxy angeben, über den Verbidnungen mit HKPS Schlüsselservern weitergeleitet werden.
Bis alles läuft, sorgen die verbose, log-file und debug Optionen dafür, über die erstellte Logdatei nachverfolgen zu können, ob Probleme auftreten und die Kommunikation mit den Schlüsselservern funktioniert.
GPG-Agent & Dirmngr starten
Die gpg-agent und dirmngr Daemons werden i. d. R. eh automatisch gestartet, sobald der Benutzer Aktionen mit GnuPG ausführt, die Dienste der beiden Daemons erfordern. Wer die beiden Daemons generell nach der grafischen An- und Abmeldung automatisch starten lassen will, kann das Skript als root in /etc/X11/Xsession.d/ speichern.
- /etc/X11/Xsession.d/90gpg-agent
GNUPGHOME="$HOME/.gnupg" SOCKETDIR="/run/usr/$(id -u)/gnupg" DIRMNGR=/usr/local/bin/dirmngr GPGAGENT=/usr/local/bin/gpg-agent DSOCK_FILE="$SOCKETDIR/S.dirmngr" GSOCK_FILE="$SOCKETDIR/S.gpg-agent" if test -x $DIRMNGR; then if [ ! -S "$DSOCK_FILE" ]; then $DIRMNGR --daemon --homedir $GNUPGHOME --sh fi fi if test -x $GPGAGENT; then if [ ! -S "$GSOCK_FILE" ]; then $GPGAGENT --daemon --sh fi fi
Wer die beiden Daemons per systemd starten lassen will, speichert die Unit-Dateien unter /etc/systemd/user/:
sudo cp /pfad/gnupg-version/doc/examples/systemd-user/*.s* /etc/systemd/user/ sudo chmod 644 /etc/systemd/user/*.s*
Danach werden die Units aktiviert:
sudo systemctl daemon-reload systemctl --user enable dirmngr.service systemctl --user enable gpg-agent.service
Danach kann man den dirmngr und gpg-agent mit den folgenden Kommandos managen:
systemctl --user [reload|restart|start|status|stop] [dirmngr|gpg-agent]
Pinentry
Man kann entweder die pinentry-curses
Anwendung in der Konsole verwenden oder die pinentry-qt4
bzw. pinentry-gtk
Anwendungen als grafische Fenster. Arbeitet man primär in der Konsole bzw. ohne X, wählt man die pinentry-curses Anwendung.
Unter Debian werden mit der Installation der pinentry-curses Anwendung und der beiden grafischen Versionen alle Anwendungen im Alternatives-System eingebunden und damit die beiden symbolischen Links /usr/bin/pinentry und /usr/bin/pinentry-x11 angelegt, die je nach Wahl der Alternative auf eine der pinentry Anwendungen verweisen.
sudo update-alternatives --display pinentry sudo update-alternatives --display pinentry-x11
zeigt an, welche der installierten pinentry Anwendungen primär von allen anderen Programmen aufgerufen wird, die pinentry verwenden. Danach kann man die Einstellung der Alternativen ändern:
sudo update-alternatives --config pinentry Es gibt 2 Auswahlmöglichkeiten für die Alternative pinentry (welche /usr/bin/pinentry bereitstellen). Auswahl Pfad Priorität Status ------------------------------------------------------------ * 0 /usr/bin/pinentry-qt4 95 Auto-Modus 1 /usr/bin/pinentry-curses 50 manueller Modus 2 /usr/bin/pinentry-qt4 95 manueller Modus Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten, oder geben Sie die Auswahlnummer ein: 1
Statt des /usr/bin/pinentry Symlinks kann man auch jenseits der Alternativen-Einstellung einen pinentry Typ fix in der gpg-agent.conf vorgeben:
- gpg-agent.conf
pinentry-program /usr/bin/pinentry-curses oder pinentry-program /usr/bin/pinentry-qt4 oder pinentry-program /usr/bin/pinentry-gtk
Während für normale Benutzer /usr/bin/pinentry bzw. eine der grafischen pinentry Versionen in der gpg-agent.conf angegeben werden können, muss für root /usr/bin/pinentry-curses in dessen gpg-agent.conf eingetragen werden, wenn man GnuPG Operationen in der Konsole oder über Skripte mit „sudo -H“ ausführen will, um root seine eigenen Schlüsselringe verwenden zu lassen.