30.5    In der Praxis

In diesem Abschnitt erfahren Sie alles, was Sie zum Betrieb oder zur Anwendung der beiden Konzepte PKI und Web-of-Trust benötigen, und Sie lernen, wie Sie diese am besten einsetzen.

30.5.1    Einrichtung einer PKI mit Server- und E-Mail-Zertifikaten

Eine eigene PKI zu betreiben kann durchaus Vorteile haben: nicht nur für das firmeninterne VPN, sondern auch, wenn Sie zusätzlich interne Webserver absichern wollen. Durch den hierarchischen Aufbau einer PKI können Sie für jedes Umfeld Unter-CAs bilden, die explizit für den jeweiligen Verwendungszweck vorgesehen sind. Dies birgt nicht nur organisatorische Vorteile in sich, einige Anwendungen setzen dies sogar voraus.

Seit der Version 3 sind in X.509-Zertifikaten erweiterte Attribute vorhanden, wie zum Beispiel Key Usage oder Extended Key Usage. Diese werden teilweise zwingend vorausgesetzt: Ohne diese verweigern einige Anwendungen den Dienst.

Der Weg zur eigenen PKI besteht aus fünf Schritten:

  1. Verzeichnisstruktur erstellen

  2. OpenSSL-Konfiguration

  3. CA erzeugen

  4. Unter-CAs erzeugen

  5. Zertifikate ausstellen

Anschließend können Sie selbst signierte Zertifikate für die entsprechenden Verwendungszwecke erstellen. Selbstverständlich können Sie die Struktur auch mit weiteren Unter-CAs erweitern. Hierfür kommt OpenSSL zum Einsatz, eine freie Implementierung der SSL/TLS-Protokolle. Es bietet weitergehende Funktionen zur Zertifikatserstellung und -verwaltung sowie unterschiedliche kryptografische Funktionen. Das von Eric A. Young und Tim Hudson entwickelte SSLeay diente dabei als Basis. Derzeit wird es von einer unabhängigen Gruppe weiterentwickelt. Es ist Bestandteil fast jeder Linux-Distribution. Auch das bekannte SSH setzt zur Verschlüsselung OpenSSL ein.

Verzeichnisstruktur erstellen

Erstellen Sie zunächst die folgende Verzeichnisstruktur in einem beliebigen Unterverzeichnis. Im Beispiel wurde das Homeverzeichnis des root-Benutzers gewählt.

.
|-- RootCA
|   |-- certs
|   |-- crl
|   |-- newcerts
|   |-- private
|   |--index.txt
|   `--serial
|-- ServerCA
|   |-- certs
|   |-- crl
|   |-- newcerts
|   |-- private
|   |--index.txt
|   `--serial
`-- E-MailCA
    |-- certs
    |-- crl
    |-- newcerts
    |-- private
    |--index.txt
    `--serial

Listing 30.7    CA-Verzeichnisstruktur

Bei der RootCA handelt es sich um die Stammzertifizierungsstelle. Diese stellt das Root-Zertifikat aus, also das oberste Zertifikat der Vertrauenskette. Des Weiteren erzeugt die RootCA Zertifikate für die Unter-CAs (ServerCA und E-MailCA). Fügen Sie das RootCA-Zertifikat (öffentlicher Schlüssel) einem System hinzu, akzeptiert dieses System aufgrund der hierarchischen Struktur alle Zertifikate, die von jedweder Unter-CA erstellt wurden.

Bei ServerCA und E-MailCA handelt es sich um solche Unter-CAs. Diese werden ihren Namen entsprechend eingesetzt: zum einen, um Serverzertifikate, zum Beispiel für Webserver mit HTTPS, zu erstellen, und zum anderen, um E-Mail-Zertifikate zu erstellen, die zum Beispiel von S/MIME eingesetzt werden können.

Die zugrunde liegende Verzeichnisstruktur ist eine (praktische) Vorgabe von OpenSSL. Tabelle 30.4 zeigt die Intention, die dahintersteckt.

Verzeichnis Typ Bedeutung
certs Verzeichnis Speicherort der Zertifikate
crl Verzeichnis Ablage der Zertifikatssperrlisten (CRL-Dateien)
newcerts Verzeichnis Ablage neu erstellter Zertifikate
private Verzeichnis Speicherort der privaten Schlüssel
index.txt Datei Indexdatei der erstellten Zertifikate dieser CA
serial Datei ASCII-Textdatei, die die aktuelle Seriennummer enthält

Tabelle 30.4    CA-Unterverzeichnisse

Zusätzlich müssen in dem CA-Verzeichnis (RootCA, ServerCA und EMailCA) jeweils eine leere index.txt und eine mit einer HEX-Zahl gefüllte Datei serial vorhanden sein. Die Datei index.txt bietet eine Übersicht über die ausgestellten Zertifikate und enthält deren Seriennummer, Gültigkeitszeitraum und aktuellen Status.

