DNSSEC und DANE: Hilfestellung zur Mail-Verschlüsselung

Fachleute kritisieren zurzeit das eigentlich zuverlässige Mail-Verschlüsselungsverfahren PGP, weil Konzeptschwächen die Verbreitung behindern. Aber auch die bequemere Mail-Verschlüsselung namens S/MIME hat erhebliche Schwächen. DNSSEC und DANE, zwei miteinander kombinierte Verfahren, versprechen Abhilfe.

24.06.2015, 16:14 Uhr

Lesezeit: 10 Min.

c't Magazin

Von

Carsten Strotmann

DNSSEC und DANE: Hilfestellung zur Mail-Verschlüsselung

DNSSEC und DANE: Hilfestellung zur Mail-Verschlüsselung

Obwohl es heute zahlreiche vertrauenswürdige Verschlüsselungstechniken gibt, sind sie in der Mail-Kommunikation wenig gebräuchlich. Das hat vielfältige Gründe. PGP, Pretty Good Privacy, schiebt die Verwaltung der Schlüssel auf den Anwender ab. Nutzer müssen sich nicht nur um ihre eigenen Schlüssel kümmern, sondern auch um die aller Leute, denen sie Mails schicken wollen. Obendrein sieht PGP keine Prüfung der auf Key-Servern hochgeladenen öffentlichen Schlüssel vor, sodass beliebige Nutzer eigene Schlüssel zu fremden Mail-Adressen veröffentlichen können. Mails, die mit solchen Keys verschlüsselt sind, kann der rechtmäßige Eigner einer Mail-Adresse nicht entschlüsseln. Und er kann die Störungen auch nicht verhindern (Die Schlüssel-Falle, Gefälschte PGP-Keys im Umlauf, c't 6/15, S. 160, kostenpflichtiger Download).

Schwächen von PGP und S/MIME

Die Alternative S/MIME (Secure/Multipurpose Internet Mail Extensions) ist deutlich bequemer. Wie bei PGP generiert der User seine Schlüssel zwar normalerweise auch selbst, aber das geschieht automatisiert, wenn man den Web-Service einer Certificate Authority in Anspruch nimmt (die meisten Desktop-Webbrowser haben dafür Krypto-Funktionen an Bord). Die CA signiert den Schlüssel auch, sodass man am Ende ein S/MIME-Zertifikat auf dem Rechner hat. Dieses Zertifikat soll eigentlich die automatisierte Identitätsprüfung ermöglichen.

Doch ob ein Schlüssel tatsächlich zur angegebenen Mail-Adresse gehört, prüfen die Unternehmen oft nur rudimentär. Viele stellen bloß sicher, dass ein Schlüssel zu einer bestimmten Mail-Adresse gehört. Angreifer, die die Kontrolle über ein Mail-Konto erlangen, können sich daher selbst S/MIME-Zertifikate ausstellen und danach die Spuren, die in der Inbox des Eigners zurückbleiben, einfach löschen (Prüfungs- und Erfolgs-Mails).

Eine noch größere Schwäche des S/MIME-Konzepts besteht darin, dass jede CA der Welt technisch korrekte Zertifikate für beliebige Mail-Adressen erzeugen darf. Angreifer, die die Kontrolle über eine CA erlangen, können so beliebige Zertifikate erzeugen (und korrekte per Update rauskegeln). Außerdem können CAs auch unter Kontrolle von Staaten stehen, die Zertifikate zum Abhören von Internet-Nutzern missbrauchen.

Dasselbe Problem haben auch Betreiber von Web- und SMTP-Servern: Auch sie setzen digitale Zertifikate von denselben CAs ein – und wiederum kann jede CA der Welt für jeden Server beliebige Zertifikate erzeugen – die Server können nicht feststellen, ob ein technisch korrektes CA-Zertifikat tatsächlich zur Gegenstelle gehört, die es nutzt.

Eine Hierarchie statt Inseln

Wie Mail-Clients OPENPGPKEY und DNSSEC nutzen: Das Zusammenspiel zwischen Mail-Client und dem DNS startet mit einer Anfrage (1, 2) an das DNS nach dem OPENPGPKEY zur Ziel-Mail-Adresse. Der zuständige DNS-Server liefert den zugehörigen Ressource-Record (3). Den RR reicht ein DNSSEC-fähiger Resolver nach Validierung an den Mail-Client weiter (4, 5). Der Cient entnimmt den PGP-Schlüssel, verschlüsselt und verschickt die Mail (6).

Entwickler, die in der Internet Engineering Task Force zusammenarbeiten, haben daher Lösungsvorschläge entwickelt, die diese Konzeptschwächen beseitigen können. Sie setzen auf DNS Security Extensions (DNSSEC). DNSSEC ist eine Erweiterung des Domain Name System, die DNS-Daten kryptografisch gegen Fälschungen absichert und die Quelle der DNS-Daten authentisiert.

Das Domain Name System ist ein weltweit verteilter hierarchisch organisierter Verzeichnisdienst, der den Namensraum des Internet verwaltet und die Domainnamen zu IP-Adressen auflöst. Der Namensraum besteht aus unabhängig verwalteten Zonen. DNSSEC verknüpft die einzelnen Zonen zu Vertrauensketten (Chains of Trust).

Dabei enthält die oben in der Hierarchie angesiedelte Zone die signierten Hashes der öffentlichen Schlüssel der darunterliegenden Zonen, sie sind als authentisch markiert. Damit können Clients prüfen, ob die Schlüssel der darunterliegenden Zonen korrekt sind. Das Prinzip setzt sich auf jeder darunterliegenden Hierarchiestufe fort: Die übergeordnete Zone signiert und publiziert die Hashes der direkt untergeordneten, also delegierten Zonen.

DNSSEC-Vertrauensketten

Ein DNSSEC-Client oder Resolver, der eine per DNSSEC abgesicherte DNS-Antwort erhält, prüft zunächst, ob die Information unverfälscht ist. Dazu vergleicht er den in der DNS-Antwort mitgeschickten Hash-Wert mit dem selbst berechneten. Sind beide gleich, prüft er die gesamte Signaturkette aufwärts, indem er jede einzelne Signatur gegenrechnet; er folgt so der Vertrauenskette bis zum in der Konfiguration hinterlegten Schlüssel hinauf (Trust Anchor).

Dies ist in der letzten Instanz, wenn keine Schlüssel der unteren Hierarchiestufen hinterlegt wurden, der IANA-Root-Key. Dieser Schlüssel lässt sich durch Gegenrechnen der Signatur prüfen; er hat ja keine übergeordnete Instanz, also auch keine Signatur. Daher prüft ein Administrator einen solchen Key vor der Einrichtung manuell, etwa indem er von der IANA veröffentlichte Hashes gegenrechnet.

Diese, schon ansehnlich gewachsene Infrastruktur lässt sich auch zum Verteilen von ganz anderen Daten als den DNSSEC-spezifischen nutzen. Dafür gibt es die DANE-Protokollfamilie (DNS-Based Authentication of Named Entities). Solche Erweiterungen sind möglich, weil sich in Zonen nicht nur IP-Adressen, sondern auch andere Informationen speichern lassen; für jeden Datentyp gibt es eigene Spezifikationen (Resource Records, RR).

DANE/TLSA ist eine erste Anwendung, die auf DNSSEC aufsetzt. Damit validieren SMTP-Mail-Server ihre TLS-Zertifikate gegenseitig (Transport Layer Security). Die Zuordnung zwischen TLS-Zertifikat und Domain übernimmt der Verwalter der jeweiligen Domain – vereinfacht gesagt, trägt er dafür in die entsprechende Zonen-Datei einen TLSA RR ein. Die Technik ist bereits im Einsatz, weltweit gibt es inzwischen etliche SMTP-Server, die mittels DANE/TLSA gegenseitig ihre Authentizität feststellen.

Dieses Konzept lässt sich leicht erweitern, um eine Mail-Adresse an einen Benutzerschlüssel zu binden. DANE/SMIMEA und DANE/OPENPGPKEY legen fest, wie S/MIME-Fingerprints (Hashes) und OpenPGP-Schlüssel im DNSSEC hinterlegt werden. Auf ganz ähnliche Art publiziert man auch SSH- oder IPSec-VPN-Schlüssel im DNSSEC.

Vorteile

Die Vorteile liegen auf der Hand: Schlüssel lassen sich umgehend online abrufen, sie können nur von einer Stelle publiziert werden und die Eigner behalten die Kontrolle darüber, können Schlüssel also auch ersetzen oder entfernen.

Aber DNSSEC dient beiden Verfahren für verschiedene Zwecke: Mittels OPENPGPKEY werden in den Zonen ganze Schlüssel deponiert und DNSSEC dient als vertrauenswürdige Verteilungsinfrastruktur. Mittels SMIMEA legt man lediglich den (vom Besitzer des Zertifikats erzeugten) Fingerprint (Hash) des S/MIME-Schlüssels in der Zone ab. Den nutzen Mail-Clients zur Validierung des öffentlichen Schlüssels, den sie automatisch in einer S/MIME-signierten Mail vom entfernten Teilnehmer erhalten.

Wie Mail-Cients SMIMEA und DNSSEC nutzen: S/MIME-fähige Mail-Clients signieren Mails automatisch und senden den öffentlichen Schlüssel gleich mit (1). Der Empfänger-Mail-Client fragt im DNS nach dem SMIMEA- Record der Absenderadresse (2, 3). Der Resolver validiert und reicht die Antwort des DNS-Servers an den Client weiter (4, 5). Wenn die aus dem DNS und der Mail erhaltenen Fingerprints identisch sind, verschlüsselt der Client die Mail und schickt sie ab (6, 7).

Die Ressource Records für SMIMEA und OPENPGPKEY sind im Aufbau gleich (hier der Entwurf des RFC für DANE/OPENPGPKEY und hier der Entwurf des RFC für DANE/SMIME). Dabei wird eine Mail-Adresse einer Domain zugeordnet. Dazu sind kleine Klimmzüge erforderlich, denn während im lokalen Teil der Mail-Adresse (die Zeichenkette vor dem „@“) Sonderzeichen wie Punkte als Teil eines Labels erlaubt sind, dienen Punkte im DNS als Label-Trenner. Deshalb werden lokale Teile der Mail-Adresse nicht im Klartext im RR abgelegt, sondern als hexadezimaler Hash abgebildet. Ursprünglich haben die Entwickler dafür SHA2-224 herangezogen, aber dieses Verfahren ist wenig erprobt und fehlt in Microsofts Crypto-API. Deshalb kommt nun SHA-256 zum Einsatz. Weil dieses Verfahren zu lange Zeichenketten liefert, wird alles ab dem 28. Octet abgeschnitten.

Darauf folgen ein Selektor („_openpgpkey“ oder „_smimecert“) sowie der Domain-Name der E-Mail-Adresse; das @-Zeichen wird nicht berücksichtigt. Ein Beispiel für einen OPEN- PGPKEY-Record sieht so aus:

6971dc5600f51bb6d27e12031b41121566e4179e525f67 eefb8eb0d8._openpgpkey.example.com. IN OPENPGPKEY <PGP-KEY>

Im Detail gibt es kleine Unterschiede zwischen den beiden RR-Typen. OPENPGPKEY bindet einen Schlüssel an eine Domain. SMIMEA bindet wahlweise das gesamte S/MIME-Zertifikat oder den Hash eines S/MIME-Zertifikats an eine Domain. Das kann sowohl der Hash eines Benutzer-, als auch eines Intermediate- oder Root-Zertifikats sein. Außerdem können Organisationen mittels DNS-Wildcards Root-Zertifikate für alle ihre Nutzer auf einen Schlag publizieren (z. B. „*._smimecert.example.com“). Beiden ist aber gemeinsam, dass PGP-Schlüssel und SMIME-Hashes nicht ohne Einverständnis des Eigners der Mail-Adresse eingetragen oder ersetzt werden dürfen. Auch dürfen die Einträge nicht länger gecachet werden, als es der zugehörige TTL-Eintrag vorgibt.

Die beiden Spezifikationen sind noch nicht ganz fertig, aber interessierte Administratoren können schon erste Erfahrungen sammeln. Beispielsweise kann man mit dem Kommandozeilenwerkzeug openpgpkey OPENPGPKEY- Records erstellen und auch PGP-Schlüssel per DNSSEC abrufen. Das Tool gehört zum Hash-Slinger-Paket der Linux-Distribution Fedora!!!. Ein Beispiel für den Abruf, bei dem der Schlüssel zugleich in die GPG-Konfiguration des lokalen Nutzers eingelesen wird, sieht so aus:

openpgpgkey --fetch max.Mustermann@example.com |— gpg --import

Fernziele

DANE/OPENPGPKEY erschwert das Fälschen von Schlüsseln, denn innerhalb der Domain kann nur der Domain-Inhaber Schlüssel publizieren. Außerdem beziehen die für DANE/OPENPGPKEY ausgelegten Tools die Schlüssel automatisch nur aus der angefragten Domain. Mittelfristig ist daher vorstellbar, dass bisher übliche Key-Server überflüssig werden und damit eine Quelle von unrechtmäßig veröffentlichten Schlüsseln versiegt.
Die Arbeiten an DANE/OPENPGPKEY könnten im ersten Halbjahr 2015 abgeschlossen sein. Mit Mail.de gibt es bereits einen ersten Provider in Deutschland, der die Technik einsetzt. Was noch zu einer komfortablen Lösung fehlt, sind Tools, die das Beziehen und Prüfen von Schlüsseln automatisieren, sodass das niemand mehr per Hand machen muss.

Wer die Technik auf seiner Domain einsetzen will, braucht nicht nur signierte Zonen, sondern auch bestimmte DNS-Server. Der verbreitete BIND kann ab den Versionen 9.10.2 und 9.9.7 mit OPENPGPKEY-Records umgehen.

Außerdem sollte man prüfen, ob DNSSEC mittels NSEC- oder den verbesserten NSEC3- Records implementiert ist (Denial of Existence). NSEC lässt sich nämlich für Zone-Walking nutzen, also um alle registrierten Domains einer Zone abzufragen. Wenn eine mit NSEC eingerichtete Zone auch OPENPGPKEY- oder SMIMEA-Records enthält, lassen sich entsprechend auch alle Mail-Adressen einer Domain ermitteln. Um das zu vermeiden, sollte man NSEC3 verwenden, welches Zone-Walking so weit erschwert, dass die Methode für Spammer uninteressant wird.

(dz)