Post on 14-Jun-2020
Whitepaper
Zertifikats- und Trustmanagement Anforderungen an Zertifikate und Vertrauensbeziehungen
Version: 1.0
Datum: 2010-11-12
Klassifizierung: öffentlich/public
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 2
Inhaltsverzeichnis
Einführung .................................................................................................................... 4
Ausgangssituation .................................................................................................... 4
Allgemeine Grundsätze des Dokuments ................................................................... 5
An gesicherter E-Mail-Kommunikation beteiligte Rollen und Verantwortlichkeiten ........ 6
Absenderseite .......................................................................................................... 7
Versender ............................................................................................................ 7
E-Mail-Infrastruktur-Betreiber ............................................................................... 7
Empfängerseite ........................................................................................................ 8
E-Mail-Infrastruktur-Betreiber ............................................................................... 8
Adressat .............................................................................................................. 8
Trust-Management ................................................................................................... 8
Anwendungsfälle .......................................................................................................... 9
Anforderungen für den Einsatz von STARTTLS ....................................................... 9
Transportverschlüsselung mit opportunistic STARTTLS ...................................... 9
Transportverschlüsselung mit mandatory STARTTLS ....................................... 10
Inhaltsverschlüsselung ........................................................................................... 11
Anforderungen für den Einsatz von E-Mail-Verschlüsselungsgateways ............. 11
Domain-Zertifikate ............................................................................................. 11
Zertifikate auf Basis persönlicher E-Mail-Adressen ............................................ 12
Anforderungen für den Einsatz von „Ende-zu-“ Lösungen ...................................... 13
Anforderungen für den Einsatz im Bereich Ende-zu-Ende ...................................... 13
Anforderungen für Interimskommunikation ............................................................. 13
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 3 V E R S I O N 1 . 0
Zertifikatsmanagement ............................................................................................... 14
Anforderungen an Zertifikate .................................................................................. 14
Identifikation des Antragstellers ......................................................................... 14
Absicherung des Transports des Schlüssels zum Antragsteller ......................... 15
Physikalische Speicherung des privaten Schlüssels .......................................... 16
Lebenszyklus ..................................................................................................... 16
Übersicht der Anforderungen an Zertifikate ........................................................ 16
Umsetzungsempfehlungen ..................................................................................... 17
Trust-Management ..................................................................................................... 19
Rollen und Aufgaben .............................................................................................. 19
Trust-Manager ................................................................................................... 19
TrustCenter ........................................................................................................ 21
Anhang ....................................................................................................................... 22
Autorenverzeichnis ................................................................................................. 22
Dokumenten- und Versionshistorie: ........................................................................ 22
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 4
Einführung
Ausgangssituation
Dieses Dokument ist Teil einer Reihe von Whitepaper, die von dem Arbeitskreis „E-
Mail-Sicherheit“ des IT-ABC erstellt wurden. Für Verweise, das Glossar und weitere
Referenzen wird auf das Hauptdokument „E-Mail-Sicherheit“ [W1] verwiesen.
Die Implementierung von Verschlüsselungslösungen allein ist nicht ausreichend für die
Absicherung einer erfolgreichen Kommunikation. Kernelement ist das Management
und die Bereitstellung der für deren Nutzung benötigten Zertifikate. Ihre
bedarfsgerechte Verfügbarkeit und unkomplizierte Nutzbarkeit bilden die Grundlage für
die Durchdringung von Lösungen in der Fläche der Anwender sowie der letzendlichen
Qualität der Absicherung.
Oft ist in der Vergangenheit das notwendige Zertifikats- und Trust-Management dem
individuellen Anwender überlassen worden. Dies führte häufig zu fehlender Akzeptanz
und Sicherheitslücken sowohl im Bezug auf die Qualität der Zertifikate und der
Verschlüsselung an sich als auch in Bezug auf die Validierung der Zertifikate.
Bei serverbasierten Lösungen werden die gleichen Defizite bezüglich dem Vertrauen in
die Voreinstellungen verschiedener Produkte gesehen. Diese Voreinstellungen
umfassen zulässige Schlüssellängen und Algorithmen, sowie als vertrauenswürdig
vordefinierte Zertifizierungsstellen.
Als Beispiel hierfür kann die Nutzung von STARTTLS im opportunistic mode angeführt
werden. Dieser werden häufig höherwertige Eigenschaften zugeschrieben, welche
jedoch nur auf eine Verwendung in einem secure high-ciphers mandatory mode
zutreffen. Hierbei sind unter anderem zu nennen:
Vertrauen auf self-signed-Zertifikate ausschließlich nach Validierung
Ausschluss von unverschlüsselter Übertragung als Fallback [W3]
Beschränkung auf anerkannte Algorithmen und Schlüssellängen [W1]
Weiterhin bedarf es der Definition von Anforderungen und Prozessen zur:
Bereitstellung von Zertifikaten
Validierung und Pflege von Zertifikaten gemäß definierter Standards (Trust-
Management)
Konfiguration und Pflege der Policy-Einstellungen
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 5 V E R S I O N 1 . 0
Allgemeine Grundsätze des Dokuments
Der Begriff „CA“ (Certification Authority) wird sowohl in einer hierarchischen X.509-PKI
als auch in einer PGP-PKI verwendet.
Für das Management von PGP-Schlüsseln gelten die gleichen Qualitätsanforderungen
hinsichtlich der verwendeten Schlüssellängen und Algorithmen wie für X.509-
Zertifikate. Um eine innerhalb des PGP-Web-of-Trust nur mittelbar vorhandene
hierarchische Struktur ähnlich einer X.509-PKI abzubilden, wird empfohlen, die PGP-
Schlüssel einzelner Anwender mit einem PGP-Unternehmensschlüssel oder einer
anerkannten PGP-CA zu unterzeichnen bzw. unterzeichnen zu lassen.
Im Folgenden werden X.509-Zertifikate und PGP-Schlüssel allgemein als Zertifikate
bezeichnet.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 6
An gesicherter E-Mail-Kommunikation beteiligte Rollen und Verantwortlichkeiten
Um eine gesicherte E-Mail-Übertragung gewährleisten zu können sind verschiedene
Rollen und zugeordnete Verantwortlichkeiten notwendig.
Abbildung: Schaubild zur Illustration des Ablaufs einer gesicherten E-Mail-Übertragung
Legende:
Grün: Weg der E-Mail während der gesicherten Übertragung
Rot: Für die gesicherte Übertragung benötigte Steuerungsinformationen
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 7 V E R S I O N 1 . 0
Absenderseite
Versender
Der Versender ist verantwortlich:
die richtige E-Mail-Adresse des Adressaten zu wählen und
die E-Mail entsprechend des Inhalts korrekt zu klassifizieren.
Auf Basis korrekter Steuerungsinformationen wird der E-Mail-Infrastrukturbetreiber im
Folgenden in die Lage versetzt, die Informationen dem korrekten Adressaten
zuzustellen, zu erkennen, ob eine Verschlüsselung notwendig und welches
Zertifikatsmaterial ggf. zu verwenden ist.
Hinweis: Vor dem Austausch von vertraulichen Informationen ist eine gegenseitige
Vereinbarung über deren Handhabung auf Basis einer Informationsklassifizierung und
einer Geheimhaltungsvereinbarung (NDA) abzuschließen.
E-Mail-Infrastruktur-Betreiber
Die E-Mail-Infrastruktur muss vom Betreiber entsprechend eingerichtet sein, so dass
sie folgende Aufgaben zuverlässig übernimmt:
Annahme von E-Mails vom Versender über gesicherte Verbindung.
Maßnahmen entsprechend der Klassifizierung und sonstigen Richtlinien (z.B.
Domains, bei denen generell verschlüsselt werden muss) durchführen.
Bei Verschlüsselung korrektes Zertifikatsmaterial verwenden.
Schutz vor unberechtigtem Zugriff auf die E-Mail.
Bereitstellen der erforderlichen sicheren E-Mail-Übertragungsweges zwischen
Absender- und Empfänger-Infrastruktur.
Auf Basis der Steuerungsinformationen sind die entsprechenden Maßnahmen
umzusetzen. Dies beinhaltet die Beschaffung der erforderlichen Zertifikate des
Adressaten und die Beschaffung, Verwaltung und Bereitstellung der eigenen
Zertifikate (Zertifikatsmanagement). Hierbei ist das besondere Augenmerk auf die
Vertrauenswürdigkeit, Validität und Qualität der Zertifikate zu richten (Trust-
Management). Für das Trust-Management ist der Trust-Manager verantwortlich.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 8
Empfängerseite
E-Mail-Infrastruktur-Betreiber
Die E-Mail-Infrastruktur muss vom Betreiber entsprechend eingerichtet sein, so dass
sie folgende Aufgaben zuverlässig übernimmt:
Möglichkeiten zur sicheren Annahme von geschützten E-Mails bereitstellen.
Beschaffung und Bereitstellung von Zertifikatsmaterial (Zertifikatsmanagement).
Durchführung von etwaigen kryptographischen Maßnahmen [W2].
Sichere Zustellung der E-Mails an den Adressaten.
Schutz vor unberechtigtem Zugriff auf die E-Mail.
Adressat
Der Adressat ist verantwortlich, empfangene Informationen entsprechend deren
Vertraulichkeitsstufe zu behandeln und diese Vertraulichkeitsstufe nicht
herabzusetzen. Wenn eine E-Mail nicht anderweitig klassifiziert ist, ist sie
standardmäßig als intern/internal zu behandeln.
Genauso wie für den Versender gilt, dass es sich bei Adressaten sowohl um Personen,
Personengruppen, Organisationen als auch um IT-Systeme handeln kann.
Trust-Management
Für eine effektive Nutzbarkeit der E-Mail-Verschlüsselung sind Zentralfunktionen
notwendig. Sie moderieren und optimieren die für ein Zertifikats-Management
notwendigen Prozesse, die bei den E-Mail-Infrastruktur-Betreibern genutzt werden.
Dies verringert in erheblichem Maße die gegenüber herkömmlichen Maßnahmen
notwendigen Aufwände für Versender, Adressat und E-Mail-Infrastruktur-Betreiber.
Eine Detaillierung der unter dem Begriff Trust-Management zusammengefassten
Funktionen ist unter Trust-Management aufgeführt.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 9 V E R S I O N 1 . 0
Anwendungsfälle
Zertifikats- und Trust-Management bildet die Basis für folgende Anwendungsfälle der
E-Mail-Sicherheit. Diese werden in dem jeweils entsprechenden Whitepaper genauer
beschrieben:
Transportverschlüsselung [W3]
STARTTLS
o „opportunistic mode“ (opportunistic STARTTLS)
o „secure high-ciphers mandatory mode“ (mandatory STARTTLS)
Hostname-Zertifikat (das mit der Domain korreliert)
nicht automatisch korrelierbares Hostname-Zertifikat
VPN
Das Thema VPN wird im Rahmen dieses Whitepapers nicht behandelt.
Inhaltsverschlüsselung [W2] mit S/MIME oder OpenPGP
EVG
o Domain-Zertifikat (Organisationszertifikat)
o Persönliches Zertifikat auf Basis der E-Mail-Adresse
„Ende-zu-“ Verschlüsselung
o Domain-Zertifikat (Organisationszertifikat)
o Persönliches Zertifikat auf Basis der E-Mail-Adresse
Ende-zu-Ende-Verschlüsselung
o Persönliches Zertifikat auf Basis der E-Mail-Adresse
Interimskommunikation: Wird in [W1] behandelt.
Anforderungen für den Einsatz von STARTTLS
Für eine Absicherung der Kommunikation unter Verwendung eines
Übertragungstunnels mittels STARTTLS sind als Grundlage Zertifikate des Formats
X.509 ab Version 3 zu verwenden [W3].
Transportverschlüsselung mit opportunistic STARTTLS
Es handelt sich hierbei um Grundschutz ohne die Voraussetzung einer
Vertrauensbeziehung, bei dem nur im Idealfall eine verschlüsselte Übertragung erfolgt
und im Zweifelsfall von einer unverschlüsselten Übertragung ausgegangen werden
muss.
Opportunistic STARTLLS ist für den Einsatz im Bereich Grundsicherheit zulässig.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 1 0
Bei der Verwendung von opportunistic STARTTLS werden keine weiteren
Anforderungen an das Zertifikat gestellt.
Es wird empfohlen, grundsätzlich nur anerkannte Algorithmen und Schlüssellängen
einzusetzen, um den Grundschutz zweckmäßig zu gestalten [W1].
Transportverschlüsselung mit mandatory STARTTLS
Mit diesem Verfahren kann der Schutz von als „vertraulich/confidential“ klassifizierten
Informationen gewährleistet werden.
In der Praxis unterscheidet man zwischen Zertifikaten, welche ausgestellt sind auf
den Hostnamen des MTAs, der mit der Zieldomain korreliert.
den Hostnamen des MTAs, der nicht automatisch mit der Zieldomain korrelierbar
ist.
Bei der Verwendung von mandatory STARTTLS für die Übertragung von vertraulichen
E-Mails werden folgende Mindestanforderungen an ein verwendetes Zertifikat gestellt:
die ausstellende Instanz (Issuing CA) des verwendeten Zertifikats ist gültig und
als für diesen Anwendungsfall vertrauenswürdig eingestuft – durch individuelle
Prüfung des E-Mail-Infrastruktur-Betreibers oder durch Auflistung auf der
STARTTLS-CA-CTL (Standard CA-Listen beispielsweise von Browsern,
Betriebssystemen oder MTAs sind für einen anderen Anwendungsfall
vorgesehen und damit nicht ungeprüft anwendbar) und
das Zertifikat schließt mindestens die Verwendungszwecke
„Schlüsselverschlüsselung“ und „Serverauthentifizierung“ ein und
wenn das Feld „alternativer Antragsteller“ genutzt wird, darf dieses als DNS-
Namen ausschließlich FQDN enthalten.
Darüber hinaus ist eine der folgenden Anforderungsalternativen zu erfüllen:
der MTA identifiziert sich mit einem Zertifikat, welches auf die Zieldomain der E-
Mail ausgestellt ist (E-Mail-Domain entspricht dem CN des Feldes „Antragsteller“)
oder
der FQHN des MTAs und der CN des Antragstellers im Zertifikat sind identisch
und der FQDN ist aus der Zieldomain ableitbar oder
weder der FQDN des MTAs noch das Zertifikat stimmen mit der Zieldomain
überein. Dies ist z.B. der Fall, wenn MTAs E-Mails für mehrere E-Mail-Domänen
eines Unternehmens entgegennehmen. Dann müssen zusätzliche Maßnahmen
getroffen werden, um diesen MTA zu berechtigen (Hostname und Zertifikat
müssen übereinstimmen und der Hostname muss per dediziertem Regelwerk der
Domain zugeordnet sein. Dies ist individuell zwischen dem Betreiber der E-Mail-
Infrastruktur und dem Zielunternehmen zu regeln oder kann einer STARTTLS-
MX-CTL entnommen werden)
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 1 1 V E R S I O N 1 . 0
Inhaltsverschlüsselung
Anforderungen für den Einsatz von E-Mail-Verschlüsselungsgateways
Der Schutz von als vertraulich/confidential klassifizierten Informationen kann mit
diesem Verfahren gewährleistet werden.
Für die serverbasierte E-Mail-Verschlüsselung mittels eines E-Mail-
Verschlüsselungsgateways (EVG) kommen X.509-Zertifikate ab Version 3 oder zu
OpenPGP kompatible PGP-Zertifikate zum Einsatz. In der Praxis unterscheidet man
hierbei zwischen Zertifikaten, welche ausgestellt sind auf
die E-Mail-Domains des Unternehmens oder der Unternehmensgruppe
persönliche E-Mail-Adressen mit Unternehmensbezug
persönliche E-Mail-Adressen ohne Unternehmensbezug
Domain-Zertifikate
Für X.509-Zertifikate gilt
das Zertifikat enthält die E-Mail-Adresse des E-Mail-Verschlüsselungsgateways
oder eine fiktive E-Mail-Adresse des Unternehmens
o im Feld „Antragsteller“ unter Eintrag „CN“ und
o im Feld „Antragsteller“ unter Eintrag „E“ und
o im Feld „Alternativer Antragsteller“ unter Eintrag „RFC822-Name“
das Zertifikat und jedes Element der Zertifikatskette ist gültig (zeitlich und nicht-
revoziert) und
die ausstellende Instanz ist für diesen Anwendungsfall als vertrauenswürdig
eingestuft. Dies erfolgt durch individuelle Prüfung des E-Mail-
Infrastrukturbetreibers oder durch Auflistung auf der EVG-CTL (siehe Glossar).
Technisch ist zu berücksichtigen, dass die E-Mail-Adresse sich für maximale
Kompatibilität mit verschiedenen Implementierungen in mehreren Feldern des
Zertifikats finden sollte.
Für PGP–Zertifikate gilt, dass sie eine gültige E-Mail-Adresse und damit
Absenderdomain haben. Diese muss entweder als primäre oder als zusätzliche PGP-
User-ID enthalten sein. Die Vertrauensbeziehung wird durch die Übergabe des
öffentlichen Schlüssels mittels vertrauenswürdiger Kanäle oder der gegenseitigen
Cross-Zertifizierung der PGP-Unternehmensschlüssel zwischen Eigentümer des
Schlüssels und Betreiber der E-Mail-Infrastruktur sichergestellt oder über eine EVG-
CTL.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 1 2
Zertifikate auf Basis persönlicher E-Mail-Adressen
Für X.509-Zertifikate gilt
das Zertifikat enthält die E-Mail-Adresse des Inhabers
o im Feld „Antragsteller“ unter Eintrag „E“ oder
o im Feld „Alternativer Antragsteller“ unter Eintrag „RFC822-Name“
das Zertifikat und jedes Element der Zertifikatskette ist gültig (zeitlich und nicht-
revoziert) und
die ausstellende Instanz ist für diesen Anwendungsfall als vertrauenswürdig
eingestuft. Dies erfolgt durch individuelle Prüfung des E-Mail-
Infrastrukturbetreibers oder durch Auflistung auf der EVG-CTL (siehe Glossar).
Für PGP-Zertifikate gilt
die E-Mail-Adresse muss im Feld „User ID“ angegeben sein.
der Name des Inhabers sollte im Feld „User ID“ enthalten sein
Die Vertrauensbeziehung kann wie folgt sichergestellt werden:
durch die Übergabe des öffentlichen Schlüssels oder dessen „Fingerabdruck“
mittels vertrauenswürdiger Kanäle vom Eigentümer des Schlüssels zum
Betreiber der E-Mail-Infrastruktur oder
der öffentliche Schlüssel in Verbindung mit der E-Mail-Adresse des Adressaten
wurde von einem für diesen Zweck als vertrauenswürdig eingestuften PGP-
Zertifikat (Signing-Key oder Trusted Introducer) signiert oder
die Vertrauenswürdigkeit von einzelnen PGP-Zertifikaten kann auch über eine
EVG-CTL gewährleistet werden.
Die Vertrauensbeziehung muss insbesondere für die einem bestehenden Schlüssel
hinzugefügten E-Mail-Adressen vor deren Verwendung erneut geprüft werden.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 1 3 V E R S I O N 1 . 0
Anforderungen für den Einsatz von „Ende-zu-“ Lösungen
Es gelten Anforderungen analog dem Einsatz von EVGs. In diesem Szenario ist
hervorzuheben, dass es sich auf Empfängerseite um verschiedenartige zur
Entschlüsselung genutzte Infrastrukturen handeln kann. Daher muss grundsätzlich von
einer Entschlüsselung durch ein EVG ausgegangen werden.
Es ist darauf hinzuweisen, dass verschiedene Kombinationen technisch nicht von allen
gängigen Produkten unterstützt werden.
Anforderungen für den Einsatz im Bereich Ende-zu-Ende
Mit derartigen Lösungen kann durch Verwendung von persönlichem Schlüsselmaterial
(Soft-PSE, Smartcard) ein höheres Sicherheitsniveau als bei der Verwendung von
EVGs erreicht werden. Damit könnte die Absicherung bis zur Vertraulichkeitsstufe
„geheim/secret“ gewährleistet werden. Da der Absender eine Entschlüsselung durch
ein EVG auf Empfängerseite nicht technisch ausschließen kann, sind hierfür
organisatorische Zusatzvereinbarungen (z. B. beidseitige Verwendung von
Smartcards) notwendig [W1].
Erfolgt keine Zusatzvereinbarung, gelten die Anforderungen für den Einsatz im Bereich
„Anforderungen für den Einsatz von E-Mail-Verschlüsselungsgateways“.
Anforderungen für Interimskommunikation
Der Schutz von als vertraulich/confidential klassifizierten Informationen kann mit
diesem Verfahren nur behelfsmäßig gewährleistet werden. In der Regel kommen keine
Zertifikate zum Einsatz, sondern häufig symmetrisches Schlüsselmaterial.
Eine Beschreibung findet sich in [W1].
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 1 4
Zertifikatsmanagement
Grundlage für die Anwendung von Verschlüsselungstechnologien ist die Nutzung von
Zertifikaten. Zertifikate bestätigen die Zugehörigkeit eines Schlüsselpaares zu einer
Identität durch eine Vertrauensinstanz.
Sie unterliegen einem Lebenszyklus, während dem sie spezifische Anforderungen
hinsichtlich der Zuordnung zu einer Identität, dem gesichertem Transport zum
Antragsteller und der Aufbewahrung erfüllen müssen.
Anforderungen an Zertifikate
Identifikation des Antragstellers
Identifikation ist ein Vorgang um eine Person bzw. System eindeutig zu erkennen. Man
kann die eigene Identität durch bestimmte Kenntnisse, Besitz oder persönliche
Anwesenheit nachweisen.
Kommerzielle Zertifikatsanbieter klassifizieren im Allgemeinen die von Ihnen
ausgestellten Zertifikate anhand der vom Antragsteller geforderten
Identifikationsmerkmale. Hierbei wird bei den gängigsten namhaften Anbietern
üblicherweise wie folgt unterschieden:
Klasse Merkmale Qualitäts-
klasse
Class 1 Verifikation des Antragstellers per E-Mail, sowohl bei
persönlichen als auch bei Serverzertifikaten. Bei
Serverzertifikaten Validierung des Domaininhabers über
E-Mail Kontakte der NIC-Handles, in Einzelfällen
telefonische Verifikation der Unternehmenszugehörigkeit
anhand der Informationen aus elektronischen
Unternehmensregistern.
niedrig
Class 2 Schriftliche Übertragung (Fax, Brief) eines amtlichen
Ausweisdokumentes zum Nachweis. Bei
Personenzertifikaten Kopie des Personalausweis oder
vergleichbares. Bei Serverzertifikaten
Handelsregisterauszug, DUNS-Nummer (Dun &
Bradstreet), Gewerbelizenz oder vergleichbarer
Dokumentationen zum Unternehmensinhaber.
mittel
Class 3 Persönliche Identifikation bei einer vom CA-Betreiber als
Notarfunktion benannten Instanz, über ein Verfahren wie
z.B. Postident.
hoch
Extended
Verification
(EV)
Erweiterte Form der Class 3, zzgl. Nachweis des
rechtlichen und gesetzlichen Vertreters des
Antragsstellers, Umfangreiches schriftliches
Antragsverfahren und eingehende Prüfung der
eingereichten Daten.
hoch
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 1 5 V E R S I O N 1 . 0
Die von kommerziellen CAs ausgestellten Zertifikate enthalten als Attribute je nach
Vertraulichkeitsstufen nur eine E-Mail-Adresse oder einen DNS-Namen (Class 1) und
bei höheren Vertraulichkeitsstufen die vom Aussteller verifizierten zusätzlichen
Angaben aus dem Antrag, wie Unternehmensname, Abteilung, oder andere. Diese
Angaben variieren von Anbieter zu Anbieter.
Unternehmensspezifische Zertifikate die auf Basis einer vertrauenswürdigen
Datenquelle generiert wurden, werden im Rahmen dieses Whitepaper als Äquivalent
zur Einstufung Class 2 gesehen. Unter einer vertrauenswürdigen Datenquelle werden
Personalstammdatenbanken eines Unternehmens verstanden, da davon ausgegangen
wird, dass diese mittels sicherer Prozesse gepflegt werden.
Absicherung des Transports des Schlüssels zum Antragsteller
Der Transport des privaten Schlüssels vom Aussteller zum Antragssteller kann durch
folgende exemplarisch aufgeführte und bewertete Wege erfolgen:
Ausprägung Qualitätsklasse
Zusendung an eine genannte E-Mail-Adresse niedrig
Zusendung an eine genannte E-Mail-Adresse innerhalb einer
gesicherten E-Mail-Infrastruktur
mittel
Zusendung durch einen Service von bzw. an
einen authentifizierten Antragsteller
mittel
Zusenden per Post mittel
Abruf von einem gesicherten Service
durch einen authentifizierten Antragsteller
hoch
Übergabe durch verlässliche Dienstleister hoch
Übergabe an einen bevollmächtigten Stellvertreter hoch
Persönliche Übergabe hoch
In der Praxis erfolgt die Schlüsselerzeugung bei kommerziellen Zertifikatsanbietern in
der Regel durch den Antragsteller, es werden in seltenen Fällen private Schlüssel beim
Anbieter erzeugt oder Sicherheitskopien von privaten Schlüsseln einbehalten oder an
den Antragsteller versandt. Der Antragsteller erstellt seinen Signierungsantrag (CSR)
i.d.R. im Format PKCS#10 und versendet diesen auf elektronischem Wege an den
Anbieter. Der Versand der Zertifikate vom Anbieter zurück zum Antragsteller erfolgt
ebenfalls elektronisch und stellt kein nennenswertes Sicherheitsrisiko dar.
Ausnahmen stellen verschiedene PKI-Produkte oder Smartcard-Lösungen
kommerzieller CAs dar. Dort erfolgt je nach Produktvariante eine persönliche
Übergabe oder ein getrennter Versand eines durch PIN geschützten Schlüssels und
der zugehörigen PIN.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 1 6
Physikalische Speicherung des privaten Schlüssels
Die physikalische Speicherung des privaten Schlüssels beim Antragssteller erfolgt per:
Ausprägung Qualitätsklasse
Soft-PSE (PKCS#12-Token oder PGP-Zertifikat)
in Hoheit des Inhabers
niedrig
Soft-PSE (PKCS#12-Token oder PGP-Zertifikat)
in Hoheit einer Anwendung (z.B. AD oder EVG)
niedrig
Smartcard oder HSM-Modul hoch
Der Zugriffsschutz muss bei allen Speicherungsformen implementiert werden, z.B.
Passwort oder PIN.
Für die Absicherung von als vertraulich/confidential klassifizierten E-Mails ist die
physikalische Speicherung des Zertifikats mittels Soft-PSE in Hoheit des Anwenders
oder des EVGs ausreichend.
Empfehlung: Zentrale Generierung, Verbleib und Benutzung der privaten Schlüssel in
der gesicherten Umgebung des EVGs.
Lebenszyklus
Lebenszyklus-Aspekte wie die Verlängerung und Revozierung von Zertifikaten sind
notwendig, werden aber im Rahmen dieses Dokuments nicht mit zusätzlichen
Anforderungen belegt. Beim Aufbau einer Lösung ist insbesondere auf den Umgang
mit privaten Schlüsseln großes Augenmerk zu legen.
Übersicht der Anforderungen an Zertifikate
Die folgende Tabelle setzt die Qualitätsklassen der vorangegangenen Unterkapitel in
Beziehung zu den unter Anwendungsfälle genannten Punkten.
Anwendungsfall Anforderungen
an die
Identifikation
Anforderungen
an den
Transport
Anforderungen
an die
Speicherung
Opportunistic STARTTLS niedrig niedrig niedrig
Mandatory STARTTLS hoch hoch niedrig
EVG mit Domainzertifikat hoch hoch niedrig
EVG mit Zertifikat auf Basis
persönlicher E-Mail-Adresse
mittel niedrig niedrig
X-zu-Ende mit Soft-PSE mittel niedrig niedrig
X-zu-Ende mit Smartcard hoch hoch hoch
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 1 7 V E R S I O N 1 . 0
Umsetzungsempfehlungen
Im Folgenden sind die Anforderungen an Zertifikate und deren technische Ausprägung
zusammengefasst. Diese sind von einem Kommunikationspartner zu erfüllen, um
Adressat einer gesicherten E-Mail-Kommunikation im Sinne des Whitepaper sein zu
können. Die gleichen Anforderungen gelten für den Versender, wenn dieser die Rolle
des Adressaten einnimmt.
Anwendungsfall
und
Umsetzungs-
Empfehlung
Anforderungen
an die
Identifikation bei
Zertifikats-
Erstellung
Anforderungen
an den
Umgang mit
dem privaten
Schlüssel
Anforderungen
an die
Speicherung
des privaten
Schlüssels
Anforderungen
an die
Validierung
durch den
Sender der E-
Opportunistic
STARTTLS -
Mindeststandard
- - - -
Opportunistic
STARTTLS -
Empfohlen
Class 3 PKCS#10
(Standard)
Soft-PSE
(Standard)
-
Mandatory
STARTTLS –
Mindeststandard
Class 3 PKCS#10
(Standard)
Soft-PSE
(Standard)
CPS (CA) oder
manuelle
Validierung
Mandatory
STARTTLS –
Empfohlen
Class 3 PKCS#10
(Standard)
Soft-PSE
(Standard)
CPS (CA)
EVG mit Domain-
Zertifikat –
Mindeststandard
Class 2 PKCS#10
(Standard)
Soft-PSE
(Standard)
CPS (CA) oder
manuelle
Validierung
EVG mit Domain-
Zertifikat –
Empfohlen
Class 3 PKCS#10
(Standard)
Soft-PSE
(Standard)
CPS (CA) oder
manuelle
Validierung
EVG mit Zertifikat
(persönliche E-
Mail-Adresse) -
Mindeststandard
Class 2 - Soft-PSE
(Standard)
CPS (CA) oder
manuelle
Validierung
EVG mit Zertifikat
auf Basis
persönlicher E-
Mail-Adresse –
Empfohlen
Class 2 PKCS#10
(Standard)
Soft-PSE
(Standard)
CPS (CA) oder
manuelle
Validierung
X-zu-Ende –
Mindeststandard
Class 2 - Soft-PSE CPS (CA) oder
manuelle
Validierung
X-zu-Ende –
Empfohlen
Class 2 PKCS#10
(Standard)
Soft-PSE CPS (CA) oder
manuelle
Validierung
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 1 8
Im Falle von PGP-Zertifikaten gilt die manuelle Validierung oder der Class 2 bzw. 3
vergleichbare Prüfung und Signierung durch eine CA analog. Bei PGP-Zertifikaten ist
das Standardvorgehen zur Erzeugung und Signierung der Zertifikate vergleichbar zum
PKCS#10-Verfahren.
Nach manueller Validierung eines Zertifikats (End Entity Certificate) durch einen E-
Mail-Infrastrukturbetreiber kann dieses, der Qualität der angestrebten
Validierungsklasse entsprechend, bilateral eingesetzt werden - unabhängig von der
Ausstellungsklasse. Eine weiterreichende Vertrauensbeziehung im Verbund wird damit
nicht erreicht.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 1 9 V E R S I O N 1 . 0
Trust-Management
Das Trust-Management beschäftigt sich mit der Validierung, Bereitstellung und
Verwaltung von Zertifikaten gemäß definierter Standards. Diese Aufgaben fallen
regelmäßig für jeden E-Mail-Infrastruktur-Betreiber des Verbundes an, der
verschlüsselte E-Mail-Kommunikation bereitstellt. Verschlüsselte E-Mail-
Kommunikation bezeichnet hierbei
- Inhaltsverschlüsselung mit PGP,
- Inhaltsverschlüsselung mit S/MIME und
- Transportverschlüsselung mit STARTTLS
von jeweils als vertraulich klassifizierten Informationen. In diesem Kontext sind jedoch
auch weitere Anwendungsfälle denkbar.
Im Folgenden werden die Rollen und Aufgaben des Trust-Managements beschrieben.
Es ist in Planung, dass die übergreifenden Aufgaben bzgl. Trust-Einstufung durch
einen zentralen Trust-Management-Dienst erbracht werden. Dies ermöglicht sowohl
die Visualisierung von organisatorischen Beziehungen und Informationsflüssen als
auch die Unterscheidung von Tätigkeiten die individuell umgesetzt oder von einem
Dienstleister – für ein Verbund-Mitglied oder zentral für den gesamten Verbund –
übernommen werden können.
Rollen und Aufgaben
Das Trust-Management gliedert sich in mehrere voneinander abgrenzbare
Verantwortungs- und Tätigkeitsbereiche, in denen unterschiedliche Rollen und
Aufgaben wahrgenommen werden.
Trust-Manager
Trust-Manager sind die jeweiligen Organisationseinheiten der am Verbund beteiligten
Unternehmen, welche für die Nutzer (Versender und Adressat) die technischen
Grundlagen für die Verschlüsselung bereitstellen. Der Trust-Manager ist verantwortlich
für die auf sein Unternehmen ausgestellten Zertifikate und die zweckbestimmte
Nutzung von Zertifikaten der Kommunikationspartner.
Der Trust-Manager bewertet zudem die Vertrauenswürdigkeit und die bereitgestellten
Dienste der vom TrustCenter betriebenen CAs. Die Bewertung erfolgt abhängig von
den grundsätzlichen Sicherheitsanforderungen
Im Rahmen des Trust-Managements nehmen Trust-Manager folgende Aufgaben wahr:
Beschaffung von Zertifikaten bei einer oder mehreren von TrustCentern
betriebener CAs oder anderer E-Mail-Infrastruktur-Betreiber
Technische Gültigkeitsprüfung und Nutzung von Zertifikaten anderer E-Mail-
Infrastruktur-Betreiber
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 2 0
Nutzung von Diensten von TrustCentern (z. B. Zertifikats- und Keyserver)
Bereitstellung von Kontaktdaten und technischen Informationen für die
Bereitstellung von Zertifikaten des eigenen Unternehmens gegenüber den
Partnern
Sicherstellung gesicherter Kommunikation mit anderen E-Mail-Infrastruktur-
Betreibern
Bewertung der von TrustCentern und anderer E-Mail-Infrastruktur-Betreibern
betriebenen CAs insbesondere hinsichtlich:
o CA-Zertifikat
o CP/CPS
o Abfragedienste (CRL, CTL etc.)
o Dokumentation der bewerteten CAs
Bereitstellung und Pflege der Dokumentation
Sicherstellung der Umsetzung und Akzeptanz der vereinbarten Regelungen im
eigenen Unternehmen?
Die Einstufung einer CA kann sich während der Laufzeit ändern. Daher sollten
nachfolgend periodische Neubewertungen erfolgen.
Vor dem Hintergrund der Vermeidung von Adressweitergabe an Dritte ist der Trust-
Manager zum vertraulichen und ausschließlich zweckbestimmten Umgang mit den
bereitgestellten Zertifikaten verpflichtet.
Vor dem Hintergrund der Vermeidung von Adressweitergabe an Dritte ist der Trust-
Manager zum vertraulichen und ausschließlich zweckbestimmten Umgang mit den
bereitgestellten Zertifikaten verpflichtet. In diesem Rahmen integrierte
Unternehmensbezogene Zertifikatsverzeichnisse sind eine Art von
Mitarbeiterverzeichnis. Zur Wahrung des Datenschutzes sind Schutzmaßnahmen
gegen unberechtigte Massenabfragen zu treffen.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
S E I T E 2 1 V E R S I O N 1 . 0
TrustCenter
Das TrustCenter betreibt eine oder mehrere Zertifizierungsstellen (CAs). Das
TrustCenter ist dabei verantwortlich für den gesamten Lebenszyklus der von seinen
CAs ausgestellten Zertifikate. Das TrustCenter definiert dabei pro CA ein
Anforderungsprofil an seine Arbeitsweise (Certificate Policy - CP) und dokumentiert
dessen konkrete Umsetzung in einem Certification Practice Statement (CPS). Das
TrustCenter hat im Allgemeinen folgende Aufgaben:
Ausstellung von Zertifikaten
Bereitstellen von zentralen Diensten zum automatischen Abruf und zur
Gültigkeitsprüfung von selbst ausgestellten Zertifikaten
Bereitstellen der CP/CPS und dementsprechend verbindliches Handeln zur
Analyse der Vertrauenswürdigkeit der CA
Im Falle einer PGP-CA fallen analoge Tätigkeiten, wie die Zertifizierung der
Zugehörigkeit von vorhandenen PGP-Schlüsseln zu Inhabern an.
E – M A I L – S I C H E R H E I T - Z E R T I F I K A T S - U N D T R U S T M A N A G E M E N T
V E R S I O N 1 . 0 S E I T E 2 2
Anhang
Für Spezifikationen, Referenzen und Glossar siehe Hauptdokument E-Mail-Sicherheit
[W1].
Autorenverzeichnis Name Unternehmen E-Mail-Adresse
Frölich, Jens AUDI AG jens.froelich@audi.de
Ionescu, Michael
Porsche-Information-
Kommunikation-Services
GmbH
michael.ionescu@porsche.de
Klingel, Jan-Arendt BMW Group jan-arendt.klingel@bmw.de
Michael Liebe Volkswagen AG michael.liebe@volkswagen.de
Scherr, Carsten Daimler AG carsten.scherr@daimler.com
Dokumenten- und Versionshistorie: Version Datum Status, Anmerkungen
1.0 2010-11-12 Finale Version