Die Datei serial hingegen stellt einen Zählerstand dar, der pro ausgestelltem Zertifikat inkrementiert wird. Der Ausgangswert kann dabei jeder beliebige HEX-Wert sein.

OpenSSL-Konfiguration

Vor dem eigentlichen Erstellen der CA muss die OpenSSL-Konfigurationsdatei Ihrer PKI angepasst werden. Die zentrale Konfigurationsdatei /etc/ssl/openssl.cnf ist in Sektionen unterteilt. Passen Sie die Grundkonfiguration, die die einzige ohne eigene Sektion ist, Ihrer Verzeichnisstruktur an:

HOME = /root/CA

Listing 30.8    Grundkonfiguration

In der Standardkonfiguration ist lediglich eine CA-Sektion enthalten, die CA_default, die auch als Standard-CA in der Sektion ca über den Parameter default_ca gewählt ist. Beim Aufruf von OpenSSL ohne Angabe einer CA wird diese benutzt. Passen Sie diesen Parameter daher an die CA an, in der Sie die meisten Zertifikate erstellen werden.

Damit jede CA ihre eigene Konfiguration bekommt, werden die CAs in eigenen Sektionen angelegt. Erweitern Sie die openssl.cnf um je eine Sektion für die RootCA, die ServerCA und die EMailCA:

[ RootCA ]
dir             = /root/CA/RootCA         # Where everything is kept
certs           = $dir/certs              # Where the issued certs are kept
crl_dir         = $dir/crl                # Where the issued crl are kept
database        = $dir/index.txt          # database index file.
new_certs_dir   = $dir/newcerts           # default place for new certs.
certificate     = $dir/RootCA.cacert.pem  # The CA certificate
serial          = $dir/serial             # The current serial number
crl             = $dir/crl.pem            # The current CRL
private_key     = $dir/private/RootCA.cakey.pem  # The private key
RANDFILE        = $dir/private/.rand      # private random number file
x509_extensions = ca_cert                 # The extentions to add to the cert
name_opt        = ca_default              # Subject Name options
cert_opt        = ca_default              # Certificate field options
crl_extensions  = crl_ext
default_days    = 365                     # how long to certify for
default_crl_days= 30                      # how long before next CRL
default_md      = sha1                    # which md to use.
preserve        = no                      # keep passed DN ordering
policy          = policy_match

Listing 30.9    Sektion »RootCA«

Tabelle 30.5 zeigt, welche Konfigurationen Sie pro CA anpassen müssen.

Parameter Bedeutung
dir Root-Verzeichnis der CA
certificate Root-Zertifikat der CA (RootCA.cacert.pem)
private_key privater Schlüssel der CA (private/RootCA.cakey.pem)
x509_extensions Angabe der Sektion für die X.509-Erweiterungen der CA
default_days Gültigkeitsdauer eines über die CA erstellten Zertifikats in Tagen
policy_match Definition der Regeln für diese CA

Tabelle 30.5    Anzupassende Parameter pro CA

Einer der entscheidenden Parameter ist hierbei x509_extensions. Dieser verweist auf eine weitere Sektion, in der der Verwendungszweck der über diese CA erstellten Zertifikate spezifiziert ist. Erstellen Sie folgende Sektionen, denen Sie den jeweiligen Parameter x509_extensions zuweisen:

[ ca_cert ]
basicConstraints=CA:TRUE
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

[ server_cert ]
basicConstraints=CA:FALSE
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = serverAuth

[ email_cert ]
basicConstraints=CA:FALSE
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = emailProtection

Listing 30.10    Sektion »ca_cert«

Beachten Sie, dass basicConstraints lediglich in der Sektion ca_cert auf CA:TRUE gesetzt ist. Dieser Parameter stellt sicher, dass lediglich über die RootCA CA-Zertifikate erstellt werden können. Ein weiterer wichtiger Parameter ist policy_match. Dieser definiert eine weitere Sektion, in der die Vorgaben für die Erstellung von Zertifikaten hinterlegt sind. Folgende Werte sind in der Standardkonfiguration enthalten:

countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Listing 30.11    Sektion »policy_match«

Die Wertigkeit der einzelnen Parameter kann wie folgt sein:

Passen Sie abschließend in der Sektion req_distinguished_name die Standardwerte für die Zertifikatserstellung Ihren Gegebenheiten an:

countryName_default             = DE
stateOrProvinceName_default     = NRW
0.organizationName_default      = Example Ltd

Listing 30.12    Standardwerte bei der Zertifikatserstellung

Diese Werte werden Ihnen bei jeder Zertifikatserstellung als Default angeboten. Sie können sie durch die Eingabe von (¢) auswählen.

CA erzeugen

OpenSSL erwartet in jeder CA im Verzeichnis private eine Random-Datei mit dem Namen .rand. Diese Datei wird zur Unterstützung bei der Erstellung von Schlüsseln und Zertifikaten durch OpenSSL verwendet. Damit diese Werte definitiv auf jedem System einzigartig sind, müssen Sie sie vorab erzeugen. Erstellen Sie zunächst die Random-Dateien für jede CA:

