GnuPG Anleitung - Seite 5

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.

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.

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.

~/.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

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

/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
}

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.

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

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.

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

Inhalt | Seite 4 | Seite 6