Whitepaper Zertifikats- und Trustmanagement

Transkript

1 Whitepaper Zertifikats- und Trustmanagement Anforderungen an Zertifikate und Vertrauensbeziehungen Version: 1.0 Datum: Klassifizierung: öffentlich/public

2 Inhaltsverzeichnis Einführung... 4 Ausgangssituation... 4 Allgemeine Grundsätze des Dokuments... 5 An gesicherter -Kommunikation beteiligte Rollen und Verantwortlichkeiten... 6 Absenderseite... 7 Versender Infrastruktur-Betreiber... 7 Empfängerseite 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 Inhaltsverschlüsselung Anforderungen für den Einsatz von -Verschlüsselungsgateways Domain-Zertifikate Zertifikate auf Basis persönlicher -Adressen Anforderungen für den Einsatz von Ende-zu- Lösungen Anforderungen für den Einsatz im Bereich Ende-zu-Ende Anforderungen für Interimskommunikation V E R S I O N 1. 0 S E I T E 2

3 Zertifikatsmanagement Anforderungen an Zertifikate Identifikation des Antragstellers Absicherung des Transports des Schlüssels zum Antragsteller Physikalische Speicherung des privaten Schlüssels Lebenszyklus Übersicht der Anforderungen an Zertifikate Umsetzungsempfehlungen Trust-Management Rollen und Aufgaben Trust-Manager TrustCenter Anhang Autorenverzeichnis Dokumenten- und Versionshistorie: S E I T E 3 V E R S I O N 1. 0

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 -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 V E R S I O N 1. 0 S E I T E 4

5 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. S E I T E 5 V E R S I O N 1. 0

6 An gesicherter -Kommunikation beteiligte Rollen und Verantwortlichkeiten Um eine gesicherte -Übertragung gewährleisten zu können sind verschiedene Rollen und zugeordnete Verantwortlichkeiten notwendig. Abbildung: Schaubild zur Illustration des Ablaufs einer gesicherten -Übertragung Legende: Grün: Weg der während der gesicherten Übertragung Rot: Für die gesicherte Übertragung benötigte Steuerungsinformationen V E R S I O N 1. 0 S E I T E 6

7 Absenderseite Versender Der Versender ist verantwortlich: die richtige -Adresse des Adressaten zu wählen und die entsprechend des Inhalts korrekt zu klassifizieren. Auf Basis korrekter Steuerungsinformationen wird der -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. -Infrastruktur-Betreiber Die -Infrastruktur muss vom Betreiber entsprechend eingerichtet sein, so dass sie folgende Aufgaben zuverlässig übernimmt: Annahme von s 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 . Bereitstellen der erforderlichen sicheren -Ü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. S E I T E 7 V E R S I O N 1. 0

8 Empfängerseite -Infrastruktur-Betreiber Die -Infrastruktur muss vom Betreiber entsprechend eingerichtet sein, so dass sie folgende Aufgaben zuverlässig übernimmt: Möglichkeiten zur sicheren Annahme von geschützten s bereitstellen. Beschaffung und Bereitstellung von Zertifikatsmaterial (Zertifikatsmanagement). Durchführung von etwaigen kryptographischen Maßnahmen [W2]. Sichere Zustellung der s an den Adressaten. Schutz vor unberechtigtem Zugriff auf die . Adressat Der Adressat ist verantwortlich, empfangene Informationen entsprechend deren Vertraulichkeitsstufe zu behandeln und diese Vertraulichkeitsstufe nicht herabzusetzen. Wenn eine 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 -Verschlüsselung sind Zentralfunktionen notwendig. Sie moderieren und optimieren die für ein Zertifikats-Management notwendigen Prozesse, die bei den -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 -Infrastruktur-Betreiber. Eine Detaillierung der unter dem Begriff Trust-Management zusammengefassten Funktionen ist unter Trust-Management aufgeführt. V E R S I O N 1. 0 S E I T E 8