root@example:~/CA# openssl rand -out RootCA/private/.rand 1024
root@example:~/CA# openssl rand -out ServerCA/private/.rand 1024
root@example:~/CA# openssl rand -out E-MailCA/private/.rand 1024

Listing 30.13    Random-Dateien erstellen

OpenSSL erstellt jeweils eine Datei .rand mit einer Größe von 1024 Bit. Zertifikate können über ein Passwort geschützt werden. Dies ist vor allem bei sensiblen Zertifikaten sinnvoll und bei solchen, die von Benutzern eingesetzt werden. Durch den Passwortschutz erhöhen Sie die Sicherheit um den konzeptionellen Schutz von »Besitz und Wissen«, der zum Beispiel bei rechtswirksamen Abwicklungen über ein Zertifikat vom Gesetzgeber gefordert ist (siehe Abschnitt 30.7, »Rechtliches«).

Das RootCA-Zertifikat stellt solch ein sensibles Zertifikat dar. Viele Empfehlungen zielen darauf ab, das RootCA-Zertifikat am besten auf einem System ohne Netzwerkanschluss und hinter einer abgeschlossenen Tür aufzubewahren. Diese auf den ersten Blick drastische Vorgabe ist aber durchaus gerechtfertigt.

[ ! ]  Wird Ihr RootCA-Zertifikat korrumpiert, ist es jedermann möglich, beliebig viele Zertifikate in Ihrem Namen zu erstellen. Das Ausmaß an Möglichkeiten und Schaden ist fast undenkbar. Sichern Sie Ihr RootCA-Zertifikat daher unbedingt mit einem Passwort ab.

Die Erstellung von Zertifikaten erfolgt dabei stets in drei Schritten:

  1. privaten Schlüssel erzeugen

  2. Zertifikatsanfrage erstellen

  3. Zertifikat zurückerhalten (signierter öffentlicher Schlüssel)

Erstellen Sie zunächst den privaten Schlüssel der RootCA:

root@example:~/CA/RootCA# openssl genrsa -aes256 \
-out private/RootCA.cakey.pem  -rand private/.rand 2048

1024 semi-random bytes loaded
Generating RSA private key, 2048 bit long modulus
.........++++++++++++
.............++++++++++++
e is 65537 (0x10001)
Enter pass phrase for private/RootCA.cakey.pem:
Verifying - Enter pass phrase for private/RootCA.cakey.pem:

Listing 30.14    »RootCA«: privaten Schlüssel erzeugen

Durch die Angabe des Parameters genrsa wird OpenSSL angewiesen, einen RSA Private Key zu erzeugen. Der Parameter -aes256 weist dem privaten Schlüssel nicht nur das AES-Verschlüsselungsverfahren mit 256 Bit Schlüssellänge zu, sondern legt vor allem auch fest, dass dieser Schlüssel passwortgeschützt sein soll. Nach der Angabe des Speicherortes mit -out und der Angabe der Random-Datei mittels -rand wird OpenSSL noch die Schlüssellänge von 2048 Bit mitgeteilt. Abschließend werden Sie aufgefordert, das Passwort für den privaten Schlüssel einzugeben und zu bestätigen. Erstellen Sie anschließend das RootCA-Zertifikat mit folgendem Befehl:

root@example:~/CA/RootCA# openssl req -new -x509 -days 1827 \
-set_serial 00 -key private/RootCA.cakey.pem -out RootCA.cacert.pem

Listing 30.15    »RootCA«: Zertifikat erzeugen

Der Befehl openssl req erstellt eine Zertifikatsanfrage. Da es sich beim RootCA-Zertifikat aber um das oberste Zertifikat dieser Vertrauenskette handelt, kann es von niemandem signiert und zurückgesandt werden. Daher erzeugt der Befehl keine Zertifikatsanfrage, sondern direkt das Zertifikat. Darüber hinaus muss sichergestellt werden, dass das RootCA-Zertifikat das erste ist, was Sie dadurch gewährleisten, dass Sie die hexadezimale Seriennummer mittels -set_serial auf 00 setzen.

Unter-CAs erzeugen

Alle Unter-CAs werden nach dem gleichen Schema erstellt. Exemplarisch wird das Vorgehen anhand der ServerCA demonstriert. Wechseln Sie in das Verzeichnis /root/CA/ServerCA, und führen Sie folgenden Befehl aus:

root@example:~/CA/ServerCA# openssl genrsa -aes256 \
-out private/ServerCA.cakey.pem -rand private/.rand 2048

1024 semi-random bytes loaded
Generating RSA private key, 2048 bit long modulus
..............................+++
..................................................................+++
e is 65537 (0x10001)
Enter pass phrase for private/ServerCA.cakey.pem:
Verifying - Enter pass phrase for private/ServerCA.cakey.pem:

