Beschreibung der VVV-Lösung
Anwendungsfälle, Komponenten und Prozesse
24. Januar 2017
Zusammenfassung
Dieses Dokument beschreibt das VVV-Verfahren auf Grundlage von „DNS
Security Extensions“ (DNSSEC), „DNS-based Authentication of Named Entities (DANE)“ und „DNS Service Resource Records (SRV-RRs)“. Mit VVV
können die Sender von verschlüsselten Nachrichten auf einfache Weise Zugang zu vertrauenswürdigen Schlüsseln der gewünschten Empfänger erhalten.
Die Betreiber des „Domain Name Systems“ (DNS) senden dazu neben der
IP-Adresse weitere verbindliche mit DNSSEC und DANE gesicherte Informationen über die unterstützten Verschlüsselungsverfahren und den zugehörigen Schlüsselverzeichnissen der gefragten Internet-Domain an den anfragenden
Nutzer. Um diese Informationen zu nutzen, stellt das VVV-Verfahren Erweiterungen (Plugins) für den Mail-Client Thunderbird und die Mail-Komponente
Open-Xchange zur Verfügung. Die VVV-Plugins sorgen dafür, dass die für eine Mail-Kommunikation benötigte Verschlüsselungsverfahren (S/MIME und
OpenPGP) und die zugehörigen öffentlichen Schlüssel der Kommunikationspartner automatisch ermittelt werden („Public-Key-Pull-Funktionalität“). Dazu
ist ausschließlich die Angabe der jeweiligen Mail-Adresse der Empfänger notwendig. Dieses Dokument beschreibt die VVV-Lösung, insbesondere die Definitionen der Anwendungsfälle, beteiligten Instanzen und Komponenten. Eine
detaillierte Definition der technischen Lösung wird in einer separaten Architekturspezifikation erfolgen.
Die in diesem Dokument enthaltenen Arbeitsergebnisse sind sorgfältig und unter Zugrundelegung des bekannten Standes der Wissenschaft erstellt worden, stellen jedoch
Forschungsansätze dar. Eine Haftung oder Garantie dafür, dass die Arbeitsergebnisse/ Informationen die Vorgaben der aktuellen Rechtslage erfüllen, wird aus diesem
Grund nicht übernommen. Gleiches gilt für die Brauchbarkeit, Vollständigkeit oder
Fehlerfreiheit, so dass jede Haftung für Schäden ausgeschlossen wird, die aus der Benutzung dieser Arbeitsergebnisse/Informationen entstehen können. Diese Haftungsbeschränkung gilt nicht in Fällen von Vorsatz.
2
Arbeitspaket
AP 1 und AP 2
Autoren
Peter Fischer (MBX), Ulrich Waldmann (SIT)
Mitwirkende
Stephan Blazy (PVT), Susan Gonscherowski (ULD),
Katharina Lorenz (DRLab)
Internes Review
4 Yan Minagawa (MBX) am 17.11.2016
4 Annika Selzer (SIT) am 15.11.2016
Veröffentlichung
4 Ja, auf der Projekt-Webseite.
2 Nein, da Projekt-internes Dokument.
Inhaltsverzeichnis
Definitionen
1
2
Einführung
10
1.1
1.2
10
10
3.2
Funktionale Anforderungen . . . . . . . . . . .
IT-Sicherheits- und Datenschutz-Anforderungen
Vertrauensmodell der VVV-Lösung . . . . . .
Anforderungen an den DNS-Server . . . . . . .
Unterstützung bestimmter Features . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Veröffentlichung von OpenPGP-Schlüsseln . . . . . . . . . .
3.1.1 DNSSEC/DANE-basiertes Verfahren . . . . . . . . .
3.1.2 Public Key Association (PKA) . . . . . . . . . . . . .
3.1.3 Web Key Service (WKS) . . . . . . . . . . . . . . . .
3.1.4 Privater HKP-Server mit SRV-RRs (Erweitertes HKP)
Veröffentlichung von S/MIME-Schlüsseln . . . . . . . . . . .
3.2.1 LDAP-Verzeichnisdienste . . . . . . . . . . . . . . .
3.2.2 Zusammenspiel mehrerer Verzeichnisdienste . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4
Veröffentlichung von OpenPGP-Schlüsseln
Veröffentlichung von S/MIME-Schlüsseln .
VVV-Komponenten . . . . . . . . . . . . .
4.3.1 VVV-Client-Plugin . . . . . . . . .
4.3.2 VVV-Server-Plugin . . . . . . . . .
Formate der Resource Records . . . . . . .
12
13
14
17
17
19
Verfahren der VVV-Lösung
4.1
4.2
4.3
5
12
Existierende Verfahren der Schlüsselverteilung
3.1
4
Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . .
Anforderungen an die VVV-Lösung
2.1
2.2
2.3
2.4
2.5
3
5
19
20
21
22
23
24
25
25
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
30
31
33
33
Anwendungsfälle der VVV-Lösung
35
5.1
38
40
42
44
46
48
50
51
53
5.2
5.3
UC 0: VVV-Client-Umgebung einrichten . . . . . . . . . . . . . .
5.1.1 UC 0.1: VVV-Client-Plugin installieren . . . . . . . . . . .
5.1.2 UC 0.2: DNSSEC-Schlüssel eines Mail-Anbieters importieren
UC 1: Clientseitigen Schlüssel auf Schlüssel-Server veröffentlichen
5.2.1 UC 1.1: Clientseitigen Schlüssel auf dem Client registrieren
5.2.2 UC 1.2: Clientseitigen Schlüssel auf dem Server registrieren
5.2.3 UC 1.3: Schlüssel auf Schlüssel-Server veröffentlichen . . .
UC 2: Clientseitig verschlüsselte Mail senden . . . . . . . . . . . .
5.3.1 UC 2.1: Information zu den Schlüssel-Servern finden . . . .
3
5.4
5.5
5.6
5.3.2 UC 2.2: DNSSEC-Signaturen prüfen . . . . . . . . . . .
5.3.3 UC 2.3: Schlüssel finden . . . . . . . . . . . . . . . . . .
UC 3: Serverseitig verschlüsselte Mail senden . . . . . . . . . . .
UC 4: Veröffentlichte Schlüssel anschauen . . . . . . . . . . . . .
UC 5: Clientseitigen Schlüssel auf Schlüssel-Server löschen . . .
5.6.1 UC 5.1: Clientseitigen Schlüssel auf dem Client abmelden
5.6.2 UC 5.2: Clientseitigen Schlüssel auf dem Server abmelden
5.6.3 UC 5.3: Schlüssel auf Schlüssel-Server löschen . . . . . .
Literatur
4
.
.
.
.
.
.
.
.
55
57
59
61
62
64
65
66
67
Abkürzungen und Definitionen
Tabelle 1: Abkürzungen und Definitionen
Bezeichnung
Bedeutung
ASCII
American Standard Code for Information Interchange:
7-Bit-Zeichenkodierung für die Kodierung von 128 Zeichen,
darunter das lateinischen Alphabet in Groß- und Kleinschreibung, die zehn arabischen Ziffern und einige Sonderzeichen.
BIND
Berkeley Internet Name Domain Server: Open-Source
DNS-Referenzsoftware für die Auflösung von DomainNamen des Domain Name System in Adressen des InternetProtokolls (IP-Adressen).
CA
Certificate Authority: Zertifizierungsstelle, Teil einer PKI
zur Ausgabe von digitalen X.509-Zertifikaten und Sperrlisten.
CLI
Command-Line Interface: Eingabe für die Steuerung einer
Software, die typischerweise im Textmodus abläuft.
CRL
Certificate Revocation List: Veröffentlichte Sperrliste mit
Seriennummern gesperrter X.509-Zertifikate für S/MIME.
DANE
DNS-Based Authentication of Named Entities: Netzwerkprotokoll, das Informationen der Internet-Domains mit DNSEinträgen verknüpft und per DNSSEC sichert.
DNS
Domain Name System: Hierarchischer Verzeichnisdienst,
der den Namensraum des Internets verwaltet.
DNSKEY-RR
DNSKEY Resource Record: Enthält den öffentlichen
Schlüssel einer DNS-Verwaltungseinheit (Zone) auf dem
dafür zuständigen DNS-Server zur Prüfung von DNSSECSignaturen.
DNSSEC
Domain Name System Security Extensions: Internetstandards, die das Domain Name System (DNS) um Sicherheitsmechanismen zur Gewährleistung der Authentizität und Integrität der im DNS veröffentlichten Daten erweitern.
DS-RR
Delegation Signer Resource Record: Enthält eine überprüfbare Referenz auf einen DNSKEY-RR einer untergeordneten
DNS-Zone und verbindet damit zwei Zonen in der DNSSECVertrauenskette.
5
6
Bezeichnung
Bedeutung
EDNS
Extended DNS: DNS-Protokoll-Erweiterungen, die den
Transport von DNS-Daten in UDP-Paketen betreffen und für
DNSSEC benötigt werden.
E2EE
End to End Encryption: Bei einer Ende-zu-EndeVerschlüsselung werden die Mailinhalte direkt beim Mailversender verschlüsselt und erst beim Empfänger wieder entschlüsselt.
GnuPG
GNU Privacy Guard: Kryptographie-Software zum Ver- und
Entschlüsseln von Daten sowie zum Erzeugen und Prüfen
elektronischer Signaturen mittels OpenPGP-Standard.
Gnu GPL
GNU General Public License: Die am weitesten verbreitete
Software-Lizenz, die einem gewährt, die Software auszuführen, zu studieren, zu ändern und unter einer kompatiblen
Lizenz zu verbreiten.
GUI
Graphical User Interface: Grafische Benutzerschnittstelle
mit der Aufgabe, den Nutzer zu informieren (z. B. über Fehlermeldungen) und ihm mittels grafischer Symbole und Steuerelemente die Bedienung der Anwendung zu ermöglichen.
HKP
HTTP Keyserver Protocol: Internetstandard, der das Hochladen und Abrufen von öffentlichen OpenPGP-Schlüsseln auf
Schlüssel-Servern mittels HTTP definiert.
HTTP
Hypertext Transfer Protocol: Protokoll zur Übertragung
von Anwendungsdaten im Internet.
HTTPS
Hypertext Transfer Protocol Secure: Protokoll für die
Transportverschlüsselung in Form einer zusätzlichen Schicht
zwischen HTTP und TCP.
IETF
Internet Engineering Task Force: Organisation, die sich mit
der technischen Gestaltung des Internets, insbesondere mit
der Entwicklung von Internetstandards (RFCs) befasst.
ITU-T
International Telecommunication Union - Telecommunication Standardization Sector: Die ITU ist eine UNSonderorganisation zur Festlegung von technischen Aspekten der Telekommunikation. Die technischen Standards der
Unterorganisation ITU-T sind weltweit anerkannt.
Bezeichnung
Bedeutung
LDAP
Lightweight Directory Access Protocol: Netzwerkprotokoll zur Abfrage und Änderung von Informationen verteilter
Verzeichnisdienste.
LDAPS
LDAP Secure: Über TLS gesichertes LDAP.
MIME
Multipurpose Internet Mail Extensions: Internetstandard
für Datenformatserweiterungen von Mails.
OCSP
Online Certificate Status Protocol: Standardisiertes Netzwerkprotokoll, nach dem Anwendungen überprüfen, ob
X.509-Zertifikate bereits vor Ende ihres regulären Gültigkeitszeitraums ungültig wurden.
OpenPGP
Open Pretty Good Privacy: Standard, der das Format für
verschlüsselte und signierte Daten und PGP-Schlüssel definiert.
OTP
One-Time Password: Einmalpasswort zur Authentisierung,
das gegen Replay-Angriffe schützt.
OX
Open-Xchange: Eine Mail- und Groupware-Lösung.
PGP
Pretty Good Privacy: Programm zur Verschlüsselung und
Signatur von Daten mittels Public-Key-Verfahren.
PK
Public Key: Englisch für öffentlicher Schlüssel.
PKA
Public Key Association: Auf DNS gegründetes Vertrauensmodell für OpenPGP und selbstsignierte X.509-Zertifikate für
S/MIME.
PKA-RR
Public Key Association Resource Record: DNS-Eintrag,
der eindeutig einer Mailadresse zugeordnet ist und Informationen über den öffentlichen OpenPGP- oder S/MIMESchlüssel vorhält, u. a. Fingerprint und URI der Bezugsquelle.
PKI
Public Key Infrastructure: System aus Zertifizierungsstelle(n), Registrierungsstelle(n), Verzeichnisdienst(en) und Validierungsdienst(en) zur Ausstellung, Verteilung und Prüfung
von digitalen X.509-Zertifikaten.
PowerDNS
Unter der GNU GPL veröffentlichter Nameserver, der verschiedene Datenquellen als Backend nutzen kann.
RFC
Request for Comments: Reihe von technischen und organisatorischen Internetstandards.
7
8
Bezeichnung
Bedeutung
RR
Resource Record: DNS-Eintrag als grundlegende DNSInformationseinheit.
RRSIG-RR
Resource Record Signature Resource Record: Enthält die
DNSSEC-Signatur für einen Satz von Resource-Records.
SHA
Secure Hash Algorithm: Gruppe standardisierter kryptologischer Hashfunktionen zur Berechnung eines eindeutigen
Prüfwerts für beliebige Daten.
S/MIME
Secure Multipurpose Internet Mail Extensions: Internetstandard für die Verschlüsselung und das Signieren von
MIME-gekapselten Mails.
SRV-RR
Service Resource Record: DNS-Eintrag über das Angebot
IP-basierter Dienste in einer Domain.
SST
Schnittstelle: Logischer und klar definierter Berührungspunkt
einer Software-Komponente für den Austausch von Kommandos und Daten zwischen verschiedenen Prozessen und
Komponenten.
TCP
Transmission Control Protocol: Netzwerkprotokoll zum
verbindungsorientierten, paketvermittelnden Datenaustausch
im Internet.
TLS
Transport Layer Security: Protokoll zur Verschlüsselung von Datenübertragungen im Internet. Da an der MailKommunikation viele Zwischenstationen beteiligt sind und
TLS jeweils zwischen zwei benachbarten Netzwerkteilnehmern in der Kette aufgebaut wird, liegen die Daten auf den
Zwischenstationen unverschlüsselt vor.
TLSA
Protokoll der DANE-Protokollfamilie zur Sicherung von
TLS-Zertifikaten.
TLSA-RR
TLSA Resource Record: DNS-Eintrag für das TLSAProtokoll zur Absicherung von TLS-Zertifikaten.
TOFU
Trust On First Use: Ein verbreitetes IT-Sicherheitsprinzip,
demgemäß der erste Identitätsnachweis (z. B. mittels Schlüssel und Zertifikat) einer Person oder einer Komponente akzeptiert und als vertrauenswürdig gespeichert wird.
UC
Use Case: Anwendungsfallbeschreibung eines Teilszenarios der VVV-Lösung ohne Berücksichtigung der technischen
Details.
Bezeichnung
Bedeutung
UDP
User Datagram Protocol: Netzwerkprotokoll zum minimalen, verbindungslosen Datenaustausch im Internet.
URI
Uniform Resource Identifier: Standardisiertes Format, das
zur Identifizierung von Ressourcen im Internet (z. B. Webseiten, Webdienste, Mail-Adressen) dient.
WebAPI
Web Application Programming Interface: Eine klar definierte minimale HTTP-Schnittstelle, worüber die Funktionen
eines Dienstes anderen Programmen bzw. Diensten zur Verfügung gestellt werden.
WKS
Web Key Service: Ein RFC-Entwurf von Werner Koch
für das Veröffentlichen von OpenPGP-Schlüsseln mittels Mail-Adressen auf Grundlage von Mails und HTTPSVerbindungen zu einem Schlüssel-Server des Mail-Anbieters.
X.509
ITU-T-Standard für das Erstellen digitaler Zertifikate, die in
einigen kryptographischen Protokollen, beispielsweise in TLS
und S/MIME, Verwendung finden.
9
1 Einführung
1.1 Problemstellung
Für die Verschlüsselung von Mails müssen sich Nutzer in der Regel zunächst darüber verständigen, welches Verfahren sie dafür verwenden möchten, da die beiden
gängigen Verschlüsselungsverfahren S/MIME und PGP/GnuPG hinsichtlich der eingesetzten Zertifikate und zugrunde liegenden Vertrauensmodelle nicht miteinander
kompatibel sind. Beide Verfahren sind in der Praxis umständlich und für den Laien
schwer zugänglich. Das Verteilen und Finden der für die Verschlüsselung benötigten „Schlüsselinformationen“ (signierte öffentliche Schlüssel für OpenPGP bzw. in
Form von X.509-Zertifikaten für S/MIME) der gewünschten Kommunikationspartner ist wenig benutzungsfreundlich, vgl. Abbildung 1.
Abbildung 1: VVV-Anwendungsbeispiel: Alice ist ratlos ...
1.2 Anwendungsbeispiel
Alice hat mit ihrem Mail-Programm Thunderbird eine Mail an Bob verfasst und
möchte diese Mail verschlüsselt absenden, siehe Abbildung 2. Sie gibt dazu lediglich Bobs Mail-Adresse „[email protected]“ ein (Schritt 1). Vor einiger Zeit hat
sie das VVV-Client-Plugin für Thunderbird installiert. Sie weiß nicht, welches Verschlüsselungsverfahren (S/MIME oder PGP) Bob verwendet und dass sie zum Verschlüsseln der Mail den öffentlichen Schlüssel von Bob benötigt. Bobs öffentlicher
Schlüssel ist im Mail-Programm Thunderbird noch nicht vorhanden. Um diese technischen Details kümmert sich im Hintergrund das VVV-Client-Plugin. Sobald Alice
10
Bobs Mail-Adresse eingegeben hat (Schritt 1), erfragt das VVV-Plugin den DNSServer, der für die Domain „example.com“ (rechter Teil von Bobs Mail-Adresse)
zuständig ist, wo Bobs Mail-Anbieter die öffentlichen Schlüssel seiner Kunden veröffentlicht hat (Schritte 2 und 3). Von dort lädt das VVV-Client-Plugin Bobs Schlüssel herunter und übergibt den Schlüssel an Thunderbird (Schritte 4 und 5). Alice
klickt auf den Sende-Button, das Mail-Programm Thunderbird verschlüsselt die Mail
mit Bobs öffentlichen Schlüssel (Schritt 6) und sendet schließlich die Mail Ende-zuEnde-verschlüsselt an Bob (Schritt 7).
Abbildung 2: Anwendungsbeispiel: Alice nutzt VVV.
Hintergrundinformation: Bob hatte sich beispielsweise bei der Volksverschlüsselung1 kostenlos ein X.509-Zertifikat für „[email protected]“ besorgt und dieses Zertifikat bei seinem Mail-Anbieter (= Mail-Domain-Inhaber) registriert. Bei der Registrierung des Zertifikats musste Bob gegenüber dem Mail-Anbieter nachweisen, dass
er Zugriff auf das Mailkonto hat und im Besitz des privaten Schlüssels ist, der zum
öffentlichen Schlüssel im Zertifikat gehört. Dazu hatte der Mail-Anbieter eine verschlüsselte Mail an Bob gesendet, die Bob entschlüsseln und beantworten konnte.
Anschließend hat der Mail-Anbieter das Zertifikat auf den LDAP-Server der Domain
„example.com“ veröffentlicht. Die Adresse des LDAP-Servers ist auf dem DNSServer hinterlegt und mit einer DNSSEC-Signatur des Mail-Anbieters geschützt. Anhand dieser Signatur kann überprüft werden, dass die Informationen authentisch sind,
d. h. dass Bob das Zertifikat einschließlich Mail-Adresse bei seinem Mail-Anbieter
registrieren ließ.
1
Initiative „Volksverschlüsselung“ des Fraunhofer SIT: www.volksverschluesselung.de.
11
2 Anforderungen an die VVV-Lösung
Eine Übersicht zu den technischen Herausforderungen und aktuellen Verfahren der
Mail-Sicherheit, z. B. S/MIME, OpenPGP, DNSSEC und DANE, bietet eine aktuelle Ausgabe der Zeitschrift „The Internet Protocol Journal“ [1]. Die VVV-Lösung
soll auf Basis dieser verfügbaren Techniken eine benutzerfreundliche Verteilung von
Schlüsselinformationen über einen kryptographisch abgesicherten Verteilungsweg
umsetzen und dabei insbesondere die folgenden Anforderungen erfüllen.
2.1 Funktionale Anforderungen
• Einfachheit: Für das Auffinden der Schlüssel für PGP und S/MIME durch das
VVV-Plugin soll allein die Kenntnis der Mail-Adressen der gewünschten Kommunikationspartner ausreichen. Der Nutzer soll mit seinem gewohnten MailClient Mails empfangen, lesen, senden, verschlüsseln und entschlüsseln. Dem
Nutzer soll aber auch klar angezeigt werden, dass ein gefundener Schlüssel
tatsächlich der aktuelle Schlüssel des gewünschten Kommunikationspartners
ist.
• Standards: Es sollen möglichst standardisierte Protokolle und Schnittstellen
zum Einsatz kommen, um eine Verbreitung dieser Technik zu fördern. Die
Komponenten sollen bevorzugt aus dem Open-Source-Umfeld kommen und
eigene Entwicklungen im Quellcode offen gelegt werden. Wichtig ist insbesondere die Interoperabilität der VVV-Lösung zur GnuPG-Komponente und zu
den Open-Xchange-Komponenten, auf die die VVV-Lösung angewiesen ist.
• Modularität: Die VVV-Lösung soll möglichst modular aufgebaut sein, um die
Erweiterbarkeit und Wiederverwendbarkeit der Komponenten zu erhöhen. Dies
vereinfacht auch die automatisierte Prüfung mittels Unit-Tests und erhöht die
Wartbarkeit.
• Zuordenbarkeit: Mit der VVV-Lösung übernehmen Mail-Anbieter die zusätzliche Aufgabe, die öffentlichen Schlüssel der Nutzer im Internet zugänglich
zu machen. Vor dem Hochladen der Schlüsselinformationen soll der MailAnbieter verifizieren, dass der Nutzer erstens im Besitz des zugehörigen privaten Schlüssels ist und zweitens die Kontrolle über die Postfächer der zu registrierenden Mail-Adressen hat. Dabei muss sichergestellt werden, dass ein
aktuell gültiger Schlüssel eindeutig einer bestimmten Mailadresse zugeordnet
ist.
12
2.2 IT-Sicherheits- und Datenschutz-Anforderungen
• Privatsphäre: Die VVV-Lösung soll die Privatsphäre der Benutzer respektieren und schützen. So darf es mit dem VVV-Plugin nicht möglich sein, mit
unvollständigen Mail-Adressen (mittels Wildcards) nach Schlüsseln und Zertifikaten anderer Nutzer zu suchen. Um zu verhindern, dass Profile über das
Nutzerverhalten erstellt werden können, müssen Angriffe, z. B. das Mitlesen
und Analysieren des Netzwerkverkehrs, betrachtet, verhindert oder zumindest
erschwert werden. Die Server sollen nur die absolut notwendigen Daten vorhalten.
• Vertraulichkeit: Die Kommunikation zwischen den VVV-Komponenten und
den beteiligten Servern soll mit SSL/TLS transportverschlüsselt sein. Das
VVV-Plugin ist jedoch nicht direkt an der Ende-zu-Ende-Verschlüsselung von
Mails beteiligt, sondern nur indirekt durch das Hochladen bzw. Beschaffen der
dazu notwendigen öffentlichen Schlüssel. Das VVV-Plugin verändert die Einstellungen des Mail-Clients bzw. Mail-Servers so wenig wie möglich, nimmt
z. B. keinen Einfluss darauf, ob Mails standardmäßig verschlüsselt werden oder
nicht. Das VVV-Plugin kann dem Nutzer Hinweise geben, aber dem MailClient bzw. Mail-Server kein bestimmtes Verhalten vorgeben, wenn beispielsweise zu einer Mail-Adresse der Schlüssel-Server nicht erreicht oder auf einem
Schlüssel-Server zu einer Mail-Adresse kein Schlüssel veröffentlicht ist.
• Nachweis des Schlüsselbesitzes: Vor dem Hochladen eines öffentlichen
Schlüssels soll ein kryptografisch gesichertes Challenge-Response-Verfahren
eingesetzt werden, um zu verifizieren, dass der Nutzer tatsächlich im Besitz
des zum öffentlichen Schlüssel gehörenden privaten Schlüssels ist. Das VVVPlugin soll dazu die Verwendung des privaten Schlüssels anstoßen, aber nicht
selbst ausführen.
• Robustheit gegenüber Man-in-the-Middle-Angriffen: Es muss verhindert
werden, dass der Mail-Anbieter als „Man-in-the-Middle“ unbemerkt eigene öffentliche Schlüssel mit den Namen der Nutzer veröffentlicht, damit verschlüsselte Mails entschlüsselt und für die Zustellung diese Mails mit den eigentlichen öffentlichen Schlüsseln der Empfängers wieder verschlüsselt. Der Nutzer
muss jederzeit überprüfen können, welche Schlüssel in seinem Namen veröffentlicht sind und ob diese mit dem ehemals hoch geladenen Schlüsseln übereinstimmen. Dies könnte auch automatisch durch VVV-Komponenten erfolgen. Jede Änderung des Veröffentlichungsstatus muss allerdings vom betroffenen Nutzer angestoßen worden sein.
• Authentizität: Die Authentizität der Informationen muss sichergestellt werden. Es ist darauf zu achten, dass die beteiligten Systeme kryptografisch gesi-
13
chert sind und in einer unterbrechungsfreien Kette von Vertrauensbeziehungen organisiert sind. Die Dienste bzw. deren SSL-Zertifikate müssen durch
einen DANE-RR im DNS mittels DNSSEC verifizierbar sein. Da die öffentlichen Schlüssel zur Validierung der DNSSEC-Signaturen bis zum DNS-RootSchlüssel direkt über das DNS-System verteilt werden (was ein kompromittierter DNS-Server nachahmen könnte), sollen die echten öffentlichen Schlüssel der DNS-Root-Zone als Sicherheitsanker in den VVV-Plugins vorinstalliert
werden.
• Transparenz: Der Nutzer soll über das graphische Benutzeroberfläche des
VVV-Plugins Hinweise oder Fehlermeldungen angezeigt bekommen, falls ihm
eine Handlungsempfehlung gegeben werden kann oder eine Entscheidung von
seiner Seite erforderlich ist (z. B. eine Aufforderung zur Einwilligung vor dem
Hochladen eines Schlüssels oder eine Übersicht zur Auswahl, wenn mehrere Schlüssel zur Auswahl stehen). Das VVV-Plugin soll ansonsten die technischen Prozesse weitestgehend im Hintergrund erledigen. Der Nutzer soll beispielsweise so wenig wie möglich mit der Unterscheidung von OpenPGP und
S/MIME konfrontiert werden.
2.3 Vertrauensmodell der VVV-Lösung
Die VVV-Lösung ergänzt die Prüfverfahren, die mit den Vertrauensmodellen von
OpenPGP und S/MIME verbundenen sind, aber ersetzt und integriert diese nicht,
siehe Tabelle 2. Die hierarchisch aufgebauten X.509-Zertifikatsketten für S/MIMESchlüssel und die Signaturen (User-IDs) des Web-of-Trust für OpenPGP-Schlüssel
sollten daher wie bisher durch die Anwendungsprogramme überprüft werden.
14
Tabelle 2: Einordnung des VVV-Vertrauensmodells
Validierung
Erläuterung
1. Ebene:
DNSSECSignaturen
Die VVV-Lösung sichert die Informationen darüber, welcher Schlüssel zu welchem Nutzer gehört, in Form von
DNSSEC-signierten Service Records auf dem DNS-Server
der Mail-Domain. Diese Service Records geben die authentischen Speicherorte der Zertifikate und Schlüssel an.
Die VVV-Plugins prüfen die Authentizität dieser Information durch die Validierung der von den Mail-Anbietern
erstellten DNSSEC-Signaturen. Damit bietet die VVVLösung ein automatisches Ermitteln der Schlüssel auf
Grundlage des Vertrauens in den Mail-Anbieter. Die Informationsübertragung wird durch kryptografisch gesicherte
Dienste (DNSSEC, HTTPS, LDAPS) erbracht.
2. Ebene:
Anwendung
des privaten
Nutzerschlüssels
Der Mail-Anbieter überprüft im Rahmen der clientseitigen VVV-Lösung vor dem Hochladen des öffentlichen
OpenPGP-Schlüssels bzw. des X.509-Zertifikats für S/MIME die Bindung des Schlüssels an den Nutzer. Der MailServer sendet dazu einen verschlüsselten Verifikationscode
an das VVV-Client-Plugin. Der Nutzer lässt den Verifikationscode durch den Mail-Client entschlüsseln und an
den Mail-Server zurücksenden. Durch den Zugriff auf das
Mail-Konto und auf den privaten Schlüssel hat der Nutzer seine Berechtigung nachgewiesen, den öffentlichen
Schlüssel zu veröffentlichen.
Alternativ könnte der Mail-Anbieter das Zertifikat mit
dem öffentlichen Schlüssel des Nutzers bereits dann akzeptieren, wenn das Zertifikat zum ersten Mal und zum
wiederholten Male vom Nutzer präsentiert wird (Prinzip
des „Trust On First Use“, TOFU, und Vertrauen durch
wiederholte Verwendung). Dies allein ist allerdings fehleranfällig, da der Nutzer ohne Anwendung des privaten
Schlüssels ungewollt ein unpassendes Zertifikat hochladen
könnte.
15
Validierung
Erläuterung
3. Ebene:
Signaturen der
hierarchischen
Zertifikatskette
bzw. des Webof-Trust
Diese Ebene umfasst die etablierten Vertrauensmodelle
der Zertifizierungshierachien und des Web-of-Trust. Diese
Ebene liegt nicht im Scope der VVV-Lösung.
Die S/MIME-Schlüssel werden von einer Zertifizierungsstelle (CA) signiert. Die Mail-Anwendung des Nutzers
kann die Signaturen prüfen und dazu die X.509-Zertifikate
der übergeordneten CAs bis hin zum Root-CA-Zertifikat in
die Prüfung einbeziehen. Das Root-CA-Zertifikat muss in
der Anwendung oder im Betriebssystem vorinstalliert sein
oder alternativ vom Nutzer in der Anwendungskonfiguration als vertrauenswürdig gekennzeichnet werden.
Die öffentlichen OpenPGP-Schlüssel werden von anderen
Kommunikationspartnern im Web-of-Trust in Form von
OpenPGP-Zertifikaten mit signierten User-IDs beglaubigt.
Mittels der OpenPGP-fähigen Anwendungen können die
Nutzer die User-IDs der anderen Nutzer validieren und die
Authentizität des Schlüssels und der jeweiligen Identität
einschätzen.
4. Ebene:
Fingerprint des
Schlüssels
Auf dieser Ebene erfolgt der Abgleich und die Verifikation
der Schlüssel und der zugehörigen Identitäten über einen
separaten manuellen Weg. Diese Ebene liegt nicht im Scope der VVV-Lösung.
Der Nutzer kann beispielsweise den Hashwert (Fingerprint) des öffentlichen Schlüssels eines Kommunikationspartners auf einem unabhängigen Kommunikationsweg
(z. B. persönlich im Gespräch, per Brief oder per WebSeite des Kommunikationspartners) erhalten und diesen
Fingerprint vor der Nutzung des Schlüssels manuell überprüfen, um sich persönlich davon zu überzeugen, dass der
vorliegende Schlüssel wirklich zu dem im Zertifikat genannten Kommunikationspartner gehört.
Die VVV-Lösung baut auf das Vertrauen, das die Nutzer in die Mail-Anbieter und
DNS-Infrastrukturanbieter des Internets haben, d. h. das Vertrauen in die Richtigkeit
von Mail-Adressen und die korrekte Zustellung von Mails, die Sicherheit der von
den Mail-Anbietern angebotenen Registrierungs- und Authentisierungsverfahren (in
der Regel Benutzername, Passwort). Würde dieses Vertrauen fehlen, dann müsste das
Versenden von Mails insgesamt in Frage gestellt werden.
16
2.4 Anforderungen an den DNS-Server
• Standards: Der DNS-Server muss sich an offenen Standards orientieren.
• Zuverlässigkeit: Der DNS-Server ist eine zentrale Komponente im Netzwerk.
Deshalb sind die Anforderungen an seine Zuverlässigkeit besonders hoch.
• Redundanz: Um die Zuverlässigkeit und Performance erhöhen zu können, soll
das System redundant ausgelegt werden können.
• DNSSEC: Der DNS-Server soll seine Zonen mit DNSSEC absichern können. Weiterhin soll er mit an ihn gerichteten DNSSEC-Anfragen gemäß
RFC6944 [2] umgehen können.
• DANE: Um die Privatsphäre der Benutzer zu schützen stellen die SchlüsselServer die öffentlichen Schlüssel über SSL gesicherte Protokolle zur Verfügung. Die verwendeten SSL-Zertifikate dieser Dienste werden zusätzlich mittels DANE-DNS-RR nach RFC6698 [3] abgesichert.
2.5 Unterstützung bestimmter Features
Feature
Argumente und Alternativen
Unterstützung
von OpenPGP
Privat wird mehr OpenPGP als S/MIME verwendet. Für
OpenPGP gibt es Erweiterungen (z. B. Enigmail, Mailvelope).
Unterstützung
von S/MIME
Beruflich wird mehr S/MIME als OpenPGP verwendet.
Viele Anwendungen haben S/MIME bereits integriert.
Plugin für Mozilla Thunderbird
Das Thunderbird-Plugin (VVV-Client-Plugin) soll sowohl
OpenPGP als auch S/MIME unterstützen.
Plugin für OpenXchange
Das Open-Xchange-Plugin (VVV-Server-Plugin) soll mindestens OpenPGP unterstützen.
Verwaltung
öffentlicher
Schlüssel
Die VVV-Lösung hat die Verwaltung öffentlicher Schlüssel im Fokus. Private Schlüssel werden durch die VVVLösung weder generiert noch verwaltet, auch wenn Firmen
für den Zugang zu verschlüsselten Mails üblicherweise die
privaten Schlüssel ihrer Mitarbeiter vorhalten. Die Verwaltung privater Schlüssel wird in VVV aber evtl. einer
rechtlichen Betrachtung unterzogen.
17
Feature
Argumente und Alternativen
Verwaltung
mehrerer Schlüssel pro Nutzer
Für jede Mail-Adresse soll ein OpenPGP-Schlüssel (d. h.
ein OpenPGP-Zertifikat mit dem öffentlichen Hauptschlüssel und evtl. vorhandenen Unterschlüsseln für Verschlüsselung, Signatur, Authentisierung) und ein S/MIMESchlüssel (X.509-Zertifikat mit einem öffentlichen Schlüssel für die Verschlüsselung) hinterlegt werden können.
Jeder hinterlegte Schlüssel gilt als aktuell und vom Nutzer
für die Verwendung autorisiert.
Verifikation des
Schlüssels mittels
HTTPS
Gegen eine Mail- mit verschlüsseltem Verifikationscode
spricht Folgendes:
• Einige Mail-Anbieter verwenden nur ein WebInterface ohne SMTP und IMAP.
• Das Postfach des Nutzers könnte überfüllt sein.
• Der Nutzer könnte seine Mails mit einem anderen
Client mittels POP3 abholen oder auf einen anderen
Client umleiten (filtern), so dass das VVV-Plugin
bzw. der Mail-Client, in dem der private Entschlüsselungsschlüssel verwendet werden kann, die verschlüsselte Mail gar nicht sehen und entschlüsseln
kann.
Die Lösung mit HTTPS-Schnittstelle über REST erfordert
eine Entschlüsselung des Verifikationscodes mit Hilfe des
Plugins mit Zugriff auf den Schlüsselspeicher durch den
Mail-Client bzw. die GnuPG-Komponente. Der Nutzer
muss neben der Anmeldung zum Postfach ggf. auch das
Schlüsselschutz-Passwort eingeben, was dem Nutzer an
dieser Stelle unbedingt erklärt werden sollte, siehe UC 1.
18
3 Existierende Verfahren der Schlüsselverteilung
3.1 Veröffentlichung von OpenPGP-Schlüsseln
Insbesondere OpenPGP ist für einen durchschnittlich IT-fernen Nutzer nur schwer
zu verstehen und nutzbar. In der Regel muss zusätzliche Software (z. B. Enigmail
für Mozilla Thunderbird oder Mailvelope für Mozilla Firefox) installiert werden. Die
Nutzer müssen sich gegenseitig ihre Schlüssel und Identitätsdaten beglaubigen („Web
of Trust“), wobei die dabei erzeugten User-IDs bestenfalls ein höheres Vertrauen in
die Herkunft der enthaltenen Signaturen ermöglichen. Die Nutzer können sich die
Schlüssel auch direkt gegenseitig mitteilen sowie auf vorhandenen Schlüssel-Servern
veröffentlichen.
Durch die öffentlichen Schlüssel-Server hat das Konzept von OpenPGP aber einige
Sicherheits- und Datenschutzprobleme. So kann z. B. ein Angreifer Schlüssel mit
beliebigen Mail-Adressen erstellen und veröffentlichen. Die authentische Herkunft
eines Schlüssels ist fraglich und der Nutzer muss manuell eine berechnete Prüfsumme (Fingerprint) zum vorliegenden Schlüssel mit dem Fingerprint vergleichen, den
der wahre Schlüsselbesitzer dem Nutzer auf anderem Wege, z. B. telefonisch oder
über eine Webseite, mitgeteilt hat. Da die Nutzer die Fingerprints nicht zwangsweise
prüfen, sind die damit generierten Signaturen ebenfalls nicht per se vertrauenswürdig. Bei Verlust des privaten Schlüssels hat der Nutzer zudem keine Möglichkeit den
öffentlichen Schlüssel auf dem Schlüssel-Server zurückzurufen (d. h. als ungültig
zu kennzeichnen). Ein Datenschutzproblem besteht darin, dass die Kommunikationspartner der Nutzer, der „Soziale Graph“, aus den Signaturen der Schlüssel rekonstruiert werden kann. Auch kann das Veröffentlichen des Schlüssels zu einem erhöhten
Spam-Aufkommen im Mail-Postfach des Nutzers führen.
Es gibt verschiedene Verfahren, um öffentliche OpenPGP-Schlüssel automatisch zu
verteilen. Im Rahmen des VVV-Projekts wurden die existierenden Verfahren betrachtet und bewertet, siehe folgende Kapitel. Die hier beschriebenen Verfahren zur automatischen Ermittlung von öffentlichen Schlüsseln setzten ein Vertrauen in den MailAnbieter und seine DNS-Server, Mail-Server und Schlüssel-Server voraus. Um das
Vertrauen in die über den Mail-Anbieter veröffentlichten Schlüssel zu erhöhen, könnten die Verfahren zusätzlich über ein öffentliches dezentrales kryptografisch abgesichertes Log-Verzeichnis gesichert werden.2
Die VVV-Lösung wird das bestehende Vertrauensmodell der OpenPGP-Schlüssel
nicht verändern, soll aber einen Veröffentlichungsmechanismus verwenden, der ein
zusätzliches Vertrauensmodell ermöglicht, welches eine einfache, eindeutige und
2
Ähnlich dem Konzept „Certificate Transparency“, vgl. die Präsentation „Transparent Keyservers –
Trust at Scale“ von Gary Belvin.
19
benutzungsfreundliche Zuordnung von öffentlichen Schlüsseln zu den betreffenden
Nutzern gestattet.
3.1.1 DNSSEC/DANE-basiertes Verfahren
Bei diesem Verfahren werden die öffentlichen OpenPGP-Schlüssel in DNS Resource
Records abgelegt3 . Wir haben uns aus folgenden Gründen gegen dieses Verfahren
entschieden.
1. Eine Absicherung der Kommunikation mittels TLS und TLSA-RR, um die
ggf. verwendeten TLS-Zertifikats abzusichern und damit die Authentizität der
DNS Resource Records sicherzustellen, ist nicht Teil des Konzepts. TLS direkt in einem DNS-Resolver zu nutzen, wäre zwar technisch möglich (vgl.
RFC7858 [6]), ist aber nicht sehr verbreitet. Als Fallback müsste die Kommunikation daher auch ohne TLS angeboten werden, wodurch es einem Angreifer
ermöglicht wird, die unverschlüsselte Fallback-Kommunikation zu erzwingen.
2. Eine Absicherung mittels DNSSEC/DANE ist es zwar möglich, allerdings sind
DNS-Anfragen grundsätzlich nicht verschlüsselt und können so von potentiellen Angreifern auf dem Übertragungsweg mitgelesen werden. Dadurch wird
die Privatsphäre der Benutzer beeinträchtigt, falls personenbezogene Daten
(z. B. die Schlüssel der Nutzer) im DNS gespeichert werden.
3. Der Draft [4] widerspricht der RFC53214 , darin dass die Mailadressen in einer case-sensitiven Schreibweise definiert werden, während die Bezeichner im
DNS nach RFC4343 [8] immer case-insensitiv anzugeben sind. In der Praxis hat sich eine case-insensitive Schreibweise der Mailadressen durchgesetzt.
Dies wird in dem Draft auch erwähnt, aber es gibt keine zwingende Festlegung,
wodurch der Draft uneindeutig ist.
4. Die Bezeichner werden nur aus den führenden 28 Oktetts des SHA-256Hash gebildet, wodurch eine theoretisch höhere Wahrscheinlichkeit von HashKollisionen besteht.
5. Es besteht eine Größenbeschränkung der DNS-Antworten durch die Verwendung des UDP-Protokolls, welche durch die Verwendung von Extended DNS
(EDNS)5 aufgehoben werden soll.
6. Bei Verwendung von EDNS können Probleme auf dem Übertragungsweg auftreten, so z. B. Fragmentierung von DNS-Antworten durch alte Firewalls.
3
Siehe auch die IETF-Entwürfe zur Veröffentlichung von OpenPGP-Schlüsseln [4] und von Schlüsseln für S/MIME [5].
4
Siehe RFC5321 Kap. 2.4 [7], „The local-part of a mailbox MUST BE treated as case sensitive“.
5
Dies wurde erstmals in RFC2671 spezifiziert, aktuell ist RFC6891 [9].
20
7. Durch große DNS-Requests, wie sie z. B. bei EDNS notwendig sind, ergibt
sich ein erhöhtes Potential für DNS-Reflektionsangriffe.
Fazit: Das Verfahren lässt in Bezug auf Datenschutz und Sicherheit (einschließlich
Verfügbarkeit der Daten) einige Fragen offen. Daher wird die VVV-Lösung dieses
Verfahren nicht für die Verteilung von datenschutzrelevanten Informationen (d. h. für
die Schlüssel der Nutzer) verwenden, sondern nur für die Veröffentlichung von „Service Resource Records“ (SRV-RRs) mit Informationen über die separaten SchlüsselServer der Mail-Anbieter, vgl. Abschnitt 3.1.4. Die Informationen der SRV-RRs enthalten keine personenbezogenen Daten oder schützenswerten Geheimnisse und können daher auch unverschlüsselt übertragen werden.
3.1.2 Public Key Association (PKA)
Bei diesem Verfahren wird für jede Mailadresse ein eigener so genannter „Public
Key Association Resource Record“ (PKA-RR) im DNS angelegt.6 Der PKA-RR
ist der Form nach ein so genannter „Text Strings Resource Record“ (TXT-RR) mit
frei definierbarem Text und enthält neben einer Versionsangabe des Protokolls und
dem Fingerprint auch die Web-Adresse (URI) einer Bezugsquelle des öffentlichen
OpenPGP-Schlüssels. Die folgenden Überlegungen sprechen allerdings gegen eine
Verwendung:
1. Die entsprechenden DNS-RRs sind nicht zwingend mittels DNSSEC/DANE
abgesichert (nach Definition), d. h. das Verfahren sieht keine TLSA-RRs vor,
um die ggf. verwendeten TLS-Zertifikats abzusichern und damit die Authentizität der DNS-RRs sicherzustellen
2. Das Verfahren wird in der Praxis zwar eingesetzt, hat sich aber nicht weiter
durchgesetzt.
3. Die Definition der Schreibweise (Case (In)sensitive) des Local-Part der Mailadressen ist nicht definiert.
4. Auf dem Übertragungsweg ist ein Mitlesen der angeforderten OpenPGPSchlüssel möglich, wodurch die Privatsphäre des Benutzers unterlaufen wird.
5. Das Verfahren ist kein RFC-Standard. Dadurch ist eine flächendeckende Verbreitung sehr schwierig zu erreichen.
Fazit: Die oben genannten Gründe sprechen gegen eine Verwendung des Verfahrens
in der VVV-Lösung, da das Verfahren einige Sicherheits- und Datenschutzanforderungen nicht erfüllen kann. Die VVV-Lösung muss in jedem Fall eine Absicherung
mittels DNSSEC/DANE voraussetzen.
6
Siehe „Public Key Association“ von Werner Koch [10].
21
3.1.3 Web Key Service (WKS)
Hierbei handelt es sich um ein neues Verfahren7 , welches die Schlüssel über eine
WebAPI bereitstellt bzw. entgegennimmt. In der aktuellen Form ist die praktische
Verwendung des Konzepts sehr eingeschränkt. So sprechen die folgenden Punkte
gegen eine Verwendung.
1. Durch den beschriebenen Aufbau muss der Mail-Anbieter die volle Kontrolle
über den Web-Server der DNS-Domain besitzen, was in der Praxis i.d.R. nicht
der Fall ist.89
2. Der Ablauf des Schlüssel-Uploads ist aus unserer Sicht unvollständig bzw. inkonsistent. Beispielsweise wird der erste Schritt, in dem die Mailadresse zum
Schlüssel-Upload ermittelt wird, 10 über eine HTTP-Schnittstelle, während alle
weiteren Schritte über SMTP definiert sind.
3. Für den Upload ist das Format des Schlüssels als „amored ASCII“11 definiert,
beim Abholen muss der Key allerdings zwingend in der binären Version vorliegen.12
4. Der Widerruf (Sperrung) von Schlüsseln wird zwar erwähnt, ist aber in der
RFC bisher nicht definiert.
5. Das Konzept nutzt den eigentlichen WKS nur für den aktuell aktiven Schlüssel. Um Signaturen von alten Schlüsseln zu prüfen, wird auf bestehende HKPServer zurückgegriffen.13 Dadurch entstehen u. U. Lücken im Sicherheitskonzept.
6. Momentan ist die Absicherung des Web-Service (DNSSEC/DANE, Certpinning, CA) nicht klar definiert. Es gibt aber einen TLSA-RR zur Absicherung
von verwendeten TLSA-Zertifikaten.
7. Da man sich beim Einreichen des Schlüssels per Mail nicht authentisieren
muss, ist es möglich, diesen Dienst für eine Art Mail-Adress-Dossier zu nutzen.
7
Das Verfahren im Draft „OpenPGP Web Key Service“ [11] spezifiziert.
Das Problem könnte man mittels entsprechender DNS-Einträge lösen, beispielsweise mittels SRVRRs, die auf separate Server des Mail-Anbieters verweisen.
9
Es gibt wohl Überlegungen dies per HTTP-Weiterleitung zu lösen, dies ist bisher allerdings nicht
weiter definiert.
10
Zum Ermitteln der Mailadresse wäre ebenfalls ein DNS-Eintrag besser geeignet, vgl. den zuvor
genannten Punkt.
11
Siehe Kap 4.3: „the body part contains the ASCII-armored transferable Public Key Packets as defined in RFC4880“ [12].
12
Siehe Draft Webservice [11] Kap.3.1: „The server MUST NOT return an ASCII armored version of
the key.“
13
Gemäß mündlicher Gespräche mit W.Koch.
8
22
8. Die Policy sollte auch die unterstützen Schlüsselgrößen angeben.
9. Ist das Postfach voll, funktioniert der Mail-gestützte Prozess nicht.
10. Momentan ist in der RFC keine „Anti-Brute-Force-Strategie“ definiert.
11. Vorteil des WKS-Verfahrens ist die Verifikation des Mail-Accounts durch das
Versenden einer Mail.
Fazit: Das Verfahren bietet momentan keine Vorteile gegenüber der HKP-Lösung
(vgl. nachfolgenden Abschnitt 3.1.4, allerdings ist eine große Verbreitung zu erwarten, da das Verfahren wahrscheinlich als RFC-Standard veröffentlicht wird. So hat
das aktuelle GnuPG 2.1 dieses Verfahren bereits implementiert.14 Die VVV-Lösung
muss in jedem Fall eine Absicherung mittels DNSSEC/DANE voraussetzen.
3.1.4 Privater HKP-Server mit SRV-RRs (Erweitertes HKP)
Dieses Verfahren [13] beschreibt ein „HTTP Keyserver Protocol“ (HKP), das „Service Resource Records“ (SRV-RRs) [14] verwendet, um unter der Mail-Domain Informationen darüber bereitzustellen, wo ein Schlüssel-Server für diese Mail-Domain
zu finden ist. Das Verfahren definiert weitere Bedingungen an die Umgebung, um
vertrauenswürdige Schlüssel zur Verfügung zu stellen. Im Gegensatz zu verbreiteten
HKP-Implentierungen ist keine Synchronisation mit anderen HKP-Servern vorgesehen. Daher werden die Schlüssel-Server dieses Verfahrens „private HKP-Server“ genannt. Eine solche Synchronisation ist in der VVV-Lösung auch nicht erwünscht, da
immer nur auf die Schlüssel-Server des jeweiligen Mail-Anbieters zugegriffen werden soll und eine Synchronisation dieser Schlüssel-Server mit anderen HKP-Servern
beispielsweise dazu führen könnte, dass die Schlüssel nicht exakt mit dem übereinstimmen, was der Nutzer auf den Schlüssel-Server hochladen ließ. Im Folgenden
einige weitere Anmerkungen zu diesem Verfahren.
1. Leider wurde der HKP-Draft aus dem Jahr 2003 nicht bis zu einem RFCStandard ratifiziert.
2. Es wird nur die mit TLS abgesicherte Variante der HKP-Schnittstelle unterstützt. Eine Absicherung der TLS-Zertifikate mittels TLSA-RR ist vorgesehen.
3. Für jede Mail-Domain wird mit dem SRV-RR ein HKP-Server definiert. Dieser DNS-RR ist zwingend erforderlich, um anzuzeigen, dass dieses Verfahren
unterstützt wird.
14
Siehe Werner Koch: Key Discovery made simple,
https://www.gnupg.org/blog/20160830-web-key-service.html, 30. August 2016.
23
4. Im Gegensatz zu dem originären HKP-Konzept ist keine Synchronisation von
HKP-Servern vorgesehen.
Fazit: Dieses erweiterte HKP-Verfahren scheint ebenso wie das WKS-Verfahren (siehe Abschnitt 3.1.3) für VVV prinzipiell geeignet. Der Open-Xchange-Server hat eine
HKP-Schnittstelle implementiert, die allerdings nicht ganz konform zur Spezifikation
ist. Die VVV-Lösung muss in jedem Fall eine Absicherung mittels DNSSEC/DANE
voraussetzen.
3.2 Veröffentlichung von S/MIME-Schlüsseln
S/MIME wird von den meisten Verschlüsselungsprogrammen unterstützt und verwendet X.509-Zertifikate von hierarchisch organisierten öffentlichen Zertifizierungsstellen („Hierarchische PKI“). Die Nutzer müssen sich vorab ihre Zertifikate mitteilen oder ihre Anwendungen so konfigurieren, dass der richtige Verzeichnisdienst
zum Auffinden der gewünschten Zertifikate eingetragen ist. Privatnutzer wissen in
der Regel nicht, wie sie Schlüssel erzeugen und wo sie entsprechende Zertifikate
für sich beziehen können. Insbesondere wissen sie nicht, wie sie die Zertifikate von
gewünschten Kommunikationspartnern erhalten können. Liegen dem Nutzer bereits
Zertifikate seiner Kommunikationspartner vor, so ist es zudem schwierig, eindeutig zu überprüfen, ob ein bestimmter Verschlüsselungsschlüssel wirklich zu dem gewünschten Kommunikationspartner gehört.
Der Nutzer muss zudem der Instanz, welche das Zertifikat erstellt hat, vertrauen, obwohl es per se nicht klar ist, wie und warum er der digitalen Signatur einer ihm wahrscheinlich unbekannten Zertifizierungsstelle vertrauen sollte. Zurzeit werden Wurzelzertifikate als Vertrauensanker verwendet, mit denen vollständige Zertifikatsketten geprüft werden können. Viele Anwendungen haben solche Wurzelzertifikate integriert. Die Auswahl dieser Vertrauensanker kontrolliert der Nutzer jedoch in der
Regel nicht selbst, da dies sehr aufwändig ist und ein Wissen um die dahinter liegenden Konzepte voraussetzt.
Wie im Falle von OpenPGP löst die VVV-Lösung auch bei S/MIME nicht das generelle Problem, dass der Bezug von Schlüsseln und Zertifikaten und deren Integration
in die Mail-Anwendungen relativ umständlich und benutzungsunfreundlich ist. Zudem verbessert die VVV-Lösung nicht das Vertrauensmodell, das der Nutzung hierarchischer Zertifizierungsketten zugrunde liegt, sondern fügt einen Veröffentlichungsmechanismus hinzu, der ein davon unabhängiges Vertrauensmodell ermöglicht, vgl.
Abschnitt 2.3.
24
3.2.1 LDAP-Verzeichnisdienste
Die Veröffentlichung von Schlüsselinformationen für S/MIME erfolgt in der Regel
über einen LDAP-Verzeichnisdienst und wird mit einen OCSP-Validierungsdienst
abgesichert. Gängige Mail-Programme, darunter Microsoft Outlook und Thunderbird, beherrschen das LDAP-Protokoll und sind in der Lage, lokal nicht bekannte
Schlüssel automatisch aus einem Verzeichnisdienst abzurufen. Im Idealfall merkt der
Nutzer davon nichts. Schwieriger wird die Situation, wenn ein Nutzer einen Verzeichnisdienst konfiguriert hat, zum Beispiel weil er einem Unternehmen angehört,
welches über eine eigene PKI mit einem eigenen Verzeichnisdienst verfügt, dann
aber nach Zertifikaten von Nutzern sucht, die (wenn überhaupt) in anderen Verzeichnissen stehen. Die Mail-Tools können zwar mehrere Verzeichnisdienste verwalten,
aber zu einer Zeit ist nur einer aktiv. Noch komplizierter wird es, wenn der Sender
eine Nachricht an mehrere Empfänger schicken will und diese sich in verschiedenen
Infrastrukturen befinden, die jeweils einen eigenen Verzeichnisdienst betreiben.
Die LDAP-Verzeichnisdienste sind zudem mit Risiken verbunden [15], die wegen des
Personenbezugs der abrufbaren Daten dem Datenschutzrecht zuzuordnen sind. So
können Verzeichnisdienste u. a. eine Profilbildung über das Nutzerverhalten ermöglichen: Schnell aufeinander folgende Anfragen von einer IP-Adresse können einem
Client zugewiesen werden. Dadurch kann sich ein Verzeichnisdienst u. a. merken,
welche Personen oder Gruppen von Menschen miteinander kommunizieren. Darüber
hinaus können Verzeichnisdienste durch gezielte Massenabfragen für geschäftliche
Zwecke, insbesondere für den Mail-Adresshandel, missbraucht werden.
Die VVV-Lösung sollte daher technische und organisatorische Maßnahmen implementieren, um gezielten Massenabfragen zu geschäftlichen Zwecken soweit möglich
entgegenzuwirken. Dies kann u. a. dadurch realisiert werden, dass nur unter Kenntnis der gesamten Mail-Adresse eine Antwort gegeben wird, d. h. auf eine Anfrage maximal ein Ergebnis zurückgegeben wird, und nach einer geringen Anzahl von
Suchanfragen ein Timeout die Weitersuche verzögert. Die Erstellung von Nutzerprofilen muss dagegen nicht unbedingt mit besonderen technischen Maßnahmen unterbunden werden, da in der VVV-Lösung die Mail-Anbieter selbst die LDAP-Dienste
betreiben und die Anbieter direkt über die gesendeten und empfangenen Mails das
Kommunikationsverhalten der Nutzer kennen.
3.2.2 Zusammenspiel mehrerer Verzeichnisdienste
Das „Lightweight Directory Access Protocol“ (LDAP) ist durch die RFCs 4510 bis
4519 definiert. Gängige Mailprogramme, darunter Microsoft Outlook und Thunderbird, beherrschen das Protokoll und sind in der Lage, lokal nicht bekannte Schlüssel
automatisch aus dem Verzeichnisdienst abzurufen. Das ist eine recht komfortable
25
Funktion, solange sich die Zertifikate der gewünschten Empfänger in demselben Verzeichnis befinden und dieses Verzeichnis in der Mail-Anwendung konfiguriert wurde.
Am besten wäre es, wenn die Mailprogramme mehrere Verzeichnisdienste gleichzeitig benutzen könnten. Ob und wann dies der Fall sein wird, ist ungewiss. Aus einer
pragmatischen Sicht ist eine Lösung wünschenswert, die sofort einsetzbar ist. Das
LDAP-Protokoll bietet für diesen Zweck zwei Mechanismen, ein dritter Mechanismus kann protokollunabhängig benutzt werden: [15]
1. Referal-Mechanismus: Dieser Mechanismus ermöglicht einem LDAP-Server,
der eine Anfrage nicht beantworten will oder kann, eine Menge von „Uniform
Ressource Identifiers“ (URIs) zurückzuliefern. Jeder davon verweist auf einen
anderen LDAP-Server, der die Anfrage möglicherweise beantworten kann. Es
ist die Aufgabe der aufrufenden Anwendung, diesen Hinweisen zu folgen und
dabei darauf zu achten, dass sie sich nicht in einer Schleife (A verweist auf B
und B verweist auf A) verfängt.
2. Continuation References: Diese ermöglichen einem LDAP-Server, der schon
Ergebnisse gefunden hat, auf weitere LDAP-Server hinzuweisen, welche die
Ergebnisse erweitern könnten. Auch dieser Hinweis geschieht durch eine Menge von URIs.
3. Chaining-Mechanismus: Dieser Mechanismus ist nicht Bestandteil des
LDAP-Protokolls. Er ermöglicht LDAP-Servern, selbständig Anfragen bei
anderen Servern zu stellen, wenn sie selbst die Anfrage nicht oder nur teilweise beantworten können. Für den Client ist das transparent.
Der Referal-Mechanismus erlaubt den Anwendungen sehr viel Kontrolle, hat aber
den Nachteil, dass die korrekte Funktionsweise davon abhängig ist, dass alle Clients,
die gelieferten URIs korrekt auswerten. Continuation References kommen nicht in
Frage, wenn der Verzeichnisdienst aus Datenschutzgründen so konfiguriert ist, dass er
entweder exakt eine Antwort liefert oder gar keine. Der Chaining-Mechanismus hat
den Nachteil, dass die aufrufende Anwendung nicht genau weiß, aus welcher Quelle eine Antwort stammt. Diese Transparenz ist jedoch zugleich ein Vorteil, denn sie
führt dazu, dass sie client-unabhängig funktioniert. Für die Akzeptanz wäre es aber
wichtig, dass sich alle beteiligten Server bezüglich der Qualität ihrer Daten auf einem
Niveau befinden. Diese Forderung muss transitiv gelten, denn auch die angefragten
Server könnten wiederum andere Server anfragen. Es ist Aufgabe der Server dafür zu
sorgen, dass kein Kreisbezug entsteht, bzw. dass ein solcher entdeckt wird. [15] Für
die VVV-Lösung ist eine solche Transparenz in jedem Fall nicht erwünscht, da immer
die Gefahr besteht, dass dem Nutzer öffentliche Schlüssel und weitere Informationen
aus anderen Quellen untergeschoben werden. Zudem ist keiner der oben genannten
Mechanismen in der breiten Anwendung, so dass viele LDAP-Verzeichnisse weiterhin Insellösungen ihres jeweiligen Betreibers darstellen.
26
Für die VVV-Lösung wird ein pragmatischer Ansatz gesucht, der möglichst nicht von
den Implementierungen bestehender LDAP-Server abhängig ist, sondern ein einheitliches und benutzungsfreundliches Verfahren zum Auffinden öffentlicher S/MIMESchlüssel bietet. Keiner der Mechanismen ist für die VVV-Lösung geeignet, da das
VVV-Vertrauensmodell darauf basiert, dass der Mail-Anbieter immer genau einen
aktuellen, authentischen Schlüssel des Nutzers vorhält. Dazu bietet sich die Nutzung des „Domain Name System“ (DNS) an, indem der Domain-Inhaber der MailAdresse, also der betreffende Mail-Anbieter, mittels DNSSEC die Adresse des für
seine Domain zuständigen LDAP-Servers authentisch veröffentlicht. Authentizität
und Vertraulichkeit sind für den Nutzer nur dann gegeben, wenn sichergestellt ist,
dass ihm kein falscher öffentlicher Schlüssel eines gewünschten Kommunikationspartners untergeschoben werden kann. Es darf nicht geschehen, dass ein SchlüsselServer fälschlicherweise als nicht erreichbar deklariert wird oder dass dem anfragenden Nutzer fälschlicherweise erklärt wird, der gewünschte Kommunikationspartner
habe keinen Schlüssel veröffentlicht. Die VVV-Lösung stellt daher die Suchanfragen nur an solche Schlüssel-Server, die durch die SRV-RRs auf dem zugehörigen
DNS-Server nachweislich die Schlüssel-Server des Mail-Anbieters sind. Die oben
genannten Mechanismen zum Zusammenspiel mehrerer Verzeichnisdienste sind dazu unnötig, könnten vielmehr die Sicherheit der VVV-Lösung untergraben und dürfen
daher im Rahmen der VVV-Lösung nicht verwendet werden.
4 Verfahren der VVV-Lösung
4.1 Veröffentlichung von OpenPGP-Schlüsseln
Zur Veröffentlichung von OpenPGP-Schlüsseln wird das im Abschnitt 3.1.4 genannte “Erweiterte HKP“ verwendet. Demgemäß wird ein öffentlicher Schlüssel von einem HKP-Server mittels einer HTTP GET-URL in Form eines HTTP-Dokuments mit
eingebettetem OpenPGP-Schlüssel abgerufen. Die Veröffentlichung eines OpenPGPSchlüssels erfolgt mittels HTTP POST-URL. In beiden Fällen liegt der OpenPGPSchlüssel ASCII-kodiert vor, um eine weniger fehleranfällige Übertragung zu ermöglichen.
Ein SRV-RR unter der Mail-Domain stellt Informationen darüber bereit, wo ein oder
mehrere Schlüssel-Server für diese Mail-Domain zu finden ist. Aufbauend auf den
Entwurf des HKP-Protokolls [13] verweist der SRV-RR-Eintrag der VVV-Lösung
auf die verschlüsselten Varianten des HKP-Protokolls. Das HKP-Protokoll wird von
den Open-Xchange-Komponenten und auch von GnuPG verwendet, wenn auch nicht
genau so wie es für VVV benötigt wird. Folgende technische Unterschiede und Erweiterungen zum spezifizierten HKP-Protokoll sind für die VVV-Lösung relevant :
27
1. Es wird das folgende HKPS-Schema verwendet: https://sks.spodhuis.
org.
2. Darin wird HKPS mit Port 443 verwendet, was für HTTPs gebräuchlich ist
und mit Firewalls keine Probleme gibt. Als Service-Kürzel wird _pgpkey-https
verwendet.
3. Die VVV-Lösung sichert das TLS-Zertifikat zur HTTPS-gesicherten Übertragung der SRV-RRs vom DNS-Server mittels DNSSEC/DANE ab.
4. Die VVV-Lösung sichert das TLS-Zertifikat zur HTTPS-gesicherten Übertragung der OpenPGP-Schlüssel vom HKP-Server mittels DNSSEC/DANE ab.
Hinweise und offene Fragen:
• Ein aktueller vom Nutzer autorisierter Schlüssel wird nicht markiert, sondern
gilt allein dadurch als autorisiert, dass er auf dem offiziellen Schlüssel-Server
des Mail-Anbieters verfügbar ist. Ein Mail-Anbieter muss also mit den Schreibrechten auf den Schlüssel-Server sehr restriktiv umgehen. Die Definition von
Sicherheitsmaßnahmen liegt allerdings außerhalb des VVV-Scopes.
• Ein Zurückrufen/ Sperren von öffentlichen OpenPGP-Schlüsseln z. B. bei Verlust oder Kompromittierung, ist nicht Teil der VVV-Lösung. Es reicht, dass
der betroffene Schlüssel vom Schlüssel-Server gelöscht wird, um anzuzeigen,
dass der Nutzer die Verwendung seines evtl. zuvor veröffentlichten öffentlichen
Schlüssels nicht mehr befürwortet. Unabhängig von VVV kann die Sperrung
eines öffentlichen Schlüssels mit den herkömmlichen Mechanismen erfolgen:
Die Sperrung eines S/MIME-Schlüssels in Form eines Eintrags in eine „Certificate Revocation List“ (CRL) durch die CA, die das Zertifikat ausgestellt hatte,
Die Sperrung eines OpenPGP-Schlüssels durch die Veröffentlichung eines Widerrufszertifikats durch den Nutzer auf einem anderen Schlüssel-Server. Die
Ermittlung und Auswertung solcher Sperrinformationen würde den Scope von
VVV weit überschreiten.
• OpenPGP-Schlüssel, die mehrere User-IDs enthalten, stellen kein Problem dar,
weil keine Synchronisation mit anderen Schlüssel-Servern stattfindet und dadurch auch keine Differenzen zum ehemals autorisierten Schlüssel auftreten
können.
• Der Open-Xchange-Server hat bereits eine HKP-Schnittstelle. Diese kann pro
Mailadresse nur einen Schlüssel ermitteln.
28
4.2 Veröffentlichung von S/MIME-Schlüsseln
Die VVV-Lösung setzt voraus, dass die Nutzer bereits Schlüssel und X.509Zertifikate für S/MIME besitzen oder diese außerhalb der VVV-Lösung in einer entsprechenden Anwendung generieren.15
Über die VVV-Lösung werden die X.509-Zertifikate anderen Nutzern zugänglich
gemacht. Dazu muss der Nutzer die Zertifikate aus dem Windows- oder MozillaZertifikatsspeicher exportieren und seinem Mail-Anbieter gemäß der VVV-Lösung
über das VVV-Client-Plugin zur Verfügung stellen, siehe Abschnitte 5.2.1 und 5.2.2.
Der Mail-Anbieter veröffentlicht die Zertifikate gemäß Abschnitt 5.2.3 mittels
LDAP-Protokoll [16]. Folgende Festlegungen zum LDAP-Protokoll sind für die
VVV-Lösung notwendig:
• Die VVV-Lösung verwendet LDAPS mit Port 636 für das Abrufen von
S/MIME-Zertifikaten für S/MIME.16
• Die VVV-Lösung sichert das TLS-Zertifikat zur Kommunikation mit dem
LDAP-Server mittels DNSSEC/DANE ab.
• Das Auslesen aller auf dem Server veröffentlichter Zertifikats- und Nutzerdaten darf nicht möglich sein. Die Suche nach einem Schlüssel soll ausschließlich
mit Angabe einer vollständigen Mail-Adresse möglich sein. Ist in einer Anfrage die Mail-Adresse nicht vollständig angegeben (Wildcard-Anfrage), so soll
kein Ergebnis zurück geliefert werden, selbst dann, wenn ein zur Anfrage passender Eintrag vorliegt. Eine Suche auf Basis der namensgebenden Attribute
eines Nutzers/Zertifikats wird also nicht zugelassen, so dass keine Auflösung
„Name“ nach „Mail-Adresse“ erfolgt. Wildcard- bzw. Teilstring-Suchen werden nicht gestattet. Die Suche anderen Attributen darf nicht möglich sein.
15
Die Nutzer können dazu beispielsweise mit Hilfe der Volksverschlüsselungs-Software für ihre privaten Mail-Adressen kostenlos Schlüssel und Zertifikate für S/MIME beziehen. Die Initiative
„Volksverschlüsselung“ des Fraunhofer SIT ist unter www.volksverschluesselung.de erreichbar. Die Volksverschlüsselungs-Software erzeugt lokal auf dem PC des Nutzers drei RSA 2048Schlüsselpaare für Verschlüsselung, Authentisierung und fortgeschrittene Signatur und lässt die öffentlichen Schlüssel online in der Zertifizierungsstelle des Fraunhofer SIT zertifizieren. Anschließend konfiguriert die Volksverschlüsselungs-Software die lokal vorhandenen Mail-Anwendungen
(Microsoft Outlook und Windows Life Mail, Mozilla Thunderbird) und Browser (Internet Explorer, Mozilla Firefox, Google Chrome) und deren Zertifikatsspeicher, so dass die Schlüssel und
Zertifikate anschließend in den Anwendungen verfügbar sind. In den Anwendungen wird auch der
LDAP-Verzeichnisdienst der Volksverschlüsselung konfiguriert. Der LDAP-Verzeichnisdienst der
Volksverschlüsselung veröffentlicht mit der Einwilligung des Nutzer das Zertifikat für Verschlüsselung und stellt auch Zertifikatssperrlisten („Certificate Revocation Lists“, CRLs) bereit. Über
das „Online Certificate Status Protocol“ (OCSP) kann eine Anwendung, die bereits ein Zertifikat
vorliegen hat, online in Erfahrung bringen, ob dieses Zertifikat in der Zwischenzeit gesperrt wurde.
16
Für LDAPS ist bei IANA der Standard-Port 636 registriert, siehe https://www.iana.org/
assignments/service-names-port-numbers/service-names-port-numbers.txt.
29
• Aus technischer Sicht könnten die oben genannten Restriktionen mittels
LDAP-Filtern auf das mail-Attribut realisiert werden, z. B.: LDAP FILTER
EQUALY ([email protected]). Alle eingehenden Filterterme werden dann auf Filter des mail-Attributs hin untersucht. Ein EQUALYAusgabefilter wird zugelassen, alle anderen Filter (z. B. Filter wie LDAP
FILTER SUBSTR (mail=max@*) oder LDAP FILTER PRESENT (mail=*)
werden verworfen. Es darf nur ein eindeutiges Ergebnis (maximale Größe
der Ergebnismenge = 1) zurückgegeben werden. Somit werden keine Informationen über die intern durchgeführten Operationen oder den Zustand des
LDAP-Servers nach außen kommuniziert.
4.3 VVV-Komponenten
Der Mail-Client ist aus Nutzersicht die zentrale Komponente der MailKommunikation. Mit dem Mail-Client kann der Nutzer seine Mails abrufen, schreiben, lesen und versenden. Es existieren verschiedene Mail-Clients für verschiedene
Betriebssysteme und Plattformen. Grundsätzlich können Mail-Clients und WebMailClients unterschieden werden. Beispiele für weit verbreitete Mail-Clients sind:
• Mozilla Thunderbird: Plattformunabhängiger Mail-Client.
• Open-Xchange: WebMail-Client des Open-Xchange-Servers.
• Microsoft Outlook: Proprietärer Mail-Client für Microsoft Windows und Mac
OS.
• RoundCube: WebMail-Client mit PHP-Backend.
• K9: Mail-Client für Android, der mittels OpenKeyChain auch PGP unterstützt.
Die VVV-Lösung soll beispielhaft für den Mail-Client Thunderbird und dem WebClient von Open-Xchange geschaffen werden. Der Nutzer benötigt dazu ein MailPostfach bei seinem Mail-Anbieter. Ein Nutzer schreibt, liest und bearbeitet seine
Mails entweder mit dem Mail-Client Thunderbird oder mit dem Web-Client von
Open-Xchange. Er besitzt ein grundlegendes Verständnis für das Medium Mail, d. h.
dass das Schreiben, Lesen, Senden sowie Empfangen von Mails normale Arbeitsgänge für ihn sind. Zum Versenden einer verschlüsselten Mail muss der Nutzer in seinem
Mail-Client „Mail verschlüsseln“ (oder ähnliche Benennung) einstellen und die vollständige Mail-Adresse des gewünschten Kommunikationspartner in das Adressfeld
der Mail eintragen. Die VVV-Lösung sorgt für die Beschaffung des für die Verschlüsselung notwendigen öffentlichen Schlüssels des Empfängers von einem SchlüsselServer des betreffenden Mail-Anbieters.
30
Teil der VVV-Lösung ist das frei erhältliche Programm GnuPG, mit dem OpenPGPSchlüssel erstellt und verwaltet werden. GnuPG ist die Verschlüsselungskomponente
welche im Hintergrund von Mail-Clients das Ver- und Entschlüsseln mittels OpenPGP unterstützt. GnuPG ist plattformunabhängig und läuft unter Windows, Linux
und MAC auf den verbreitetsten Betriebssystemen. Seit der Version 2.1.9 wird der
DANE-OPENPGP-Draft von GnuPG unterstützt. Diese Version ist allerdings noch
recht neu und liegt momentan den meisten Linux-Distributionen noch nicht bei.
Im Folgenden werden die VVV-Komponenten kurz dokumentiert, welche im Rahmen des VVV-Projekts entwickelt werden.
4.3.1 VVV-Client-Plugin
Das VVV-Client-Plugin vermittelt zwischen dem Mail-Client (Thunderbird) mit der
zugehörigen Kryptokomponente GnuPG und dem VVV-Server-Plugin zum Veröffentlichen und Löschen von veröffentlichten OpenPGP- und S/MIME-Schlüsseln
durch den Nutzer. Das Plugin stellt die Anfragen an die von der VVV-Lösung
angesprochenen Server (DNS-Server, HKP-Server, LDAP-Server). Es übergibt die
ermittelten kryptographischen Schlüssel im Fall von OpenPGP an die GnuPGKomponente und im Fall von S/MIME direkt an den Mail-Client. Das VVV-ClientPlugin bettet sich in den Mail-Client ein, besitzt aber auch eine eigene grafische Benutzeroberfläche („Graphical User Interface“, GUI), um direkte Eingaben des Nutzers und die Anzeige von Informationen (z. B. Fehlermeldungen) zu ermöglichen.
Bei der Installation des VVV-Client-Plugins für OpenPGP und S/MIME werden die
öffentlich verfügbaren Schlüssel der DNS-Root-Zone17 vorinstalliert, um anschließend dem Plugin in der Anwendung als Sicherheitsanker für die Verifikation der
DNSSEC-Signaturen der SRV-RRs und TLSA-RRs zur Verfügung zu stehen, vgl.
Anwendungsfall in Abschnitt 5.1.
Tabelle 4: Realisierungsmöglichkeiten des VVV-Client-Plugins
Feature
Entwicklung
17
JavaSript, XML User Interface Language (XUL), Cascading Style Sheets (CSS).
Zonenschlüssel der Rootzone: https://www.iana.org/dnssec/files.
31
Aspekt
18
Enigmail
Das Thunderbird-Add-on Enigmail 2.0 wird auch eine
Autokey-Funktion unterstützen, auf die ein VVV-Addon aufbauen könnte. Wie das geht, zeigt das pEp-Add-on
(„pretty Easy privacy“),18 das über Web-Service-Aufrufe
mit Enigmail kommuniziert.
VVVEnigmail
Falls die Enigmail-Schnittstelle für VVV nicht passt,
könnte für VVV ein neuer Entwicklungszweig („Fork“)
erzeugt werden, um ein VVV-spezifisches Enigmail zu
entwickeln. Dann müsste dieses aber kontinuierlich mit der
aktuellen Enigmail-Entwicklung abgeglichen werden. Wir
müssten auch damit umgehen können, dass Nutzer möglicherweise sowohl das originäre Enigmail-Plugin als auch
das VVV-Client-Plugin installiert haben. Zusätzlich müsste S/MIME-Funktionalität entwickelt werden. Idealerweise
würde das Plugin von OpenPGP und S/MIME abstrahieren.
Anbindung
GnuPG
Das VVV-Client-Plugin könnte einen vom HKP-Server
herunter geladenen OpenPGP-Schlüssel direkt der GnuPGKomponente übergeben, d. h. könnte GnuPG über das
Command-Line Interface (CLI) ansprechen. Das bedeutet allerdings, dass das Plugin an die Änderungen der CLI
laufend angepasst werden muss.
DNSResolver
Für die wichtigsten Browser und Betriebssysteme existieren Open Source DNSSEC- und DANE-Validatoren19
(Browser Add-ons in C, C++ und JavaScript) unter Windows, Mac OS X und Linux auf Basis der DNS-Bibliothek
(in C) von ldns.20 Statdns21 bietet DNS- und DNSSECRessourcen (auch DNSSEC-Tools) an. DNSSEC-Tools22
bietet Tools und C-Bibliotheken.
pretty Easy privacy, siehe https://prettyeasyprivacy.com/docs
DNSSEC/TLSA Validator, siehe www.dnssec-validator.cz.
20
Stichting NLnet Labs, siehe www.nlnetlabs.nl/projects/ldns.
21
Frederic Cambus: statdns, siehe www.statdns.com/resources.
22
DNSSEC-Tools, siehe www.dnssectools.org/wiki/index.php?title=DNSSEC_Application_Development.
19
32
4.3.2 VVV-Server-Plugin
Das VVV-Server-Plugin stellt die VVV-Funktionen für den WebMail-Client der OXSuite zur Verfügung. Die OX-Suite beinhaltet eine eigene serverseitige Kryptokomponente, den OX-Guard, welcher u. a. auch einen Schlüsselspeicher integriert hat.
Das Plugin implementiert die im Rahmen der VVV-Lösung entwickelten Protokolle, um die Beschaffung der öffentlichen Schlüssel transparent in die Weboberfläche
zu integrieren. OX-Guard veröffentlicht automatisch den öffentlichen Schlüssel des
Nutzers. DNSSEC wird durch einen entsprechend eingerichteten DNS-Resolver auf
Seiten des Mail-Anbieters umgesetzt.
Hinweise und offene Fragen:
• Die Veröffentlichung des öffentliche Schlüssels des Nutzers ist nicht optional,
sondern wird in jedem Fall durchgeführt, um die Benutzungsfreundlichkeit der
VVV-Lösung zu erhöhen.
• Denkbar ist die zusätzliche Bereitstellung einer Upload/Publish API, um die
clientseitige Schlüsselgenerierung durch den Nutzer im Web-Browser und ein
Hochladen auf den Server zu unterstützen.
• Mehrere User-IDs in den OpenPGP-Schlüsseln wären nur dann ein Problem,
wenn der Schlüssel-Server sich mit anderen HKP-Servern synchronisiert.
Wenn das unterstützt werden würde, dann müssten bei hochgeladenen Schlüsseln alle User-IDs verifiziert werden, da es sonst möglich wäre, dem Kommunikationspartner Schlüssel unterzuschieben.
4.4 Formate der Resource Records
DNS-Server stellen die Zonen und zugehörige Informationen in Form von „Resource
Records“ (RR) öffentlich zur Verfügung. BIND ist der bekannteste DNS-Server und
De-Facto-Standard. PowerDNS ist ein flexibler DNS-Server, der mit unterschiedlichen Backends betrieben werden kann. Für die VVV-Lösung werden „Service Resource Records“ (SRV-RR) gemäß RFC6335 [17] benötigt, um innerhalb der VVVLösung die notwendigen Informationen zu den HKP-Servern und LDAP-Servern zur
Verfügung zu stellen. Sind ein oder mehrere solcher RRs vorhanden, wird damit zugleich kommuniziert, dass die entsprechenden Verfahren von dem Mail-Anbieter unterstützt werden. Die veröffentlichten Schlüssel werden über das TCP-Protokoll angeboten.
SRV-RRs besitzen das folgende Format: _<Service>._<Protocol>.<Name> <TTL>
<Class> SRV <Priority> <Weight> <Port> <Target>, wobei die Bezeichner für den
33
Dienst und das Protokoll als Präfix einen Unterstrich („_“) haben, um Namenskollisionen im selben Namensraum zu vermeiden. „Service“ bezeichnet den symbolischen Namen des Dienstes. Für einen HKP-Server (mit OpenPGP-Zertifikaten) heißt
der Service „_pgpkey-https‘“, für einen LDAP-Server (mit X.509-Zertifikaten für S/MIME) „ldaps“.
Des Weiteren bezeichnet „Protocol“ den symbolischen Namen des zu verwendenden
Netzwerkprotokolls und „Name“ die Domain, für die der Resource Record gilt. Die
„TTL“ (Time To Live) des Resource Records gibt an, wie viele Sekunden die Namensauflösung gültig bleibt, d. h. in dieser Zeitspanne kann auf das DNS-Caching
zurückgegriffen werden. Als „Class“ wird bei SRV-RRs „IN“ als Klasse (für Internet) angegeben. „Priority“ bezeichnet die Priorität, mit der der Server die Anfragen
behandelt. „Weight“ gibt die Gewichtung des Eintrags an und wird u. a. für LoadBalancing genutzt, wenn am Ziel-Host-Rechner parallel mit derselben Priorität angefragt wird. „Port Number“ bezeichnet den Port, über den der Server den Dienst
anbietet. „Target“ ist der voll qualifizierte Domain-Name des Ziel-Host-Rechners.
Die Veröffentlichung der SRV-RRs erfolgt unter der entsprechenden Mail-Domain.
Beispielsweise würden für die Mail-Domain maildomain.net die RRs die folgenden Bezeichnungen besitzen: _pgpkey-https._tcp.maildomain.net sowie _ldaps._tcp.maildomain.net. Die RRs sind folgendermaßen formatiert:
Listing 1: Muster des SRV-RR für HKP
\_pgpkey−https.\_tcp.<Name> <TTL> IN SRV 10 0 443 <Target>
Listing 2: Beispiel eines SRV-RR für HKP
\_pgpkey−https.\_tcp.maildomain.net 3600 IN SRV 0 0 443 hkp.maildomain.net
Listing 3: Muster des SRV-RR für LDAP
_ldaps._tcp.<Name> <TTL> IN SRV 0 0 636 <Target>
Listing 4: Beispiel eines SRV-RR für LDAP
_ldaps._tcp.maildomain.net 3600 IN SRV 0 0 636 ldap.maildomain.net
34
5 Anwendungsfälle der VVV-Lösung
Die VVV-Lösung vereinfacht das Verschlüsseln von Mails durch den Nutzer mit
OpenPGP oder S/MIME, indem ein VVV-Plugin die Schlüssel der Kommunikationspartner automatisch ermittelt und der Mail-Anwendung zur Verfügung stellt, siehe Abschnitte 5.3 und 5.4. Die Szenarien der Veröffentlichung von Schlüsseln und
der clientseitig bzw. serverseitig unterstützten Mailverschlüsselung zeigen die Abbildungen 3, 4 und 5.
Abbildung 3: VVV-Szenario der Veröffentlichung von Schlüsseln durch den Client
Den Szenarien der Schlüsselveröffentlichung sowie der client- und der serverseitigen
Verschlüsselung von Mails liegen aus Sicht des Nutzers mehrere Anwendungsfälle
zugrunde, die in den folgenden Abschnitten beschrieben werden. Das Veröffentlichen
von Schlüsseln, die auf Serverseite verwaltet werden und das Einstellen der SRVRR für einen HKP-Server (für OpenPGP) und einen LDAP-Server (für S/MIME)
sind keine Anwendungsfälle, in denen VVV-Komponenten involviert wären, sondern
erfolgen durch einen Administrator des Mail-Anbieters.
Hinweise und offene Fragen:
• Nach dem derzeitigen HKP-Protokoll kann zu einer Mail-Adresse nicht mehr
als ein OpenPGP-Zertifikat auf dem Server hinterlegt werden. Das ist auch
nicht nötig. Ein OpenPGP-Zertifikat kann neben dem öffentlichen Hauptschlüssel optional auch mehrere öffentliche Unterschlüssel (für Verschlüsselung, Signatur, Authentisierung) enthalten.
35
Abbildung 4: VVV-Szenario der clientseitigen Verschlüsselung von Mails
Abbildung 5: VVV-Szenario der serverseitigen Verschlüsselung von Mails
• Für S/MIME macht eigentlich nur die Veröffentlichung des Verschlüsselungszertifikats Sinn, auch wenn es daneben noch Zertifikate für Signatur und Authentisierung geben sollte. Denn beim Signieren einer Mail wird das zugehörige Signaturzertifikat automatisch an die Mail gehängt (zusätzlich auch das
Verschlüsselungszertifikat), so dass der Empfänger für die Verifikation der
Signatur nicht das Signaturzertifikat suchen muss. Ebenso muss im Kontext
einer Client-Authentisierung nicht nach einem Authentisierungszertifikat ge-
36
sucht werden, da ein Authentisierungsprotokoll in der Regel die Übermittlung
des Zertifikats durch den Client an den Server mit einschließt. Mail-ClientImplementierungen scheinen ohnehin Probleme mit mehreren veröffentlichten
Zertifikaten pro Mail-Adresse zu haben, zumindest hat Mozilla Thunderbird
damit ein Problem.
• Für das Hochladen eines öffentlichen Schlüssels durch den Nutzer, könnte der
Mail-Anbieter zusätzlich ein Web-Interface anbieten. Für ein Hochladen direkt
aus dem VVV-Plugin heraus ist eine Web-API mit Anmeldung vorgesehen. Alternativ könnte man hier eine Mail-Schnittstelle wie im Draft [11] beschrieben
umsetzen.
• Vorausgesetzt dass sich das Unternehmen die privaten Schlüssel der Nutzer
vorhalten möchte, wird ein Administrator der Mail-Domain vom Unternehmen damit beauftragt, für die Mitarbeiter sowohl die öffentlichen als auch die
privaten Schlüssel zu verwalten. Das Verwalten von privaten Schlüsseln liegt
allerdings nicht im Scope des VVV-Projekts.
37
5.1 UC 0: VVV-Client-Umgebung einrichten
Tabelle 5:
UC 0: VVV-Client-Umgebung einrichten
Beschreibung
Der Nutzer installiert für den Mail-Client Thunderbird
das VVV-Client-Plugin, siehe UC 0.1 in Abschnitt 5.1.1.
Anschließend kann der Nutzer DNSSEC-Schlüssel von
einem oder mehreren Mail-Anbietern installieren, siehe
UC 0.2 in Abschnitt 5.1.2.
Beteiligte
Komponenten
Browser, Mail-Client, VVV-Client-Plugin.
Enthaltene
Anwendungsfälle
UC 0.1, UC 0.2.
Vorbedingungen
Der Nutzer hat den Mail-Client Thunderbird installiert.
Ein Browser ist eingerichtet und hat Zugriff auf das Internet.
Ergebnis
Das VVV-Client-Plugin ist installiert und bereit zur Veröffentlichung von clientseitigen Schlüsseln.
Hinweise und offene Fragen:
• Add-ons, beispielsweise Erweiterungen (Extensions) und Plugins, sind technisch gesehen Zip-Archive, die Quellcode-Dateien enthalten und die Dateiendung .xpi besitzen. Dabei kann es sich intern beispielsweise um Text-Dateien
(.txt), JavaScript (.js), XUL (.xul), XML (.xml), aber auch um andere handeln.
• Bei der Installation des VVV-Client-Plugins für OpenPGP und S/MIME werden die öffentlich verfügbaren Schlüssel der DNS-Root-Zone23 automatisch
vorinstalliert, um anschließend dem Plugin in der Anwendung als Sicherheitsanker für die Verifikation der DNSSEC-Signaturen der SRV-RRs und der
TLSA-RRs zur Verfügung zu stehen. Um die Sicherheit und Vertraulichkeit
der abrufbaren Schlüssel weiter zu erhöhen, können die Benutzer zusätzlich
den Schlüssel ihres Mail-Anbieters im VVV-Client-Plugin hinterlegen, siehe
UC 0.2 in Abschnitt 5.1.2.
23
Zonenschlüssel der Rootzone: https://www.iana.org/dnssec/files .
38
• Im Falle eines Key-Rollover des Root-Schlüssels muss ein Update des Plugins erfolgen. Das Nachladen eines weiteren oder neuen DNS-Schlüssels eines
Mail-Anbieters kann manuell im Plugin angestoßen werden.
39
5.1.1 UC 0.1: VVV-Client-Plugin installieren
Tabelle 6:
UC 0.1: VVV-Client-Plugin installieren
Beschreibung
Der Nutzer lädt sich mittels Browser von einem VVVDownload-Server das signierte VVV-Client-Plugin möglichst auf ein lokales Laufwerk (z. B. auf den Desktop)
herunter und klickt darauf, um die Installation zu starten.
Download und Installation können auch direkt mit dem
Thunderbird-Add-ons-Manager erfolgen. Der WindowsInstaller oder Thunderbird überprüft die Signatur des Installationspakets und zeigt dessen Herausgeber an. Das
Plugin installiert sich automatisch in den Mail-Client
Thunderbird.
Beteiligte
Komponenten
Browser, Mail-Client, VVV-Client-Plugin.
Vorbedingungen
Der Nutzer hat den Mail-Client Thunderbird installiert.
Ein Browser ist eingerichtet und hat Zugriff auf das Internet.
Ergebnis
Das VVV-Client-Plugin ist installiert.
Hinweise und offene Fragen:
• Beim Herunterladen von Add-ons werden diese von manchen Browsern (Internet Explorer) irrtümlich entpackt. Beispielsweise können sich Browser
am angegebenen „Content-Type“ orientieren, der evtl. vom Download-Server
falsch (oder gar nicht) gesetzt ist. Wird die Plugin-Download-Datei z. B. als
„text/html“ gekennzeichnet, könnte der Browser versuchen, die Zip-Datei
intern direkt intern zu öffnen. Beispiel eines geeigneten HTTP-Headers:
Content-Type: application/x-xpinstall, Content-Disposition:
attachment; filename=„plugin.xpi“. Ein Entpacken durch den Browser
führt jedenfalls dazu, dass die geladenen Dateien für den Thunderbird-Addons-Manager nicht mehr nutzbar sind. Ein unpassendes Entpacken kann man
dadurch verhindern, dass man zum Herunterladen Rechtsklick -> Ziel speichern unter ... verwendet. Zum Download sollte Firefox verwendet werden.
Download und Installation können auch direkt mit dem Thunderbird-Add-onsManager erfolgen.
40
• Wenn der Windows-Installer nicht startet, liegt es häufig daran, dass die Datei nicht auf ein lokales Laufwerk kopiert wurde, sondern auf ein Netzlaufwerk. Installationsprogramme laufen mit erhöhten Rechten in einem separaten
Admin-Kontext und lassen sich daher evtl. nicht direkt von einer NetzwerkFreigabe aus starten.
• Für die Installation ist die aktuelle .NET-Umgebung wichtig, d. h. das PluginInstallationspaket bringt die aktuelle Version mit. Die anfängliche SetupAnwendung muss ein natives Programm sein, das keine .NET-Umgebung erfordert. Das Setup prüft, ob die vorliegende .NET-Umgebung aktuell ist, ansonsten wird sie neu installiert.
• Damit der Herausgeber des VVV-Client-Plugin vom Installer bzw. von Thunderbird verifiziert werden kann, so dass der Nutzer bei der Installation nicht
mit einer irritierenden Sicherheitswarnung konfrontiert wird, sollte das Installationspaket mit einen Schlüssel signiert sein („Code Signing“), der beispielsweise von einer CA wie GlobalSign24 zertifiziert wurde. Das Root-Zertifikat
einer solchen CA ist im Zertifikatsspeicher von Microsoft bzw. von Mozilla
(Firefox, Thunderbird) vorinstalliert.
24
Code Signing Certificates von GlobalSign, siehe www.globalsign.com/en/code-signingcertificate . Andere Anbieter, siehe https://globalprotec.com/de/anbieter .
41
5.1.2 UC 0.2: DNSSEC-Schlüssel eines Mail-Anbieters importieren
Tabelle 7:
UC 0.2: DNSSEC-Schlüssel eines Mail-Anbieters importieren
Beschreibung
Der Nutzer lädt sich mittels VVV-Client-Plugin den öffentlichen DNSSEC-Schlüssel eines beliebigen MailAnbieters herunter.
Beteiligte
Komponenten
VVV-Client-Plugin.
Vorbedingungen
Der Nutzer hat den gewünschten DNSSEC-Schlüssel eines
Mail-Anbieters installiert.
Ergebnis
Das VVV-Client-Plugin ist bereit zur Veröffentlichung von
clientseitigen Schlüsseln.
Hinweise und offene Fragen:
• Um die Sicherheit und Vertraulichkeit der abrufbaren Schlüssel weiter zu
erhöhen, können die Benutzer zusätzlich zu den vorinstallierten DNS-RootSchlüsseln den Schlüssel ihres Mail-Anbieters im VVV-Client-Plugin hinterlegen:
(1) Der Mail-Anbieter stellt den Schlüssel der betreffenden DNS-Zone mit einer entsprechenden Anleitung auf einer Website zur Verfügung.
(2) Der Nutzer trägt die Adresse dieses Mail-Anbieter-Schlüssels in das VVVClient-Plugin ein.
(3) Das VVV-Client-Plugin importiert den Schlüssel, ermittelt die Schlüssel
der höheren Domains bis hin zum DNS-Root-Schlüssel.
(4) Das VVV-Client-Plugin prüft die Signaturen der importierten Schlüssel
und überprüft, dass der ermittelte DNS-Root-Schlüssel mit einem vorinstallierten DNS-Root-Schlüssel übereinstimmt. Das VVV-Client-Plugin
weist ggf. auf Unstimmigkeiten hin. Im Negativfall muss der Nutzer darüber aufgeklärt werden, dass es Sicherheitsbedenken gibt. Das Plugin sollte zuvor seine eigene Aktualität überprüfen, muss evtl. aktualisiert werden,
um die aktuellen DNS-Root-Schlüssel zu kennen. Dazu soll das Klicken
auf ein Update-Button genügen. Das Plugin sollte auch über eine Liste veralteter DNS-Root-Schlüssel verfügen für die Fälle, in denen Mail-Anbieter
42
ihre DNSSEC-Schlüssel nicht schnell genug aktualisieren. In solchen Fällen würde ein Hinweis genügen, ein Abbruch ist nicht notwendig.
• Die DNSSEC-Schlüssel in der Kette zwischen dem Schlüssel des MailAnbieters und dem Root-Schlüssel können sich ändern, sollten daher regelmäßig geprüft und ggf. erneut abgerufen werden. Daher werden diese Schlüssel
besser nicht im Plugin gespeichert (gecached, importiert). Falls es irgendwo
(z. B. im Zertifikatsspeicher des Betriebssystems) die Möglichkeit gibt, die
Schlüssel der gesamten Kette einzusehen bzw. zu verwalten, sollten dort nur
Schlüssel aufgenommen sein, die der Nutzer manuell und bewusst importiert
hat (abgesehen von den DNS-Root-Schlüsseln im VVV-Client-Plugin).
• Für die nachfolgenden Anwendungsfälle ist es wichtig, dass lokal im MailClient ein E-Mail-Account eingerichtet ist, zu dem ein Schlüsselpaar für die
Mail-Verschlüsselung vorliegt, dessen öffentlicher Teil auf einem SchlüsselServer des Mail-Anbieters veröffentlicht werden kann. Für die Nutzung von
OpenPGP-Schlüsseln müssen lokal die Thunderbird-Erweiterung Enigmail
und die GnuPG-Komponente installiert sein. Schön wäre es, wenn das Plugin das schon bei der Installation überprüfen könnte. Dabei muss der Nutzer
allerdings bereits wissen, ob er OpenPGP nutzen möchte. Das Plugin könnte
ihn bei der Entscheidung unterstützen. Aber was wäre, wenn später ein weiteres Verfahren genutzt werden soll? Um das die VVV-Lösung bedienbar und
nachvollziehbar zu machen, sollte das Plugin prüfen, ob Enigmail und GnuPG
installiert sind, wenn OpenPGP einrichtet und konfiguriert wird.
43
5.2 UC 1: Clientseitigen Schlüssel auf Schlüssel-Server
veröffentlichen
Tabelle 8:
UC 1: Clientseitigen Schlüssel auf Schlüssel-Server veröffentlichen
Beschreibung
Der Nutzer lässt zu einer bestimmten Mail-Adresse einen
öffentlichen Schlüssel (OpenPGP oder S/MIME) auf einem Schlüssel-Server veröffentlichen.
Beteiligte
Komponenten
Mail-Client, GnuPG, VVV-Client-Plugin, VVV-ServerPlugin, HKP-Server, LDAP-Server.
Enthaltene
Anwendungsfälle
UC 1.1, UC 1.2., UC 1.3
Vorbedingungen
Nutzer besitzt ein Schlüsselpaar für OpenPGP oder S/MIME. Im Falle von S/MIME muss der öffentliche Schlüssel
als X.509-Zertifikat vorliegen.
Ergebnis
Der Schlüssel ist auf dem HKP-Server bzw. LDAP-Server
des Mail-Anbieters veröffentlicht.
Hinweise und offene Fragen:
• Der Nutzer muss zuvor ein OpenPGP-Schlüsselpaar bzw. ein Schlüsselpaar für
S/MIME generiert und zertifiziert haben. Neben einem Mail-Account benötigt
der Nutzer dazu für OpenPGP spezielle Komponenten, muss für OpenPGP oder
S/MIME u. a. einen ausreichend sicheren Algorithmus und eine entsprechende
Schlüssellänge ausgewählt haben. Im Falle von S/MIME kann das Schlüsselpaar durch den Mail-Client selbst erzeugt werden. Der öffentliche Schlüssel
kann selbst signiert oder von einer externen Zertifizierungsstelle signiert sein.
Der private Schlüssel und das Zertifikat wurden im Schlüsselspeicher des MailClients bzw. der OpenPGP-Komponente (GnuPG) abgelegt.
• Der Nutzer muss den Besitz des privaten Schlüssels und den Zugriff auf das
Mail-Postfach gegenüber dem Mail-Anbieter nachweisen und lädt über das
VVV-Client-Plugin den öffentlichen Schlüssel ggf. mit zugehörigem Zertifikat auf den Mail-Server, siehe UC 1.2 in Abschnitt 5.2.2. Der Mail-Anbieter
veröffentlicht den Schlüssel auf dem HKP-Server bzw. LDAP-Server, siehe UC
1.3 in Abschnitt 5.2.3.
44
• Die Schnittstelle einschließlich Authentisierung des Nutzers zum Hochladen
und Löschen von OpenPGP- und S/MIME-Schlüsseln sollte näher spezifiziert
werden. Weil es viele unterschiedliche Anmeldeverfahren gibt, dürfte aber kein
bestimmtes Verfahren vorgeschrieben werden. Im Folgenden werden nur Empfehlungen für die technische Implementierung dieser Anmeldeverfahren gegeben. Das Plugin führt als „Assistent“ den Nutzer durch die notwendigen Schritte.
45
5.2.1 UC 1.1: Clientseitigen Schlüssel auf dem Client registrieren
Tabelle 9:
UC 1.1: Clientseitigen Schlüssel auf dem Client registrieren
Beschreibung
Der Nutzer ruft das VVV-Client-Plugin auf, um einen existierenden öffentlichen Schlüssel auszuwählen. Im Fall von
OpenPGP wird über den Mail-Client der Schlüssel mit
zugehöriger User-ID der GnuPG-Komponente entnommen. Im Fall von S/MIME liest das VVV-Client-Plugin
den Schlüssel aus dem Zertifikatsverzeichnis des MailClients.
Beteiligte
Komponenten
VVV-Client-Plugin, Mail-Client, GnuPG.
Vorbedingungen
Nutzer besitzt ein Schlüsselpaar für OpenPGP oder S/MIME und im Falle von S/MIME ein zugehöriges Zertifikat.
Ergebnis
Das VVV-Client-Plugin hat den öffentlichen Schlüssel, um
ihn im nächsten Schritt (UC 1.2 im Abschnitt 5.2.2) auf
den Mail-Server zu laden.
Hinweise und offene Fragen:
• Das VVV-Client-Plugin greift für den OpenPGP-Schlüssel direkt (evtl. mittels
der Funktionen von Enigmail) auf den Keystore von GnuPG zu. Die User-ID
soll dabei durch das VVV-Client-Plugin sowohl vor dem Hochladen als auch
vor dem Abrufen (siehe UC 2.3 in Abschnitt 5.3.3 auf Korrektheit geprüft werden, d. h. die Signaturen müssen gültig sein und die User-ID muss genau eine Mail-Adresse enthalten, die mit der Mail-Adresse, für die der Nutzer den
Zugriff gegenüber dem Mail-Anbieter nachgewiesen hat, übereinstimmt. Die
User-ID zusätzlich auf Serverseite zu prüfen, bringt keinen wirklichen Vorteil,
da man ohnehin von einem gutwilligen Mail-Anbieter ausgehen muss. Beim
Abrufen eines Schlüssels wird erneut geprüft, damit auf Seiten des Nutzers eine Manipulation des Schlüssels auf Serverseite ausgeschlossen werden kann.
Die Mechanismen des Web-of-Trust (vgl. die 3. Ebene des Vertrauensmodells
in Abschnitt 2.3) werden davon nicht berührt, sind aber nicht mehr entscheidend, da der Mail-Anbieter die entscheidende Rolle im VVV-Vertrauensmodell
innehat.
46
• Das VVV-Client-Plugin greift für den S/MIME-Schlüssel direkt auf den Keystore von Thunderbird zu.
• Die Qualität des Schlüssels wird durch das Plugin überprüft: Verfahren (OpenPGP oder S/MIME), Algorithmus (RSA, DSA, ElGamal, bestimmte ECCKurven), Schlüssellänge, Schlüsselaufbau (verschiedene User-IDs bei OpenPGP), ...
• Das Plugin führt als „Assistent“ den Nutzer durch die folgenden Schritte:
1. Der Nutzer startet das Plugin und wählt „Verschlüsselung einrichten“.
2. Das Plugin sucht nach Mail-Accounts, die im Mail-Client eingerichtet
sind, und zeigt sie dem Nutzer zur Auswahl.
3. Der Nutzer wählt eine bestimmte Mail-Adresse aus.
4. Das Plugin ermittelt anhand verfügbarer SRV-RRs der Mail-Domain, ob
der Mail-Anbieter des Mail-Accounts Schlüssel auf einem SchlüsselServer veröffentlicht.
5. Das Plugin sucht lokal auf dem PC des Nutzers im Zertifikatsspeicher des
Mail-Clients nach öffentlichen Schlüsseln des Nutzers und zeigt sie dem
Nutzer an.
6. Der Nutzer wählt einen Schlüssel aus. Wenn kein Schlüssel vorhanden
ist, wird das Programm verlassen. Das Plugin soll an dieser Stelle auf die
Volksverschlüsselung verweisen, mit deren Hilfe sich der Nutzer Schlüssel generieren und zertifizieren lassen kann.
47
5.2.2 UC 1.2: Clientseitigen Schlüssel auf dem Server registrieren
Tabelle 10:
UC 1.2: Clientseitigen Schlüssel auf dem Server registrieren
Beschreibung
Das VVV-Client-Plugin meldet sich mit seinem Mailkonto
an und sendet den in UC 1.1 (siehe Abschnitt 5.2.1) ausgewählten Schlüssel an den Mail-Server. Der Mail-Server
sendet einen mit dem öffentlichen Schlüssel verschlüsselten Verifikationscode an das VVV-Client-Plugin. Das
VVV-Plugin übergibt den verschlüsselten Verifikationscode an den Mail-Client bzw. die GnuPG-Komponte zur
Entschlüsselung und sendet anschließend den entschlüsselten Verifikationscode an den Mail-Server zurück. Ist
die Verifikation erfolgreich durchgeführt, dann wird der
Schlüssel auf dem entsprechenden Server veröffentlicht,
siehe UC 1.3 in Abschnitt 5.2.3.
Beteiligte
Komponenten
VVV-Client-Plugin, Mail-Client, Mail-Server.
Vorbedingungen
Das VVV-Client-Plugin hat den hochzuladenden Schlüssel
erhalten, siehe UC 1.1 in Abschnitt 5.2.1.
Ergebnis
Der Mail-Server hat den öffentlichen Schlüssel und den
korrekten Verifikationscode vom VVV-Client-Plugin erhalten.
Hinweise und offene Fragen:
• Der Nutzer authentisiert sich gegenüber dem Mail-Server über das VVVClient-Plugin mittels HTTPS-Anmeldung. Die Authentisierungsdaten sind wie
gewohnt die Mailadresse (Benutzerkonto) und ein Passwort oder OTP-Token.
• Ein Nachteil dieses Ablaufs ist, dass der Zugriff auf das Mail-Postfach nicht
direkt durch das Versenden einer Mail an die gegebene Mail-Adresse verifiziert
wird, sondern implizit nur durch die HTTPS-Anmeldung beim Mail-Anbieter.
• Nach einer gewissen Zeit sollte ein begonnener Schlüssel-Upload verworfen
werden, falls der Upload nicht bis zum Ende durchgeführt und verifiziert werden kann. Vorschlag: Nach 10 min. werden unvollendete Vorgänge abgebrochen.
48
• Das Plugin führt als „Assistent“ den Nutzer durch die folgenden Schritte:
1. Das Plugin vermittelt die Authentisierung gegenüber dem Mail-Server
(„HTTP-Session öffnen“). Der Nutzer gibt das Zugangspasswort ein.
2. Das Plugin lädt anschließend den Schlüssel auf den Mail-Server. Der
Mail-Server sendet einen verschlüsselten Verifikationscode an das Plugin
zurück.
3. Das Plugin übergibt den verschlüsselten Verifikationscode an den MailClient bzw. an GnuPG zur Entschlüsselung und informiert den Nutzer
darüber, dass im Hintergrund der private Schlüssel verwendet werden
muss und daher eine Passwort-Eingabe nötig wird.
4. Der Nutzer wird durch Client bzw. GnuPG zur Passworteingabe für den
privaten Schlüssel aufgefordert, falls der Schlüssel passwortgeschützt ist
und noch keine Eingabe des Passworts erfolgt ist.
5. Nach erfolgreicher Passwort-Eingabe entschlüsselt der Mail-Client bzw.
die GnuPG-Komponente den Verifikationscode und übergibt ihn unverschlüsselt dem Plugin.
6. Das Plugin sendet den Verifikationcode transportverschlüsselt an den
Mail-Server.
49
5.2.3 UC 1.3: Schlüssel auf Schlüssel-Server veröffentlichen
Tabelle 11:
UC 1.3: Schlüssel auf Schlüssel-Server veröffentlichen
Beschreibung
Der Schlüssel wird durch den Mail-Server auf dem HKPServer bzw. LDAP-Server veröffentlicht.
Beteiligte
Komponenten
Mail-Server, VVV-Server-Plugin, HKP-Server, LDAPServer.
Vorbedingungen
Der VVV-Server-Plugin hat den öffentlichen Schlüssel und
den korrekten Verifikationscode vom VVV-Client-Plugin
erhalten.
Ergebnis
Der öffentliche Schlüssel des Nutzers ist auf dem HKPServer bzw. LDAP-Server veröffentlicht.
Hinweise und offene Fragen:
• Im Falle eines serverseitigen Schlüssels ist aus Nutzersicht die Veröffentlichung des Schlüssels kein eigener Schritt sondern wird automatisch im Hintergrund durchgeführt.
• Der Schlüssel wird auf dem Schlüssel-Server veröffentlicht. Falls bereits ein
Schlüssel gleicher Art vorliegt, wird der Nutzer darüber informiert. Mit Zustimmung des Nutzers wird der bisherige Schlüssel gelöscht und durch den
neuen Schlüssel ersetzt.
• Eine Rückmeldung an den Nutzer, dass der Schlüssel tatsächlich hochgeladen
wurde, ist sinnvoll. Wenn es schnell geht, könnte man eine solche Bestätigung
über das Plugin anzeigen. In jedem Fall, insbesondere wenn es mehr Zeit benötigt als man dem Nutzer gerade zumuten kann, sendet der Mail-Server eine
Bestätigungsmail an den Nutzer.
50
5.3 UC 2: Clientseitig verschlüsselte Mail senden
UC 2: Clientseitig verschlüsselte Mail senden
Beschreibung
Der Nutzer verfasst in seinem Mail-Client eine Mail,
hat „Mail verschlüsseln“ eingestellt und trägt eine MailAdresse in das Empfängerfeld ein. Das VVV-ClientPlugin sucht mit der eingetragenen Mail-Adresse nach
dem entsprechenden Schlüssel des Empfängers. Dazu
fragt das Plugin das DNS nach der DNS-Server-Adresse
der Mail-Domain des Empfängers. Mit der empfangenen Information ruft das Plugin vom DNS-Server des
Mail-Anbieters des Empfängers die entsprechenden
SRV-RRs der Schlüssel-Server ab. Das Plugin überprüft
die DNSSEC-Signaturen der SRV-RRs und fragt die
Schlüssel-Server nach den Schlüsseln des Empfängers.
Das VVV-Client-Plugin übergibt schließlich mindestens
einen Schlüssel des Empfängers an den Mail-Client, der
schließlich die Mail verschlüsselt und absendet.
Beteiligte
Komponenten
VVV-Client-Plugin, DNS-Server, HKP-Server, LDAPServer.
Enthaltene
Anwendungsfälle
UC 2.1, UC 2.2, UC 2.3.
Vorbedingungen
–
Ergebnis
Mindestens ein Schlüssel des Empfängers wurde ermittelt,
Mail konnte verschlüsselt versendet werden.
Hinweise und offene Fragen:
• Das VVV-Client-Plugin sieht zunächst nach, welches Verschlüsselungsverfahren (OpenPGP oder S/MIME) der Nutzer für die zu sendende Mail ausgewählt
hat. Im Mail-Client Thunderbird kann man beide Verfahren parallel konfiguriert haben und nutzen, allerdings nicht innerhalb einer einzelnen Mail. S/MIME wird von Thunderbird direkt unterstützt, OpenPGP durch das zusätzlich
installierte Enigmail-Plugin.
• Das VVV-Client-Plugin soll Rückmeldung an den Nutzer geben, wenn zu dem
gewählte Verschlüsselungsverfahren kein Schlüssel gefunden wird, evtl. kurze
Empfehlung, je nach gefundenen Schlüsseln das andere Verfahren einzustellen.
Ablauf: 1) Für welche Verfahren gibt es eigene Schlüssel? 2) Unterstützt der
51
Empfänger eines oder mehrere dieser Verfahren (indem entsprechende Schlüssel abrufbar sind)? Falls mehrere Kombinationen existieren, wird das voreingestellte Verfahren verwendet. Wenn die Schlüssel / Verfahren nicht zusammen
passen, werden Hinweise gegeben.
• Das VVV-Client-Plugin soll in jedem Fall aktiv werden, auch dann, wenn der
Mail-Client vor dem Absenden lokal einen Schlüssel finden konnte. Es könnte
z. B. sein, dass der lokale Schlüssel nicht mehr aktuell bzw. auf dem Server
bereits gelöscht ist. Das Plugin wird bereits vor dem Klicken auf den SendeButton aktiv und könnte dem Nutzer daher rechtzeitig eine Rückmeldung geben, z. B. die Adressen in der Adresszeile entsprechend einfärben (beispielsweise: rot = es wurde kein Schlüssel gefunden; gelb = es wurde lokal ein
Schlüssel gefunden, der allerdings nicht auf dem Schlüssel-Server vorhanden
ist; grün = Schlüssel wurde auf einem VVV-konformen Schlüssel-Server gefunden).
• Im Fall von mehreren Empfängern, die teils nur S/MIME-, teils nur OpenPGPSchlüssel besitzen, soll der Versand abgebrochen und der Nutzer darüber informiert werden.
52
5.3.1 UC 2.1: Information zu den Schlüssel-Servern finden
Tabelle 13:
UC 2.1: Information zu den Schlüssel-Servern finden
Beschreibung
Der Mail-Client ruft mit Angabe einer Mail-Adresse und
des eingestellten Verschlüsselungsverfahrens (OpenPGP oder S/MIME) das VVV-Client-Plugin bzw. VVVServer-Plugin auf, um einen öffentlichen Schlüssel des
Empfängers zu bekommen. Das VVV-Client-Plugin bzw.
VVV-Server-Plugin fragt das DNS nach dem DNS-Server
des Mail-Anbieters der eingegebenen Mail-Adresse zu
den SRV-RRs und den DNSSEC-spezifischen RRs der
Schlüssel-Server.
Beteiligte
Komponenten
Mail-Client, VVV-Client-Plugin bzw. VVV-Server-Plugin,
DNS-Server.
Vorbedingungen
Der Nutzer erstellt im Mail-Client eine neue Mail, hat
„Nachricht verschlüsseln“ eingestellt und im EmpfängerAdressfeld eine Mail-Adresse eingetragen.
Ergebnis
Das VVV-Client-Plugin bzw. VVV-Server-Plugin besitzt
die SRV-RRs zu den Schlüssel-Servern des Mail-Anbieters
der eingegebenen Mail-Adresse.
Hinweise und offene Fragen:
• Auch wenn der Mail-Client lokal einen öffentlichen Schlüssel des Empfängers
hat, muss das VVV-Plugin dennoch auf dem Schlüssel-Server nachsehen, da an
keinem Schlüssel ersichtlich ist, ob er aktuell und „VVV-autorisiert“ ist. Das
Plugin führt weder eine lokale Schlüsselsuche durch noch speichert es einen
gefundenen Schlüssel in einem lokalen Schlüsselspeicher.
• Machen die Anwendungen Probleme, wenn ihnen ein abgelaufener Schlüssel
vom Server angeboten wird? Besser ist es, einen abgelaufenen Schlüssel anzubieten, als gar nicht verschlüsseln zu können. Der Nutzer soll darüber informiert werden.
• Wie wird der DNS-Server des Mail-Anbieters gefunden? Im DNS werden die
gesuchten DNS-Server direkt mit beispielsweise dig ns mailbox.org plus dnssec ermittelt.
53
• Soll die Anfrage in jedem Fall alle verfügbaren SRV-RRs zurückliefern? Bei
Angabe des gewünschten Verfahrens würde auch eine Server-Adresse (HKPServer oder LDAP-Server) reichen. Allerdings könnte die Frage, welches Verfahren der Empfänger nutzt bzw. eine Gruppe von Empfängern bedienen kann,
zu diesem Zeitpunkt noch offen sein, da anschließend vom Nutzer noch weitere
Empfänger-Adressen eingetragen werden könnten.
• Das Konzept sollte auch vorsehen, dass es mehrere Schlüssel-Server und
LDAP-Server geben kann, um großen Mail-Anbietern die Skalierung zu ermöglichen. Im Demonstrator muss dies aber nicht unbedingt realisiert werden.
Es geht dabei vor allem um die Lastverteilung im Netzwerk, denn alle Server
des gleichen Dienstes müssen denselben Datenbestand haben.
Das Plugin soll automatisch die unterstützten Verfahren für den Schlüsseltausch ermitteln, um dem Benutzer das passende Verfahren für eine Auswahl anzubieten und
ihn bei der Entscheidung zu unterstützen. Technisch wird dem VVV-Client-Plugin
bzw. VVV-Server-Plugin das Verschlüsselungsverfahren über das Vorhandensein eines entsprechenden SRV-RR signalisiert. Die SRV-RR sind verpflichtend25 und mit
deren Hilfe signalisiert der Mail-Anbieter, für welche Verfahren er einen SchlüsselServer unter welcher URL bzw. IP zur Verfügung stellt. Die Funktion und das Format
sind bei dem jeweiligen Verschlüsselungsverfahren definiert.
Die DANE-Spezifikation RFC6698 [3] geht im TLSA-Protokoll davon aus, dass
eine TLS-Verbindung zum Server aufgebaut wird und dass der Server beim TLSHandshake sein TLS-Zertifikat übergibt.26
25
26
In den zugrunde liegenden Standards sind diese i.d.R. optional.
Siehe https://tools.ietf.org/html/rfc6698#section-2.1 .
54
5.3.2 UC 2.2: DNSSEC-Signaturen prüfen
Tabelle 14:
UC 2.2: DNSSEC-Signaturen prüfen
Beschreibung
Das VVV-Client-Plugin bzw. VVV-Server-Plugin validiert die DNSSEC-Signaturen der SRV-RRs für die MailDomain eines Mail-Anbieters und extrahiert nach erfolgreicher Prüfung die Informationen über die Adressen, die
Ports und ggf. die Verfahrensversionen der SchlüsselServer.
Beteiligte
Komponenten
VVV-Client-Plugin bzw. VVV-Server-Plugin, DNS-Server
in der DNS-Hierarchie.
Vorbedingungen
Das VVV-Client-Plugin bzw. VVV-Server-Plugin besitzt
SRV-RRs (siehe UC 2.1 in Abschnitt 5.3.1), deren Authentizität überprüft werden soll.
Ergebnis
Das VVV-Client-Plugin bzw. VVV-Server-Plugin hat die
Authentizität mindestens einer Schlüssel-Server-Adresse
der Mail-Domain geprüft, um im nächsten Schritt dort
nach einem Schlüssel zu fragen (siehe UC 2.3 in Abschnitt 5.3.3).
Hinweise und offene Fragen:
• Die Plugins haben als Vertrauensanker die entsprechenden DNS-RootSchlüssel des eigenen Mail-Anbieters vorinstalliert. Die DNS-Zonen einer
Domain sind für die Prüfung der Vertrauenskette über „Delegation Signer
Resource Records“ (DS-RRs) verbunden. Die DS-RRs enthalten jeweils den
Namen einer untergeordneten Zone und den Hash des öffentlichen Schlüssels (des „Key Signing Keys“) zur Prüfung von „Resource Record Signature
Resource Records“ (RRSIG-RRs). Jede Zone kann mehrere DS-RRs für
untergeordnete Zonen enthalten und hat jeden DS-RR mit ihrem privaten
Zonenschlüssel signiert.
• Ein RRSIG-RR enthält die DNSSEC-Signatur über einen Satz von ResourceRecords, z. B. über mehrere SRV-RRs mit Informationen zu den SchlüsselServern der Mail-Domain. Jede DNSSEC-Signatur wird mit dem privaten Zonenschlüssel erstellt. Die Plugins validieren die DNSSEC-Signaturen jeweils
mit dem öffentlichen Zonenschlüssel aus dem DNSKEY-RR und überprüfen
55
mittels des übergeordneten DS-RR, dass der öffentliche Zonenschlüssel authentisch und Teil der Vertrauenskette ist.
• Sollen die Plugins vollständig DNSSEC-konforme rekursive DNS-Resolver
sein, so müssen sie die zur Validierung der DNSSEC-Signaturen notwendigen
Resource-Records (DS-RRs, DNSKEY-RRs, RRSIG-RRs, ...) der Vertrauenskette selbst ermitteln und auswerten können und über einen Cache verfügen,
der die Ergebnisse speichern kann, siehe RFC4034 [18] und RFC4035 [19].
Die Plugins müssten die DNSSEC-Vertrauenskette von unten nach oben bis zu
einem Vertrauensanker durchlaufen. Evtl. bedeutet dies alles einen nicht vertretbaren Implementierungsaufwand und mangelnde Performance, insbesondere wenn die VVV-Lösung später auch von kleineren und mobilen Geräten
übernommen werden soll.
56
5.3.3 UC 2.3: Schlüssel finden
Tabelle 15:
UC 2.3: Schlüssel finden
Beschreibung
Das VVV-Client-Plugin bzw. VVV-Server-Plugin fragt
einen Schlüssel-Server zu einer bestimmten Mail-Adresse
nach Schlüsseln und übergibt ggf. die abgerufenen Schlüssel an den Mail-Client bzw. den OX-Mail-Server.
Beteiligte
Komponenten
VVV-Client-Plugin bzw. VVV-Server-Plugin, HKP-Server
bzw. LDAP-Server, Mail-Client bzw. OX-Mail-Server.
Vorbedingungen
Das VVV-Client-Plugin bzw. VVV-Server-Plugin
kennt die Adresse mindestens eines HKP-Servers oder
LDAP-Servers der Mail-Domain (siehe UC 2.1 in Abschnitt 5.3.1) sowie die Mail-Adresse, zu der ein Schlüssel
beschafft werden soll.
Ergebnis
Das VVV-Client-Plugin bzw. VVV-Server-Plugin hat die
Schlüssel des Empfängers vom Schlüssel-Server abgerufen
und der betreffenden Mail-Anwendung übergeben.
Hinweise und offene Fragen:
• Mit einer Anfrage sollen mehrere Schlüssel-Server gefragt werden, d. h. es
können mehrere Schlüssel übermittelt werden, damit die Anwendung eine Auswahl treffen kann. Dies ist besonders bei Mail an mehrere Empfänger wichtig,
um einen „gemeinsamen Nenner“ der Verschlüsselung ermitteln zu können.
• Das VVV-Client-Plugin fügt die abgerufenen Schlüssel NICHT in lokale
Schlüsselspeicher ein, sondern überlässt die Entscheidung darüber dem MailClient bzw. OX-Mail-Server. Kein Schlüssel soll automatisch importiert werden (siehe Vertrauensmodell im Abschnitt 2.2), da das VVV-Konzept nicht
vorsieht, die Schlüssel im Zertifikat als „VVV-autorisiert“ zu markieren, Eine Markierung z. B. in Form einer speziellen Zertifikatserweiterung würde von
keiner unabhängigen Anwendung interpretiert werden. Im Mail-Client Thunderbird werden allerdings empfangene X.509-Zertifikate für S/MIME egal welcher Herkunft automatisch in den lokalen Schlüsselspeicher importiert.
• Idealerweise färbt das VVV-Client-Plugin die Empfängeradresse, zu der ein
Schlüssel gefunden und übergeben wurde, in der Benutzeroberfläche des MailClients grün bzw. gelb, falls der Mail-Client lokal einen Schlüssel gefunden
57
hat bzw. rot, falls kein Schlüssel gefunden wurde. Allerdings erfordert eine
Überprüfung, ob der Mail-Client lokal einen Schlüssel findet, weitere Zugriffe
evtl. nicht triviale Zugriffe auf den Mail-Client.
58
5.4 UC 3: Serverseitig verschlüsselte Mail senden
Tabelle 16:
UC 3: Serverseitig verschlüsselte Mail senden
Beschreibung
Der Nutzer verfasst in seinem Browser mittels OX-MailClient eine Mail, hat dazu „Mail verschlüsseln“ eingestellt
und trägt eine Empfängeradresse ein. Der OX-Guard prüft,
ob zu dem Empfänger ein gültiger öffentlicher Schlüssel im Keystore des OX-Guards vorliegt. Ist dies nicht
der Fall, prüft der OX-Guard, ob der Mail-Anbieter des
Kommunikationspartners ein kompatibles Verfahren zur
Schlüsselverteilung unterstützt. Wird ein Verfahren erkannt, dann lädt das VVV-Server-Plugin des OX-Guards
den öffentlichen Schlüssel herunter. Dabei gilt wie bei der
client-seitigen Verschlüsselung von Mail (siehe UC 2 in
Abschnitt 5.3) jeder Schlüssel, der VVV-konform auf einem Schlüssel-Server des Mail-Anbieters veröffentlicht
ist, als aktuell und vom betreffenden Nutzer (Schlüsselbesitzer) autorisiert. Falls das VVV-Server-Plugin des OXMail-Servers keinen Schlüssel des Empfängers ermitteln
kann, wird der Mailversand abgebrochen und der Benutzter informiert, damit dieser entscheiden kann, wie weiter
verfahren werden soll. Wurden für alle Kommunikationspartner Schlüssel ermittelt, wird die Mail serverseitig
durch den OX-Guard verschlüsselt.
Beteiligte
Komponenten
OX-Guard, VVV-Server-Plugin, DNS-Server, HKP-Server
Enthaltene
Anwendungsfälle
UC 2.1, UC 2.2, UC 2.3.
Vorbedingungen
Der Benutzer ist an der OX-Suite angemeldet und hat eine
neue Mail erstellt, die verschlüsselt versendet werden soll.
Ergebnis
Die Schlüssel der Empfänger wurden ermittelt, die Mail
konnte verschlüsselt versendet werden. Falls nicht alle
notwendigen Schlüssel ermittelt werden konnten, wurde
das Versenden abgebrochen, der Nutzer informiert und um
Konfliktlösung gebeten.
59
Hinweise und offene Fragen:
• Das Generieren eines serverseitigen Schlüsselpaars des Nutzers auf dem MailServer und das Veröffentlichen bzw. Löschen des öffentlichen Schlüssels auf
den Schlüssel-Servern liegen nicht im Scope des VVV-Projekts. Die enthaltenen Anwendungsfälle UC 2.1, UC 2.2 und UC 2.3 zum Abrufen von veröffentlichten Schlüsseln sind aber Teil der VVV-Lösung.
• Für die Generierung des Schlüsselpaars meldet sich der Nutzer an der OX-Suite
an und öffnet die Schlüsselverwaltung des OX-Guard, um ein neues Schlüsselpaar zu erzeugen. Der Benutzer wird bei der Erzeugung von dem OX-Guard
durch einen Assistenten unterstützt, in dem z. B. sinnvolle und dem Stand der
Technik angepasste Voreinstellungen dem Benutzer empfohlen werden. Die
Onlinehilfe des OX-Guards erläutert diesen Vorgang und die Bedeutung der
einzelnen Parameter. Weiterführende Hinweise sowie Hintergründe werden in
den HowTo’s des Mail-Anbieters näher erläutert. Der OX-Guard veröffentlicht
schließlich den öffentlichen Schlüssel auf dem HKP- bzw. LDAP-Server. Der
Schlüssel steht anschließend der VVV-Lösung zur Verfügung.
• Der OX-Guard ist bei allen serverseitigen Vorgängen involviert, da dort die
Schlüssel bekannt sind und entschieden werden kann, ob Schlüssel bereit gestellt werden können.
• Es gibt zudem ein konfiguriertes Default-Verfahren, nach dem der OX-Guard
versucht, die öffentlichen Schlüssel der Kommunikationspartner zu laden. Ist
dies nicht möglich, wird das Versenden abgebrochen und dem Benutzer das
Ergebnis angezeigt (z. B.: „Schlüssel für Kontakt 1, aber kein Schlüssel für
Kontakt 2 vorhanden.“). Dann wird nach einem anderen Verfahren gefragt und
die Schlüsselbeschaffung neu gestartet. Die Rolle des VVV-Server-Plugins in
diesem Verfahren muss noch definiert werden.
• Der OX-Guard hat eine OpenPGP-Implementierung integriert (Java-KryptoBibliothek „Bouncy Castle“) und verwendet damit die Schlüssel selbstständig
ohne GnuPG.
60
5.5 UC 4: Veröffentlichte Schlüssel anschauen
Tabelle 17:
UC 4: Veröffentlichte Schlüssel anschauen
Beschreibung
Der Nutzer lässt sich zu einer bestimmten Mail-Adresse
die veröffentlichten Schlüssel (OpenPGP oder S/MIME)
anzeigen. Die Mail-Adresse kann eine eigene Adresse sein
oder die dem Nutzer bekannte Adresse einer anderen Person. Für die Schlüssel können Optionen angezeigt werden,
z. B. im Falle der eigenen Schlüssel die Löschung eines
bestimmten Schlüssels.
Beteiligte
Komponenten
Mail-Client oder OX-Mail-Client, OX-Mail-Server, VVVClient-Plugin oder VVV-Server-Plugin, HKP-Server,
LDAP-Server.
Enthaltene
Anwendungsfälle
UC 2.1, UC 2.2, UC 2.3.
Vorbedingungen
–
Ergebnis
Die zu einer Mail-Adresse registrierten Schlüssel werden
dem Nutzer im VVV-Client-Plugin oder im OX-MailClient des Browsers angezeigt.
Hinweise und offene Fragen:
• Dieser Anwendungsfall kann in verschiedenen Zusammenhängen nützlich
sein: Zur Übersicht über die registrierten Schlüssel im Vorfeld der Registrierung eines neuen eigenen Schlüssels, siehe UC 1 im Abschnitt 5.2, oder der
Löschung eines registrierten eigenen Schlüssels, siehe UC 5 im Abschnitt 5.6.
• Ein Schlüsselimport in das lokale Verzeichnis der Mail-Clients bzw. des OXMail-Servers soll nicht durch das VVV-Plugin angeboten werden. Dies wurde
in UC 2.3 (Abschnitt 5.3.3) ausgeschlossen.
61
5.6 UC 5: Clientseitigen Schlüssel auf Schlüssel-Server
löschen
Tabelle 18:
UC 5: Clientseitigen Schlüssel auf Schlüssel-Server löschen
Beschreibung
Der Nutzer lässt zu einer bestimmten Mail-Adresse einen
clientseitigen öffentlichen Schlüssel (OpenPGP oder S/MIME) auf einem Schlüssel-Server löschen, d. h. der Nutzer
nimmt die Veröffentlichung des Schlüssel zurück unabhängig davon, ob das Schlüsselpaar lokal vorhanden bleibt
und vom Nutzer weiterhin verwendet wird. Das VVVClient-Plugin nimmt den Löschwunsch entgegen und informiert den Mail-Server darüber. Der Mail-Server sendet schließlich eine Löschanweisung an den betreffenden
Schlüssel-Server.
Beteiligte
Komponenten
Mail-Client, GnuPG, VVV-Client-Plugin, Mail-Server,
HKP-Server, LDAP-Server.
Enthaltene
Anwendungsfälle
UC 5.1, UC 5.2, UC 5.3.
Vorbedingungen
Nutzer hat einen Schlüssel für OpenPGP oder S/MIME
veröffentlicht.
Ergebnis
Der Schlüssel ist auf dem LDAP- oder HKP-Server der
Mail-Domain gelöscht worden.
Hinweise und offene Fragen:
• Der Nutzer muss den Zugriff auf das Mail-Postfach gegenüber dem MailAnbieter durch die gewohnte Anmeldung nachweisen. Dies sollte für die VVVLösung ausreichen, da in vielen Fällen, in denen die Veröffentlichung eines
Schlüssels zurückgenommen werden soll, ein Zugriff auf den zugehörigen privaten Schlüssel oder sogar auf den betreffenden PC mehr möglich ist. Der
Nutzer besitzt unter Umständen den privaten Schlüssel oder das zugehörige
Passwort nicht mehr. Oder der Schlüssel bzw. der gesamte PC des Nutzers ist
kompromittiert worden und der Nutzer möchte vielleicht gerade aus diesem
Grund den öffentlichen Schlüssel löschen lassen.
• Der Mail-Anbieter kann für die allgemeine Anmeldung zum Mail-Postfach
bzw. für die spezielle Anmeldung im Fall, dass der Nutzer einen Schlüssel lö-
62
schen möchte, weitere Authentisierungsschritte vorsehen, z. B. eine 2-FaktorAuthentisierung mittels FIDO27 , die Eingabe der Kundennummer, einer Transaktionsnummer oder eines speziellen Passworts oder durch eine „Kreuzauthentisierung‘“ (OpenPGP x S/MIME), bei der ein Nutzer, der beide Verfahren verwendet, die Löschung von einem öffentlichen auf dem Schlüssel-Server mit
dem Zugriff auf den jeweils privaten Schlüssel des anderen Verfahrens bestätigt. Die VVV-Lösung fordert aber keine bestimmten Anmeldeprozesse, um
keine zusätzlichen Hürden zu errichten.
• Im Fall, dass das Mail-Postfach kompromittiert wurde, kann die gesamte Kommunikation des rechtmäßigen Nutzers unterlaufen werden, können beispielsweise Mails gelöscht oder hinzugefügt werden, kann von einem Angreifer ein
neues Schlüsselpaar erzeugt und dessen öffentlicher Teil auf dem SchlüsselServer veröffentlicht werden. Allerdings ist davon noch nicht die lokale Entschlüsselung von Mails, die vor dem Angriff verschlüsselt wurden, betroffen. Auch kann der lokale private Schlüssel des rechtmäßigen Nutzers nicht
von einem Angreifer ersetzt werden, solange der Angreifer neben dem MailPostfach nicht auch den PC und Schlüsselspeicher des Nutzers kontrolliert. Ob
ein Schlüssel veröffentlicht ist und ob es sich ggf. um den rechtmäßigen Schlüssel handelt, kann der Nutzer jederzeit mittels VVV-Client-Plugin überprüfen,
siehe UC 4 in Abschnitt 5.5.
• Der Mail-Server löscht den Schlüssel auf dem HKP-Server bzw. LDAP-Server.
Der Schlüssel soll nicht lokal gelöscht werden. Der Entschlüsselungsschlüssel
muss lokal erhalten bleiben, damit ggf. alte verschlüsselte Mails weiterhin gelesen werden können. Der VVV-Anwendungsfall umfasst keine Sperrung (Wideruf) eines Schlüssels oder Zertifikats. Die Sperrung liegt wie die Zertifizierung
von Schlüsseln außerhalb des VVV-Scopes.
27
„Fast IDentity Online“ (FIDO), siehe https://fidoalliance.org/specifications/
overview
63
5.6.1 UC 5.1: Clientseitigen Schlüssel auf dem Client abmelden
Tabelle 19:
UC 5.1: Clientseitigen Schlüssel auf dem Client abmelden
Beschreibung
Der Nutzer ruft das VVV-Client-Plugin auf, um einen existierenden öffentlichen Schlüssel auf dem Schlüssel-Server
löschen zu lassen.
Beteiligte
Komponenten
VVV-Client-Plugin, Mail-Client, GnuPG.
Vorbedingungen
Nutzer hat einen OpenPGP-Schlüssel oder einen S/MIMESchlüssel, der auf einem Schlüssel-Server veröffentlicht
ist.
Ergebnis
Das VVV-Client-Plugin besitzt die notwendigen Angaben,
um im nächsten Schritt (siehe UC 5.2 in Abschnitt 5.6.2)
die Informationen für die Löschung des betreffenden
Schlüssels an den Mail-Server weiterzugeben.
Hinweise und offene Fragen:
• Pro Verschlüsselungsverfahren (S/MIME, OpenPGP) wird maximal genau ein
aktiver Schlüssel angezeigt.
• Wäre es hilfreich oder überhaupt möglich, ggf. beide Schlüssel lokal zur Auswahl zu stellen? Evtl. müsste dazu zunächst auf den Schlüssel-Servern nachgesehen werden, welche Schlüssel dort veröffentlicht sind. Dies ist der weitere Anwendungsfall UC 4 „Veröffentlichte Schlüssel anschauen“ gemäß Abschnitt 5.5. Dies hat den Vorteil, dass der Nutzer nur die betreffende MailAdresse angeben müsste, um alle registrierten Schlüssel zur Auswahl zu bekommen.
64
5.6.2 UC 5.2: Clientseitigen Schlüssel auf dem Server abmelden
Tabelle 20:
UC 5.2: Clientseitigen Schlüssel auf dem Server abmelden
Beschreibung
Das VVV-Client-Plugin meldet sich am Mail-Server an
und sendet die Angaben über den zu löschenden Schlüssel. Der Mail-Server braucht keinen Verifikationscode an
das Postfach des Nutzers zu senden, da der Zugriff bereits
mit der Anmeldung verifiziert wurde und der Besitz des
privaten Schlüssels nicht mehr vorausgesetzt werden kann.
Beteiligte
Komponenten
Mail-Client, VVV-Client-Plugin, Mail-Server.
Vorbedingungen
Das VVV-Client-Plugin besitzt die notwendigen Angaben
für die Löschung eines bestimmten Schlüssels (siehe UC
5.1 in Abschnitt 5.6.1).
Ergebnis
Der Mail-Server besitzt die notwendigen Angaben für die
Löschung eines bestimmten Schlüssels, um im nächsten
Schritt (siehe UC 5.3 in Abschnitt 5.6.3) auf dem entsprechenden Schlüssel-Server den Schlüssel löschen zu lassen.
65
5.6.3 UC 5.3: Schlüssel auf Schlüssel-Server löschen
Tabelle 21:
UC 5.3: Schlüssel auf Schlüssel-Server löschen
Beschreibung
Der Mail-Server lässt einen Schlüssel des Nutzers auf dem
HKP-Server bzw. LDAP-Server löschen.
Beteiligte
Komponenten
Mail-Server, HKP-Server, LDAP-Server.
Vorbedingungen
Der Mail-Server hat die notwendigen Angaben zur Löschung des Schlüssels erhalten.
Ergebnis
Der Schlüssel ist auf dem HKP-Server bzw. LDAP-Server
gelöscht.
Hinweise und offene Fragen:
• Eine Rückmeldung an den Nutzer, dass der Schlüssel tatsächlich gelöscht wurde, ist sinnvoll. Wenn es schnell geht, könnte man dies über das VVV-ClientPlugin durch einen Versuch des Abrufens des Schlüssels durchführen. In jedem
Fall, insbesondere wenn es mehr Zeit benötigt als man dem Nutzer zumuten
kann, versendet der Mail-Server eine Bestätigungsmail an den Nutzer.
66
Literatur
[1] Stallings, William: Comprehensive Internet E-Mail Security. The Internet Protocol Journal, 19(3):2–30, November 2016.
[2] Rose, Scott: Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status. RFC 6944, Oktober 2015.
[3] Schlyter, Jakob und Paul E. Hoffman: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. RFC
6698, Oktober 2015.
[4] Wouters, Paul: Using DANE to Associate OpenPGP public keys with email
addresses. Internet-Draft draft-ietf-dane-openpgpkey-12, Internet Engineering
Task Force, Mai 2016. Work in Progress.
[5] Schlyter, Jakob und Paul E. Hoffman: Using Secure DNS to Associate Certificates with Domain Names For S/MIME. Internet-Draft draft-ietf-dane-smime14, Internet Engineering Task Force, November 2016. Work in Progress.
[6] Zhu, Liang, John Heidemann, Duane Wessels, Paul E. Hoffman, Allison Mankin und Zi Hu: Specification for DNS over Transport Layer Security (TLS). RFC
7858, Mai 2016.
[7] Klensin, Dr. John C.: Simple Mail Transfer Protocol. RFC 5321, Oktober 2015.
[8] 3rd, Donald E. Eastlake: Domain Name System (DNS) Case Insensitivity Clarification. RFC 4343, Oktober 2015.
[9] Damas, J., M. Graff und P. Vixie: RFC6891: Extension Mechanisms for DNS
(EDNS(0)). RFC 6891, April 2013.
[10] Koch, Werner: Public Key Association. Technischer Bericht, Feb 2006.
[11] Koch, W.: OpenPGP Web Key Service. Draft Koch-openpgp-webkey-service01, May 2016.
[12] Finney, Hal, Lutz Donnerhacke, Jon Callas, Rodney L. Thayer und David
Shaw: OpenPGP Message Format. RFC 4880, März 2013.
[13] Shaw, David: The OpenPGP HTTP Keyserver Protocol (HKP). InternetDraft draft-shaw-openpgp-hkp-00, Internet Engineering Task Force, März 2003.
Work in Progress.
[14] Horowitz, Marc: A PGP Public Key Server. Technischer Bericht, Massachusetts Institute of Technology, 1996. Last-Modified: Tue, 19 Nov 1996 05:24:05
GMT.
67
[15] Herfert, Michael, Annika Selzer und Ulrich Waldmann: Laientaugliche
Schlüsselgenerierung für die Ende-zu-Ende-Verschlüsselung – Schlüssel für
all durch die Volksverschlüsselung. Datenschutz und Datensicherheit – DuD,
05:290–294, 2016.
[16] Sermersheim, Jim: Lightweight Directory Access Protocol (LDAP): The Protocol. RFC 4511, Oktober 2015.
[17] Cotton, Michelle S., Lars Eggert, Dr. Joseph D. Touch, Magnus Westerlund
und Stuart Cheshire: Internet Assigned Numbers Authority (IANA) Procedures
for the Management of the Service Name and Transport Protocol Port Number
Registry. RFC 6335, Oktober 2015.
[18] Rose, Scott, Matt Larson, Dan Massey, Rob Austein und Roy Arends: Resource Records for the DNS Security Extensions. RFC 4034, Oktober 2015.
[19] Rose, Scott, Matt Larson, Dan Massey, Rob Austein und Roy Arends: Protocol Modifications for the DNS Security Extensions. RFC 4035, Oktober 2015.
68

Physisches Theater - mime centrum berlin

Anmeldebogen Notfalldarsteller

Anmeldung für Schiedsrichter und Mimen

Antrag für einen Arbeitsplatzwagen

Vereinsordnung des Billard Sport Verein Bad Homburg e.V.

SEO küsst Social: wpSEO 4 ist da.

Batteriewechsel für Elektrofahrzeuge

Benutzungsordnung Arbeitsplatzwagen

als PDF - Wilhelmshorst

Der Seminartag Theaterluft schnuppern!