9 Anwendungsfälle Zertifikats- und Trust-Management bildet die Basis für folgende Anwendungsfälle der -Sicherheit. Diese werden in dem jeweils entsprechenden Whitepaper genauer beschrieben: Transportverschlüsselung [W3] STARTTLS o o VPN opportunistic mode (opportunistic STARTTLS) secure high-ciphers mandatory mode (mandatory STARTTLS) Hostname-Zertifikat (das mit der Domain korreliert) nicht automatisch korrelierbares Hostname-Zertifikat 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 -Adresse Ende-zu- Verschlüsselung o Domain-Zertifikat (Organisationszertifikat) o Persönliches Zertifikat auf Basis der -Adresse Ende-zu-Ende-Verschlüsselung o Persönliches Zertifikat auf Basis der -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. S E I T E 9 V E R S I O N 1. 0

10 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 s 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 -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 ( -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 s für mehrere -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 - Infrastruktur und dem Zielunternehmen zu regeln oder kann einer STARTTLS- MX-CTL entnommen werden) V E R S I O N 1. 0 S E I T E 10

11 Inhaltsverschlüsselung Anforderungen für den Einsatz von -Verschlüsselungsgateways Der Schutz von als vertraulich/confidential klassifizierten Informationen kann mit diesem Verfahren gewährleistet werden. Für die serverbasierte -Verschlüsselung mittels eines - 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 -Domains des Unternehmens oder der Unternehmensgruppe persönliche -Adressen mit Unternehmensbezug persönliche -Adressen ohne Unternehmensbezug Domain-Zertifikate Für X.509-Zertifikate gilt das Zertifikat enthält die -Adresse des -Verschlüsselungsgateways oder eine fiktive -Adresse des Unternehmens o o o im Feld Antragsteller unter Eintrag CN und im Feld Antragsteller unter Eintrag E und im Feld Alternativer Antragsteller unter Eintrag RFC822-Name das Zertifikat und jedes Element der Zertifikatskette ist gültig (zeitlich und nichtrevoziert) und die ausstellende Instanz ist für diesen Anwendungsfall als vertrauenswürdig eingestuft. Dies erfolgt durch individuelle Prüfung des - Infrastrukturbetreibers oder durch Auflistung auf der EVG-CTL (siehe Glossar). Technisch ist zu berücksichtigen, dass die -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 -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 -Infrastruktur sichergestellt oder über eine EVG- CTL. S E I T E 11 V E R S I O N 1. 0

12 Zertifikate auf Basis persönlicher -Adressen Für X.509-Zertifikate gilt das Zertifikat enthält die -Adresse des Inhabers o o im Feld Antragsteller unter Eintrag E oder im Feld Alternativer Antragsteller unter Eintrag RFC822-Name das Zertifikat und jedes Element der Zertifikatskette ist gültig (zeitlich und nichtrevoziert) und die ausstellende Instanz ist für diesen Anwendungsfall als vertrauenswürdig eingestuft. Dies erfolgt durch individuelle Prüfung des - Infrastrukturbetreibers oder durch Auflistung auf der EVG-CTL (siehe Glossar). Für PGP-Zertifikate gilt die -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 -Infrastruktur oder der öffentliche Schlüssel in Verbindung mit der -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 -Adressen vor deren Verwendung erneut geprüft werden. V E R S I O N 1. 0 S E I T E 12

13 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 -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]. S E I T E 13 V E R S I O N 1. 0

14 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ätsklasse Class 1 Class 2 Class 3 Extended Verification (EV) Verifikation des Antragstellers per , sowohl bei persönlichen als auch bei Serverzertifikaten. Bei Serverzertifikaten Validierung des Domaininhabers über Kontakte der NIC-Handles, in Einzelfällen telefonische Verifikation der Unternehmenszugehörigkeit anhand der Informationen aus elektronischen Unternehmensregistern. 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. Persönliche Identifikation bei einer vom CA-Betreiber als Notarfunktion benannten Instanz, über ein Verfahren wie z.b. Postident. Erweiterte Form der Class 3, zzgl. Nachweis des rechtlichen und gesetzlichen Vertreters des Antragsstellers, Umfangreiches schriftliches Antragsverfahren und eingehende Prüfung der eingereichten Daten. niedrig mittel hoch hoch V E R S I O N 1. 0 S E I T E 14