Listing 30.16    »ServerCA«: privaten Schlüssel erstellen

Da es sich um eine CA handelt, wird diese ebenfalls wieder mit einem Passwort versehen (Parameter -aes265). Anschließend wird der Signing Request erzeugt:

root@example:~/CA/ServerCA# openssl req -new \
-key private/ServerCA.cakey.pem -out ServerCA.cacert.req.pem

Enter pass phrase for private/ServerCA.cakey.pem:

Listing 30.17    »ServerCA«: Request erzeugen

Bestätigen Sie die Passwortabfrage mit dem vorher erstellten Passwort für den privaten Schlüssel der RootCA. Die erstellte Datei ServerCA.cacert.req.pem wird nun mit folgendem Befehl von der RootCA signiert:

root@example:~/CA/ServerCA# openssl ca -name RootCA \
-in ServerCA.cacert.req.pem -out ServerCA.cacert.pem

Enter pass phrase for /root/CA/RootCA/private/RootCA.cakey.pem:

Listing 30.18    »ServerCA«: Zertifikat signieren

Wie bereits erläutert wurde, muss für die Signierung der »Nicht-Standard-CA« diese explizit angegeben werden. Dies wurde durch den Parameter -name RootCA erreicht.

[+]  Bedenken Sie, dass nun das Passwort des privaten Schlüssels der RootCA erfragt wird und nicht das Passwort der zuvor gesetzten ServerCA. Diese Passwörter sollten unbedingt unterschiedlich sein.

Beim Betrieb einer PKI sollten Sie einige Konventionen einhalten. Dazu zählt die Archivierung von Zertifikaten. Das soeben erstellte Zertifikat ServerCA.cacert.pem finden Sie ebenfalls, da es von der RootCA ausgestellt wurde, und zwar unter dem dafür vorgesehenen Verzeichnis /root/CA/RootCA/newcerts.

Die Namensgebung entspricht der Seriennummer des Zertifikats. Verschieben Sie dieses nach /root/CA/RootCA/certs/, da es in Benutzung und nicht mehr »neu« ist. Im Betrieb sucht OpenSSL Zertifikate anhand ihres 8-Bit-Hash-Werts. Verlinken Sie daher das Zertifikat mit seinem Hash-Wert als Namen.

root@example:~/CA/RootCA/certs# ln -s 01.pem $(openssl x509 -hash -noout \
-in 01.pem).0
root@example:~/CA/RootCA/certs# ls -l
-rw-r--r-- 1 root root 4806 2018-04-28 19:25 01.pem
lrwxrwxrwx 1 root root    6 2018-04-28 20:37 b189e175.0 -> 01.pem

Listing 30.19    Zertifikat-Hash-Wert-Link erzeugen

Die Dateinamenerweiterung .0 des Links stellt dabei eine Indizierung dar. Wird das Zertifikat neu herausgegeben, so wird dieser Wert inkrementiert. Wiederholen Sie diese Arbeitsschritte zur Erstellung der E-MailCA.

Zertifikate ausstellen

Das Erstellen von Zertifikaten erfolgt wie bereits erläutert immer nach demselben Schema. Exemplarisch wurden in Listing 30.20 die Befehle zur Erstellung eines Serverzertifikats für mail.example.net aufgelistet:

root@example:~/CA/ServerCA# openssl genrsa -out mail.example.net.key.pem \
-rand ./private/.rand 1024

root@example:~/CA/ServerCA# openssl req -new -key mail.example.net.key.pem \
-out mail.example.net.req.pem

root@example:~/CA/ServerCA# openssl ca -name ServerCA \
-in mail.example.net.req.pem -out mail.example.net.cert.pem

root@example:~/CA/ServerCA# mv newcerts/01.pem certs/01.pem

root@example:~/CA/ServerCA# ln -s ln -s 01.pem $(openssl x509 -hash -noout \
-in 01.pem).0

Listing 30.20    Serverzertifikat erzeugen

Jedes über eine CA erstellte Zertifikat wird in der Datei index.txt notiert. Die Datei besteht aus sechs Feldern, die durch je einen Tabulator getrennt sind und dabei die in Tabelle 30.6 dargestellte Bedeutung haben.

Feld-Nr. Wert Bedeutung
1 V Zertifikatsstatus: V (valid), R (revoked) oder E (expired)
2 110928172943Z UTZ-Zeit des Gültigkeitsendes des Zertifikats
(Format: YYMMDDHHMMSSZ)
3 - Widerrufszeit (bei gültigen Zertifikaten leer)
4 01 Seriennummer des Zertifikats
5 unknown Aufbewahrungsort des Zertifikats (wird derzeit immer mit unknown angegeben)
6 /C=DE/ST=NRW/… Subject-Line des Zertifikats

Tabelle 30.6    Felder der »index.txt«

Bei der Erstellung neuer Zertifikate wird jeweils die letzte Version der Dateien index.txt und serial mit der Endung .old versehen und bleibt erhalten.

Zertifikate widerrufen

