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 basicadvancedexpertguru 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

pinentry-qt4 unter KDE

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.

Verweise auf aktuelle Seite