Schlüssel zum DNS

Inhaltsverzeichnis

Derzeit gibt es zwei etablierte Standards für vertrauenswürdige und verschlüsselte E-Mails: das hierarchisch organisierte S/MIME, welches mit SSL-Zertifikaten nach dem Standard X.509 arbeitet, und OpenPGP, dem im Wesentlichen eine Netz-Struktur, das so genannte Web-Of-Trust, zu Grunde liegt. Insbesondere PGP kämpft jedoch mit einem prinzipiellen Problem: die zuverlässige und vertrauenswürdige Verteilung der öffentlichen Schlüssel.

Zur Validierung einer Signatur benötigt man vertrauenswürdige Schlüssel, was in der Regel noch einige Handarbeit erfordert. Im Falle von PGP liest man sich sogar oft noch bei persönlichen Treffen die Fingerprints vor, um sie mit denen der vorliegenden Schlüssel zu vergleichen. Bei S/MIME stellt sich das Problem, woher man das Zertifikat einer bestimmten Person bekommt, spätestens dann, wenn man ihr eine verschlüsselte E-Mail schicken will.

Für automatisierte Prozessen, wie beispielsweise die Absenderauthentifizierung durch einen E-Mail-Server, sind solche Methoden nicht praktikabel. Neuere Ansätze wie das Sender Policy Framework (SPF) und Yahoos DomainKeys versuchen, dieses Problem mit Hilfe des Domain Name System (DNS) zu beheben. DomainKeys arbeitet anders als SPF dabei zwar auch mit SSL-Zertifikaten, allerdings nur für die Mail-Server selbst.

Blick nach vorn

GnuPG unterstützt ab Version 1.4.3 zwei neue Methoden zur leichteren Validierung von Schlüsseln und Zertifikaten von Endanwendern, die sich in ihren Kernpunkten an den DNS Security Extensions (DNSSEC) und an SPF orientieren: DNS-CERT und die wesentlich einfachere Public Key Association (PKA). Beide nutzen DNS-Erweiterungen, um Zertifikats- und Schlüsselinformationen per DNS zu verteilen.

Die Einzelheiten von DNS-CERT sind im RFC4398[1] (ehemals 2538bis) beschrieben. Im Wesentlichen sieht es die Einführung eines neuen Resource Records (RR) vor, den der Nameserver Bind seit Version 9 von Haus aus unterstützt. Er besteht aus je einem Feld für die Typbezeichnung, das so genannte Tag zur besseren Schlüssel-Identifizierung, den eingesetzten Signaturalgorithmus sowie das Zertifikat selbst.

Der Aufbau eines CERT-RR soll anhand einer Beispiels für Bind9 zur Verteilung eines S/MIME-Zertifikats erläutert werden:

cr.ct.heise.de.  86400  IN CERT PKIX 13735 RSASHA1 (
  MIIFPzCCAyegAwIBAgIDAbTxMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv
  b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
[...]
  ++vtnJWJ7ZcaYk+/FZwEHzVjm6auHcYOK1mjloRkrQpzLz6UfrW11RZv34wA1Jcy
  dIeQ)

An erster Stelle eines RR steht der DNS-Name, auf den er sich bezieht. RFC4398 legt Richtlinien fest, wie er aus den Daten der Zertifikate und Schlüssel abzuleiten ist: Ersetzt man in der E-Mail-Adresse den Klammeraffen durch einen Punkt, erhält man den zugehörigen DNS-Namen. Bei einem realen DNS-Eintrag mit obigem RR ließe sich das Zertifikat für die E-Mail-Adresse cr@ct.heise.de folglich mit dem Befehl host -t cert cr.ct.heise.de abrufen.

Existieren für ein Zertifikat mehrer E-Mail-Adressen, können dafür weitere DNS-Aliase, so genannte CNAMEs, angelegt werden, die auf die Haupt-Domain mit den eigentlichen Daten verweisen. Für PGP-Schlüssel schlägt das RFC außerdem vor, zusätzliche Domainnamen entsprechend der Key-ID beziehungsweise des Fingerabdrucks zu wählen.

Als Time To Live (TTL) wurde im RR explizit ein hoher Wert von 86400 Sekunden angegeben. Nameserver sollen den RR demnach einen Tag lang im Cache behalten, um die zwischen den Servern übertragenen Datenmengen zu reduzieren. IN CERT legt den gewünschten RR-Typ CERT in der Klasse "Internet" fest.