Beim Widerrufen von Zertifikaten, was man auch als Sperren bezeichnet, wird eine CRL (Certificate Revokation List) rstellt. Diese enthält Informationen zum Zertifikat und dazu, wann dieses für ungültig erklärt wurde. Dies ist sinnvoll, wenn ein Zertifikat verloren gegangen ist, gelöscht oder korrumpiert wurde. Neben den Namenskonventionen sieht der Betrieb einer CA auch das Pflegen der CRLs vor. Sie müssen die CRLs erstellen und über einen Webserver zum Download zur Verfügung stellen. Um Zertifikate zu widerrufen, setzen Sie folgenden Befehl auf das betreffende Zertifikat ab:

root@example:~/CA/ServerCA# openssl ca -revoke certs/01.pem
Enter pass phrase for /root/CA/ServerCA/private/ServerCA.cakey.pem:
Revoking Certificate 09. Data Base Updated

Listing 30.21    Zertifikat widerrufen

OpenSSL setzt das Zertifikat in der Datenbank (index.txt) auf »R« (Revoke = Widerruf) und ergänzt das Feld »Widerrufszeit« (wie in Tabelle 30.6 beschrieben). Die benötigte Widerrufsliste erzeugen Sie mit nachstehendem Befehl:

root@example:~/CA/ServerCA# openssl ca -name ServerCA -gencrl -out crl/crl.pem
Enter pass phrase for /root/CA4/ServerCA/private/ServerCA.cakey.pem:

Listing 30.22    Sperrlisten erzeugen

Die Informationen der CRL können Sie sich ebenfalls mit OpenSSL anzeigen lassen:

root@example:~/CA4/ServerCA# openssl crl -in crl/crl.pem -noout -text
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=DE/ST=NRW/O=Example Ltd/CN=ServerCA/emailAddress=ca@example.net
        Last Update: Sep 29 12:04:50 2010 GMT
        Next Update: Oct 29 12:04:50 2010 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                keyid:33:BA:B6:30:FA:29:18:94:80:87:67:23:EA:D0:7D:81:7E:A1:4B:5B
                DirName:/C=DE/ST=NRW/L=Moers/O=Example Ltd/CN=RootCA/\
                        emailAddress=ca@example.net
                serial:01

Revoked Certificates:
    Serial Number: 09
        Revocation Date: Sep 29 09:26:27 2010 GMT
    Signature Algorithm: …

Listing 30.23    Sperrlisten anzeigen lassen

Unter dem Punkt Revoked Certificates werden alle widerrufenen Zertifikate mit ihrer Seriennummer und dem Datum ihres Widerrufs aufgelistet. Ein erneutes Erstellen der CRL erweitert die Einträge entsprechend.

Weitere nützliche OpenSSL-Funktionen

Neben den bisher gezeigten OpenSSL-Befehlen gibt es eine Reihe weiterer und sehr nützlicher Befehle. In Tabelle 30.7 finden Sie die nützlichsten zusammengefasst.

Befehl Bedeutung
openssl x509 -text -noout -in <CERT> Ausgabe des gesamten Inhalts
openssl x509 -issuer -noout -in <CERT> zeigt den Herausgeber an
openssl x509 -purpose -noout -in <CERT> Ausgabe des Verwendungszwecks
openssl x509 -subject -noout -in <CERT> Ausgabe des »subject«
openssl x509 -hash -noout -in <CERT> Ausgabe des »hash«-Werts
openssl x509 -dates -noout -in <CERT> Ausgabe des Gültigkeitszeitraums
openssl rsa -in <KEY> -out <KEY> entfernt das Passwort eines privaten Schlüssels
openssl rsa -aes256 -in <KEY> -out <KEY> fügt dem privaten Schlüssel ein Passwort hinzu

Tabelle 30.7    OpenSSL-Befehle

30.5.2    E-Mail-Verschlüsselung

Zur Absicherung des E-Mail-Verkehrs finden zwei gängige Methoden Anwendung:

GnuPG

GnuPG wird vermehrt von Privatanwendern genutzt – allein schon aufgrund des Konzepts des Web-of-Trust, in dem jeder jeden über Ecken kennt. Nichtsdestotrotz stellt es eine gut implementierte Lösung zum Signieren und Verschlüsseln von E-Mails dar.

Auch dieses Verfahren setzt auf Zertifikate mit einem öffentlichen und einem privaten Schlüssel. Lediglich die übergeordnete Kopfstelle existiert nicht, da die Authentizität zwischen den Protagonisten selbst geregelt wird.

Durch das Grundprinzip der Vertrauenskette gibt es unterschiedliche Vertrauensstufen. In Tabelle 30.8 sehen Sie die Vertrauensstufen, die Sie vergeben können.

Stufe Bedeutung
unbekannt keine Angaben vorhanden
kein Vertrauen Der Signatur wird NIE vertraut.
geringfügiges Vertrauen Personen, die man nicht persönlich kennt
volles Vertrauen Personen, denen man vollkommen vertraut
ultimatives Vertrauen Diese Stufe findet nur bei einem selbst Anwendung.