15 Die von kommerziellen CAs ausgestellten Zertifikate enthalten als Attribute je nach Vertraulichkeitsstufen nur eine -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 Zusendung an eine genannte -Adresse Zusendung an eine genannte -Adresse innerhalb einer gesicherten -Infrastruktur Zusendung durch einen Service von bzw. an einen authentifizierten Antragsteller Zusenden per Post Abruf von einem gesicherten Service durch einen authentifizierten Antragsteller Übergabe durch verlässliche Dienstleister Übergabe an einen bevollmächtigten Stellvertreter Persönliche Übergabe Qualitätsklasse niedrig mittel mittel mittel hoch hoch hoch 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. S E I T E 15 V E R S I O N 1. 0

16 Physikalische Speicherung des privaten Schlüssels Die physikalische Speicherung des privaten Schlüssels beim Antragssteller erfolgt per: Ausprägung Soft-PSE (PKCS#12-Token oder PGP-Zertifikat) in Hoheit des Inhabers Soft-PSE (PKCS#12-Token oder PGP-Zertifikat) in Hoheit einer Anwendung (z.b. AD oder EVG) Smartcard oder HSM-Modul Qualitätsklasse niedrig niedrig hoch Der Zugriffsschutz muss bei allen Speicherungsformen implementiert werden, z.b. Passwort oder PIN. Für die Absicherung von als vertraulich/confidential klassifizierten s 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 -Adresse mittel niedrig niedrig X-zu-Ende mit Soft-PSE mittel niedrig niedrig X-zu-Ende mit Smartcard hoch hoch hoch V E R S I O N 1. 0 S E I T E 16

17 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 -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 Opportunistic STARTTLS - Mindeststandard 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- Mail Opportunistic STARTTLS - Empfohlen Class 3 PKCS#10 Soft-PSE - Mandatory STARTTLS Mindeststandard Class 3 PKCS#10 Soft-PSE CPS (CA) oder manuelle Validierung Mandatory STARTTLS Empfohlen Class 3 PKCS#10 Soft-PSE CPS (CA) EVG mit Domain- Zertifikat Mindeststandard EVG mit Domain- Zertifikat Empfohlen EVG mit Zertifikat (persönliche E- Mail-Adresse) - Mindeststandard EVG mit Zertifikat auf Basis persönlicher E- Mail-Adresse Empfohlen Class 2 Class 3 PKCS#10 PKCS#10 Soft-PSE Soft-PSE Class 2 - Soft-PSE Class 2 PKCS#10 Soft-PSE CPS (CA) oder manuelle Validierung CPS (CA) oder manuelle Validierung CPS (CA) oder manuelle Validierung CPS (CA) oder manuelle Validierung X-zu-Ende Mindeststandard X-zu-Ende Empfohlen Class 2 - Soft-PSE CPS (CA) oder manuelle Validierung Class 2 PKCS#10 Soft-PSE CPS (CA) oder manuelle Validierung S E I T E 17 V E R S I O N 1. 0

18 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. V E R S I O N 1. 0 S E I T E 18

19 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 -Infrastruktur-Betreiber des Verbundes an, der verschlüsselte -Kommunikation bereitstellt. Verschlüsselte - 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 -Infrastruktur-Betreiber Technische Gültigkeitsprüfung und Nutzung von Zertifikaten anderer - Infrastruktur-Betreiber S E I T E 19 V E R S I O N 1. 0

20 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 -Infrastruktur- Betreibern Bewertung der von TrustCentern und anderer -Infrastruktur-Betreibern betriebenen CAs insbesondere hinsichtlich: o o o o CA-Zertifikat CP/CPS Abfragedienste (CRL, CTL etc.) 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. V E R S I O N 1. 0 S E I T E 20

21 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. S E I T E 21 V E R S I O N 1. 0

22 Anhang Für Spezifikationen, Referenzen und Glossar siehe Hauptdokument -Sicherheit [W1]. Autorenverzeichnis Name Unternehmen -Adresse Frölich, Jens AUDI AG Ionescu, Michael Porsche-Information- Kommunikation-Services GmbH Klingel, Jan-Arendt BMW Group Michael Liebe Volkswagen AG Scherr, Carsten Daimler AG Dokumenten- und Versionshistorie: Version Datum Status, Anmerkungen Finale Version V E R S I O N 1. 0 S E I T E 22