PGP-Schlüssel einfach und sicher verteilen

Abstract

Die PGP-Schlüsselserver waren eine Ad-hoc-Lösung der PGP-Benutzer der ersten Stunde. Das Verfahren ist kompliziert und bietet unnötig Angriffsfläche. OPENPGPKEYS, ein RFC kurz vor der Verabschiedung, hat das Zeug, diesen Anachronismus durch ein einfaches uns sicheres Verteilverfahren zu ersetzen. In meinem Post gehe ich auf die Vor- und Nachteile ein und zeige, wie wir bei sys4 OPENPGPKEYS nutzen.

Note

2015-05-14 Anpassung des Textes an die dritte Version des Internet Drafts (draft-ietf-dane-openpgpkey-03)

"PGP ist kaputt!" So kann man das Editorial und den Artikel Die Schlüssel-Falle, Gefälschte PGP-Keys im Umlauf von Jürgen Schmidt (c't) in einem Satz zusammenfassen. Die Kritik ist berechtigt. Die Schlüsselverteilung ist eine Schwachstelle im PGP-System. PGP selbst (und auch der IETF-Standard OPENPGP) hat die Schlüsselverteilung nie definiert.

PGP-Anfänger und auch langjährige Benutzer sind mit der manuellen Prüfung von Schlüsseln überfordert. Die PGP-Schlüsselserver waren eine Ad-hoc-Lösung der PGP-Benutzer der ersten Stunden. Sie wälzt die Prüfung der Schlüssel ganz auf die Benutzer ab und gestattet das Einstellen von Schlüsseln für fremde E-Mail-Adressen (im c't Artikel "gefälschte Schlüssel" genannt).

Dieses System hat mehrere Schwachstellen in der Benutzbarkeit. Es versucht nicht, eine Fehlbedienung durch den Benutzer zu verhindern. In einem Sicherheitsprotokoll wie PGP ist eine Fehlbedienung fatal. Sie bricht die Sicherheit des Systems, ohne dass dies dem Benutzer bewusst wird. In Sicherheitssoftware ist eine solche Möglichkeit einer Fehlbedienung ein schwerer Fehler und sollte mit der gleichen Priorität behandelt und beseitigt werden wie ein Software-Fehler (z.B. Buffer-Overflow oder schlechte Zufallszahlen).

Das PGP-System ist nicht kaputt. Die Benutzbarkeit muss verbessert werden!

Ein Ansatz, den Schlüsselaustausch im PGP-System sicherer und für den Benutzer einfacher zu gestalten, ist der OPENPGPKEY-Draft der IETF. Mit der dort beschriebenen Methode kann der Besitzer einer E-Mail-Adresse den zur Adresse passenden (öffentlichen) PGP-Schlüssel im DNS veröffentlichen.

Die DNS-Zone sollte dazu mit DNSSEC abgesichert sein, damit sichergestellt ist, dass die Key-Informationen wirklich vom Schlüsselbesitzer stammen. DNSSEC authentiziert den Domain-Besitzer als Autor der DNS-Daten, hier des PGP-Keys.

Note

OPENPGPKEY vereinfacht das Finden und Laden eines PGP-Schlüssels in den eigenen Schlüsselring. Die Methode ersetzt aber nicht die Prüfung des Schlüssels. Der Anwender sollte auf jeden Fall den per OPENPGPKEY geladenen Schlüssel mittels des Web of Trust oder anderer Verfahren prüfen. Auch bei dieser Prüfung müssen Programme den Benutzer besser unterstützen, als es mit den bisherigen Werkzeugen möglich ist. Dies ist eine weitere "Baustelle" im PGP-System.

Die Vorteile

Eine Mail-Anwendung, die PGP unterstützt, kann die PGP-Schlüssel-Informationen über eine DNS-Anfrage ermitteln und die Quelle der Daten über DNSSEC prüfen. Verglichen mit den PGP-Schlüsselservern hat dieses System einige Vorteile:

Eine autorisierte Stelle
Gegenwärtig kann jeder für jeden PGP-Schlüssel publizieren. Genau das war im Fall von Jürgen Schmidt geschehen und wurde zum Anlass für diesen Artikel. OPENPGPKEY verhindert das effektiv. Es macht die DNS-Zone, zu der die E-Mail-Adresse des Empfängers gehört, zur autorisierten Instanz für Auskünfte zu PGP-Schlüsseln. Nur der Besitzer der DNS-Domain kann die PGP-Schlüssel publizieren.
Saubere Schlüsselverwaltung
Der Besitzer der DNS-Domain kann dort aufgeführte PGP-Schlüssel jederzeit entfernen oder ersetzen. Dies ist bei den heute eingesetzten PGP-Schlüsselservern nicht möglich und stellt ein gängiges Problem dar. Alte PGP-Schlüssel ohne Ablaufdatum, deren Passphrase beispielsweise vergessen wurde, können nicht entfernt werden. Sie liegen nun für die Ewigkeit auf den PGP-Schlüsselservern. Ein Fehler, den auch der Autor dieses Artikels bei den ersten Gehversuchen mit PGP gemacht hat...
Bewährte Technologie
Die Abfrage der Schlüssel über DNS ist nicht aufwendig. Sie kann einfach in bestehende Anwendungen implementiert werden.

Wie funktioniert OPENPGPKEY?

OPENPGPKEY speichert den vollständigen, öffentlichen Teil des PGP-Schlüssels in einer DNS-Zone. Dieser Teil wird der E-Mail-Adresse des Schlüsselbesitzers über einen OPENPGPKEY Resource Record (RR) zugeordnet. Die E-Mail-Adresse wird aber nicht "einfach so" gelistet, sondern nach einem bestimmten Schema.

Das Schema setzt sich zusammen aus:

  • den ersten 28 Bytes aus einem SHA256 Hash (hexadezimal) des local part der E-Mail-Adresse (dem Teil vor dem @)
  • dem Sub-Domain-Selektor _openpgpkey
  • und der Domain der E-Mail-Adresse

Für die E-Mail-Adresse cs@sys4.de ergibt sich damit z.B. folgender OPENGPGKEY record:

3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de
|                                                       |           |        |
|                28 Byte des SHA256 Hash                | selector  | domain |

Der OPENPGKEY Record kann einfach mit dem Kommandozeilenprogramm hash-slinger (als Paket in Fedora und anderen Linux-Distributionen vorhanden) erstellt werden:

# openpgpkey --create cs@sys4.de

Note

Debian und Ubuntu-Anwender aufgepasst! Für den Einsatz in diesen Distributionen ist (noch) ein Patch einer Python-Library erforderlich. Näheres beschreibt Paul Wouters im hash-slinger-Repo.

Note

Im Artikel OPENPGPKEY mit Unix Bordmitteln beschreibe ich, wie OPENPGPKEY Record nur mit Unix-Bordmitteln erstellt werden können.

Der ausgegebene DNS-Record wird dann in der DNS-Zone publiziert und die Zone per DNSSEC signiert.

DNS Record Typ

Für den OPENPGPKEY-Record wurde ein eigener DNS-Record-Typ verabschiedet. Es ist der DNS-Record-Typ 61. Ältere Nameserver kennen diesen Record-Typ verständlicherweise noch nicht. Benutzer älterer BIND-9-Versionen oder anderer DNS-Server, welche den OPENPGPKEY-Record noch nicht unterstützen, müssen die Daten in der generischen Kodierung für DNS-Records (siehe: RFC 3597 - "Handling of Unknown DNS Resource Record (RR) Types") in der DNS-Zone eintragen.

Note

OPENPGPKEY-Records werden von BIND 9 DNS-Server ab den Versionen 9.10.2 und 9.9.7 unterstützt.

Für das Tool von Paul Wouters ist beides kein Problem. Es kann beide Versionen – generic ist Typ 61 und rfc entspricht dem neuen OPENPGPKEY – erzeugen:

openpgpkey --create --output generic cs@sys4.de
; keyid: 38CECA690C6A6A6E
3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de. \
    IN TYPE61 \# 3340 <PGPKEY>

openpgpkey --create --output rfc cs@sys4.de
; keyid: 38CECA690C6A6A6E
3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de. \
    IN OPENPGPKEY <PGPKEY>

Mit der Erstellung dieser RRs liegen die Informationen passend vor, um PGP nun einfacher zu gestalten.

Note

Kann man das schon einsetzen? OPENPGPKEY befindet sich auf der Zielgeraden zum IETF-Standard. Der sogenannte WGLC (Working Group Last Call) steht unmittelbar bevor. Ich erwarte, dass die Arbeiten im ersten Halbjahr 2015 abgeschlossen werden und OPENPGPKEY als RFC-Dokument veröffentlicht wird.

Schlüsselpflege sys4-style

OPENPGPKEY vereinfacht und sichert die Schlüsselverteilung für Nutzer, aber nicht für deren Anbieter. Wir haben OPENPGPKEY bei sys4 in Betrieb. Uns war wichtig, dass die Besitzer der Schlüssel ihre Schlüssel jederzeit selbstständig aktualisieren können. Sie sollten nicht auf einen DNS-Administrator oder ein DNS-Provisionierungssystem angewiesen sein.

Die Zone sys4.de ist eine per statischer Zonen-Datei administrierte Zone. Sie wird auf einem hidden Master DNS-Server gepflegt. Beide Eckpunkte, statische Administration und hidden Master, sollten erhalten bleiben. Wir haben deshalb die Sub-Domain _openpgpkey auf einen DNS-Server delegiert. Dort ist sie als dynamische Master-Zone so eingebunden, dass direkt im Internet aktualisiert werden kann.

In der Hauptzone sys4.de steht dazu in der Zonen-Datei:

$ORIGIN sys4.de.
_openpgpkey    IN NS danens1.sys4.de.
               IN NS danens2.sys4.de.
               IN DS 57961 8 2 (
                     608C7B2A38C3330AAFD0DC079BDD56362F80C69A68FE
                     9F85304F67C91EF34A85 )

Als Master-DNS-Server für die neue Zone _openpgpkey.sys4.de. kommt ein BIND 9 9.10.2 Server zum Einsazu, der schon mit den neuen OPENPGPKEY RRs umgehen kann. Dort ist die Zone als dynamische Zone eingetragen:

zone "_openpgpgkey.sys4.de" {
  type master;
  auto-dnssec maintain;
  update-policy { grant *._openpgpkey.sys4.de. self *._openpgpkey.sys4.de.;  };
  file "master/_openpgpkey.sys4.de";
};

Die so formulierte update-policy erlaubt einem Besitzer eines in der BIND-9-Konfiguration hinterlegten TSIG-Schlüssels einen Record zu ändern. Der Besitzer darf seinen eigenen Eintrag – über ein dynamisches Update – erstellen, ändern und löschen. Vorausgesetzt er wendet das auf den gleichen Domain-Namen an, auf den der TSIG-Schlüssels (self) ausgestellt wurde.

Dazu hat der Administrator der _openpgpkey-Zone für jeden Mitarbeiter einen eigenen TSIG-Schlüssel mit dem Namen des OPENPGPKEY-Records des Mitarbeiters erzeugt (Befehl für BIND 9.9.x):

# dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST \
    3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de.

oder mit BIND 9.10.x:

# tsig-keygen 3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de.

TSIG-Schlüssel sind symmetrische Schlüssel; der erstellte Schlüssel wird dem Mitarbeiter auf sicherem Wege zugestellt und in der BIND 9 named.conf eingetragen:

key "3b8b91c75627be...20a3eab2520bcff8d26c8715._openpgpkey.sys4.de." {
   algorithm HMAC-SHA256;
   secret "<secret-key-data>";
};

Note

Auf Dauer wollen wir die symmetrischen TSIG-Schlüssel durch asymmetrische SIG(0)-Schlüssel ersetzen, so dass die Mitarbeiter auch ihre DNS-Update-Schlüssel ohne Zutun des DNS-Administrators selbst verwalten können. Mehr dazu in einem späteren Blog-Post.

Wir können nun mit dem BIND-9-Programm nsupdate (BIND 9.9.7, BIND 9.10.2 oder neuer) die eigenen OPENPGPKEY-Record-Daten ändern. Das folgende Script hilft uns dabei. Es automatisiert den Export des öffentlichen Schlüssels, generiert den OPENPGPKEY-RR und führt die Kommandos aus, um den neuen Eintrag an den DNS-Server zu übermitteln:

#!/bin/sh
# Usage: openpgpkey-update <email-address> <tsig-key-file>

# generate the OPENPGPKEY record using the openpgpkey command from
# hash-slinger
openpgpkeyrr=$(openpgpkey --create --output rfc $1 | tail -1)

# get the domain name of the resource record
domain=$(echo $openpgpkeyrr | cut -d " " -f 1)

# send the DNS update
# requires nsupdate 9.9.7, 9.10.2 or newer
nsupdate -k $2 << EOF
ttl 3600
del $domain OPENPGPKEY
add $openpgpkeyrr
send
quit
EOF

Caution!

Das Kommando nsupdate ist bis zur Version 9.9.6-P2 auf die Übermittlung 4K großer Einträge limitiert. Weil PGP-Schlüssel aber schnell mal größer als 4K werden, kommt es hier zu Problemen. Ein Update mit derart limitierten nsupdate-Versionen schlägt fehl (siehe auch: size limit on RDATA in nsupdate). In BIND 9.10.x und 9.9.7 wurde der Buffer in nsupdate für Records auf 128K vergrößert. Das sollte auch für PGP-Keys mit vielen Unterschriften ausreichen.

Beispiel-Aufruf des Scripts:

./openpgpkey-update cs@sys4.de cs-openpgp.tsig

Die TSIG-Schlüssel-Datei cs-openpgp.tsig:

key "3b8b91c75627bee566dcb88f4805901b20a3eab2520bcff8d26c8715._openpgpkey.sys4.de." {
        algorithm hmac-sha256;
        secret "<secret-tsig-key>";
};

Wir versuchen die DNS-Update Funktion direkt im Befehl openpgpkey des hash-slinger-Paketes zu implementieren, so dass ein extra Script und auch nsupdate nicht notwendig sind.

OPENPGPKEY benutzen

OPENPGPKEY ist ein Glied in einer Kette verschiedener Maßnahmen, die Nutzung von PGP sicherer und anwenderfreundlicher zu gestalten. Nur wenige Produkte unterstützen OPENPGPKEY heute.

Sicherer ist die Beschaffung des Schlüssels schon heute. Mit dem Befehl openpgpkey kann ein PGP-Schlüssel aus dem DNS gelesen und in GNU-Privacy-Guard eingespielt werden. Dabei prüft der openpgpkey-Befehl, ob die empfangenen Daten erfolgreich per DNSSEC validiert wurden und somit vertrauenswürdig sind:

$ openpgpkey --fetch cs@sys4.de | gpg --import

Wer Verschlüsselung automatisieren möchte, sieht sich den OPENPGPKEY-Milter an. Dieser Milter kann z.B. in einen Postfix- oder Sendmail-Mailserver eingebunden werden. Dort prüft er bei jeder noch nicht mit PGP verschlüsselten E-Mail, ob OPENPGPKEY-Daten für die Emfänger der E-Mail vorhanden sind.

Sind OPENPGPKEY-Daten über entsprechende OPENPGPKEY-RRs im DNS des Empfängers, lädt der Milter die Daten und verschlüsselt die E-Mail mit den PGP-Schlüsseln der Empfänger. Dies passiert transparent und ohne Eingriffe durch den E-Mail-Benutzer. Der Benutzer muss sich nicht um die Verwaltung der PGP-Schlüssel kümmern und kann trotzdem von der Sicherheit des PGP-Systems profitieren.

PGP muss erwachsen werden!

PGP ist nicht tot. PGP mit den bisher vorhandenen Werkzeugen und Schlüssel-Verteil-Protokollen ist nicht benutzerfreundlich. Es ist keine universelle Verschlüsselungslösung. Die Teilnehmer der IETF arbeiten an Protokoll-Erweiterungen, um die Benutzung von PGP zu erleichtern und damit die Sicherheit zu erhöhen.

Damit diese neuen Protokolle und Erweiterungen ein Erfolg werden, müssen diese in möglichst vielen Produkten eingebaut werden. Uns Anwendern kommt die Aufgabe zu, die neuen Funktionen und Verbesserungen bei den Programmierern und Herstellern einzufordern (bzw. bei freier und Open-Source-Software selbst zu implementieren oder die Projekte zu unterstützen).

Carsten Strotmann, 26. February 2015