Tabelle 30.8    GnuPG-Vertrauensstatus

Bei GnuPG findet der Begriff Schlüsselbund Anwendung. Dies bezieht sich auf die Speicherform der Schlüssel in einem »Klumpen«, also in einer Datei, und nicht – wie es bei einer PKI üblich ist – je Schlüssel/Zertifikat.

Bevor Sie anderen das Vertrauen aussprechen können, benötigen Sie zunächst selbst einen Schlüssel. Diesen können Sie mit GnuPG wie folgt erzeugen:

daniel@example:~# gpg --full-generate-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 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.

gpg: Verzeichnis `/home/daniel/.gnupg' erzeugt
gpg: Neue Konfigurationsdatei `/home/daniel/.gnupg/gpg.conf' erstellt
gpg: WARNUNG: Optionen in `/home/daniel/.gnupg/gpg.conf' sind während
gpg: dieses Laufes noch nicht wirksam
gpg: Schlüsselbund `/home/daniel/.gnupg/secring.gpg' erstellt
gpg: Schlüsselbund `/home/daniel/.gnupg/pubring.gpg' erstellt

Listing 30.24    GnuPG-Schlüssel erzeugen

Bei der ersten Verwendung von gpg werden die Verzeichnisse und benötigten Dateien vorab erstellt. Wählen Sie anschließend den Verwendungszweck und den Verschlüsselungsstandard (siehe Listing 30.25). Der Wert RSA und RSA entspricht dem aktuellen Standard.

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) RSA und RSA (voreingestellt)
   (2) DSA und Elgamal
   (3) DSA (nur unterschreiben/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
Ihre Auswahl? 1

Listing 30.25    GnuPG: Auswahl der Schlüsselart

Wählen Sie anschließend die Länge des Schlüssels (siehe Listing 30.26). Der Standardwert von 2048 Bit Länge entspricht dem aktuellen Standard bei Verschlüsselungsverfahren.

RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (3072)
Die verlangte Schlüssellänge beträgt 3072 Bit

Listing 30.26    GnuPG: Auswahl der Schlüssellänge

Nun können Sie die Gültigkeitsdauer wählen (siehe Listing 30.27). Bedenken Sie, dass ein verloren gegangener Schlüssel zwar widerrufen, mit diesem aber weiterhin gültig verschlüsselt werden kann. Widerstehen Sie daher der Versuchung, den Schlüssel mit unbegrenzter Gültigkeit zu erstellen, und wählen Sie besser einen Wert zwischen zwei und vier Jahren.

Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)
Schlüssel verfällt nie
Ist dies richtig? (j/N) j

Listing 30.27    GnuPG: Auswahl der Gültigkeitsdauer

Auch zu einem gpg-Schlüssel gehören Benutzerangaben. Geben Sie diese entsprechend der Aufforderung an:

Sie benötigen eine User-ID, um Ihren Schlüssel eindeutig zu machen; das
Programm baut diese User-ID aus Ihrem echten Namen, einem Kommentar und
Ihrer E-Mail-Adresse in dieser Form auf:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Ihr Name ("Vorname Nachname"): Max Mustermann
E-Mail-Adresse: mm@example.net
Kommentar:
Sie haben diese User-ID gewählt:
    "Max Mustermann <mm@example.net>"

Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F

Listing 30.28    GnuPG: Angaben zur User-ID

Der private Schlüssel muss mit einem Passwort geschützt werden. Vergeben Sie dieses, und bestätigen Sie es:

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen.

Geben Sie die Passphrase ein:
Geben Sie die Passphrase nochmal ein:

Listing 30.29    GnuPG: Passwort festlegen

Anders als bei der Schlüsselerzeugung mithilfe von OpenSSL hier wird keine Random-Datei verwendet, sondern es werden Zufallswerte aus der gerade laufenden Sitzung extrahiert. Dazu müssen Sie GnuPG unterstützen, wozu Sie auch aufgefordert werden. Geben Sie in einem weiteren Fenster »wilde« Zeichenfolgen ein, und/oder bewegen Sie die Maus.

Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie zum Beispiel in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.

Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere
Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann!
(Es werden noch 284 Byte benötigt.)
+++++
..........................+++++

gpg: /home/daniel/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel 7FE9F522 ist als uneingeschränkt vertrauenswürdig
gpg: gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.

gpg: "Trust-DB" wird überprüft
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0 gültig:   1 signiert:   0 Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/7FE9F522 2018-04-29
      Schl.-Fingerabdruck = 1722 E5A6 15FC C991 F844  1938 CAD6 22AA 7FE9 \
                            F522
uid                  Max Mustermann <mm@example.net>
sub   2048R/74785821 2018-04-29

Listing 30.30    GnuPG: Erzeugung von Zufallswerten

Sind ausreichend viele Zufallszahlen generiert worden, erstellt GnuPG Ihren privaten Schlüssel und legt weitere noch nicht vorhandene Dateien an. Alle von GnuPG angelegten Daten befinden sich im Homeverzeichnis unter dem Verzeichnis .gnupg. Die in Tabelle 30.9 dargestellten Dateien sind dort hinterlegt.

Datei Bedeutung
pubring.gpg Schlüsselbund der öffentlichen Schlüssel und Signaturen
secring.gpg Schlüsselbund des/der eigenen privaten Schlüssel(s)
trustdb.gpg Vertrauensstufe für fremde öffentliche Schlüssel

Tabelle 30.9    GnuPG-Dateien

Entscheidend für das Prinzip des Web-of-Trust ist das Publizieren und Verteilen des eigenen Schlüssels. Exportieren Sie daher als Erstes Ihren öffentlichen Schlüssel:

daniel@example:~# gpg --output max_mustermann.gpg --export mm@example.net

Listing 30.31    GnuPG: Schlüssel exportieren

GnuPG erzeugt nun eine binäre Schlüsseldatei. Der Schlüssel kann ebenfalls als Klartext ausgegeben werden. Verwenden Sie dafür den Schalter -a. Sie können Ihren öffentlichen Schlüssel nun auf Ihrer Website zum Download anbieten oder ihn per E-Mail an Ihre Bekannten verschicken.

Erhalten Sie Schlüssel von Kommunikationspartnern, müssen Sie diese in Ihren Public-Schlüsselbund importieren:

daniel@example:~# gpg --import Ute_Musterfrau.gpg

Listing 30.32    GnuPG: Schlüssel importieren

Dieser Schlüssel wird somit Ihrem »Schlüsselbund« hinzugefügt, sodass dieser durch GnuPG ausgelesen werden kann, um Nachrichten zu verifizieren. Zusätzlich kann diesem Schlüssel jetzt noch das Vertrauen ausgesprochen werden. Dafür bietet GnuPG einen separaten Befehlsmodus. Starten Sie GnuPG mit dem folgenden Parameter:

daniel@example:~# gpg --edit-key um@example.net
gpg (GnuPG) 2.2.4; Copyright (C) 2017 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.

pub  2048R/67B3EB27  erzeugt: 2018-04-30  verfällt: 2018-09-29  Benutzung: SC
                     Vertrauen: unbekannt     Gültigkeit: unbekannt
sub  2048R/C939EF31  erzeugt: 2018-04-30  verfällt: 2018-09-29  Benutzung: E
[ unbekannt] (1). Ute Musterfrau <um@example.net>

Listing 30.33    GnuPG: einem Schlüssel das Vertrauen aussprechen

Der Schlüssel der Person »Ute Musterfrau« steht sowohl bei Vertrauen als auch bei Gültigkeit auf unbekannt. Das Vertrauen können Sie selbst bestimmen. Verwenden Sie dafür den Befehl trust. Anschließend können Sie die Vertrauensstufe zu diesem Schlüssel einstellen. Neben der Möglichkeit, Schlüssel manuell auszutauschen, über E-Mail, einen USB-Stick oder – wie es eine Zeit lang in »Mode« war – auf einer sogenannten Keysigning-Party, können Sie diese auch über Keyserver publizieren.

E-Mail-Verschlüsselung testen

Jeder moderne MTA[ 64 ] bietet die Möglichkeit, GnuPG-Schlüssel zu verarbeiten. Dazu gehören zum Beispiel:

Diese MTAs ermöglichen es Ihnen, komfortabel Ihren Schlüssel und die Schlüssel Ihrer Kommunikationspartner hinzuzufügen und zu verwalten.

Damit Sie den erstellten Schlüssel testen können, wurde vom GNU Privacy Project (GnuPP) der »freundliche E-Mail-Roboter Adele« geschaffen. Senden Sie eine unverschlüsselte E-Mail mit Ihrem öffentlichen Schlüssel (entweder als Klartext in der Mail oder als Anhang) mit dem Betreff »Mein öffentlicher Schlüssel« an adele@gnupp.de. Der E-Mail-Roboter sendet Ihnen daraufhin eine mit Ihrem öffentlichen Schlüssel verschlüsselte E-Mail zurück. In dieser ist der öffentliche Schlüssel von Adele enthalten. Importieren Sie diesen Schlüssel. Dann können Sie Adele selbst eine mit ihrem öffentlichen Schlüssel verschlüsselte Nachricht senden, die sie ebenfalls wieder beantwortet.

Erhalten Sie keine Antwort, sollten Sie Ihren Schlüssel noch einmal genauer unter die Lupe nehmen.

Keyserver

Wie bereits erläutert wurde, findet die effektivste Art des Schlüsselaustauschs über Keyserver statt. Es existiert eine Vielzahl solcher Server; nachstehend eine Auswahl:

[ ! ]  Hochladen von Schlüsseln

Es sei nochmals eindringlich darauf hingewiesen, dass Sie Ihren Schlüssel mit Bedacht publizieren sollten, da Sie einmal hochgeladene Schlüssel nicht einfach entfernen, sondern nur widerrufen können.

Welchen Server Sie verwenden, spielt prinzipiell keine Rolle, da die Keyserver untereinander einen regen Austausch betreiben. Tabelle 30.10 zeigt, welche Befehle beim Umgang mit Keyservern relevant sind.

Befehl Bedeutung
gpg --send-key <KEY-ID> Schlüssel hochladen
gpg --search-keys "Vorname Nachname" nach einem Schlüssel suchen
gpg --recv-keys <KEY-ID> Schlüssel herunterladen
gpg --refresh-keys <KEY-ID> Schlüssel aktualisieren

Tabelle 30.10    »gpg«-Befehle

Widerrufszertifikat

Ist das Kind dann doch in den Brunnen gefallen, hilft nur noch eines: der Widerruf. Da GnuPG auf das Web-of-Trust aufsetzt, sollten Sie den Widerruf nicht nur zum Keyserver senden, sondern auch alle Ihre Kontakte benachrichtigen.

Ein Widerrufszertifikat erstellen Sie wie folgt:

daniel@example:~# gpg --output revoke_7FE9F522.asc --gen-revoke 7FE9F522
sec  2048R/7FE9F522 2018-04-29 Max Mustermann <mm@example.net>
Ein Widerrufszertifikat für diesen Schlüssel erzeugen? (y/N) y

Listing 30.34    GnuPG: Widerrufszertifikat erzeugen

Der Option --gen-revoke wurde dabei als Parameter die Key-ID des betreffenden Schlüssels übergeben. Entspricht die Ausgabe von GnuPG dem Schlüssel, den Sie widerrufen möchten, fahren Sie mit der Eingabe von y fort. Anschließend werden Sie aufgefordert, den Grund für den Widerruf anzugeben. Wählen Sie den entsprechenden Grund aus, und geben Sie falls notwendig noch eine Beschreibung an:

Grund für den Widerruf:
  0 = Kein Grund angegeben
  1 = Hinweis: Dieser Schlüssel ist nicht mehr sicher
  2 = Schlüssel ist überholt
  3 = Schlüssel wird nicht mehr benutzt
  Q = Abbruch
(Wahrscheinlich möchten Sie hier 1 auswählen)
Ihre Auswahl? 1
Geben Sie eine optionale Beschreibung ein. Beenden mit einer leeren Zeile:
> Laptop Diebstahl
>
Grund für Widerruf: Hinweis: Dieser Schlüssel ist nicht mehr sicher
Laptop Diebstahl
Ist das richtig? (y/N) y

Listing 30.35    GnuPG: Grund des Widerrufs

Anschließend müssen Sie das Passwort des Schlüssels angeben:

Sie benötigen einen Passwortsatz, um den geheimen Schlüssel für
Nutzer: "Max Mustermann <mm@example.net>" zu entsperren
2048-Bit RSA Schlüssel, ID 7FE9F522, erstellt 2018-04-29

gpg: GPG-Agent ist in dieser Sitzung nicht vorhanden
Ausgabe mit ASCII Hülle erzwungen
Widerrufszertifikat wurde erzeugt.

Listing 30.36    GnuPG: Passwortabfrage

[ ! ]  Der Haken bei der Erstellung von Widerrufszertifikaten

Zum Erstellen von Widerrufszertifikaten müssen Sie auch über das Zertifikat selbst verfügen. Sie können nur dann ein Widerrufszertifikat erstellen, wenn Sie den entsprechenden Schlüssel auch besitzen! Legen Sie das Widerrufszertifikat also am besten direkt nach der Erstellung an, und sichern Sie dieses gewissenhaft.

Das erstellte Widerrufszertifikat kann nun publiziert werden. Fügen Sie dieses auch Ihrem Schlüsselbund hinzu, damit Sie nicht Opfer Ihres eigenen Schlüssels werden:

daniel@example:~# gpg --import Widerruf_BBF427A7.asc

Listing 30.37    GnuPG: Widerrufszertifikat importieren

S/MIME

Über S/MIME können E-Mails ähnlich wie bei GnuPG signiert und verschlüsselt werden. Hierfür werden zwei Content-Typen zur Verfügung gestellt: zum einen das Multipart/Signed-Format zur Signierung und zum anderen das Multipart/Encrypted-Format zur Verschlüsselung. Anders als bei GnuPG basiert S/MIME auf dem PKI-Prinzip. Daher findet dieses Modell auch eher in Unternehmen Anwendung. Über (kostenpflichtige) öffentliche Zertifikate von TrustCentern können E-Mails ohne Zutun des Nutzers authentifiziert und entschlüsselt werden. Sobald Sie über ein X.509-Zertifikat verfügen, können Sie über alle gängigen MTAs die S/MIME-Signierung/Verschlüsselung konfigurieren.