Der Resource-Record CERT

Die nach dem Schlüsselwort CERT stehenden Felder sind typspezifisch. Das erste Feld ist der Typbezeichner und gibt vor, welche Art von Information im CERT-RR enthalten ist:

Wert	Bezeichner	Zertifikatstyp
0		reserviert
1	PKIX	X.509-Zertifikat
2	SPKI	SPKI-Zertifikat
3	PGP	OpenPGP-Schlüsselblock
4	IPKIX	URL eines X.509-Objektes
5	ISPKI	URL eines SPKI-Zertifikats
6	IPGP	Fingerprint und URL eines OpenPGP-Schlüsselblocks
7	ACPKIX	Attribut-Zertifikat
8	IACPKIX	URL eines Attribute-Zertifikats

Der Wertebereich für den Typ beträgt 16 Bit. In diesem gibt es zwar noch eine Handvoll reservierter Typen, doch die anderen rund 65000 sind zur Vergabe durch die IANA freigegeben. Hierbei ist anzumerken, dass Bind je nach eingesetzter Version nicht alle Typbezeichner kennt. Sollte es beim Server-Start zu entsprechenden Fehlermeldungen kommen, lässt sich auch einfach der Dezimalwert angeben. Gleiches gilt übrigens auch für die auf der nächsten Seite beschriebenen Schlüsselalgorithmen.

Tags und Signaturalgorithmen

Tags und Signaturalgorithmen

Das zweite Feld der CERT-RR beinhaltet den so genannten Tag. Er ist 16 Bit lang und berechnet sich wie die in Anhang B von RFC4034 [2] beschriebenen Tags für die DNS Security Extensions. Vereinfacht gesagt ist er eine Art Quersumme über alle 16-Bit-Worte des Zertifikatsblocks. Er dient der zuverlässigeren Unterscheidung, da häufig mehrere Zertifikate für eine E-Mail-Adresse existieren.

Im dritten Feld, das 8 Bit lang ist, ist der verwendeten Signaturalgorithmus kodiert:

Wert	Bezeichner	Signaturalgorithmus
0		reserviert
1	RSAMD5	RSA mit MD5
2	DH	Diffie-Hellman
3	DSA	DSA mit SHA-1
4	ECC	Elliptic Curve
5	RSASHA1	RSA und SHA-1

Die in einem Zertifikat verwendeten Algorithmen lassen sich beispielsweise mit Hilfe des openssl-Kommandos in Erfahrung bringen. Folgendes Kommando liefert die gewünschte Information für ein Zertifikat im PEM-Format:

openssl x509 -text -noout -inform pem \
 -in zertifikat.pem | grep Sig.*Alg

Das letzte Feld des CERT-RR beginnt und endet mit einer runden Klammer und enthält schließlich das eigentliche Zertifikat in Base64-kodierter Form. Wenn das Zertifikat bereits im PEM-Format vorliegt, muss man lediglich die Zeilen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- weglassen. Zur Konvertierung anderer Formate eignet sich ebenfalls das Werkzeug openssl. Die Einrückungen am Beginn einer jeden neuen Zeile sind wichtig. Sie sind durch das Konfigurations-Format von Bind vorgegeben.

Darf es auch etwas automatischer sein?

Mike Schiraldi hat für VeriSign ein Perl-Skript [3] entwickelt, das die Erstellung eines Bind-Kompatiblen CERT-RRs automatisiert. Leider unterstützt es nur den Algorithmentyp RSAMD5 und verwendet vorschriftsmäßig das dritt- und vorletzten Byte des Schlüsselblocks als Tag. Entsprechende Modifikationen wären nicht schwierig, zumal eine Beispielimplementation des neuen Quersummen-Algorithmus in RFC4034 angegeben ist. Doch leider sind die rechtlichen Bedingungen zur Verwendung des Skriptes unklar.

Es geht auch einfacher

Es geht auch einfacher

DNS-CERT verteilt komplette Zertifikate und Schlüssel über die Nameserver. Obwohl sie diese Aufgabe anstandslos bewältigen, sind sie ursprünglich nicht für die Übertragung größerer Datenmengen konzipiert worden. Dies ist beispielsweise auch daran erkennbar, dass das Host-Kommando für DNS-Antworten mit mehr als rund 1500 Bytes in den TCP-Modus wechseln muss und eine entsprechende Fehlermeldung ausgibt. Standardmäßig verwendet DNS UDP. RFC4398 widmet daher dem Performance-Aspekt ein eigenes Kapitel.

Das bislang nur für PGP-Schlüssel eingesetzte und wesentlich einfachere PKA-Verfahren[4] trägt dem Umstand Rechnung, dass diese in der Regel über Keyserver erhältlich sind. Es benutzt deshalb ähnlich dem Sender Policy Framework das TXT-Feld von DNS-Einträgen, um nur die Meta-Informationen Fingerprint und Bezugsquelle zu transportieren. Ein Beispiel-RR für Bind9 sieht folgendermaßen aus:

cr._pka 86400 IN TXT \
"v=pka1;fpr=761D[...]264E;uri=http://intern.heise.de/cr.asc"

Typisch für PKA ist die Einrichtung einer neuen, virtuellen Subdomäne mit den Namen _pka. Um aus einer E-Mail-Adresse die abzufragende Domain zu erhalten, muss man lediglich das @-Zeichen durch ._pka. ersetzen. v=pka1 spezifiziert die derzeit einzige Protokollversion PKAv1. Nach fpr= ist der Fingerabdruck des Schlüssels angegeben und uri= beschreibt die Quelle, unter der der Schlüssel abrufbar ist.

Werner Koch, Geschäftsführer der GnuPGP-Entwicklerfirma g10 Code, betreibt derzeit für seine E-Mail-Adresse werner@fsfe.org einen funktionsfähigen PKA-Eintrag:

$ host -t txt werner._pka.fsfe.org
werner._pka.fsfe.org descriptive text \
  "v=pka1;fpr=A4D94[...]58A2;uri=finger:wk@g10code.com"

Sogar der in der URI angegebene Finger-Server zum Abruf seines PGP-Schlüssels ist mit finger wk@g10code.com erreichbar. Sofern Koch seiner Signatur mit der gpg-Option -N pka-address@gnupg.org=werner@fsfe.org die notwendige PKA-Notation hinzufügt, nimmt GnuPG ab Version 1.4.3 bei Verwendung der Option --auto-key-locate die zur Validierung seiner Signaturen notwendigen Schritte automatisch vor. PKA befindet sich noch allerdings noch in der Entwicklung. Für die Zukunft soll eventuell auch ein eigener Resource Record beantragt werden, um nicht mehr den Umweg über den TXT-RR gehen zu müssen.

Biegen und Brechen

Ansätze wie DNS-CERT und PKA bilden eine sinnvolle Weiterentwicklung sich etablierender Anti-Spam-Technologien wie SPF und DomainKeys. Sie ermöglichen dabei nicht nur die Authentifizierung von E-Mail-Servern, sondern auch der einzelnen Kommunikationspartner. Ein funktionierendes Verteilungssystem für S/MIME-Zertifikate ist ohnehin schon längst überfällig.

Ein großflächiger Einsatz von DNS-CERT und PKA würde das DNS zusätzlicher Belastung aussetzen. Ob es dieser gewachsen ist, bleibt abzuwarten. Ein unerwünschter Effekt bei PKA und DNS-CERT ist darüber hinaus, dass durch die DNS-Anfragen Informationen über die Kommunikationsgewohnheiten der Anwender nach außen gelangen.

Der Pferdefuß einer DNS-basierten Lösung ist jedoch die derzeit mangelhafte Sicherheit des Domain Name System. Der Aufwand für die Fälschung einer Identität reduziert sich auf das Fälschen eines DNS-Eintrags, und manipulierte DNS-Einträge sind leider noch an der Tagesordnung. Daher ist der ernsthafte Einsatz von DNS für die Übertragung kritische Daten keinesfalls zu empfehlen, so lange es keine ausreichende Sicherheit vor Manipulationen bietet. Und bis dahin ist es noch ein langer Weg.

Literatur

[1] Storing Certificates in the Domain Name System (DNS)

[2] Resource Records for the DNS Security Extensions

[3] makecertrrs.pl, Perl-Skript von VeriSign zur CERT-RR-Erstellung

[4] Public Key Association, Hintergrundpaper von Werner Koch (cr)