ssl-studie - bsi - bund.de

Zertifizierungsinfrastruktur

für diePKI-1-Verwaltung

SSL-Studie

Referenzanwendungen, Analyse, Tests,Zertifizierungshierarchie, Konzeptentscheidungen

Version 1.4Stand 31.01.03

Jörg Völker, Hans-Joachim Knobloch

Secorvo Security Consulting GmbHAlbert-Nestler-Straße 9

D-76131 [email protected]

[email protected]

Dr. Andreas SchmidtBundesamt für Sicherheit in der Informationstechnik

Godesberger Allee 185-189D-53175 Bonn

[email protected]

Dieses Dokument einschließlich aller Teile ist urheberrechtlich geschützt.

Die unveränderte Weitergabe (Vervielfältigung) des Dokuments ist ausdrücklicherlaubt.

Jede weitergehende Verwertung außerhalb der engen Grenzen desUrhebergesetzes ist ohne Zustimmung des Bundesamtes für Sicherheit in der

Informationstechnik unzulässig und strafbar.

© 2003 Bundesamt für Sicherheit in der Informationstechnik

Godesberger Allee 185-189, 53175 Bonn

Telefon: 0228/9582-0 - Telefax: 0228/9582-405

Inhaltsübersicht

1 Einleitung 8

2 Anforderungsanalyse, Referenzanwendungen, Tests 10

2.1 Anforderungsanalyse 10

2.1.1 Ausgangslage 10

2.1.2 Lösungsansatz 11

2.1.3 Rahmenbedingungen 12

2.2 Referenzanwendungen 15

2.2.1 Szenario „WWW-Client-Server-Kommunikation miteinseitiger Authentisierung“ 16

2.2.2 Szenario „WWW-Client-Server-Kommunikation mitbeidseitiger Authentisierung“ 18

2.3 Tests 20

2.3.1 Testaufbau 20

2.3.2 Getestete Komponenten 21

2.3.3 PKI-Hierarchie 22

2.3.4 Testzertifikate und –sperrlisten 23

2.3.5 Zusammenfassung der Testergebnisse 25

3 Zertifizierungshierarchie 27

3.1 SSL-Client-Server Architektur 27

3.1.1 Historie 28

3.1.2 Architektur 29

3.1.3 Funktionsweise 35

3.2 Einbettung der Architektur in die PKI-1-Verwaltung 39

3.3 Zertifizierungshierarchie und Struktur der PKI-1-Verwaltungunter Berücksichtigung von SSL 41

4 Konzeptentscheidungen 46

4.1 Randbedingungen und Problemstellungen 46

4.1.1 SSL-Varianten 46

4.1.2 Geeignete Algorithmen (Cipher Suites) 47

4.1.3 Produktauswahl Clients 49

4.1.4 Zertifikatsimport Clients 52

4.1.5 Produktauswahl Server 55

BSI SSL-Studie Seite 3 von 90BSI-SSL-Studie_34.doc Stand 31. Januar 2003

4.1.6 Zertifikatsimport Server 57

4.1.7 SSL und Firewalls 58

4.1.8 Einsatz von Smartcards für SSL 60

4.1.9 European Bridge-CA 61

4.1.10 Verzeichnisdienstkonzept der Verwaltung 62

4.2 Sperrmanagement von SSL-Zertifikaten 63

4.2.1 Sperrung von SSL-Serverzertifikaten im Browser 63

4.2.2 Sperrung von SSL-Clientzertifikaten 65

4.3 Migrationsstrategie 66

4.3.1 Zertifikatsformate 66

4.3.2 Sicherheit der privaten Schlüssel 68

4.3.3 Beschluss des KoopA ADV 71

5 Referenzen 72

A Technischer Anhang 73

A.1 Details der verwendeten Standard-Testzertifikate 73

A.2 Varianten der verwendeten Standard-Testzertifikate 77

A.2.1 Varianten Server-Testzertifikate 77

A.2.2 Varianten Client-Testzertifikate 78

A.3 Testergebnisse bei einseitiger Authentisierung des Servers 79

A.4 Testergebnisse bei beidseitiger Authentisierung 82

A.5 Sperrlistenverarbeitung durch Browser 84

A.6 Sperrlistenverarbeitung durch Server 85

A.7 Schutz des privaten Schlüssels 86

A.8 Dezentrale Schlüsselgenerierung durch Browser 87

A.9 Sicherheitsbetrachtungen zu SSL 2.0 88


Abkürzungen

ADV Automatisierte Datenverarbeitung

AES Advanced Encryption Standard

AG Arbeitsgruppe

API Application Programming Interface

ARL Authoritiy Revocation List

ASN.1 Abstract Syntax Notation Number 1

ATM Asynchronous Transfer Mode

AZR Ausländerzentralregister

BCA Bridge Certification Authority

BSI Bundesamt für Sicherheit in der Informationstechnik

C Country

CA Certification Authority

CBC Cipher Block Chaining

CDP CRL Distribution Point

CN Common Name

CRL Certificate Revocation List

CSP Cryptographic Service Provider nach Microsoft Crypto API

DER Distinguished Encoding Rules (zu ASN.1)

DES Data Encryption Standard

DIT Directory Information Tree

DN Distinguished Name

DNS Domain Name Service

DAS Digital Signature Algorithm

DSS Digital Signature Standard (synonym zu DAS verwendet)

ELSTER Elektronische Steuererklärung

FTP File Transfer Protocol

HMAC Hashed Message Authentication Code

HSM Hardware Security Modul

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

ICMP Internet Control Message Protocol

IETF Internet Engineering Task Force

IGMP Internet Gateway Message Protocol

IP Internet Protocol

ISIS Industrial Signature Interoperability Specification

IV Initialisierungs-Vektor

IVBB Informationsverbund Berlin-Bonn


KoopA ADV Kooperationsausschuss ADV Bund/Länder/Kommunaler Bereich

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

MAC Message Authentication Code

MD5 Message Digest No. 5

MIME Multipurpose Internet Mail Extensions

MTT MailTrusT

O Organization

OCSP Online Certificate Status Protocol

OID Object Identifier (nach ASN.1)

OSI Open System Interconnection

OU Organizational Unit

PCA Policy Certification Authority

PEM Privacy Enhanced Mail

PIN Persönliche Identifikations-Nummer

PKCS Public Key Cryptography Standard (Industriestandards der RSA Security Inc.)

PKI Public Key Infrastruktur

POP Post Office Protocol

PSE Personal Security Environment

PSM Personal Security Manager

RACE Research in Advanced Communications for Europe

RC4 Ron’s Cipher No. 4, Verschlüsselungsalgorithmus nach Ron Rivest

RFC Request For Comments

RIPE RACE Integrity Primitives Evaluation

RIPEMD RIPE Message Digest

RSA Kryptoverfahren nach Rivest, Shamir und Adleman

SHA Secure Hash Algorithm

SMTP Simple Mail Transfer Protocol

SP Service Pack

SPKAC Signed Public Key And Challenge

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLS Transport Layer Security

UDP User Datagram Protocol

URL Uniform Resource Locator

UTF8 Unicode Transformation Format (16 Bit auf 8 Bit)

VPN Virtual Private Network

VS Verschlusssache

VS-NfD Verschlusssache – NUR FÜR DEN DIENSTGEBRAUCH


Änderungshistorie

Version Datum Änderung Autor

1.0 30.09.02 Erste vollständige Version Knobloch

1.1 14.10.02 Einarbeitung Anmerkungen Herr Schmidt (BSI) Knobloch

1.2 17.10.02 Einarbeitung Anmerkungen Herr Schmidt (BSI) Knobloch

1.3 22.11.02 Einarbeitung Anmerkungen aus der internen Kommentierung durch das BSI

Knobloch

1.4 31.01.03 Korrektur in Abschnitt 2.3.5 und Anhang A.5 betreffend LDAP-Zugriffe unter Windows 2000

Dr. Schmidt, BSI


1 Einleitung

Im Rahmen der PKI-1-Verwaltung wird vom Bundesamt für Sicherheit in der

Informationstechnik (BSI) eine Policy Certification Authority (PCA) betrieben.

Die dazu notwendige Sicherheitsleitlinie (PCA-Policy) umfasst zur Zeit

Zertifikate für die Anwendung E-Mail. Für die Bundesverwaltung wird die

Bereitstellung von SSL-Zertifikaten aus der PKI-1-Verwaltung erforderlich.

Daher ist die PCA-Policy um einen Teil „SSL-Zertifikate für Clients und Server“

zu ergänzen, um einen erweiterten Betrieb der PCA ab Ende 2002 zu

ermöglichen.

Im Rahmen dieser Studie wird die vorhandene PCA-Policy um den Aspekt SSL

einschließlich des erforderlichen Namenskonzepts und ggf. weiterer Dokumente

erweitert.

Die Ziele der SSL-Studie ist es zu untersuchen:

• ob die bestehenden E-Mail Zertifikate als SSL-Zertifikate eingesetzt und

• die bisherigen Gruppenzertifikate als SSL-Serverzertifikate verwendet

werden können,

• in welcher Form technisch mögliche und sinnvolle Alternativen zur

Ausgestaltung und Verwendung von SSL-Serverzertifikaten existieren sowie

• welche Möglichkeiten existieren, von den E-Mail-Zertifikaten abgeleitete

Zertifikate ausschließlich als SSL-Zertifikate zu verwenden.

Die SSL-Studie soll des Weiteren in Abstimmung mit dem Auftraggeber einen

geeigneten Lösungsweg zur Umsetzung der Anforderungen darlegen.

Als Randbedingungen werden die Anbindung der PKI-1-Verwaltung an die

European Bridge-CA, die Migration zu ISIS-MTT und die Festlegungen des

Verzeichnisdienstkonzeptes der Verwaltung beachtet [VZK2002].

Die SSL-Studie beschäftigt sich dabei nur mit der Fragestellung der

Authentifizierung der Kommunikationspartner und dem Aufbau einer


gesicherten Verbindung zwischen diesen. Fragestellungen hinsichtlich der

Autorisierung der Kommunikationspartner sind nicht Gegenstand der Studie.


2 Anforderungsanalyse, Referenzanwendungen, Tests

Das Kapitel 2 ist wie folgt aufgebaut:

• Kapitel 2.1 Anforderungsanalyse: In einem ersten Schritt werden im

Rahmen einer Anforderungsanalyse die Einsatzmöglichkeiten für SSL-

geschützte Kommunikation in der Bundesverwaltung zusammengestellt.

Hierzu werden die Informationen aus [Bed_SSL] ausgewertet und

gegebenenfalls erweitert und ergänzt.

• Kapitel 2.2 Referenzanwendungen: Auf Basis von [Bed_SSL] werden zwei

Anwendungsszenarien dargestellt, die in konkreten Beispielen die

Verwendung von SSL in einem Szenario nur zur Serverauthentisierung, im

anderen Szenario sowohl zur Server- als auch zur Clientauthentisierung

aufzeigen. Diese Referenzanwendungen werden in Abstimmung mit dem

Auftraggeber ausgewählt.

• Kapitel 2.3 Tests: Dieses Kapitel beschreibt die Ergebnisse der im Rahmen

der SSL-Studie durchgeführten Tests, die Aufschluss geben sollen über

• die Eignung bzw. Nicht-Eignung von persönlichen E-Mail-Zertifikaten

und Gruppen-Zertifikaten der PKI-1-Verwaltung zur Verwendung für

eine SSL-geschützte Kommunikation

• die Reaktion zuvor festgelegter Beispielanwendungen auf unkorrekte

Zertifikate

• die Verarbeitung von Sperrlisten durch diese Beispielanwendungen.

Weiterführende technische Details zu den Tests finden sich im Anhang.

2.1 Anforderungsanalyse

2.1.1 Ausgangslage

Mit der E-Government-Initiative BundOnline2005 besteht auf Seite der

öffentlichen Verwaltung zunehmend Bedarf, mit Bürgern, Wirtschaft und


Verwaltung über das Internet sicher kommunizieren zu können. Insbesondere

vor diesem Hintergrund muss dabei die Authentizität, Vertraulichkeit und

Integrität der ausgetauschten Informationen gewährleistet werden.

2.1.2 Lösungsansatz

Um die oben formulierten Anforderungen (Authentizität, Vertraulichkeit und

Integrität) an sichere Web-Transaktionen zu erfüllen, wurden in den letzten

Jahren mehrere Kommunikationsprotokolle samt der zugehörigen Applikationen

entwickelt. Das heutzutage mit Abstand am weitesten verbreitete Protokoll

nennt sich „Secure Sockets Layer“ (SSL) in der aktuellen Version 3.0, das seit

1996 von der Firma Netscape entwickelt wurde. Aufgrund der schnellen

Verbreitung und hohen Akzeptanz dieses Ansatzes befasst sich seit 1996 die

Internet Engineering Task Force (IETF) mit einer eigenen Arbeitsgruppe

(Transport Layer Security, TLS) mit der Standardisierung und Fortentwicklung

eines Transport Layer Security Protokolls. Die TLS Arbeitsgruppe startete ihre

Arbeit mit SSL in der Version 3.0 und 1999 wurde die Version 1.01 des

Transport Layer Security Protokolls als Request For Comments (RFC) 2246

veröffentlicht.

SSL dient zur Absicherung von Client-Server Kommunikationsbeziehungen, z.

B. beim Informationsaustausch zwischen Webbrowser und HTTP-Server. Das

SSL-Verfahren wurde speziell mit Blick auf die nachträgliche Ergänzung

bestehender Protokolle (wie z.B. HTTP, FTP, Telnet, POP, SMTP) um diese Si

cherheitsfunktionalitäten bei möglichst geringfügigen Änderungen an

bestehenden Anwendungsprogrammen entworfen.

SSLv3 hat sich damit de facto zum internationalen Industriestandard zur

Absicherung schutzbedürftiger Transaktionen im Internet entwickelt und bietet

sich dadurch auch zur Absicherung der Kommunikation zwischen Behörde und

Wird in der Regel mit der SSL-Version 3.1 gleichgesetzt. Im weiteren Text wird für die

beiden momentan marktgängigen Varianten von SSL/TLS, nämlich SSL in der Version 3.0

und TLS in der Version 1.0 der Einfachheit halber nur noch der Begriff SSL verwendet.


1

Kommunikationspartner (Bürger, Wirtschaft, Behörde) in einer heterogenen

offenen Netzlandschaft wie dem Internet an.

SSL stellt prinzipiell folgende Sicherheitsfunktionen2 zur Verfügung:

• Vertraulichkeit und Unversehrtheit der Nachrichten durch Verschlüsselung

der Nachrichten (obligatorisch) auf Basis von Public-Private Key

Verschlüsselungsverfahren

• Serverauthentisierung (optional, in der Praxis fast immer verwendet)

• Clientauthentisierung (optional).

Für den Einsatz im Behördenbereich kommen je nach Anforderung sowohl

SSL-Verbindungen mit rein serverseitiger Authentifizierung (Authentisierung

des Behörden-Servers gegenüber dem Client des Kommunikationspartners) als

auch server- und clientseitige Authentifizierung (Authentisierung des Behörden-

Servers gegenüber dem Client des Kommunikationspartners sowie des Clients

des Kommunikationspartners gegenüber dem Behörden-Server) in Frage. Rein

theoretisch wäre auch eine einseitige Clientauthentisierung möglich, d. h. nur

der Client des Kommunikationspartners authentifiziert sich gegenüber dem

Behörden-Server. Die verschlüsselte Übertragung der Daten gewährleistet

dabei die Vertraulichkeit und Unversehrtheit des Inhalts sowie die Authentizität

des Datenursprungs.

2.1.3 Rahmenbedingungen

Die Absicherung der Kommunikation zwischen Behörde und Kommunikations

partner (Bürger, Wirtschaft, Behörde) in einer heterogenen offenen

Netzlandschaft wie dem Internet mittels SSL ist gewissen Rahmenbedingungen

unterworfen, die den Einsatz dieser Sicherheitsmaßnahme einschränken.

Eine detaillierte Beschreibung der Funktionsweise und Sicherheitsmechanismen von SSL

findet sich in Abschnitt 3.1.


2

• Formvorschriften

Für den betrachteten Datenaustausch gelten keine Formvorschriften,

insbesondere sind keine qualifizierten Signaturen erforderlich.

• Vertraulichkeit

Es werden Daten bis zu einem mittleren Schutzbedarf bzgl. der Vertraulichkeit

übertragen, so dass eine ungeschützte Übertragung der Daten nicht

zweckmäßig ist. Die unbefugte Kenntnisnahme des Inhalts muss verhindert

werden. Ggf. ist sogar die Information, welche Daten von wem abgerufen

werden, als sensitiv anzusehen. Der geregelte Bereich ist nicht betroffen, d. h.

es werden keine Verschlusssachen VS-VERTRAULICH und höher übertragen.

Die Übertragung von VS-NUR FÜR DEN DIENSTGEBRAUCH kann erfolgen,

sofern das BSI eine Zulassung oder Einsatzempfehlung für die verwendeten

Sicherheitskomponenten ausgesprochen hat.

• Integrität

Es werden Daten bis zu einem mittleren Schutzbedarf bzgl. Integrität

übertragen.

• Verfügbarkeit und Aufbewahrungsfristen

Die Definition und Bestimmung für die Verfügbarkeit des IT-Systems und

eventuell erforderliche Aufbewahrungsfristen für transferierte Daten obliegt dem

Betreiber des IT-Systems. Allerdings muss bei einer Authentisierung der

Kommunikationspartner mittels digitaler Zertifikate bei Verwendung von SSL

berücksichtigt werden, dass die Verfügbarkeit von Sperrinformationen

grundsätzlich Auswirkungen auf die tatsächliche Verfügbarkeit von SSL und

darauf aufbauenden Anwendungen haben kann. Während die Zertifikate selbst

von den beteiligten Instanzen (Client, Server) vorgehalten und bilateral

ausgetauscht werden, müssen Sperrinformationen – sofern überhaupt

unterstützt – automatisch oder manuell von einem Verzeichnis bezogen

werden. Ob bei Nichtverfügbarkeit aktueller Sperrinformationen dennoch eine

SSL-Verbindung zustande kommt, eine Rückfrage an den Benutzer gestellt wird


oder der Verbindungsaufbau abgelehnt wird, ist abhängig vom jeweils

eingesetzten Produkt.

• Authentizität

In bezug auf die Authentizität der Kommunikationspartner sind nach [KryptInt],

Abschnitt 3.3.5, folgende Ausprägungen zu unterscheiden:

• keine oder schwache Authentisierung (e-Mail-Adresse/Wohnanschrift)

• mittlere Authentisierung (persönliche Identifizierung; Account/PIN oder

kryptographische Verfahren mit in Software gespeicherten Schlüsseln)

• starke Authentisierung (persönliche Identifizierung; kryptographische

Verfahren mit in Hardware gespeicherten Schlüsseln)

• starke Authentisierung mit eindeutiger persönlicher Zuordnung (persönliche

Identifizierung; kryptographische Verfahren mit in Hardware gespeicherten

Schlüsseln; zur Vermeidung von Doppeldeutigkeiten müssen zusätzliche

Angaben zur Person – etwa Geburtsname, Adresse, Geburtsdatum, ... –

verfügbar sein)

Innerhalb der PKI-1-Verwaltung kann somit mit Schlüsseln, die ein Webbrowser

in Software speichert, eine mittlere Authentisierungsstufe erreicht werden, beim

Einsatz von Smartcards bzw. Hardware Security Modulen (HSMs) für

Speicherung und Gebrauch der geheimen Schlüssel auch eine höhere Stufe.

• Autorisierung

Fragestellungen hinsichtlich der weitergehenden, applikationsgebundenen

Autorisierung der Kommunikationspartner werden in diesem Kontext nicht

behandelt. Durch den Einsatz von SSL kann die Identität der

Kommunikationspartner mit einer mittleren (oder ggf. auch höheren)

Authentisierungsstärke festgestellt werden. Welche Berechtigung die so

identifizierten Personen im Rahmen des im weiteren Verlauf der Kommunika

tionsbeziehung verwendeten IT-Systems erhalten, muss durch die jeweiligen

Systemverantwortlichen bestimmt und zugeteilt werden (zur Verdeutlichung

siehe Beispiel Kapitel 2.2.2).


• Rechtsverbindlichkeit

Die Rechtsverbindlichkeit sowie die Unabstreitbarkeit der Urheberschaft der

übermittelten Daten werden in diesem Kontext nicht betrachtet; falls diese

aufgrund der Sicherheitsanforderungen des Fachverfahrens notwendig sein

sollten, sind zusätzliche Sicherheitsmechanismen erforderlich.

2.2 Referenzanwendungen

Der Einsatz von SSL-Verbindungen in der Bundesverwaltung ist in der

Entwicklung begriffen. Einige Insellösungen befinden sich bereits jetzt im

Einsatz – eine behördenübergreifende Infrastruktur existiert jedoch noch nicht.

Folgende Beispiele für bereits realisierte oder geplante SSL-Applikationen

lassen vielfältige Einsatzgebiete für gesicherte Web-Kommunikation in der

öffentlichen Verwaltung erkennen:

• Administration und Wartung eines Projektservers im IVBB über eine SSL-

Verbindung zum BSI.

• Sicherung der Übertragung von Formulardaten und aktiven Inhalten bei

einem automatischen Travelmanagement-System des Bundesministeriums

des Innern.

• Gesicherter Zugriff auf das Portal des Bundes „www.bund.de“.

• Gesicherter Zugriff auf die Sperrlisten und sonstige Informationen der

Bridge-CA der deutschen Wirtschaft. Ein authentischer und integerer

Download der Sperrlisten für alle angeschlossenen PKIs stellt einen

wichtigen Bestandteil der Lösung dar.

Das Nutzungspotential von SSL-Verbindungen in der behördlichen Kommunika

tion in einer heterogenen offenen Netzlandschaft soll exemplarisch an zwei

Szenarien verdeutlicht werden.


2.2.1 Szenario „WWW-Client-Server-Kommunikation mit einseitiger

Authentisierung“

Betrachtet wird in diesem Szenario der gesicherte Datenaustausch zwischen

Behörde und Kommunikationspartner (Bürger, Wirtschaft, Behörde) über eine

verschlüsselte WWW-Client-Server-Verbindung in einer heterogenen offenen

Netzlandschaft. Dabei findet eine einseitige Authentisierung des Behörden-

Servers gegenüber dem Client des Kommunikationspartners statt, damit sich

dieser davon überzeugen kann, dass er tatsächlich mit dem Behörden-Server

verbunden ist. Gewahrt werden soll dabei die Vertraulichkeit und Integrität der

übertragenen Daten sowie die Authentizität des Datenursprungs (Server).

Als Beispiel kann hier der Abruf von Informationen und Formularen von einem

Behörden-Server sowie die vertrauliche Übermittlung von Formulardaten an

diese Behörde dienen. Exemplarisch für solch ein Anwendungsszenario kann

das Projekt ELSTER angeführt werden.

ELSTER (Elektronische Steuererklärung) ist ein Projekt der deutschen

Finanzverwaltung, das die sichere elektronische Übermittlung von Steuerdaten

zum Ziel hat. Neben den Steuerberatern erstellen immer mehr Bürger ihre

Steuererklärungen am Computer. Bei dieser Gelegenheit werden die Daten für

den Ausdruck der Steuererklärungsformulare elektronisch erfasst. Diese bereits

erfassten elektronischen Daten will die Steuerverwaltung zur

Weiterverarbeitung in den Rechenzentren der einzelnen Bundesländer nutzen.

Die elektronischen Formulare können dabei von einem zentralen Web-Server

der Steuerverwaltung bezogen werden.

Das Sicherheitskonzept von ELSTER garantiert dabei den authentischen Bezug

der elektronischen Formulare sowie die sichere Übertragung und Verarbeitung

der persönlichen Daten. Im einzelnen umfasst dieses Konzept folgende

Aspekte:

• Authentifizierung: Wenn eine Verbindung zu dem Web-Server der

Steuerverwaltung www.elsterformular.de hergestellt wird, identifiziert sich

die Website automatisch mit Hilfe eines Zertifikats. Dieses Zertifikat wurde


von einer unabhängigen, vertrauenswürdigen Organisation, einer

Zertifizierungsstelle, ausgestellt und enthält unter anderem die Internet-

Adresse des Web-Servers. Das Zertifikat wird vom Client-Computer

automatisch überprüft, bevor er Daten an www.elsterformular.de schickt.

Das Zertifikat garantiert, dass die Verbindung tatsächlich mit

www.elsterformular.de erfolgt.

Abbildung 1: Anzeige des Zertifikats von „www.elsterformular.de“ in Windows NT

• Vertraulichkeit: Die gesamte Kommunikation zwischen den

Kommunikationspartnern (Kunde und www.elsterformular.de) findet in

verschlüsselter Form statt. Dabei wird ein Schlüssel verwendet, der nur dem

Rechner des Kunden und dem ElsterFormular-Webserver bekannt ist. Für

mögliche Mithörer sind die verschlüsselten Nachrichten lediglich eine

bedeutungslose, scheinbar zufällige Folge von Zeichen. Selbst wenn

jemand diese Nachrichten abhören sollte, ist ausgeschlossen, dass er oder

BSI SSL-Studie Seite 17 von 90 BSI-SSL-Studie_34.doc Stand 31. Januar 2003

sie verwertbare Informationen herausziehen kann. Der bei

www.elsterformular.de verwendete Schlüssel hat eine Länge von 128 Bit.

• Datenintegrität: Da aufgrund der Verschlüsselung niemand außer dem

Kommunikationspartner und dem ElsterFormular-Webserver die Bedeutung

der Nachrichten verstehen kann, kann auch niemand diese Nachrichten

gezielt verändern. Wahllose, „blinde“ Änderungen einer Nachricht werden

durch Verwendung des Secure Sockets Layer Protokolls (SSL) bei

www.elsterformular.de ausgeschlossen. SSL garantiert die Integrität von

Nachrichten durch einen Message Authentication Code (MAC), eine Art

Prüfsumme, die zusammen mit der Nachricht übertragen wird. Veränderte

Nachrichten werden an einem fehlerhaften MAC erkannt und

zurückgewiesen.

2.2.2 Szenario „WWW-Client-Server-Kommunikation mit beidseitiger

Authentisierung“

Betrachtet wird in diesem Szenario der gesicherte Datenaustausch zwischen

Behörde und Kommunikationspartner (Bürger, Wirtschaft, Behörde) über eine

verschlüsselte WWW-Client-Server-Verbindung in einer heterogenen offenen

Netzlandschaft. Dabei findet eine beidseitige Authentisierung des Behörden-

Servers gegenüber dem Client des Kommunikationspartners sowie des Clients

des Kommunikationspartners gegenüber dem Behörden-Server statt. Damit

kann sich der Kommunikationspartner davon überzeugen, dass er tatsächlich

mit dem Behörden-Server verbunden ist und die Behörde kann sich davon

überzeugen, dass sie tatsächlich mit dem Client des gewünschten

Kommunikationspartners verbunden ist. Gewahrt werden soll dabei die

Vertraulichkeit der übertragenen Daten sowie die Authentizität des

Datenursprungs (Server bzw. Client).

Als Beispiel sei hier das Ausländerzentralregister (AZR) aufgeführt, dessen

Information serverseitig vertraulich und authentisch abrufbar sein muss, wobei

nur entsprechend autorisierten Stellen der Zugriff gewährt werden darf.


Basierend auf dem AZR-Gesetz [AZRG] vom 2. September 1994 wird das

Ausländerzentralregister vom Bundesverwaltungsamt (Registerbehörde)

geführt. Das Register besteht aus einem allgemeinen Datenbestand und einer

Visadatei. Im allgemeinen Datenbestand werden Daten von Ausländern zentral

gespeichert, die sich nicht nur vorübergehend -– d.h. länger als drei Monate – in

Deutschland aufhalten bzw. aufgehalten haben oder bei denen ein anderer in

§ 2 AZR-Gesetz festgelegter Anlass für eine Datenspeicherung vorliegt.

Der Kreis der öffentlichen und privaten Stellen, die Daten an das Register

liefern und aus dem Register empfangen, ist sehr weit gehalten. Auf Ersuchen

wird an alle öffentlichen Stellen ein begrenzter Datensatz übermittelt (§ 14

AZRG). Ein umfangreicherer, je nach Behörde im Umfang differenzierter

Datensatz steht zur Übermittlung bereit. Etlichen öffentlichen Stellen ist der

Abruf der Daten im automatisierten Verfahren gestattet (§ 22 AZRG), wobei der

Online-Abruf von einem besonderen Zulassungsverfahren abhängig gemacht

wird. Der Zugriff auf das AZR ist sieben Tage die Woche, 24 Stunden am Tag

möglich.

Im Rahmen der E-Government Strategie ist der Benutzerzugriff auf das AZR

einem Re-Design unterworfen und auf moderne webbasierende Dialogformen

umgestellt worden (AZR-Portal). Dabei wird schon heute die Kommunikation

zwischen Client und Server durch die Verwendung des SSL-Protokolls

verschlüsselt, das zusätzlich die sichere Authentifizierung des Servers

ermöglicht.

Die Authentisierung des Clients erfolgt bis dato durch die Übermittlung von

Behördenkennziffer, Anwendername und einem anwenderspezifischen

Passwort. Zukünftig kann, und dies ist auch bereits geplant, die Authentisierung

des Clients ebenfalls über die Nutzung von SSL und digitalen Zertifikaten

erfolgen. Es muss dabei allerdings sichergestellt werden können, dass für das

AZR-Portal durch die Verwendung eines Zertifikats Behörde und Anwender

eindeutig zu bestimmen sind. Dazu müssen die im Client-Zertifikat verfügbaren

Informationen eine zweifelsfreie Zuordnung des digitalen Zertifikats zu einem

AZR Benutzer erlauben.


2.3 Tests

In den durchgeführten Tests sollten die Eignung bzw. Nicht-Eignung von

persönlichen E-Mail-Zertifikaten und Gruppen-Zertifikaten der PKI-1-Verwaltung

zur Verwendung für eine SSL-geschützte Kommunikation, die Reaktion zuvor

festgelegter Beispielanwendungen auf unkorrekte Zertifikate und die

Verarbeitung von Sperrlisten durch diese Beispielanwendungen überprüft

werden.

2.3.1 Testaufbau

Getestet wurde der Zugriff von einem Browser auf eine einfache Webseite

eines Webservers über SSL (URL „https://www.test.de/index.html“) sowohl mit

einseitiger Authentisierung des Servers als auch mit beidseitiger Authentisie

rung des Servers und des Clients. Ein Einsatz von SSL ohne Authentisierung

des Servers ist zwar im Rahmen des SSL/TLS-Standards grundsätzlich erlaubt,

kann jedoch mit den getesteten Produkten nicht realisiert werden.

Als Testumgebung wurden wie in Abbildung 2 dargestellt folgende Elemente

bereitgestellt:

• eine zweistufige Test-PKI-Hierarchie entsprechend den Vorgaben der PKI-1

Verwaltung ([Policy, Namen, GrReg]), bestehend aus Wurzelzertifizierungs

stelle, zwei dieser Wurzel untergeordneten Zertifizierungsstellen und

verschiedenen von den untergeordneten Zertifizierungsstellen ausgestellten

Benutzerzertifikaten für Server und Clients,

• ein Test-LDAP-Verzeichnis entsprechend dem Verzeichnisdienstkonzept der

PKI-1-Verwaltung [VZK2002], sowie

• ein lokaler DNS-Service. Dieser DNS-Service wird für die Abbildung (und

Rück-Abbildung) von DNS-Hostnamen, wie sie in URLs und Zertifikaten

verwendet werden auf die IP-Adresse des jeweiligen Testsystems, zu dem

Verbindungen aufgebaut werden müssen, verwendet. Die Port-Adresse

ergibt sich explizit aus der URL (z.B. „https://www.test.de:444/“) bzw. implizit

aus der Standard-Portadresse des verwendeten Dienstes (z.B. Port 389 für


LDAP). Innerhalb des Testaufbaus wurden Server-Namen in der Domain

„test.de“ verwendet, die im Internet von der Stiftung Warentest belegt ist. Da

der Testaufbau sich auf den reinen Laborbetrieb beschränkte, ergaben sich

hierdurch keine Überschneidungen.

Netzwerk

zu testender Client (Browser)

Server der Testumgebung (DNS-Server, LDAP-Verzeichnis)

CA der Test-PKI

zu testender Webserver

Abbildung 2: Schematische Darstellung des Testaufbaus

2.3.2 Getestete Komponenten

Es wurden fünf Produkte als Webbrowser und drei Produkte als Webserver

gestestet, die ausgehend von der ungefähren Verbreitung im Markt (vgl. z.B.

die einschlägigen Pressemeldungen unter

http://www.heise.de/newsticker/data/anw-28.08.02-006/default.shtml und

http://www.heise.de/newsticker/data/anw-20.08.02-003/default.shtml)

vorgeschlagen wurden. Durch Rückfrage wurde anschließend festgestellt, dass

in der Bundesverwaltung ähnliche Verhältnisse gegeben sind, und somit die

Produktauswahl bestätigt.


Als Betriebssystemplattform dominiert in der Verwaltung Windows NT 4.0, wird

aber zunehmend durch Windows 20003 oder (hauptsächlich im Server-Bereich)

durch Linux abgelöst. Dementsprechend wurden die Betriebssystemplattformen

für die Tests gewählt.

Tabelle 1 gibt eine Übersicht über die getesteten Komponenten.

Kurzname Genaue Bezeichnung Betriebssystemplattform

Webbrowser

MSIE6/W2K Microsoft Internet Explorer 6.0 Windows 2000 SP 2

MSIE6/NT Microsoft Internet Explorer 6.0 Windows NT 4.0 SP6a

MSIE5 Microsoft Internet Explorer 5.5 SP2 Windows NT 4.0 SP5

Netscape6 Netscape 6.0 Windows NT 4.0 SP6a

Netscape4 Netscape Communicator 4.79 Windows NT 4.0 SP5

Opera Opera 6.04 Java Windows NT 4.0 SP5

Webserver

IIS Microsoft Internet Information Server 5.0 Windows 2000 Server SP 2

iPlanet Sun ONE Web Server 6.0 SP2 (vormals iPlanet WebServer Enterprise)

Windows NT 4.0 SP6a

Apache Apache 1.3.26 mit mod_SSL 2.8.10 und OpenSSL 0.9.6e

SuSE Linux 7.2 (Linux Kernel 2.4.4)

Tabelle 1: Getestete Komponenten

2.3.3 PKI-Hierarchie

Es wurde eine zweistufige Test-PKI-Hierarchie als funktional gleichwertige

Nachbildung der momentanen PKI-1-Verwaltung aufgebaut, die in Abbildung 3

dargestellt ist. Das von der Wurzelzertifizierungsinstanz PCA-1-Test

ausgestellte Zertifikat für L1CA2-Test und einige der von L1CA1-Test

ausgestellten Zertifikate wurden durch Aufnahme in die jeweilige Sperrliste

revoziert.

Im Client-Bereich kommt zunehmend Windows XP hinzu, was zu Beginn der Studie noch

nicht erkennbar war.


3

CN=User Test 1

O=PKI-1-Test

CN=User Test 1

O=PKI-1-TestCN=User Test 1

O=PKI-1-Test

CN=User Test 1

O=PKI-1-Test

CN = PCA-1-Test O=PKI-1-Test

C=de

CN=L1CA1-Test OU=Testlabor O=PKI-1-Test

C=de

CN=L1CA2-Test OU=Testlabor O=PKI-1-Test

C=de

OU=Benutzerzertifikate

C=de


C=de OU=Benutzerzertifikate

C=de


C=de

CN=User Test 1 OU=Benutzerzertifikate

O=PKI-1-Test C=de

CN=User Test 6 OU=Benutzerzertifikate

O=PKI-1-Test C=de

CN=GRP: www.test.de OU=Serverzertifikate

O=PKI-1-Test C=de

CN=www.test.de OU=Serverzertifikate

O=PKI-1-Test C=de

Abbildung 3: Test-PKI-Hierarchie (schraffiert dargestellt revozierte Zertifikate)

2.3.4 Testzertifikate und –sperrlisten

Die Regelungen der PKI-1-Verwaltung legen das Zertifikatsformat – insbeson

dere das Format der Zertifikate, die von untergeordneten Zertifizierungsstellen

ausgestellt werden – nicht eindeutig fest, sondern lassen einige Optionen offen,

insbesondere:

• Ein „E-Mail“-Attribut im Inhaber-DN sollte nicht verwendet werden, ist aber

für eine Übergangsphase zulässig. Optional dürfen auch „Locality Name“

Attribute oder zusätzliche „Organizational Unit“-Attribute verwendet werden.

• Die ASN.1-Formate für die Kodierung von Zeitangaben und Strings sind

nicht für alle Elemente eindeutig festgelegt.

• Die zu verwendenden Zertifikatserweiterungen sind nur für die von der PCA

ausgestellten Zertifikate festgelegt; von diesen sind zwei Erweiterungen

(Subject Key Identifier und CRL Distribution Points) optional. Prinzipiell sind

beliebige Erweiterungen zulässig, sofern sie nicht als kritisch markiert sind.


• Verschiedene Optionen hinsichtlich der Ausgestaltung einzelner

Zertifikatserweiterungen sind zulässig. Beispielsweise braucht ein

persönliches Zertifikat oder Gruppenzertifikat die „Basic Constraints“

Erweiterung nicht zu enthalten. Falls es sie enthält, kann der Wert CA=False

explizit angegeben oder das entsprechende Feld leer gelassen werden,

wodurch implizit der Vorgabewert CA=False gilt.

Da der Test aller Kombinationen der möglichen Optionen den Testaufwand um

ein vielfaches erhöht hätte, wurde für jeden der vier Zertifikatstypen

• Wurzelzertifikat,

• Zertifikat einer untergeordneten Zertifizierungsstelle,

• Persönliches Zertifikat (als Clientzertifikat) und

• Gruppenzertifikat (als Serverzertifikat)

anhand

• der Regelungen der PKI-1-Verwaltung [Policy, GrReg],

• der Festlegungen zu Zertifikatsinhalten und -erweiterungen, Formaten und

Protokollen [Formate],

• der Namenskonvention der PKI-1-Verwaltung für Distinguished Names von

Inhaber und Aussteller [Namen],

• vorliegender „echter“ Zertifikate der PKI-1-Verwaltung, sowie

• den Vorgaben des ISIS-MTT Standards [ISIS-MTT]

ein Standard-Testzertifikat ermittelt, das jeweils die entsprechenden Zertifikate

innerhalb der PKI-1-Verwaltung nachbildet, und ausgestellt. Technische Details

dieser Standard-Testzertifikate finden sich im Anhang.

Anschließend wurden die Client- und Server-Zertifikate in den für den Gebrauch

mit SSL relevanten Optionen

• Aufnahme des DNS-Namens in Serverzertifikate als CN-Attribut des

Inhabernamens oder „SubjectAltNames“ Erweiterung,


• Umlaute im Inhabernamen von Clientzertifikaten,

• ASN.1-Stringkodierung des Inhabernamens und

• Belegung der Schlüsselverwendung

variiert und einzelne Zertifikate gesperrt. Tabelle 9 und Tabelle 10 im Anhang

geben einen detaillierten Überblick über diese Variationen.

2.3.5 Zusammenfassung der Testergebnisse

Technische Details und vollständige Testergebnisse sind im Anhang aufgeführt.

Zusammenfassend ergeben sich aus den durchgeführten Tests die folgenden

Resultate hinsichtlich Namensgebung, Zertifikatsprofil und Sperrlisten

verarbeitung:

• Damit ein Serverzertifikat von allen getesteten Browsern ohne Fehler

meldung oder Warnung akzeptiert wird, muss das CN-Attribut des

Inhabernamens identisch mit dem DNS-Namen der Servers sein.

Der SSL/TLS Standard macht zu dieser Thematik keine Angaben. Laut RFC

2818 (der allerdings nur informativen Charakter hat und kein offizieller

Internet-Standard ist) sollte bei Vorhandensein einer „SubjectAltNames“

Erweiterung, die einen DNS-Namen enthält, dieser anstelle des CN-Attributs

im Inhabernamen für den Vergleich mit dem Servernamen in der

angefragten „https://“-URL herangezogen werden. Dieses Verhalten ist unter

den getesteten Browsern jedoch nur beim MSIE anzutreffen. Alle anderen

getesteten Browser verwenden ausschließlich das CN-Attribut als

Vergleichsgrundlage und ignorieren eine ggf. vorhandene

„SubjectAltNames“ Erweiterung.

• Damit ein Serverzertifikat von allen getesteten Browsern ohne Fehler

meldung oder Warnung akzeptiert wird, muss die Schlüsselverwendung

„keyEncipherment“ angegeben werden, sofern die Erweiterung zur Angabe

der Schlüsselverwendung im Zertifikat enthalten ist (für RSA, für andere

Algorithmen gelten andere Schlüsselverwendungen, vgl. [RFC2246] 7.4.2).


Damit ein Clientzertifikat von allen getesteten Servern akzeptiert wird, muss

die Schlüsselverwendung „digitalSignature“ angegeben werden, sofern die

Erweiterung zur Angabe der Schlüsselverwendung im Zertifikat enthalten ist

(für RSA, für andere Algorithmen gelten teilweise andere Schlüssel

verwendungen, vgl. [RFC2246] 7.4.8).

Allerdings wird offenbar die Schlüsselverwendung von einigen der

getesteten Produkte überhaupt nicht ausgewertet, so dass hierdurch keine

verlässliche Möglichkeit zur „Nicht-Verwendung“ eines Zertifikats für SSL

gegeben ist.

• Verschiedene Browser-, Server- bzw. Windows-Versionen haben Probleme

unterschiedlichen Grades (bis hin zum Programmabsturz) bei der

Verwendung von Umlauten bzw. den damit verbundenen ASN.1

Kodierungen BMPString und UTF8String in Attributen von Inhaber- bzw.

Ausstellernamen der Zertifikate.

• Ein größerer Teil der getesteten Produkte kann nicht automatisiert per LDAP

auf Sperrlisten zugreifen, so dass Sperrlisten lokal installiert werden

müssen.

Mit Windows 2000 ist ein LDAP-Zugriff auf Sperrlisten grundsätzlich

möglich. Hierzu müssen jedoch normalerweise absolute LDAP-Pfade in den

"Certificate Distribution Point" Erweiterungen anzutreffen sein. Zugriffe auf

eine in dieser Erweiterung enthaltene LDAP-URL ohne Hostnamen

("relativer Pfad") werden, sofern ein Active Directory im Einsatz ist und bei

Domänenmitgliedschaft des anfragenden Rechners, über das Active

Directory in der Domäne aufgelöst.

Manche Browser (Opera) können gar keine Sperrlisten verwenden, andere

(Netscape) nur solche der mittlerweile überholten Version v1.

• Die von den Webbrowsern für den Endbenutzer ausgegebenen Fehler

meldungen und Warnungen beim Scheitern eines sicheren Verbindungs

aufbaus sind teilweise miss- oder unverständlich oder sogar irreführend.


3 Zertifizierungshierarchie

In diesem Kapitel wird die

• grundlegende SSL-Client-Server Architektur ausgearbeitet, d.h. die

Mechanismen einer Client-Server-Authentisierung mittels SSL dargestellt,

• die Einbettung dieser Architektur in die PKI-1-Verwaltung aufgezeigt, sowie

• die Zertifizierungshierarchie und Struktur der PKI-1-Verwaltung unter

Berücksichtigung von SSL dargestellt.

3.1 SSL-Client-Server Architektur

Secure Sockets Layer (SSL) wurde von der Netscape Communication Corpo

ration4 entwickelt. Es handelt sich hier um eine technische Spezifikation, die

Sicherheit und Zuverlässigkeit zwischen zwei Applikationen, die über offene

Netzwerke (wie z.B. das Internet) kommunizieren, gewährleisten soll. Dazu wird

innerhalb des TCP/IP-Schichtenmodells eine zusätzliche Zwischenschicht

(Layer) zwischen Transport- (Open System Interconnection, OSI-Schicht 4) und

Anwendungsschicht (OSI-Schichten 5-7) eingeführt. Diese Zwischenschicht

verhält sich hinsichtlich der Schnittstelle zu den oberen Schichten sehr ähnlich

wie TCP und kann dadurch einfach in Verbindung mit beliebigen TCP-

basierenden Protokollen genutzt werden (siehe Tabelle 2).

Damit ist es theoretisch möglich, bestehende Protokolle nachträglich sicher zu

machen. Das SSL Protokoll unterstützt somit eine applikationsunabhängige

„Kanal-Sicherheit“, die die folgenden drei Hauptmerkmale aufweist:

• Vertraulichkeit: alle Nachrichten werden verschlüsselt.

• Authentizität: es findet immer eine Server- und optional eine Clientauthen

tifizierung statt.

Vgl. http://www.netscape.com


4

• Integrität: die Nachrichtenübertragung beinhaltet einen Integritätscheck

(mittels MAC).

Die zu diesen Zwecken eingesetzten Kryptoverfahren für

• Authentifikation und Schlüsselaustausch,

• symmetrische Datenverschlüsselung und

• symmetrischen Integritätscheck

und die für den Einsatz der Verfahren zu verwendenden Parameter

(Schlüssellängen etc.) werden zwischen Client und Server interaktiv

ausgehandelt. Um Konfiguration und Aushandlung handhabbar zu machen,

werden jeweils ein Verfahren dieser drei Klassen samt den notwendigen

Parametern zu einer sogenannten „Cipher Suite“ zusammengefasst. So steht

beispielsweise die Cipher Suite „TLS_RSA_WITH_RC4_128_SHA“ für

Authentifikation und Schlüsselaustausch mit dem RSA-Verfahren (die

Schlüssellänge ergibt sich aus den jeweiligen Zertifikaten), Daten

verschlüsselung mit RC4 (Schlüssellänge 128 Bit) und Integritätscheck mit

HMAC-SHA-1.

3.1.1 Historie

Im Jahre 1994 wurde das „Secure Sockets Layer“ Protokoll in der Version 1.0

(SSLv1) erstmalig veröffentlicht, allerdings wurde es in keinem Produkt

implementiert. Im gleichen Jahr erschien jedoch der Netscape Navigator in der

Version 1.1, der bereits die inzwischen weiterentwickelte Version 2.0 von SSL

(SSLv2) beinhaltete. Im Jahre 1995 wurde die Version 3.0 des SSL-Protokolls

(SSLv3) verabschiedet, die eine Reihe von Modifikationen enthielt, wobei die

Abwärtskompatibilität zu SSLv2 gewahrt wurde. So wurden in SSLv3 eine

Reihe weiterer kryptographischer Algorithmen integriert sowie Protokoll

schwächen beseitigt, um bis dato mögliche Angriffe zu erschweren. Im Mai

1996 wurde durch die Internet Engineering Task Force (IETF) die Transport

Layer Security (TLS) Arbeitsgruppe gebildet. Diese Arbeitsgruppe hatte das Ziel

die Standardisierung eines SSL-ähnlichen Protokolls voranzutreiben und


gleichzeitig die Lösungsansätze der Firmen Microsoft und Netscape zu

harmonisieren. Im Januar 1999 wurde schließlich TLS Version 1.0

veröffentlicht.

Die Unterschiede zwischen SSL und TLS sind relativ gering und betreffen im

Wesentlichen folgende Punkte:

• TLS verwendet einen Hashed Message Authentication Code (HMAC) statt

des MAC-Algorithmus von SSL 3.0.

• In TLS fiel die in SSL 3.0 hinzugekommene Unterstützung für die in den

sogenannten „Fortezza“-Karten in Hardware realisierten US-Behörden

algorithmen wieder weg.

• In TLS werden folgende zusätzliche Cipher Suites vorgeschlagen:

• Elliptic Curve Cryptosystem (ECC) und

• Kerberos 5.

• TLS schlägt als obligatorische Cipher Suite (wie oben näher erklärt)

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA vor, d.h. Schlüsselaus

tausch mittels des Diffie-Hellman-Verfahrens, wobei die zum Schlüssel

austausch verwendeten Daten per DSS-Signatur authentisiert werden,

Datenverschlüsselung mit Triple-DES im CBC-Modus (Schlüssellänge

168 Bit) und Integritätscheck mit HMAC-SHA-1 (vgl. auch Abschnitt 4.1.2).

Die Interoperabilität zwischen SSL und TLS ist durch diese kleinen

Unterschiede nicht zwingend gegeben.

3.1.2 Architektur

SSL unterscheidet zwischen Sitzungen (Sessions) und Verbindungen:

• Eine Session ist als Kommunikationskanal zwischen einem Client und einem

Server definiert. Seine Sicherheitsparameter werden durch das Handshake-

Protokoll aufgebaut.


• Eine Verbindung stellt eine Peer-to-Peer Beziehung zwischen Client und

Server dar.

Jede Verbindung gehört zu genau einer Session und zu einer Session können

mehrere Verbindungen gehören. Aus Sicherheitsgründen empfiehlt die SSL

Spezifikation eine maximale Session-Lebensdauer von 24 Stunden.

Der Grund für diese Unterscheidung ist primär ein rein technischer. Bedingt

durch die Eigenschaften von HTML-Beschreibungssprache und HTTP-Protokoll

werden in der Regel alle zur Darstellung einer einzigen Webseite benötigten

Elemente (Text, Stilelemente, Grafiken, Icons, Applets etc.) in Form vielen

separaten kurzen TCP-Verbindungen übertragen. Für jede dieser kurzen

Verbindungen eine vollständige kryptographische Authentifikation

durchzuführen würde zu einem drastischen Leistungseinbruch der beteiligten

Systeme führen. Daher wurde die Möglichkeit geschaffen, mehrere

Verbindungen zu einer Sitzung zusammenzufassen, für die insgesamt nur ein

vollständiger Authentifikationsvorgang durchgeführt werden muss.

3.1.2.1 Sitzungs- und Verbindungs-Zustände

Es liegt in der Verantwortung des SSL-Handshake-Protokolls die Zustände

(session and connection states) des Clients und des Servers zu koordinieren,

d. h. die Zustände der beiden zueinander konsistent zu halten, auch im Hinblick

auf die Tatsache, dass die beiden nicht exakt synchron operieren.

Logisch ist der Gesamtzustand der Übertragung zweifach repräsentiert, einmal

als der aktuelle operating state und (während des Handshake-Protokolls) als

pending state. Zusätzlich werden noch unabhängige Lese- und Schreib-

Zustände verwaltet (read, write states). Wenn der Client oder der Server eine

Change-Cipher-Spec Nachricht erhalten, wird der „pending state“ in den

aktuellen „read state“ kopiert. Wenn der Client oder der Server eine Change-

Cipher-Spec Message senden, wird der „pending state“ in den aktuellen „write

state“ kopiert. Wenn die Handshake-Phase beendet ist, tauschen Client und

Server Change-Cipher-Spec Messages aus und kommunizieren dann unter

Verwendung der vereinbarten Cipher Spec. BSI SSL-Studie Seite 30 von 90BSI-SSL-Studie_34.doc Stand 31. Januar 2003

Eine SSL-Sitzung kann mehrere sichere Verbindungen verwalten; zusätzlich

können auch die unterschiedlichen Parteien verschiedene Sitzungen

gleichzeitig offen haben.

Der Sitzungszustand (session state) enthält die folgenden Elemente:

• session identifier: eine beliebige Bytesequenz, ausgewählt vom Server um

einen aktiven oder wiederaufzunehmenden „session state“ zu identifizieren.

• peer certificate: X509.v3[X509] Zertifikat des Partners (optional).

• compression method: der Algorithmus, mit dem die Daten vor der

Verschlüsselung komprimiert werden.

• cipher spec: spezifiziert den „bulk data encryption“ - Algorithmus (wie DES

oder RC4) und einen MAC5 - Algorithmus (wie MD5 oder SHA). Definiert

ebenso die kryptographischen Attribute, wie beispielsweise die Hashgröße.

• master secret: 48-Byte Geheimzahl, die Client und Server bekannt ist.

• is resumable: ein Flag das anzeigt, ob die Sitzung dazu verwendet werden

kann neue Verbindungen aufzubauen.

Der Verbindungszustand (connection state) enthält die folgenden Elemente:

• server and client random: Bytesequenzen, die vom Server und Client für

jede Verbindung gewählt werden.

• server write MAC secret:: die Geheimzahl, die bei MAC bzw. HMAC

Operationen auf Daten vom Server angewandt wird.

• client write MAC secret: die Geheimzahl, die bei MAC bzw. HMAC

Operationen auf Daten vom Client angewandt wird.

• server write key: der „bulk cipher key“ (Schlüssel für die symmetrische

Verschlüsselung) für Daten, die vom Server verschlüsselt und vom Client

entschlüsselt werden.

Im Falle von TLS den HMAC


5

• client write key: der „bulk cipher key“ (Schlüssel für die symmetrische

Verschlüsselung) für Daten, die vom Client verschlüsselt und vom Server


• initialization vectors: wenn eine Block-Cipher im Cipher Block Chaining

(CBC) Modus verwendet wird, wird ein Initialisierungs-Vektor (IV) für jeden

Schlüssel verwaltet.

• sequence numbers: jede Partei verwaltet getrennte Sequenz-Nummern für

übertragene und empfangene Nachrichten für jede Verbindung. Wenn eine

Partei eine Change-Cipher-Spec Nachricht empfängt oder sendet, wird die

zugehörige Sequenz-Nummer auf Null gesetzt.

3.1.2.2 SSL Schichtenprotokoll

SSL ist ein Schichtenprotokoll und ist wie folgt aufgebaut:

• Record Layer: Der Record Layer bearbeitet alle ihm übergebenen

Datenpakete gemäß dem Sicherheitsparameter und bedient sich der

folgenden vier Protokolle.

• Handshake-Protokoll: Das Handshake-Protokoll bestimmt den Ablauf der

gegenseitigen Authentifizierung von Server und Client sowie die

Aushandlung der Sicherheitsparameter.

• Change-Cipher-Spec-Protokoll: Das Change-Cipher-Spec-Protokoll regelt

den Wechsel zu einer neu ausgehandelten Cipher Spec. Cipher Spec

beinhaltet den in SSL verwendeten symmetrischen Verschlüsselungs

algorithmus und die Hash-Funktion zur Berechnung des MAC bzw. HMAC

sowie deren Schlüssel.

• Application-Protokoll: Das Application-Protokoll wickelt die Datenüber

mittlung zwischen Anwendung und SSL ab.

• Alert-Protokoll: Das Alert-Protokoll macht sich bemerkbar, wenn im Ablauf

von TLS Fehler auftreten.


Tabelle 2 gibt einen Überblick über die Architektur von SSL sowie die

Einordnung in das OSI-Referenz- und TCP-IP-Schichtenmodell

OSI Schicht Protokolle TCP/IP Schicht

7 Anwendung HTTP

6 Darstellung FTP Anwendung 4

TELNET

5 Sitzung Change-Cipher- Alert Handshake Application Spec SSL

Record-Layer4 Transport

TCP, UDP Transport 3

3 Netz IP, ICMP, IGMP Netz 2

2 Datenlink Ethernet, ATM 1 Netzzugang

1 Physikalisch Token-Ring

Tabelle 2: Einordnung von SSL in das OSI und TCP/IP-Schichtenmodell

Record Layer

Die Aufgabe des Record Layers besteht darin, alle SSL-Nachrichten

komprimiert zu übermitteln. Dafür teilt er den Datenstrom an der Senderseite in

eine Serie von Fragmenten auf. Diese werden gemäß den im Handshake-

Protokoll vereinbarten Sicherheitsparametern abgesichert (z.B. mit einem

Message Authentication Code versehen und verschlüsselt) und übertragen. Auf

der Empfängerseite werden die Fragmente entschlüsselt und verifiziert. Auf

dem Record Layer setzen das Handshake-, Change-Cipher-Spec-, Application

und Alert-Protokoll zum Austausch von TLS-Kontrollnachrichten auf.

Handshake-Protokoll

Zu Beginn jeder neuen Verbindung findet zwischen dem Client und Server ein

sogenannter Handshake statt. Das Handshake-Protokoll erfüllt dabei die

folgenden drei Aufgaben:

• Vereinbarung von kryptographischen Algorithmen zwischen dem Server und

dem Client, welche für den Schutz der Kommunikation eingesetzt werden.

• Vereinbarung von kryptographischen Schlüsseln, welche von diesen

Algorithmen genutzt werden.


• Die zertifikatsbasierte Authentifizierung des Servers sowie optional des

Clients.

Das Handshake-Protokoll regelt also sowohl die Authentifizierung von Client

und Server als auch die Aushandlung von Sicherheitsparametern, die vom

Record-Protokoll benötigt werden. Das Handshake-Protokoll erlaubt es,

Sicherungsdienste und Schlüssel auszuhandeln, bevor das Anwendungs

protokoll Daten sendet oder empfängt. Client und Server einigen sich während

des Handshakes dazu auf die Sicherheitsparameter (z.B. die Cipher Spec) oder

brechen die Verbindung gegebenenfalls ab. Die Cipher Spec wiederum besteht

aus Schlüsseln (Master Secret), Schlüsselaustausch-, Verschlüsselungs-,

MAC- und Hash-Verfahren sowie entsprechenden Parametern, die für eine

Session gelten.

Change-Cipher-Spec-Protokoll

Das Change-Cipher-Spec-Protokoll ist das einfachste der vier eingesetzten

Protokolle. Es besteht lediglich aus einer Nachricht. Diese zeigt an, dass die

sendende Applikation zu dem im Handshake vereinbarten kryptographischen

Algorithmus und Schlüsselmaterial wechselt. Alle nachfolgenden Nachrichten

werden mit diesen Vorgaben geschützt übertragen.

Application-Protokoll

Das Application-Protokoll übermittelt die Nutzdaten höherer Schichten an den

Record Layer. Die Daten werden gemäß der bestehenden Session-Parameter

fragmentiert, komprimiert und verschlüsselt.

Alert-Protokoll

Das Alert-Protokoll leitet im Fehlerfall eine Meldung über den darunterliegenden

Record-Layer an das andere Ende der Verbindung weiter. Diese Fehler

meldung gibt Auskunft über die Schwere und den Typ des aufgetretenen

Fehlers. Bei gravierenden Fehlern, z.B. einem falschen MAC, bewirkt die Alert-

Nachricht, dass die Verbindung von beiden Seiten abgebrochen wird.


3.1.3 Funktionsweise

Im Folgenden wird der Abstimmungsprozess zwischen einem Client und Server

bei einem SSL Verbindungsaufbau schematisch dargestellt. Initiiert wird eine

SSL-Verbindung grundlegend immer durch den Client, durch die Anfrage eines

SSL-geschützten Dokumentes auf einem SSL-fähigen Server. Damit eine

beiderseitige Authentifizierung erfolgen kann, müssen sowohl der Client als

auch der Server über geeignete digitale Zertifikate verfügen.

1. Zum Verbindungsaufbau stellt der Client die Anfrage an ein SSL-

geschütztes Dokument auf dem Server, das durch eine URL mit dem

Protokollbezeichner https:// referenziert wird. Die eigentliche HTTP-Anfrage

nach diesem Dokument wird vom Client aber erst nach dem SSL-

Verbindungsaufbau an den Server übertragen, d.h. nach Handshake und

Change-Cipher-Spec.

2. Der Server kann darauf hin eine optionale Hello-Request Nachricht an den

Client senden.

3. Der Client übermittelt diese Anfrage (Client-Hello) an den Server und teilt

ihm die unterstützten Public-, Private-Key, Hash-Verfahren und Schlüssel

längen, die sogenannte „Cipher Suite“ mit. Dabei wird auch eine vom Client

zufällig generierte Zeichenkette (session identifier) übergeben, die entweder

eine frühere oder neu initiierte Sitzung kennzeichnet. Auf diese Weise ist es

möglich, mehrere Kommunikationsverbindungen über die selbe Sitzung zu

verwalten, ohne jedes mal erneut die komplette Handshake-Phase zu

durchlaufen.

4. Der Server sendet darauf hin eine Server-Hello Nachricht an den Client und

übermittelt ihm

• eine durch ihn unterstützte Cipher Suite,

• sein Server-Zertifikat oder zusätzlich

• eine Server-Key-Exchange Nachricht, sofern der Server kein Zertifikat

hat, oder sich das Zertifikat nur zur Unterzeichnung eignet,


• eine Sitzungs-Identifikationsnummer und

• sofern eine optionale Client-Authentisierung erfolgen soll, fordert der

Server das Zertifikat des Clients an (Certificate-Request).

Finden sich unter den aufgeführten Verschlüsselungsoptionen keine

Gemeinsamkeiten, beendet der Server an dieser Stelle die Verbindung.

Der Server signalisiert dem Client durch das Senden einer Server-Hello-

Done Nachricht, dass er alle Nachrichten gesendet hat und auf die

Antworten des Clients wartet.

5. Nach erhalt der Server-Hello-Done Nachricht

• überprüft der Client das Server-Zertifikat, ermittelt daraus den Public-

Key des Servers und verschlüsselt damit einen vom Client zufällig

erzeugten initialen Sitzungsschlüssel (Pre-Master Secret). Dieser

verschlüsselte Sitzungsschlüssel wird an den Server übergeben (Client-

Key-Exchange). Nur der Server mit dem entsprechenden Private-Key

ist nun in der Lage, den Sitzungsschlüssel zu entschlüsseln. Beide, der

Client und der Server, generieren nun mit diesem Sitzungsschlüssel je

ein Paar symmetrische Lese- und Schreibschlüssel, um ein- und

ausgehende Daten zu verschlüsseln (Master Secret). Da der Client und

der Server sowohl das gleiche Protokoll als auch den gleichen

Sitzungsschlüssel verwenden, sind die erzeugten symmetrischen

Schlüsselpaare identisch. Ab diesem Zeitpunkt kann die wesentlich

performantere symmetrische Verschlüsselung verwendet werden.

• sendet der Client bei einer geforderten Client-Authentisierung sein

Zertifikat an den Server (Client-Certificate). Dieser überprüft das

Zertifikat des Clients. Dazu sendet der Client eine Certificate-Verify

Nachricht an den Server, die mit seinem privaten Schlüssel signiert ist.

Die Signaturprüfung auf Seiten des Servers erfolgt mit dem öffentlichen

Schlüssel aus dem Zertifikat des Clients.


• signalisiert der Client dem Server, dass er alle folgende Nachrichten mit

den beim vorausgehenden Handshake vereinbarten Sicherheits

parametern sichern wird (Change-Cipher-Spec).

• schickt der Client anschließend eine mit dem vereinbarten

symmetrischen Verschlüsselungsverfahren verschlüsselte Client-

Finished Nachricht an den Server und wartet auf dessen Reaktion.

6. Nach der Überprüfung der Client-Finished Nachricht sendet der Server

• ebenfalls eine Change-Cipher-Spec Nachricht an den Client und teilt

diesem dadurch mit, dass er alle weiteren Daten dieser Verbindung mit

der neuen Cipher Spec sichern wird.

• abschließend eine mit dem vereinbarten symmetrischen

Verschlüsselungsverfahren verschlüsselte Server-Finished Nachricht

an den Client. Die gegenseitige Authentifikation ist nun erfolgt und die

Sicherungsparameter wurden ausgehandelt.

Ab diesem Moment können die Nutzdaten verschlüsselt übertragen werden,

d.h. die eigentliche HTTP-Anfrage nach dem ursprünglich angefragten

Dokument wird vom Client an den Server übertragen.


Client 1. https:// Anfrage Server

2. Hello-Request

3. Client-Hello

4. Server-Hello

5. Certificate-Request

6. Server-Hello-Done

7. Client-Certificate

8. Client-Key-Exchange

9. Certificate-Verify

10. Change-Cipher-Spec

verschlüsselter Datenaustausch ...

11. Client-Finished

12. Change-Cipher-Spec

6. Server-Finished

Abbildung 4: Schematische Darstellung einer SSL-Verbindung


PCA-1-Verwaltung

zertifiziert

akkreditiert

CACACA

registriertSub- CA

zertifiziert optional

RA

RA Person Gruppe SSL

Funktion VPN (geplant) IT-Prozess

3.2 Einbettung der Architektur in die PKI-1-Verwaltung

Die Architektur der PKI-1-Verwaltung ist in Abbildung 5 dargestellt.

Abbildung 5: Architektur der PKI-1-Verwaltung (aus [Policy])

Die wichtigsten Rahmenbedingungen dieser Architektur in Hinblick auf SSL sind

folgende:

• Teilnehmer sind Personen, Personengruppen, Funktionen oder Dienste (IT-

Prozesse), die im Rahmen der PKI-1-Verwaltung Schlüssel und Zertifikate

erhalten oder aus dem Verzeichnisdienst PKI-Informationen von CAs oder

Teilnehmern abrufen. Endanwender sind natürliche oder juristische

Personen, die Teilnehmer und Inhaber eines Zertifikates der PKI-1-Ver-


waltung sind. Für natürliche Personen werden Pseudonyme zugelassen.

Hier fügt sich die SSL-Architektur wie folgt ein:

• Clientzertifikate sind in der Regel persönliche Zertifikate, je nach

Anwendung ggf. auch Gruppenzertifikate für Personengruppen oder

Inhaber von Funktionen. Die Verwendung von Pseudonymen für SSL-

Clientzertifikate ist grundsätzlich möglich.

• Serverzertifikate sind Gruppenzertifikate für automatisierte IT-Prozesse

mit deren Referenzpersonen (in der Regel Server-Administratoren) als

Schlüsselverantwortliche.

• Es ist eine maximal fünfstufige PKI-Hierarchie vorgegeben.

Dies ist mit Blick auf SSL praxisgerecht:

• Der SSL/TLS Standard macht keine Vorgaben hinsichtlich der Tiefe

einer PKI-Hierarchie. Kommerzielle PKI-Anbieter für SSL-Server

verwenden in aller Regel eine ein- oder zweistufige Hierarchie.

• Eine Kopplung von Zertifizierungsinfrastrukturen durch Über-Kreuz

zertifizierung ist prinzipiell möglich.

In diesem Punkt könnten sich potenziell Probleme hinsichtlich des Einsatzes

von SSL ergeben:

• SSL/TLS trifft keine Aussagen zur Über-Kreuzzertifizierung. Eine

Unterstützung ist also für Konformität mit dem SSL/TLS Standard nicht

gefordert und wird daher von gängigen Produkten nicht implementiert.

In der Praxis kann dies jedoch gelöst werden, indem die betreffenden

Zertifikate so installiert werden, dass die Über-Kreuzzertifizierung sich

den Produkten darstellt wie eine „normale“ Zertifikatskette.

• Die Wurzelzertifizierungsstelle stellt die von ihr ausgestellten Zertifikate und

Sperrlisten in den öffentlich zugänglichen Teil des Verzeichnisses des IVBB

ein.

Das Verzeichnis kann von SSL teilweise genutzt werden:


• SSL/TLS verlangt, dass Server bzw. Client im Zuge der Authentisierung

während des Verbindungsaufbaus ihr Zertifikat einschließlich der

gesamten Zertifikatskette selbst dem Kommunikationspartner über

mitteln. Einzig auf die Übermittlung des Wurzelzertifikats der Kette kann

optional verzichtet werden.

Eine Notwendigkeit, Zertifikate aus einem Verzeichnis zu beziehen, ist

bei SSL also nicht gegeben.

• Anders verhält es sich hinsichtlich der Sperrlisten. Hier können die

gängigen Produkte teilweise Sperrlisten automatisch per LDAP aus

dem Verzeichnis beziehen; teilweise erlauben sie dem Benutzer bzw.

Administrator, Sperrlisten auf Anforderung per HTTP aus dem

Verzeichnis zu beziehen oder anderweitig bezogene Sperrlisten lokal

zu installieren. In jedem Fall können problemlos dieselbe Verzeichnis

struktur und dieselben Sperrlisten verwendet werden, wie für die

E-Mail-Anwendung.

3.3 Zertifizierungshierarchie und Struktur der PKI-1-Verwaltung

unter Berücksichtigung von SSL

Für eine Integration von SSL in die PKI-1-Verwaltung kommen grundsätzlich

zwei Alternativen in Betracht:

• Variante 1: Es wird eine eigene Zertifizierungshierarchie für SSL-

Zertifikate eingerichtet. Dies kommt dem Aufbau einer separaten PKI („PKI

2-Verwaltung“) unter weitgehender Mitbenutzung der technischen,

räumlichen und personellen Infrastruktur der PKI-1-Verwaltung gleich.

• Variante 2: SSL-Zertifikate werden in die bestehende Zertifizierungs

hierarchie der PKI-1-Verwaltung integriert. Somit wird der

Nutzungsbereich der Endanwenderzertifikate von E-Mail auf SSL

ausgedehnt.

Diese Alternativen sind hinsichtlich der folgenden Kriterien abzuwägen:


• Kompatibilität der Sicherheitsleitlinien für die beiden Anwendungen E-Mail

und SSL

• Kompatibilität der Zertifikatsformate und Namensregelungen

• Durchsetzung des geforderten Sicherheitsniveaus

• Möglichkeit der funktionalen Trennung zwischen SSL- und E-Mail-

Zertifikaten

• Perspektiven hinsichtlich der Integration weiterer Anforderungen

• Aufwand für die PCA

• Aufwand für untergeordnete Zertifizierungsstellen

Die Sicherheitsleitlinien der Wurzelzertifizierungsinstanz der Verwaltung

lassen den untergeordneten Zertifizierungsstellen weitgehende Freiheit bei der

Ausgestaltung des von Ihnen angebotenen Dienstes. Sie sind mit allenfalls

geringfügigen Änderungen auch für SSL als PKI-Endanwendung anwendbar.

Dieses Kriterium spricht also für die Variante 2.

Die in [Formate] für E-Mail beschriebenen Zertifikatsformate für Endanwender

sind grundsätzlich auch für SSL einsetzbar. Zwar sind abhängig vom

verwendeten Produkt bzw. Betriebssystem Probleme mit Umlauten oder

bestimmten Sonderzeichen in den Namen von Inhabern und Ausstellern und

den damit verbundenen Zeichendarstellungen zu erwarten. Dies trifft jedoch

auch auf eine Reihe von marktüblichen E-Mail-Produkten zu. Das bestehende

Namensformat für E-Mail-Zertifikate kann für SSL-Clientzertifikate unverändert

übernommen werden. Für SSL-Serverzertifikate muss das Namensformat für

Gruppenzertifikate erweitert werden; der Aufwand für diese Überarbeitung in

Variante 2 ist sicherlich geringer als der Aufwand für die Neuerstellung in

Variante 1. Insbesondere die Möglichkeit, bereits ausgestellte E-Mail-Zertifikate

als SSL-Clientzertifikate zu benutzen, spricht für Variante 2.

Grundsätzlich ist das gleiche Sicherheitsniveau wie für E-Mail gefordert. Eine

Analyse des Schutzbedarfs zeigt auch, dass die auf SSL aufbauenden

Anwendungen in der Regel Dokumente und Daten mit vergleichbarem


Schutzbedarf übermitteln wie bei E-Mail. Zur Durchsetzung des

Sicherheitsniveaus sind an dieser Stelle mehrere Aspekte zu betrachten:

• Eine schwache technische Sicherung des zu einem SSL-Zertifikat gehörigen

privaten Schlüssels (z.B. Verzicht auf Passwort-Schutz des Schlüssels)

könnte das bisher geforderte Sicherheitsniveau herabsetzen.

Für SSL-Server stellt dies in der Praxis kein Problem dar, da

sicherheitskritische Webserver unabhängig von spezieller Sicherung des

SSL-Schlüssels ohnehin in einer gesicherten (Rechenzentrums-)Umgebung

betrieben werden sollten.

Für die Verwendung von SSL-Clientzertifikaten muss auf organisatorischem

Wege der Einsatz von Browser-Produkten (ggf. in Kombination mit dem

Betriebssystem) erreicht werden, die dem Endanwender einen

entsprechenden Mindest-Schutz des privaten Schlüssels ermöglichen.

Hinsichtlich der Durchsetzbarkeit eines dem Niveau der Anwendung E-Mail

gleichen Sicherheitsniveaus unterschieden sich die beiden Varianten nicht.

Dem gegenüber wäre in Variante 1 eine separate Herabsetzung des

verlangten Sicherheitsniveaus innerhalb der getrennten Hierarchie der SSL

PKI (im Verhältnis zur E-Mail-PKI) denkbar. Dies wäre aber gleichzeitig mit

Einschränkungen hinsichtlich der Abdeckung des Schutzbedarfs der SSL

benutzenden Anwendungen verbunden. D.h. die Realisierung von

Anwendungen mit mittlerem Schutzbedarf bzw. Schutzbedarf nach VS-NfD

mit SSL auf Basis einer SSL-PKI mit herabgesetztem Sicherheitsniveau

wäre ggf. nicht mehr zulässig.

• Es ist möglich und sinnvoll, dieselben geeigneten kryptographischen

Verfahren (speziell RSA, SHA-1) für SSL einzusetzen wie für E-Mail-

Anwendungen. Auch unter diesem Aspekt ergibt sich also kein Grund, eine

getrennte Zertifizierungshierarchie einzusetzen.

• Ein dem Sicherheitsniveau bei E-Mail vergleichbares Sperrmanagement,

speziell hinsichtlich Serverzertifikaten, gestaltet sich bei SSL schwierig. Dies

gilt für beide Varianten in gleichem Maße. Allerdings wird durch diese

Probleme ausschließlich das Sicherheitsniveau der SSL-Verbindungen


gesenkt; das Sicherheitsniveau der Anwendung E-Mail wird auch bei

Variante 2 nicht beeinflusst.

Eine funktionale Trennung von SSL-Zertifikaten gegenüber E-Mail-Zertifikaten

für SSL ist in Variante 1 aufgrund des unterschiedlichen Wurzelzertifikats a

priori gegeben.

In Variante 2 kann diese funktionale Trennung (falls überhaupt erforderlich) zu

einem gewissen Grad (abhängig vom standardkonformen Verhalten der

eingesetzten Produkte) technisch über die „KeyUsage“ Erweiterung abgebildet

werden. Darüber hinaus müssen ggf. organisatorische Maßnahmen (z.B.

spezielle, eindeutige OU-Attribute in der Namensgebung) verwendet werden.

Bei der Integration weiterer Anwendungen (z.B. VPN-Zertifikate) müssten

nach Variante 1 folgerichtig – sofern keine neuartigen Argumente für die

Abwägung zwischen den Alternativen vorliegen – jeweils neue, getrennte

Infrastrukturen aufgebaut und der damit verbundene Aufwand getätigt werden.

Dies spricht in der Konsequenz für Variante 2.

Der organisatorische und wirtschaftliche Aufwand für die PCA sollte

angesichts der weitgehenden Kompatibilität bestehender Richtlinien,

Regelungen und Formate zu SSL in Variante 2 (und der begrenzten Anzahl der

derzeit angeschlossenen Zertifizierungsstellen, deren Verträge mit der PKI-1

Verwaltung ggf. geringfügig angepasst werden müssten) in Variante 2 merklich

geringer ausfallen.

Noch deutlicher verschiebt sich das Bild zugunsten von Variante 2, wenn man

den Aufwand der untergeordneten Zertifizierungsstellen betrachtet. Diese

müssten nämlich – sofern sie SSL-Zertifikate ausgeben wollen – sämtlich die

logische Zweiteilung der PCA nachvollziehen und eine separate SSL-PKI

einrichten, die sich in die SSL-Zertifizierungshierarchie der „PKI-2-Verwaltung“

einordnet. Dies heißt u.a., dass für die SSL-Clientauthentisierung zwingend

neue Zertifikate ausgestellt werden müssen und nicht auf die bereits verteilten

E-Mail-Zertifikate zurückgegriffen werden kann.


Zusammenfassend sprechen diese Argumente recht eindeutig für die

Umsetzung der Variante 2, also für die Integration der SSL-Zertifikate in die

bestehende Zertifizierungshierarchie.


4 Konzeptentscheidungen

In diesem Kapitel werden

• verschiedene Konzeptentscheidungen mit ihren Randbedingungen und

Problemstellungen diskutiert und soweit nötig Empfehlungen für die

Entscheidungen erarbeitet,

• Empfehlungen zur Durchführung der Sperrung von SSL-Zertifikaten

gegeben sowie

• eine Migrationsstrategie empfohlen, mit der der Übergang zur Unterstützung

von SSL vollzogen werden kann.

4.1 Randbedingungen und Problemstellungen

4.1.1 SSL-Varianten

Momentan gibt es drei verbreitete Versionen von SSL: SSL 2.0, SSL 3.0 und

TLS 1.0. SSL 2.0 weist im Vergleich mit seinen Nachfolgern einige

Protokollschwächen auf und unterstützt keine mehrstufigen

Zertifikatshierarchien. Daher sollten nur SSL 3.0 und TLS 1.0 verwendet

werden. Zwischen diesen beiden Versionen gibt es keine wesentlichen

Unterschiede hinsichtlich der Sicherheit des Protokolls, sofern äquivalente

Cipher Suites verwendet werden (vgl. unten die Betrachtungen zu Cipher

Suites). In der Spezifikation der beiden neueren Versionen wurde ein

Mechanismus vorgesehen, der es erlaubt, beim Aufbau der SSL-Verbindung

zwischen TLS 1.0, SSL 3.0 und ggf. auch SSL 2.0 zu wechseln.

In den durchgeführten Tests waren sowohl auf Client- als auch auf Serverseite

jeweils mindestens drei verschiedene SSL-Implementierungen vertreten

(Microsoft, Netscape/Sun und OpenSSL/Opera). Alle diese Implementierungen

unterstützen SSL 2.0, SSL 3.0 und, mit Ausnahme des Netscape4 Browsers,

auch TLS 1.0. In sämtlichen Kombinationen war eine prinzipielle

Interoperabilität gegeben, d.h. „passende“ Zertifikate vorausgesetzt, kam eine


sichere Verbindung zustande (vgl. die detaillierten Testergebnisse im Anhang).

Die beobachteten Unterschiede zwischen den SSL-Implementierungen bzw.

Produkten betreffen nur die Handhabung von Zertifikaten und Sperrlisten, die

(zum überwiegenden Teil) nicht vom SSL/TLS Standard abgedeckt wird.

In der Regel kann durch Konfiguration des Servers bzw. Clients festgelegt

werden, welche Versionen von SSL verwendet werden dürfen. Eine Ausnahme

bildet hier der IIS Webserver, der grundsätzlich alle drei Versionen von SSL

parallel unterstützt. Wie eine detaillierte Sicherheitsbetrachtung (siehe Anhang)

zeigt, kann dies toleriert werden.

Empfehlung

• Soweit möglich sollte der Einsatz von SSL in Verbindung mit Zertifikaten der

PKI-1-Verwaltung auf die SSL-Versionen SSL 3.0 und TLS 1.0 beschränkt

werden; die verwendeten Produkte sollten entsprechend ausgewählt und

konfiguriert werden, soweit dies möglich ist.

4.1.2 Geeignete Algorithmen (Cipher Suites)

Das BSI schlägt in [KrypAlg] geeignete Algorithmen für digitale Signatur (RSA,

DSA und DSA-Varianten basierend auf elliptischen Kurven) und als

Hashfunktionen (RIPEMD-160 und SHA-1) vor. Für Grundschutzniveau kommt

als Hashfunktion zusätzlich noch MD5 in Betracht, dessen Schwächen bei der

Verwendung als MAC-Verfahren weniger ins Gewicht fallen als beim Einsatz in

Signaturverfahren. Zu Verschlüsselungs- und Schlüsselaustauschverfahren

werden in [KrypAlg] keine Aussagen getroffen.

Nach dem Stand der Technik muss das Diffie-Hellman-Schlüsselaustausch

verfahren bei gleichen Schlüssellängen als vergleichbar sicher wie der DSA

Signaturalgorithmus betrachtet werden. Auf Diffie-Hellman basierende Cipher

Suites sind allerdings in der Praxis wenig relevant. Die Cipher Suite

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ist zwar nach RFC 2246

obligatorisch, erfordert aber die Verwendung von in der Praxis eher unüblichen

DSA-Zertifikaten. Diffie-Hellman Cipher Suites in Verbindung mit RSA-

Zertifikaten werden oft nicht unterstützt (vgl.Tabelle 3 und Tabelle 4).


Als Verschlüsselungsverfahren kommen als Stand der Technik solche mit

mindestens 112 Bit Schlüssellänge in Frage ([GSHB], Maßnahme M 5.66

empfiehlt mindestens 80 Bit Schlüssellänge; keine der praxisrelevanten Cipher

Suites verwendet Chiffren mit einer Schlüssellänge zwischen 80 und 111 Bit). In

den SSL/TLS Cipher Suites sind dies 3DES, RC4, IDEA und AES. Die beiden

ersteren sind in allen getesteten Produkten implementiert, IDEA wird meist

aufgrund lizenzrechtlicher Probleme nicht unterstützt, AES als neues Verfahren

derzeit noch nicht in vielen Produkten umgesetzt.

Die zu verwendende RSA-Schlüssellänge ergibt sich implizit aus der

Schlüssellänge im verwendeten Zertifikat. Hierfür gelten im Bereich der PKI-1

Verwaltung die in [Policy] getroffenen Regelungen zur Schlüssellänge, d.h.

momentan entsprechend [KrypAlg] eine Mindestlänge von 1024 Bit.

Empfehlungen

• Als zulässige Cipher Suites für IT-Grundschutzniveau werden die folgenden

empfohlen (zu genauen Definition der Cipher Suites siehe [RFC2246],

Anhang C und [RFC3268]):

• TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_RSA_WITH_RC4_128_SHA

• TLS_RSA_WITH_RC4_128_MD5

• TLS_RSA_WITH_AES_128_CBC_SHA


• Als zulässige Cipher Suites für die Übertragung von Inhalten des VS-Grades

VS-NUR FÜR DEN DIENSTGEBRAUCH sind die folgenden vom BSI

empfohlen (zu genauen Definition der Cipher Suites siehe [RFC2246],

Anhang C und [RFC3268]):

• TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_RSA_WITH_RC4_128_SHA




Dies sind die oben für IT-Grundschutzniveau empfohlenen Cipher Suites

mit Ausnahme derjenigen, die MD5 anstelle von SHA-1 für den Integritäts

schutz einsetzt.

Daneben gibt es unter den definierten Cipher Suites weitere, die zwar prinzipiell

ebenfalls geeignet, aber wenig praxisrelevant sind.

4.1.3 Produktauswahl Clients

Generell sollten die in Frage kommenden SSL-Clients (Browser) einer

eingehenden Untersuchung hinsichtlich der Gesamtheit ihrer Sicherheits

eigenschaften unterzogen werden.

Solange eine solche detaillierte Prüfung und Freigabe bzw. Empfehlung

bestimmter Produkte nicht vorliegt, sind an die in Frage kommenden Produkte

zumindest gewisse Mindestanforderungen zu stellen. Diese Mindest

anforderungen beziehen sich primär auf den Schutz der geheimen Schlüssel

der Endanwender (im Fall der zweiseitigen Server- und Clientauthentisierung)

und den vertrauenswürdigen Import der Wurzelzertifikate für die

Serverauthentisierung.

In einigen Anwendungsfällen – insbesondere bei Anwendungen ohne Client

authentisierung, die sich an eine große Zahl von Anwendern außerhalb der

öffentlichen Verwaltung richten, wie z.B. das oben beschriebene ELSTER

Projekt – kann jedoch die Verwendung eines bestimmten Webbrowsers durch

Vorgaben für die Produktauswahl praktisch nicht reguliert werden. In diesem

Fall verbleibt als Lösungsansatz, das Sicherheitsniveau der SSL-Verbindung

über die Konfiguration des Servers unabhängig von der Konfiguration des

Clients (Browsers) beeinflussen, z.B. über die Festlegung bestimmter vom

Server ausschließlich akzeptierter Cipher Suites und die Einhaltung einer

sinnvollen Mindestschlüssellänge (beim ausschließlichen Einsatz von RSA-

Schlüsseln mit einer Schlüssellänge von mehr als 512 Bit wird der Gebrauch

„Export“ Cipher Suites mit schwacher Verschlüsselung verhindert, selbst wenn


ein Server-Produkt keine direkte Einstellung der akzeptierten Cipher Suites

erlaubt).

Empfehlungen

• Es werden folgende Mindestanforderungen an Clients (Browser, ggf. unter

Berücksichtigung des Betriebssystems) gestellt, die für Anwendungen mit

SSL-Clientauthentisierung eingesetzt werden sollen:

• Der geheime Schlüssel des Anwenders muss so verschlüsselt

abgespeichert werden, dass er gegen unbefugtes Auslesen geschützt

ist (z.B. mit einem von einem Benutzerpasswort abgeleiteten

Schlüssel).

• Der Gebrauch des geheimen Schlüssels muss vom Benutzer durch

Eingabe eines Passworts autorisiert werden (mindestens ein Mal pro

Browser-Sitzung, besser bei jedem Gebrauch).

• Der Client darf neue vertrauenswürdige Wurzelzertifikate nicht ohne

Autorisierung durch den Benutzer installieren. Der Benutzer muss die

Möglichkeit haben, ein vertrauenswürdiges Wurzelzertifikat eindeutig zu

identifizieren, z. B. anhand eines Fingerprints.

Soweit möglich sollte allerdings der Benutzer von diesen Aufgaben

entlastet werden, vgl. die Überlegungen zum Zertifikatsimport unten.

• Der Client muss SSL 3.0 und/oder TLS 1.0 und mindestens eine

geeignete Cipher Suite unterstützen. Im Sinne einer breiten

Interoperabilität sollte zumindest die Cipher Suite

TLS_RSA_WITH_3DES_EDE_CBC_SHA unterstützt werden. Je nach

Anwendung können darüber hinaus weitere geeignete Cipher Suites

(vgl. Abschnitt 4.1.2) unterstützt werden.

• Beim Betrieb von SSL-Clients (Browsern) sollten unbedingt regelmäßig alle

sicherheitsrelevanten Patches – insbesondere solche, die die Sicherheit der

SSL-Implementierung bzw. die Auswertung von SSL-Zertifikaten betreffen –

eingespielt werden.


Die Eignung der getesteten Browser hinsichtlich dieser Anforderungen kann der

folgenden Tabelle entnommen werden:

Kriterium Microsoft Internet Explorer 5.5 oder 6.0 unter Windows NT oder Windows 2000

Netscape Communicator 4.79 und Netscape 6

Opera 6.04

Ausreichender Schutz des geheimen Schlüssels6

Wird unterstützt. Es muss für den Schutz des geheimen Schlüssels Sicherheitsstufe „hoch“ gewählt und ein zusätzliches Passwort vergeben werden, ansonsten ist ein Zugriff auf den geheimen Schlüssel auch für den Windows-Domänenadministrator möglich.

Wird unterstützt. Wird unterstützt.

Freigabe des geheimen Schlüssels durch Passwort

Wird unterstützt. Wird unterstützt. Wird unterstützt.

Schutz beim Import von Wurzelzertifikaten


SSL 3.0/TLS 1.0 Wird unterstützt. Wird unterstützt. Wird unterstützt.

Zulässige Cipher Suites

Wird unterstützt. Allerdings kann nicht zwischen einzelnen Cipher Suites differenziert werden. Dies ist jedoch nicht kritisch, da bereits serverseitig die Cipher Suites festgelegt werden.

Diffie-Hellman in Verbindung mit RSA wird nicht unterstützt.

Wird unterstützt.

Diffie-Hellman in Verbindung mit RSA wird von Netscape 4.79 und 6.0 noch nicht unterstützt, jedoch von neueren Versionen.

Wird unterstützt.


weiteres Keine Anmerkungen. Netscape 4.79 unterstützt keine Umlaute in DNs von Zertifikaten und verstößt somit gegen die Anforderungen des Namenskonzepts [Namen].

Opera unterstützt keine Sperrung von Serverzertifikaten über Sperrlisten und ist daher nur für Anwendungen mit entsprechend niedrigen Sicherheitsanforderungen geeignet.

Tabelle 3: Eignung verschiedener Client-Produkte

Die Klärung der Eignung für VS-NfD ist Aufgabe der Zulassung oder Einsatzempfehlung des

BSI.


6

4.1.4 Zertifikatsimport Clients

Zur Serverauthentisierung müssen im Client die Wurzelzertifikate installiert und

als vertrauenswürdig markiert sein. Hierfür gibt es mehrere Möglichkeiten:

• Variante 1: Der Endanwender installiert die Wurzelzertifikate selbst. Hierfür

muss ihm eine Möglichkeit gegeben sein, die Authentizität der

Wurzelzertifikate zu prüfen, z.B. durch einen Fingerprint. Hierzu bedarf es

generell des Vergleichs oder des Bezugs einer nicht fälschbaren

veröffentlichten Version des jeweiligen Wurzelzertifikats bzw. des

zugehörigen Fingerprints.

• Variante 2: Die Wurzelzertifikate können vom Systemadministrator über

Netzwerk in den fertig installierten Browser eines Benutzers eingespielt

werden (z.B. durch Überschreiben der Datei „cert7.db“ beim Netscape-

Browser, die die installierten Zertifikate enthält, oder durch Verteilung über

das Active Directory einer Windows 2000 Domäne beim Microsoft Internet

Explorer). Die Prüfung der Authentizität der Wurzelzertifikate erfolgt in

diesem Fall durch den Systemadministrator.

• Variante 3: Die Wurzelzertifikate werden über ein Software-Management

system innerhalb eines Administrationsbereichs (Rechnernetzes) verteilt,

das eine „Muster-Installation“ des passend konfigurierten Browsers auf den

angeschlossenen Systemen repliziert. Die Prüfung der Authentizität der

Wurzelzertifikate erfolgt in diesem Fall durch den Administrator des

Software-Managementsystems.

• Variante 4: Die Wurzelzertifikate werden in eine installationsfähige (d.h. aus

Setup-Dateien bestehende) angepasste Version des Browsers („Corporate

Edition“) eingebracht und im Zuge der normalen Browser-Installation

automatisch mit installiert.

Eine solche Corporate Edition kann für den Microsoft Internet Explorer mit

dem „Internet Explorer Administration Kit“ zusammengestellt werden Bei

Netscape gibt es ein sogenanntes „Client Customization Kit“, bei Opera ein

„Sales Referral Partner Program“; in beiden Fällen ist unklar, ob dabei auch


die in den Setup-Dateien enthaltenen Wurzelzertifikate angepasst werden

können.

• Variante 5: Die Wurzelzertifikate werden vom Hersteller des Browsers in

eine neue reguläre Version des Browsers integriert. Dies setzt eine

Kooperation des jeweiligen Browser-Herstellers voraus. U.U. fordern

Hersteller hierfür die Zahlung einer sehr hohen (an den Umsätzen

kommerzieller Zertifizierungsstellen orientierten) Lizenzgebühr.

Variante 1 hat den Vorteil, in praktisch jedem Anwendungskontext anwendbar

zu sein, belastet aber den häufig in dieser Hinsicht unbedarften Anwender mit

der Verantwortung für sicherheitsrelevante Konfiguration. Variante 2 hat den

Nachteil, dass dadurch unter Umständen Zertifikate gelöscht werden, die ein

Benutzer selbst in seine persönliche Zertifikatsdatenbank importiert hat.

Variante 3 setzt voraus, dass ein entsprechendes Software-Management

system im jeweiligen Bereich bereits eingesetzt wird. Die Varianten 4 und 5

haben den Nachteil, dass sie erst bei Neuinstallation eines Browsers bzw. bei

der Aktualisierung der bereits eingesetzten Browser im Rahmen einer Migration

wirksam werden.

Zur Clientauthentisierung muss zusätzlich das Zertifikat (und der geheime

Schlüssel) des Endanwenders und die gesamte zugehörige Zertifikatskette

installiert werden. Die technischen Abläufe bei der Verteilung von

Clientzertifikaten und Schlüsseln müssen sich nach den individuellen

Gegebenheiten der jeweiligen Zertifizierungsinstanz und des jeweiligen Clients

richten und können hier nicht verbindlich festgelegt werden. Es wird jedoch

empfohlen falls möglich wie folgt vorzugehen:

• Die Schlüssel werden von der Zertifizierungsinstanz generiert und

zusammen mit dem Clientzertifikat und der Zertifikatskette (inklusive

Wurzelzertifikaten) als passwortgeschützte PKCS#12-Datei an den

Zertifikatsinhaber übermittelt, der diese in seinen Browser importieren kann.

Die bei dieser Vorgehensweise mit installierten Wurzelzertifikate der PCA-1

Verwaltung dienen gleichzeitig als Vertrauensanker für die Server-


authentisierung.

Bei der Übermittlung des Transportpassworts zu der PKCS#12-Datei sollte

genau so verfahren werden, wie dies auch im Fall von E-Mail-Zertifikaten

vorgesehen ist.

• Die Schlüssel werden im Browser generiert und online über ein von der

Zertifizierungsstelle angebotenes Web-Formular ein Zertifizierungsantrag

gestellt (vgl. Abschnitt A.8). Das daraufhin ausgestellte Clientzertifikat und

die Zertifikatskette werden dann ebenfalls online per HTTP zum Download

angeboten (i. d. R. im Format PKCS#7). Um die Authentizität der auf diesem

Wege installierten Zertifikate zu sichern, sollte der Zertifikatsdownload über

eine SSL-Verbindung mit Serverauthentisierung erfolgen.

D.h. bei dieser Vorgehensweise müssen die Wurzelzertifikate der PCA-1

Verwaltung als Vertrauensanker für die Serverauthentisierung bereits im

Browser installiert sein.

Ein Zertifikatsimport per LDAP ist bei SSL-Clients in der Praxis nicht relevant,

da die eigene Zertifikatskette sowie die notwendigen Wurzelzertifikate lokal

installiert sind, während die Zertifikatskette des Kommunikationspartners von

diesem beim SSL-Verbindungsaufbau übermittelt wird.

Empfehlungen

• Für Clients innerhalb und außerhalb des Bereichs der öffentlichern

Verwaltung sollte die Möglichkeit zum Download der Wurzelzertifikate per

HTTP geschaffen werden. Die zugehörigen Fingerprints sind bereits an

diversen Stellen publiziert.

• Für Clients, die zur Clientauthentisierung eingesetzt werden, sollte

bevorzugt das PKCS#12-Format zum Import von geheimem Schlüsseln,

Zertifikaten und Zertifikatsketten (inklusive Wurzelzertifikaten) verwendet

werden. Bei PKCS#12 handelt es sich um ein Dateiformat, dessen Inhalt

verschlüsselt ist.

• Für Clients innerhalb der Verwaltung, die nicht zur Clientauthentisierung

eingesetzt werden, sollten die Wurzelzertifikate bevorzugt über ein


Software-Managementsystem oder eine „Corporate Edition“ des Browsers

installiert werden. Hierbei muss der ausführende Systemadministrator

besondere Sorgfalt auf die Verifikation der Authentizität der zu

installierenden Wurzelzertifikate legen.

4.1.5 Produktauswahl Server

Spezielle Anforderungen aus PKI-Sicht beziehen sich auf die Speicherung und

Freigabe des geheimen Schlüssels und auf die Clientauthentisierung (vgl. den

Abschnitt zum Sperrmanagement unten).

Über diese Aspekte hinaus ist die allgemeine logische und physikalische

Sicherheit des SSL-Servers zu gewährleisten (insbesondere mit Blick auf den

Schutz des geheimen SSL-Schlüssels). Die hierfür zu ergreifenden

Maßnahmen hängen stark von individuellen Gegebenheiten ab und können hier

nicht allgemein festgelegt werden. Es wird empfohlen, insbesondere folgende

Punkte zu beachten:

• Der Aufbau, Umgebung und Betrieb des Servers muss mindestens IT-

Grundschutzniveau (siehe [GSHB]) genügen. Je nach Anwendung sind

darüber hinaus ggf. weitere Regelungen und Sicherheitsanforderungen (z.B.

für Daten des VS-Grads VS-NfD) im Sicherheitskonzept für das jeweilige

LAN zu beachten.

• Je nach Anwendung, Aufbau oder Einbindung des SSL-Servers kann es

erforderlich sein, den SSL-Server mit einer Firewall, Filterung aktiver Inhalte

und /oder einem Virenschutz zu koppeln, z.B

• wenn von den Clients beliebige Informationen auf dem Server abgelegt

werden können oder

• wenn der Kreis der berechtigten Nutzer schlecht überschaubar oder mit

vorsätzlichen Handlungen der Nutzer zu rechnen ist (z.B. bei Servern,

die über das Internet erreicht werden können).

• Bei Servern mit erhöhtem Schutzbedarf wird empfohlen, den Server

ausschließlich für die SSL-Anwendung einzusetzen. BSI SSL-Studie Seite 55 von 90BSI-SSL-Studie_34.doc Stand 31. Januar 2003

Empfehlungen

• Es werden folgende Mindestanforderungen an Server (ggf. unter

Berücksichtigung des Betriebssystems) gestellt:

• Der geheime Schlüssel des Servers muss so verschlüsselt

abgespeichert werden, dass er gegen unbefugtes Auslesen geschützt

ist (z.B. mit einem von einem Benutzerpasswort abgeleiteten

Schlüssel).

• Grundsätzlich muss der Gebrauch des geheimen Schlüssels von einem

Mitglied der zugeordneten Gruppe (im Sinne des Gruppenzertifikats;

hier in der Regel die Gruppe der Administratoren des betreffenden

Servers) beim Start des Servers durch Eingabe eines Passworts

autorisiert werden. Das einzusetzende Produkt muss diese Freigabe

durch Passwort unterstützen.

Nur dann, wenn im Einzelfall gemäß [GrReg, Kapitel 3.4] eine Regelung

getroffen wird, die einen automatisierten Zugriff auf den geheimen

Schlüssel erlaubt, kann auch ein Produkt eingesetzt werden, das keine

derartige Freigabe-Funktionalität unterstützt.

• Server, die für Anwendungen mit Clientauthentisierung verwendet

werden, müssen die Verwendung von Sperrlisten der Version CRLv2

zur Prüfung der Gültigkeit von Client-Zertifikaten unterstützen.

• Der Server muss SSL 3.0 und/oder TLS 1.0 und mindestens eine

geeignete Cipher Suite unterstützen. Im Sinne einer breiten

Interoperabilität muss zumindest die Cipher Suite

TLS_RSA_WITH_3DES_EDE_CBC_SHA und darüber hinaus

möglichst viele weitere geeignete Cipher Suites (vgl. Abschnitt 4.1.2)

unterstützt werden.

• Beim Betrieb von SSL-Servern sollten unbedingt regelmäßig alle

sicherheitsrelevanten Patches – insbesondere solche, die die Sicherheit der

SSL-Implementierung bzw. die Auswertung von SSL-Zertifikaten betreffen –

eingespielt werden.


• Auf die oben genannten Empfehlungen zur allgemeinen Sicherheit des SSL-

Servers wird im Umsetzungskonzept hingewiesen. Hinsichtlich der

allgemeinen IT-Sicherheit gibt das IT-Grundschutzhandbuch [GSHB] weitere

geeignete Empfehlungen.

Die Eignung der getesteten Server-Produkte hinsichtlich der Mindest

anforderungen kann der folgenden Tabelle entnommen werden:

Kriterium Microsoft Internet Information Server 5.0 unter Windows 2000

Sun ONE Web Server 6.0 (vormals iPlanet WebServer Enterprise)

Apache 1.3.26 mit mod_SSL 2.8.10

Ausreichender Schutz des geheimen Schlüssels

Wird unterstützt. Allerdings ist ein Zugriff auf den geheimen Schlüssel auch für den Windows-Domänenadministrator möglich. Sofern dies im Einzelfall gegen Sicherheitsanforderungen verstößt, muss eine Smartcard oder HSM eingesetzt werden.


Freigabe des geheimen Schlüssels durch Passwort

Wird nicht unterstützt. Sofern im Einzelfall benötigt muss eine Smartcard oder HSM mit Freigabe durch PIN eingesetzt werden.


CRLv2 Sperrlisten für Clientzertifikate.


SSL 3.0/TLS 1.0 Wird unterstützt. Wird unterstützt. Wird unterstützt.

Zulässige Cipher Suites

Wird unterstützt. Allerdings kann nicht zwischen Cipher Suites mit MD5 und Cipher Suites mit SHA-1 differenziert werden.


Wird unterstützt.


Wird unterstützt.

Diffie-Hellman in Verbindung mit RSA wird unterstützt.

Tabelle 4: Eignung verschiedener Server-Produkte

4.1.6 Zertifikatsimport Server

Zur Serverauthentisierung muss vom Server-Administrator im Rahmen der

Installation bzw. Konfiguration des Servers das Zertifikat (und der geheime

Schlüssel) des Servers und die gesamte zugehörige Zertifikatskette installiert

werden.


Zur Clientauthentisierung müssen die Wurzelzertifikate, u.U. auch nur die

Zertifikate einzelner untergeordneter Zertifizierungsstellen importiert und als

vertrauenswürdig gekennzeichnet werden.

Da für den Serverbetrieb in aller Regel geschultes Fachpersonal zur Verfügung

steht und die Installation von Zertifikaten im Rahmen von ohnehin anfallenden,

teilweise sicherheitsrelevanten Abläufen (Installation und Konfiguration von

Servern, Webseiten und Web-basierten Anwendungen, Zugriffsrechteverwal

tung) stattfindet, sind hier keine besonderen Probleme zu erwarten.

Ein Zertifikatsimport per LDAP ist bei SSL-Servern in der Praxis nicht relevant,

da die eigene Zertifikatskette sowie die notwendigen Wurzelzertifikate lokal

installiert sind, während die Zertifikatskette des Kommunikationspartners von

diesem beim SSL-Verbindungsaufbau übermittelt wird.

4.1.7 SSL und Firewalls

Zur Benutzung von SSL über eine Firewall hinweg kommen mehrere

Möglichkeiten in Frage:

• Verbindungen zu dem betreffenden TCP-Port eines SSL-geschützten

Servers (standardmäßig Port 443 für HTTP über SSL/TLS) können in einer

Paketfilter-Firewall freigegeben werden.

• Es kann ein Socks-Proxy [RFC1928] eingesetzt werden, der die Daten der

TCP-Schicht für SSL transparent zwischen Client und Server weiterleitet.

• Es kann ein Web-Proxy eingesetzt werden, der über die „connect://“

Methode die Daten der TCP-Schicht für SSL transparent zwischen Client

und Server weiterleitet.

Alle diese Methoden gewährleisten eine durchgängige Transport-Sicherheit

zwischen Client und Server. Daneben sind auch noch Proxy-Verfahren

anzutreffen, die zwei logische SSL-Verbindungen (eine zwischen Client und

Firewall, eine andere zwischen Firewall und Server) aufbauen. Diese Verfahren

bieten nur eingeschränkte Sicherheit und erlauben entweder keine Client

authentisierung oder erfordern Speicherung und Gebrauch der privaten


Schlüssel und Zertifikate der Endanwender auf dem Firewall-Proxy, was der

Anforderung nach Nicht-Weitergabe des privaten Schlüssels in [Policy] zuwider

läuft.

Sofern SSL-Clients über eine Firewall auf SSL-Server zugreifen, ist zu

beachten, dass aktive Inhalte (Java, Javascript, ActiveX etc.) und Viren

aufgrund von Verschlüsselung und Integritätsschutz durch SSL – anders als bei

nicht SSL-geschützten HTTP-Verbindungen – nicht durch die Firewall blockiert

werden können. Ggf. müssen zusätzliche Sicherheitsmaßnahmen wie z.B. die

folgenden getroffen werden:

• Soweit möglich zentrale Deaktivierung der Ausführung aktiver Inhalte in den

betroffenen Browsern durch Vorgabe geeigneter Sicherheitseinstellungen,

die von den Endnutzern nicht verändert werden können. Dies ist abhängig

von der eingesetzten Browser-Version und kann sich in der Praxis schwierig

gestalten.

• Sofern nicht zentral möglich, lokale Deaktivierung der Ausführung aktiver

Inhalte am Client-Rechner.

• Realisierung eines umfassenden Virenschutzes für die SSL-fähigen Client-

Rechner.

• Einschränkung der über die Firewall zulässigen SSL-Verbindungen auf

bestimmte Client-Rechner und auf bestimmte, hinsichtlich der Verwendung

aktiver Inhalte und der Verbreitung von Viren hinreichend vertrauenswürdige

SSL-Server.

Empfehlung

• Firewall-Lösungen, die keine durchgängige Transport-Sicherheit zwischen

Client und Server gewährleisten, sondern die Verwendung von SSL-

Schlüsseln und Zertifikaten auf einem Proxy erfordern, sollten grundsätzlich

nicht eingesetzt werden.

Wenn im Einzelfall doch solche SSL-Proxies eingesetzt werden, weil durch

Maßnahmen auf den Endsystemen keine ausreichende Sicherheit gegen

aktive Inhalte erzielt werden kann, so muss das Sicherheitskonzept der


betreffenden Lösung sicherstellen, dass Benutzer durch dessen

Verwendung nicht gegen das Verbot der Weitergabe von geheimen

Schlüsseln und zugehörigen PINs bzw. Passwörtern [Policy, Kapitel 3.3]

verstoßen.

• Auf die Problematik hinsichtlich aktiven Inhalten und Viren, die über SSL-

geschützte Verbindungen übertragen werden können, und die möglichen

Gegenmaßnahmen wird im Umsetzungskonzept besonders hingewiesen.

4.1.8 Einsatz von Smartcards für SSL

Unter den getesteten Webbrowsern bieten der MSIE (über CSP API) und die

Netscape Browser (über PKCS#11 API) die Möglichkeit, zu Speicherung und

Gebrauch der privaten Schlüssel für die Clientauthentisierung Smartcards

einzusetzen. Dazu kompatible Karten, Leser und Treibersoftware werden von

mehreren Herstellern angeboten. Prinzipiell können dieselben Smartcards auch

für E-Mail-Anwendungen eingesetzt werden, sofern das eingesetzte E-Mail-

Produkt Karten des jeweiligen Herstellers unterstützt.

Auf der Server-Seite gibt es ebenfalls die Möglichkeit, Hardware Security

Module (HSM) für Speicherung und Gebrauch der geheimen Schlüssel

einzusetzen. In der Regel sind dies Einschubkarten oder externe Geräte, die

jedoch funktional und unter Sicherheitsgesichtspunkten weitestgehend

äquivalent zu Smartcards sind.

Zur Einhaltung des Sicherheitsniveaus sind diese Maßnahmen grundsätzlich zu

empfehlen, allerdings nicht unbedingt erforderlich. Sowohl Server- als auch

Clientzertifikate sind den bisherigen E-Mail-Zertifikaten gleichzusetzen, die nicht

in Smartcards gespeichert werden müssen.

Empfehlungen

• Für Systeme bzw. Anwendungen mit erhöhtem Sicherheitsbedarf wird der

Einsatz von Smartcards bzw. Hardware Security Modulen empfohlen.


4.1.9 European Bridge-CA

Die European Bridge-CA ist derzeit auf E-Mail als PKI-Dienstleistung fokussiert;

spezielle Regelungen der Bridge-CA zu SSL gibt es nicht. Die folgenden, in

[BCATln] festgelegten Anforderungen für die Teilnahme an der Bridge-CA

können vom dem hier beschriebenen Lösungsansatz für die Integration von

SSL-Zertifikaten erfüllt werden:

• Persönliche Identifikation und Registrierung des Zertifikatsinhabers.

• Zugriff auf Rückruf-Daten seitens der Bridge-CA und deren Teilnehmer

(CRLs im eigenen Directory bzw. über replizierte Directories oder durch

Einsatz eines OCSP-Servers).

• Bei der Vergabe von Namen (Nutzer- oder PKI-Zertifikaten) muss

sichergestellt sein, dass die gewählten DNs über alle beteiligten

Infrastrukturen hinweg eindeutig sind.

• Zertifikate sind konform zum Standard X.509v3.

• Der Private Key ist ein RSA-Schlüssel mit einer Schlüssellänge von

mindestens 1024 Bit.

• Das Attribut KeyUsage ist auf Signatur und/oder Verschlüsselung gesetzt.

• Die Zertifikate müssen als Datei im Format .crt, .der oder .p7c (als

Austauschformat) vorliegen.

SSL-Clientzertifikate erfüllen diese Anforderungen unmittelbar, für SSL-Server

zertifikate muss dabei der Begriff „Zertifikatsinhaber“ als Schlüsselverantwort

licher des Serverzertifikats interpretiert werden. Die in [BCAErkl] geforderte

eindeutige Erkennbarkeit von Serverzertifikaten wird dadurch gewährleistet,

dass innerhalb der PKI-1-Verwaltung nur diese Zertifikate einen DNS-Namen

als CN des Inhabers führen.

Für die zu verwendenden PKI-Clients fordert [BCATln] aus Interoperabilitäts

gründen die Unterstützung von S/MIMEv2. Diese Anforderung wird um SSL als

Alternative ergänzt werden, falls und sobald die Bridge-CA SSL als Anwendung


offiziell unterstützt. Hinsichtlich der jetzigen Anwendung E-Mail ist die PKI-1

Verwaltung auch dann konform zu den Anforderungen der Bridge-CA, wenn die

E-Mail-Zertifikate gleichzeitig als SSL-Clientzertifikate eingesetzt werden.

Die Bridge-CA verteilt die Wurzelzertifikate der angeschlossenen Mitglieder

momentan in Form einer signierten Zertifikatsliste (ZIP-Datei). Die

Zertifikatsliste in diesem Format kann nicht automatisiert weiter verarbeitet

werden.

Nach einer „manuellen“ Prüfung der Signatur der Zertifikatsliste verbleibt das

Problem, die Wurzelzertifikate der anderen Bridge-CA-Mitglieder weiter zu

verteilen. Dies ist vergleichbar zur authentischen Verteilung des eigenen

Wurzelzertifikats und wird sich in der Praxis aufwändig gestalten. Konkrete

Angaben zum Import von Wurzelzertifikaten der Bridge-CA-Mitglieder in SSL-

Clients können nicht gemacht werden, ehe die European Bridge-CA SSL als

Anwendung offiziell unterstützt und entsprechende Regelungen veröffentlicht.

4.1.10 Verzeichnisdienstkonzept der Verwaltung

Grundsätzlich besteht kein Bedarf, SSL-Zertifikate für Server und Clients in

Verzeichnisse aufzunehmen, da alle Zertifikate beim Aufbau der Verbindung mit

übertragen werden, so dass hier kein Handlungsbedarf besteht.

Im Rahmen der SSL-Verbindungen werden Sperrlisten genutzt. Diese sollen

nach dem Verzeichnisdienstkonzept zur Verfügung gestellt werden (sowohl

zum Abruf aus dem Verzeichnis als auch über eine Website), so dass die

bestehenden Mechanismen ohne Änderung zukünftig mit genutzt werden

können. Auch ein ggf. zukünftig zu realisierender OCSP-Dienst benötigt nicht

die Zertifikate selbst, sondern nur eine aktuelle Sperrliste der betreffenden

Zertifizierungsinstanz als Grundlage für die zu generierenden OCSP-Antworten.

Werden für einen Benutzer mehrere Zertifikate ausgestellt (z.B. eines zur E-

Mail-Absicherung und eines für SSL), so ist der Domänenbetreiber nach dem

Verzeichnisdienstkonzept verpflichtet, nur das E-Mail-Verschlüsselungs-

Zertifikat in die zentralen Verzeichnisdienste zu replizieren. Da diese


Problematik allerdings nicht nur bei Nutzung von SSL, sondern auch bei

Nutzung mehrerer E-Mail-Zertifikate vorliegt, sind entsprechende Mechanismen

zur Auswahl ebenfalls bereits im Verzeichnisdienstkonzept vorgesehen.

Hinsichtlich der Integration des Verzeichnisdienstkonzepts der Verwaltung sind

also keine konzeptionellen Probleme durch die Unterstützung von SSL als

zusätzliche Anwendung zu erwarten.

4.2 Sperrmanagement von SSL-Zertifikaten

4.2.1 Sperrung von SSL-Serverzertifikaten im Browser

Die Sperrung von SSL-Serverzertifikaten in einem Browser wird durch

verschiedene Faktoren erschwert:

• Bei Anwendungen mit einseitiger Serverauthentisierung (ohne

Clientauthentisierung), die sich an Anwender außerhalb der Verwaltung

richten, können praktisch keine Vorgaben hinsichtlich Version und

Konfiguration der einzusetzenden Browser gemacht werden.

• Nicht alle Browser beherrschen die Verarbeitung von Sperrlisten im

aktuellen Format CRLv2. Bei anderen ist die Verarbeitung von Sperrlisten in

der Standardkonfiguration deaktiviert und/oder erfordert bewusste Aktionen

des Benutzers.

• Nur der Netscape Browser ab Version 6.1 beherrscht derzeit eine

Sperranfrage per OCSP.

Daher muss davon ausgegangen werden, dass eine automatisierte Sperrung

von SSL-Serverzertifikaten über Sperrlisten nicht immer möglich ist.

Empfehlungen

• Wenn eine automatisierte Verarbeitung von Sperrlisten vom Browser

unterstützt wird, ist diese einzusetzen.


• Andernfalls muss abhängig von den individuellen Gegebenheiten der

jeweiligen System- und Netzwerkumgebung eine andere Lösung

eingerichtet werden:

• Soweit möglich sollte der Systemadministrator die aktuellen Sperrlisten

über Netzwerk in den fertig installierten Browser eines Benutzers

einspielen.

• Falls der Systemadministrator diese Möglichkeit nicht hat, muss dem

Endanwender der Download und die manuelle Installation der aktuellen

Sperrlisten ermöglicht werden.

Es liegt dann in der Verantwortung des Endanwenders, diese

Sperrlisten zu nutzen. Sobald der verantwortliche Systemadministrator

Kenntnis von der Sperrung eines Serverzertifikats erlangt, sollte er die

betroffenen Endanwender (z.B. per E-Mail) informieren und zur

Installation der betreffenden Sperrliste im Browser auffordern.

• Es können und sollten sensibilisierten Endanwendern je nach Anwender

kreis mehrere, zum Bürger hin möglichst alle Möglichkeiten für eine

Sperranfrage angeboten werden:

• automatischer Sperrlistenimport via CDP-Erweiterung mit LDAP-URL,

• künftig ggf. eine automatische Sperranfrage via OCSP (derzeit nur vom

Netscape Browser ab Version 6.1 unterstützt) und

• manueller Sperrlistenimport via HTTP.

• Als Basis für ein durchgängiges Sicherheitsniveau kann jedoch nur die

Server-Seite dienen. Hier ist die Kombination mehrerer Maßnahmen zu

empfehlen:

• Der Schlüsselverantwortliche (Server-Administrator) veranlasst bei

Vorliegen eines Sperrgrunds (vgl. [Policy, Kapitel 5.4.1] und [GrReg,

Kapitel 3.2 und 3.4]) die Sperrung des jeweiligen Server-Zertifikats

durch Meldung bei der betreffenden Zertifizierungsstelle.


• Der Schlüsselverantwortliche (Server-Administrator) ist dazu zu

verpflichten, bei Benachrichtigung über die Sperrung des jeweiligen

Serverzertifikats das Zertifikat und den zugehörigen geheimen

Schlüssel unverzüglich zu löschen bzw. eine zugehörige Hardware-

PSE einzuziehen.

Hierdurch wird ein Missbrauch des gesperrten Zertifikats zuverlässig

verhindert, falls der Sperrgrund nicht Schlüsselkompromittierung war.

• Durch die eindeutige Erkennbarkeit eines SSL-Serverzertifikats am

Inhabernamen (DNS-Namen im CN) wird die Reichweite des möglichen

Missbrauchs eines kompromittierten Schlüssels zu einem gesperrten

Zertifikat auf die Vorspiegelung der Server-Identität für SSL-

Verbindungen begrenzt. Eine missbräuchliche Verwendung des

Zertifikats für die E-Mail-Sicherung oder für andere SSL-Server-

Identitäten kann am Inhabernamen erkannt werden.

Auf diesem Wege wird bezüglich der Sperrung von SSL-Serverzertifikaten ein

ausreichendes Sicherheitsniveau erreicht. Das Sicherheitsniveau hinsichtlich

der Sperrung von E-Mail-Zertifikaten und SSL-Clientzertifikaten bleibt hiervon

unberührt.

4.2.2 Sperrung von SSL-Clientzertifikaten

Deutlich einfacher als bei der Sperrung von SSL-Serverzertifikaten stellt sich

die Situation bei SSL-Clientzertifikaten dar. Alle betroffenen Server als Inhaber

von Zertifikaten der PKI-1-Verwaltung sind – im Gegensatz zu Browsern von

Endanwendern außerhalb der Verwaltung – den geltenden Regelungen

hinsichtlich des Sperrmanagements unterworfen. Alle getesteten Server

produkte können Sperrlisten der Version CRLv2, wie sie von der PCA-1

Verwaltung erstellt werden, verarbeiten.

Empfehlungen

• Die SSL-Server müssen so konfiguriert werden, dass sie die jeweils gültigen

Sperrlisten zur Überprüfung von Zertifikaten verwenden. Dies kann auf

mehrere Arten realisiert werden:


• Sofern vom eingesetzten Produkt unterstützt (unter den getesteten nur

vom IIS), können die Sperrlisten automatisch per LDAP über die in der

CDP-Erweiterung der Zertifikate angegebene URL bezogen werden.

Dazu ist keine Änderung am derzeitigen Verzeichnisdienstkonzept oder

Sperrlistenformat nötig. Allerdings muss für die korrekte Verarbeitung

des CDP durch Microsoft-Produkte (IIS, aber auch ggf. MSIE) der

Hostname des LDAP-Servers in der URL angegeben sein.

Hierfür muss ein Zugriff auf das Verzeichnis technisch möglich sein

(mögliches Problem z.B. Firewalls).

• Andernfalls muss der Server-Administrator einen Prozess einrichten,

um vor Ablauf der Sperrliste (oder häufiger) die aktuellen Sperrlisten

aus dem Verzeichnis zu beziehen und in den Server zu importieren.

Dabei können die Sperrlisten grundsätzlich über das bestehende

LDAP-Verzeichnis oder den HTTP-Server entsprechend dem

Verzeichnisdienstkonzept der PKI-1-Verwaltung bezogen werden.

Es bietet sich an, diesen Prozess der Sperrlistenaktualisierung zu

automatisieren. Gegebenenfalls können geeignete Beispielkonfigura

tionen (Skripte etc.) für die verbreitet eingesetzten Server entwickelt

werden, die für betroffene Systeme mit minimalem Aufwand

übernommen werden können.

Auf diesem Wege wird bezüglich der Sperrung von SSL-Clientzertifikaten ein

zur E-Mail-Anwendung äquivalentes Sicherheitsniveau erreicht.

4.3 Migrationsstrategie

4.3.1 Zertifikatsformate

Im Vergleich mit der Anwendung E-Mail ergibt sich hinsichtlich der

Zertifikatsformate folgender Änderungsbedarf:

• Als SSL-Clientzertifikate können prinzipiell die bisherigen persönlichen E-

Mail-Zertifikate unverändert genutzt werden.


• Alternativ können neue SSL-Clientzertifikate, die nicht als E-Mail-Zertifikate

genutzt werden sollen („SSL-only“), mit einer geänderten Belegung der

„KeyUsage“-Erweiterung (Nutzungsart nur „digitalSignature“7) ausgestellt

werden. Diese „SSL-only“-Zertifikate dürfen keine E-Mail-Adresse in der

„SubjectAltNames“-Erweiterung enthalten.

Hierfür kommt wie in Abschnitt 4.1.4 beschrieben eine zentrale Schlüssel

generierung mit anschließender Übermittlung einer PKCS#12-PSE oder

eine dezentrale Schlüsselgenerierung in Frage (vgl. auch Abschnitt A.8).

In beiden Fällen muss die zuständige Zertifizierungsinstanz durch

organisatorische Maßnahmen zuverlässig feststellen, ob ein SSL-Zertifikat

beantragt wurde und das Zertifikat dementsprechend als „SSL-only“

ausstellen. Diese Feststellung kann bei zentraler Schlüsselgenerierung z.B.

durch einen Vermerk auf dem Antragsformular der Zertifizierungsinstanz

erfolgen, bei dezentraler Schlüsselgenerierung z.B. implizit aufgrund der

Tatsache, dass der Zertifizierungsantrag über eine Web-Schnittstelle aus

einem Browser heraus gestellt wurde.

• Als SSL-Serverzertifikate werden Zertifikate nach den selben Regelungen

wie bisher für die E-Mail-Gruppenzertifikate genutzt. Es erfolgt lediglich eine

Änderung im Naming durch Weglassen des „GRP:“-Präfixes im CN. Hier

müssen grundsätzlich neue Zertifikate ausgestellt werden; bereits

ausgegebene Gruppenzertifikate für E-Mail dürfen nicht als SSL-

Serverzertifikate verwendet werden.

Diese Anpassungen erfordern keine oder allenfalls geringfügige technische

Änderungen, daher muss eine Migrationsstrategie hinsichtlich der

Zertifikatsformate nicht vorgesehen werden, sondern primär die Anpassung der

organisatorischen Rahmenbedingungen betrachtet werden. Somit könnte nach

einer

Solche Zertifikate müssen von MailTrusTv2-konformen E-Mail-Clients bzw. –Plugins

zurückgewiesen werden, da nach [Mttv2-4], Kapitel 4.2 bzw. 4.3 für Signieren von Mails die

Nutzungsart „NonRepudiation“ und für Verschlüsseln „KeyEncipherment“ gefordert wird.


7

• Anpassung der Regelungen der PKI-1-Verwaltung an diese Änderung des

Namensschemas und einige weitere Randbedingungen des Einsatzes von

SSL und der

• anschließenden Abstimmung dieser geänderten Regelungen mit allen

angeschlossenen Zertifizierungsstellen (und ggf. der Anpassung der

Richtlinien der Zertifizierungsstellen)

unmittelbar mit der Ausstellung von SSL-Serverzertifikaten und der

Verwendung von vorhandenen E-Mail-Zertifikaten für die SSL-Client

authentisierung bzw. der Ausstellung von „SSL-only“-Clientzertifikaten

begonnen werden.

4.3.2 Sicherheit der privaten Schlüssel

Ein besonders wichtiger Sicherheitsaspekt bei der Benutzung von E-Mail-

Zertifikaten und Schlüsseln für die SSL-Clientauthentisierung ist der Schutz der

privaten Schlüssel in den jeweils eingesetzten Produkten.

Ein privater Schlüssel, der im Rahmen der SSL-Anwendung durch

unzureichende Schutzmechanismen eines SSL-Produkts kompromittiert wird,

kann selbstverständlich auch nicht mehr zur Sicherung von E-Mail verwendet

werden. Als besonders kritisch ist der Fall einzustufen, dass eine

Schlüsselkompromittierung über längere Zeit unbemerkt bleibt.

Um in dieser Hinsicht bei der Einführung von SSL keine zusätzlichen Risiken

einzugehen, sollten idealerweise SSL-Produkte (insbesondere Clients) zum

Schutz von privaten Schlüsseln gleichwertige Sicherheitsmechanismen

einsetzen wie die bereits im Einsatz befindlichen E-Mail-Produkte. Beim

(grundsätzlich empfehlenswerten, jedoch vergleichsweise aufwändigen) Einsatz

von Smartcards für beide Anwendungen ist diese Gleichwertigkeit offensichtlich

gegeben, da der bestimmende Sicherheitsmechanismus zum Schutz des

privaten Schlüssels die Smartcard selbst ist.


In allen anderen Fällen stehen der erstrebenswerten Feststellung einer

Gleichwertigkeit eines SSL-Produktes mit den eingesetzten E-Mail-Produkten

zwei fundamentale Probleme entgegen:

• Aus den Regelungen der PKI-1-Verwaltung lassen sich keine direkten

Vorschriften hinsichtlich des Umgangs der eingesetzten E-Mail-Produkte mit

privaten Schlüsseln ableiten. Daher kann schwerlich beurteilt werden, ob ein

bestimmter Satz an Anforderungen (z.B. die oben in Abschnitt 4.1

aufgestellten Mindestanforderungen an Client-Produkte), gegen die SSL-

Produkte gemessen werden könnten, die angestrebte Gleichwertigkeit

gewährleistet.

• Selbst wenn ein solcher Maßstab zur Verfügung stünde, gestaltet es sich

schwierig, die in Frage kommenden SSL-Client-Produkte verlässlich

dagegen zu vergleichen. Der verfügbare Kenntnisstand beruht derzeit im

Wesentlichen auf Herstellerangaben (vgl. Abschnitt A.7 im Anhang), die

durch Black-Box-Tests, Code-Inspektion oder vergleichbare Unter

suchungen validiert werden müssten.

Bis zur abschließenden Klärung der Frage, welche SSL-Produkte unter welchen

Betriebsbedingungen unbedenklich zur Verwendung mit solchen Zertifikaten

und Schlüsseln eingesetzt werden können, die auch zur Sicherung von E-Mail

eingesetzt werden, sollten daher zur SSL-Clientauthentisierung

• entweder Schlüssel verwendet werden, die auf Smartcards gespeichert und

angewendet werden und daher gegen unbefugtes Auslesen geschützt sind,

• oder neue „SSL-only“-Zertifikate ausgestellt werden.

Durch diese Strategie ergibt sich ein gewisser Zusatzaufwand für die

Ausstattung derjenigen Endanwender, die bereits über gültige E-Mail-Zertifikate

verfügen, mit SSL-Clientzertifikaten. Dieser Zusatzaufwand ist im wesentlichen

bestimmt durch:

• den organisatorischen Aufwand für die Ausstellung und Übermittlung von

Zertifikaten und Schlüsseln (hierbei kann sich möglicherweise die


Verwendung der existierenden E-Mail-Zertifikate für die sichere Übermittlung

von SSL-Zertifikaten und -Schlüsseln als kostensenkend erweisen), wobei

ein Import in die Browser in jedem Fall realisiert werden muss, also keinen

Zusatzaufwand darstellt, und

• die Gebühren eines beauftragten Zertifizierungsdienstleisters bzw. die

Lizenzgebühren der zur Zertifizierung eingesetzten CA-Produkte (hier ist im

konkreten Fall zu prüfen, ob diese Gebühren pro ausgestelltem Zertifikat

berechnet werden oder pro zertifiziertem Teilnehmer, unabhängig von der

Anzahl der für ihn ausgestellten Zertifikate).


4.3.3 Beschluss des KoopA ADV

Durch einen Beschluss der AG Kommunikation und Sicherheit des KoopA ADV

vom 07.11.2002 wurden folgende Festlegungen getroffen:

‚1) Bis Browser evaluiert wurden, sollten SSL-only Zertifikate ausgegeben

werden.‘

‚2) SSL-Proxies sollten grundsätzlich nicht eingesetzt werden, gemäß

Empfehlung in SSL-Studie in Abschnitt 4.1.7 "SSL und Firewalls"‘


5 Referenzen

[AZRG] Gesetz über das Ausländerzentralregister (AZR-Gesetz)vom 2. September 1994 (BGBl. I S. 2265)

[Bed_SSL] BSI (intern), A. Rosenhauer: „Bedarf an SSL-Verbindungen in der Bundesverwaltung“, 2001

[GrReg] Secorvo, BSI: „Regelungen für Gruppenzertifikate“, Version 1.1, 14.06.2002

[Namen] Secorvo, BSI: „Namensregeln und –formate“, Version 1.2, 14.06.2002

[Formate] Secorvo, BSI: „Technische Grundlagen der Wurzelzertifizierungsstelle – Formate und Protokolle nach MTTv2“, Version 1.01, 08.03.2001

[Policy] BSI: „Sicherheitsleitlinien der Wurzelzertifizierungsinstanz der Verwaltung“, Version 2.1, 14.06.2002

[SSL_Dipl] S. Sommermeyer: „Anforderungen an zertifikatsbasierte Datenübertragung mittels SSL-Verschlüsslung“, Diplomarbeit, FH Bonn-Rhein-Sieg, Oktober 2001

[VZK2002] Secorvo, BSI: V. Hammer, D. Neundorf, A. Rosenhauer: „Zertifizierungsinfrastruktur für die PKI-1-Verwaltung – Verzeichnisdienstkonzept“, Version 1.2, 07.05.2002

[GSHB] BSI: „IT-Grundschutzhandbuch“, Ausgabe Mai 2002

[KrypInt] Projektgruppe E-Government im Bundesamt für Sicherheit in der Informationstechnik (BSI): „Kryptographie im Internet“ (Modul aus dem E-Government Handbuch), 13.02.2002

[KrypAlg] BSI: „Geeignete Kryptoalgorithmen In Erfüllung der Anforderungen nach §17 (1) SigG vom 22. Mai 2001 in Verbindung mit Anlage 1, I 2, SigV vom 22. November 2001“, Entwurf vom 09.09.2002

[MTTv2-4] TeleTrusT: „MailTrusT Version 2 Austauschformat“, Stand 16.03.1999

[ISIS-MTT] T7 & TeleTrusT: „Common ISIS-MailTrusT Specifications For Interoperable PKIApplications“, Version 1.0.2, Juli 2002

[BCATln] TeleTrusT: „Organisatorische und technische Anforderungen für die Teilnahme an derBridge-CA“

[BCAErkl] TeleTrusT: „Selbsterklärung zur Teilnahme an der Bridge-CA“

[BCACPS] TeleTrusT: „Bridge-CA Certificate Practice Statement (CPS)“, Version 1.0

[SSLv3] A. O. Freier, P. Karlton, P. C. Kocher: Internet Draft draft-freier-ssl-version3-02.txt „The SSL Protocol Version 3.0“, http://wp.netscape.com/eng/ssl3/draft302.txt

[RFC1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones: RFC 1928 „SOCKS ProtocolVersion 5“

[RFC2246] T. Dierks, C. Allen: RFC 2246 „The TLS Protocol Version 1.0“

[RFC2818] E. Rescorla: RFC 2818 „HTTP Over TLS“

[RFC3268] P. Chown: RFC 3268 „Advanced Encryption Standard (AES) Ciphersuites for TransportLayer Security (TLS)“

[Key3] S. Henson: „Netscape Communicator Key Database Format“, http://www.drh-consultancy.demon.co.uk/key3.html

[KeyPro] S. Finnegan, Microsoft: „Crypto, Key Protection, and Mobility in Windows“, http://csrc.nist.gov/pki/twg/y2000/presentations/twg-00-35.pdf

[WinPro] NAI Labs: „Windows Data Protection“, http://msdn.microsoft.com/library/en-us/dnsecure/html/windataprotection-dpapi.asp

[SPKAC] Netscape: „Netscape Extensions for User Key Generation Communicator 4.0 Version“, http://wp.netscape.com/eng/security/comm4-keygen.html


A Technischer Anhang

A.1 Details der verwendeten Standard-Testzertifikate

Datenfeld Wert

Version v3

Seriennummer 27:81:59:26:53:58:97:93 [8 Byte Länge]

Signaturalgorithmus sha1withRSAEncryption (1.2.840.113549.1.1.5)

Aussteller Attribut Wert Kodierung

CN PCA-1-Test PrintableString

O PKI-1-Test PrintableString

C de PrintableString

Gültigkeitszeitraum 06.08.2002, 10:01 GMT bis 06.08.2003, 10:01 GMT [1 Jahr]

Inhaber Attribut Wert Kodierung




Public Key des Inhabers [RSA-Schlüssel, 2048 Bit]

Erweiterungen Art Krit. Wert

basicConstraints ja CA, keine Pfadlängenbeschränkung

certificatePolicies nein Policy OID gemäß [Policy] (1.3.6.1.4.1.7924.1.1)

cRLDistributionPoints nein URL:ldap:///cn=PCA-1-Test,o=PKI-1Test,c=de?authorityRevocationList

subjectKeyIdentifier nein [20 Byte SHA-1-Hash]

authorityKeyIdentifier nein CN=PCA-1-Test, O=PKI-1-Test, C=de,

Seriennummer des Zertifikats 27:81:59:26:53:58:97:93

keyUsage ja keyCertSign, cRLSign

Tabelle 5: Standard-Testzertifikat für die Wurzelzertifizierungsinstanz


Datenfeld Wert

Version v3

Seriennummer 27:81:59:26:53:58:97:95






Gültigkeitszeitraum 06.08.2002, 10:02 GMT bis 06.08.2003, 10:02 GMT [1 Jahr]


CN L1CA1-Test PrintableString

OU Testlabor PrintableString



Public Key des Inhabers [RSA-Schlüssel, 2048 Bit]


basicConstraints ja CA, Pfadlängenbeschränkung auf 3

certificatePolicies nein Policy OID gemäß [Policy] (1.3.6.1.4.1.7924.1.1)

cRLDistributionPoints nein URL:ldap://ldap.test.de/CN=CDP PCA-1Test,CN=PCA-1-Test,O=PKI-1Test,C=DE?certificateRevocationList

(DIT-DN für CDP konform zu [Namen])


authorityKeyIdentifier nein CN=PCA-1-Test, O=PKI-1-Test, C=de,


keyUsage ja keyCertSign, cRLSign

subjectAltName nein email:[email protected]

Tabelle 6: Standard-Testzertifikat für untergeordnete Zertifizierungsinstanzen


Datenfeld Wert

Version v3

Seriennummer 31:41:59:26:53:58:97:97







Gültigkeitszeitraum 06.08.2002, 10:10 GMT bis 03.01.2003, 10:10 GMT [150 Tage]


CN GRP: www.test.de PrintableString


OU Serverzertifikate PrintableString



Public Key Info [RSA-Schlüssel, 1024 Bit]


basicConstraints ja keine CA

keyUsage ja digitalSignature, nonRepudiation, keyEncipherment


cRLDistributionPoints nein URL:ldap://ldap.test.de/CN=CDP L1CA1Test,CN=L1CA1Test,OU=Testlabor,O=PKI-1Test,C=DE?certificateRevocationList


authorityKeyIdentifier nein Key-ID [20 Byte SHA-1-Hash], CN=PCA-1-Test, O=PKI-1-Test, C=de,



Tabelle 7: Standard-Testzertifikat für SSL-Server


Datenfeld Wert

Version v3

Seriennummer 31:41:59:26:53:58:97:96







Gültigkeitszeitraum 06.08.2002, 10:06 GMT bis 03.01.2003, 10:06 GMT [150 Tage]


CN User Test 1 PrintableString

EMAIL [email protected] IA5String


OU Benutzerzertifikate PrintableString



Public Key Info [RSA-Schlüssel, 1024 Bit]


basicContraints ja Keine CA

keyUsage ja digitalSignature, nonRepudiation, keyEncipherment


cRLDistributionPoints nein URL:ldap://ldap.test.de/CN=CDP L1CA1Test,CN=L1CA1Test,OU=Testlabor,O=PKI-1Test,C=DE?certificateRevocationList


authorityKeyIdentifier nein Key-ID [20 Byte SHA-1-Hash], CN=PCA-1-Test, O=PKI-1-Test, C=de,



Tabelle 8: Standard-Testzertifikat für SSL-Clients


A.2 Varianten der verwendeten Standard-Testzertifikate

A.2.1 Varianten Server-Testzertifikate

Nr. Abweichungen vom Standard-Testzertifikat Bemerkungen

S1 Standard-Testzertifikat Das Standard-Testzertifikat bildet ein typisches Gruppenzertifikat der PKI-1-Verwaltung nach und ist gleichzeitig konform mit den Anforderungen des SSL/TLS-Standards. (Der bei den Tests zu Tage tretende Effekt, dass SSL-Browser i.allg. den DNS-Namen des Webservers als Inhaber-CN des Zertifikats erwarten, ist nicht im SSL/TLS-Standard selbst begründet.)

Details des Zertifikats siehe oben.

S2 Schlüsselverwendung umfasst nur „digitalSignature“ und „nonRepudiation“, nicht aber „keyEncipherment“

Die Schlüsselverwendung „keyEncipherment“ entspricht genau der Art und Weise, wie das Serverzertifikat bei SSL technisch verwendet wird, auch wenn der primäre Verwendungszweck in der Regel die Authentisierung ist.

Dieses Zertifikat sollte als SSL-Serverzertifikat wegen unpassender Schlüsselverwendung nicht akzeptiert werden.

S3 Als alternativer Inhabername (Zertifikatserweiterung „SubjectAltName“) ist zusätzlich der DNS-Name des Servers angegeben

Der DNS-Name wird vom Browser für den Vergleich mit dem Servernamen in der vom Benutzer angefragten „https://“-URL benötigt.

Falls vorhanden, sollte der DNS-Name der „SubjectAltName“ Erweiterung und nicht der Inhabername (CN) für den Vergleich herangezogen werden.

S4 Inhabername (CN) ist der DNS-Name des Servers ohne „GRP:“

Der DNS-Name wird vom Browser für den Vergleich mit dem Servernamen in der vom Benutzer angefragten „https://“-URL benötigt.

Der Verzicht auf das Präfix „GRP:“ ist eine Abweichung von den Regelungen für Gruppenzertifikate.

S5 Inhabername (außer C) als ASN.1-Typ UTF8String kodiert, Inhabername (CN) ist der DNS-Name des Servers ohne „GRP:“

Verwendung von UTF8String (generell, nicht nur für Umlaute) wird von ISIS-MTT für alle Zertifikate gefordert, die nach dem 31.12.2003 ausgestellt werden.

S6 Schlüsselverwendung umfasst „digitalSignature“, „nonRepudiation“, „keyEncipherment“ und „dataEncipherment“, Inhabername (CN) ist der DNS-Name des Servers ohne „GRP:“

Dies sind alle für ein Teilnehmerzertifikat zu einem RSA-Schlüssel überhaupt sinnvollen Schlüsselverwendungen.

S7 Inhabername (CN) ist der DNS-Name des Servers ohne „GRP:“

Zertifikat wurde revoziert.

S8 Aussteller ist L1CA2-Test, Inhabername (CN) ist der DNS-Name des Servers ohne „GRP:“

Ausstellerzertifikat wurde revoziert.

Tabelle 9: Eigenschaften der verschiedenen getesteten Serverzertifikate


A.2.2 Varianten Client-Testzertifikate

Nr. Abweichungen vom Standard-Testzertifikat Bemerkungen

C1 Standard-Testzertifikat Das Standard-Testzertifikat bildet ein typisches persönliches E-Mail-Zertifikat der PKI-1-Verwaltung nach und ist gleichzeitig konform mit den Anforderungen des SSL/TLS-Standards.

Details des Zertifikats siehe oben.

C2 Schlüsselverwendung umfasst nur „digitalSignature“

Für Signaturen von E-Mails wird nach MTTv2 und ISISMTT standardkonform Schlüsselverwendung „nonRepudiation“ vorausgesetzt, für SSL-Clientauthentifikation nach [RFC2246] die Schlüsselverwendung „digitalSignature“ (für Zertifikate zu RSA-Schlüsseln; die in der Praxis irrelevanten Zertifikate zu Diffie-Hellman-Schlüsseln erfordern die Schlüsselverwendung „keyEncipherment“).

Dieses Zertifikat wäre also für SSL-Clientauthentifikaton, nicht aber für E-Mail-Signatur mit standardkonformen Systemen verwendbar.

C3 Schlüsselverwendung umfasst „nonRepudiation“, „keyEncipherment“ und „dataEncipherment“, nicht aber „digitalSignature“

Gegenstück zu Testzertifikat C2.

Dieses Zertifikat sollte als SSL-Clientzertifikat wegen unpassender Schlüsselverwendung nicht akzeptiert werden.

C4 Schlüsselverwendung umfasst „digitalSignature“, „nonRepudiation“, „keyEncipherment“ und „dataEncipherment“

Dies sind alle für ein Teilnehmerzertifikat zu einem RSA-Schlüssel überhaupt sinnvollen Schlüsselverwendungen.

C5 Inhabername (CN) enthält Umlaute Der CN wird dadurch als ASN.1-Typ BMPString kodiert.

C6 Inhabername (außer C und EMAIL) als ASN.1-Typ UTF8String kodiert, Inhabername (CN) enthält Umlaute

Die Verwendung von UTF8String (generell, nicht nur für Umlaute) wird von ISIS-MTT für alle Zertifikate gefordert, die nach dem 31.12.2003 ausgestellt werden.

C7 Standard-Testzertifikat Zertifikat wurde revoziert.

C8 Aussteller ist L1CA2-Test Ausstellerzertifikat wurde revoziert.

Tabelle 10: Eigenschaften der verschiedenen gestesteten Clientzertifikate


A.3 Testergebnisse bei einseitiger Authentisierung des

Servers

In den folgenden Tabellen sind die beobachteten Testergebnisse bei der

einseitigen Authentisierung des Servers dargestellt. Dabei ist von besonderem

Interesse die Reaktion der getesteten Browser auf die Serverzertifikate in

Tabelle 11. Beobachtete Eigenheiten der Webserver hinsichtlich der Server

zertifikate sind in Tabelle 12 festgehalten.

Während für die gültigen Zertifikate recht eindeutig nach korrektem und

unkorrektem Verhalten unterschieden werden kann, ist dies für die Reaktion auf

die revozierten Zertifikate nicht in allen Fällen möglich. Hier reicht die

Bandbreite des Verhaltens von korrekt über akzeptabel (im wesentlichen

korrektes Verhalten mit zusätzlichem manuellen Aufwand und/oder Warnungen

an den Benutzer), problematisch (dem Sinne nach korrekt, aber nicht konform

zu aktuellen Standards und/oder unter nur gewissen Umständen korrekt) bis zu

unkorrekt.

Zert.

Nr.

MSIE6/W2K MSIE6/NT MSIE5

S1 korrektes Verhalten

Es wird eine Warnung angezeigt, dass das Zertifikat nicht zum Servernamen passt, und der Benutzer hat die Wahl, die Verbindung abzubrechen oder fortzufahren.

korrektes Verhalten


korrektes Verhalten


S2 unkorrektes Verhalten


unkorrektes Verhalten





Eine sichere Verbindung wird aufgebaut.

korrektes Verhalten


korrektes Verhalten





korrektes Verhalten


korrektes Verhalten






Dieses Verhalten ist darauf zurück zu führen, dass das CN-Attribut in URF8String-Kodierung von Windows NT nicht korrekt ausgewertet wird.



Dieses Verhalten ist darauf zurück zu führen, dass das CN-Attribut in URF8String-Kodierung von Windows NT nicht korrekt ausgewertet wird.



korrektes Verhalten


korrektes Verhalten



Es wird eine CRL per LDAP vom CRL Distrubution Point bezogen, das Zertifikat als gesperrt erkannt und eine entsprechende Fehlermeldung angezeigt.

problematisches Verhalten

Die Sperrung des Zertifikats über CRL unter Windows NT erfordert den Einsatz eines Microsoft Active Directory oder lokale Installation einer CRL. Siehe Erläuterung im Anhang.




Es wird eine CRL per LDAP vom CRL Distrubution Point bezogen, das Zertifikat als gesperrt erkannt und eine entsprechende Fehlermeldung angezeigt.





Zert.

Nr.

Netscape6 Netscape4 Opera



korrektes Verhalten


korrektes Verhalten



Der Browser bricht die Verbindung ab und zeigt (auf Anforderung des Benutzers) eine Fehlermeldung, dass das Zertifikat nicht für die beabsichtigte Operation zugelassen ist.

korrektes Verhalten

Der Browser zeigt eine Fehlermeldung, dass das Zertifikat nicht für die beabsichtigte Operation zugelassen ist, und bricht die Verbindung ab.












korrektes Verhalten


korrektes Verhalten





Der Browser zeigt eine Fehlermeldung, dass das Zertifikat nicht korrekt nach DER8 kodiert ist, und bricht die Verbindung ab.

korrektes Verhalten




korrektes Verhalten


korrektes Verhalten



Es konnte im Testbetrieb keine CRL in den Browser geladen werden (eine SSL-Verbindung wird aufgebaut). Siehe Erläuterung im Anhang.


Nach Download einer CRL (X.509 v1 Format – ISIS-) wird das Zertifikat als gesperrt erkannt und eine entsprechende Fehlermeldung angezeigt.


Die Sperrung des Zertifikats über CRL ist nicht möglich (eine SSL-Verbindung wird aufgebaut).


Es konnte im Testbetrieb keine CRL in den Browser geladen werden (eine SSL-Verbindung wird aufgebaut). Siehe Erläuterung im Anhang.


Nach Download einer CRL (X.509 v1 Format) wird das Zertifikat als gesperrt erkannt und eine entsprechende Fehlermeldung angezeigt.


Die Sperrung des Zertifikats über CRL ist nicht möglich (eine SSL-Verbindung wird aufgebaut).

Tabelle 11: Reaktion der Webbrowser auf die verschiedenen Serverzertifikate

IIS iPlanet Apache

Damit das installierte Zertifikat als gültig verifiziert werden kann, darf das Wurzelzertifikat keinen CRL Distribution Point ohne Hostnamen enthalten. Vgl. die Anmerkungen zu MSIE unten.

Der iPlanet Webserver kann keine Schlüssel (somit auch keine zugehörigen Zertifikate) installieren, die von einer Zertifizierungsinstanz generiert wurden.

Stattdessen generiert der Webserver Schlüsselpaare intern und erzeugt einen Zertifizierungsantrag für den öffentlichen Schlüssel im PKCS#10 Format.

Das mod_SSL Modul zu Apache benötigt Schlüssel und Zertifikate in dem von OpenSSL verwendeten Standardformat (PEM-Format).

Eine Umwandlung vom gebräuchlichen PKCS#12 Format in dieses PEM-Format ist mit dem Kommandozeilen-Tool von OpenSSL möglich.

Tabelle 12: Eigenheiten der Webserver bei Installation und Benutzung derServerzertifikate

Gemeint, aber dem Leser der Fehlermeldung nicht näher erläutert, sind die Distingiushed

Encoding Rules nach ASN.1.


8

A.4 Testergebnisse bei beidseitiger Authentisierung

In den Fällen, bei denen bei einseitiger Authentisierung des Webservers korrekt

eine sichere Verbindung aufgebaut wurde, konnte anschließend eine

beidseitige Authentisierung von Client und Server getestet werden. In den

folgenden Tabellen sind die dabei beobachteten Testergebnisse dargestellt. Die

Reaktion des Browser auf die Serverzertifikate ist jeweils dieselbe wie in

Tabelle 11 für die einseitige Authentisierung angegeben. Die Reaktion der

getesteten Webserver auf die Clientzertifikate ist in Tabelle 13 wiedergegeben,

beobachtete Eigenheiten der Browser hinsichtlich der Client-Zertifikate in

Tabelle 14.

Zert.

Nr.

IIS iPlanet Apache

C1 korrektes Verhalten


korrektes Verhalten


korrektes Verhalten




korrektes Verhalten


korrektes Verhalten


C3 unkorrektes Verhalten


korrektes Verhalten

Der Verbindungsaufbau wird abgelehnt.

korrektes Verhalten

Der Verbindungsaufbau wird abgelehnt.



korrektes Verhalten


korrektes Verhalten




korrektes Verhalten


korrektes Verhalten




korrektes Verhalten


korrektes Verhalten



Es wird eine CRL per LDAP vom CRL Distrubution Point bezogen, der Verbindungsaufbau wird abgelehnt.

akzeptables Verhalten

Nach lokaler Installation einer CRL durch den Server-Administrator wird der Verbindungsaufbau abgelehnt.

akzeptables Verhalten



C8 korrektes Verhalten akzeptables Verhalten akzeptables Verhalten

Es wird eine CRL per LDAP vom CRL Distrubution Point bezogen, der Verbindungsaufbau wird abgelehnt.



Das Wurzelzertifikat darf keinen CRL Distribution Point ohne Hostnamen enthalten. Vgl. die Anmerkungen zur Sperrlistenverarbeitung.

Tabelle 13: Reaktion der Webserver auf die verschiedenen Clientzertifikate

MSIE6/W2K MSIE6/NT MSIE5

Der MSIE benutzt den allgemeinen Zertifikatsspeicher von Windows, d.h. dieselben Zertifikate stehen beispielsweise in Microsoft Outlook zur Verfügung.



Wenn ein Verbindungsaufbau abgelehnt wird, weil das Zertifikat revoziert ist, wird fälschlich als Fehlergrund angezeigt, dass das Server-Zertifikat gesperrt wäre.

Wenn ein Verbindungsaufbau abgelehnt wird, weil das Zertifikat revoziert ist, wird diese Tatsache als Fehlergrund angezeigt.

Wenn ein Verbindungsaufbau abgelehnt wird, weil das Zertifikat revoziert ist, wird fälschlich ein allgemeiner Verbindungsfehler als Fehlergrund angezeigt.

Netscape6 Netscape4 Opera

Es konnte keine Clientauthentisierung getestet werden, da das Personal Security Manager Modul des Browsers bei jedem versuchten Import einer PKCS#12-Datei abstürzte. Vgl. die Anmerkungen zur Sperrlistenverarbeitung.

Beim Versuch, eine PKCS#12 Datei mit Schlüssel und Zertifikat zu installieren, stürzt der Browser ab, wenn das Zertifikat Namensattribute in UTF8String oder BMPString Kodierung enthält.

Bei der Anzeige des Client-Zertifikats werden Namen in BMPString Kodierung inkorrekt und unleserlich (als Folge von schwarzen Balken) dargestellt.

Wenn ein Verbindungsaufbau abgelehnt wird, weil das Zertifikat revoziert ist, wird ohne Angabe des genaueren Grundes angezeigt, dass der Server die Verbindung abgebrochen hat.

Wenn ein Verbindungsaufbau abgelehnt wird, weil das Zertifikat revoziert ist, bleibt die anzuzeigende Webseite ohne entsprechende Fehlermeldung oder Warnung leer.

Tabelle 14: Eigenheiten der Webbrowser bei Installation und Benutzung derClientzertifikate


A.5 Sperrlistenverarbeitung durch Browser

Bezüglich der Sperrung von SSL-Serverzertifikaten über eine CRL hat jeder der

getesteten Webbrowser gewisse Probleme:

• Beim MSIE5 und MSIE6 muss die Überprüfung auf Sperrung von Server

bzw. CA-Zertifikaten im Einstellungsmenü konfiguriert werden. Falls diese

Überprüfung aktiviert ist, wird die „cRLDistributionPoints“-Erweiterung des

Zertifikates ausgewertet und der Browser versucht die dort angegebene

CRL per LDAP zu beziehen. Hierbei ergeben sich weitere Eigenheiten bzw.

Probleme:

• Unter Windows NT (ohne Zusatzbibliothek von Microsoft für LDAP)

versucht das System, sich mit einer nicht standardkonformen

Authentifikationsmethode an den LDAP-Server zu binden, die nur von

Microsoft Active Directory, nicht aber von anderen LDAP-

Verzeichnissen unterstützt wird. Die CRL-Abfrage bei dem zu den Tests

verwendeten OpenLDAP-Server scheitert somit. Als Konsequenz wird

der Benutzer gewarnt, dass die Gültigkeit des Serverzertifikats nicht

überprüft werden kann, und ihm die Wahl gegeben, den

Verbindungsaufbau abzubrechen oder trotzdem fortzusetzen.

Erst unter Windows 2000 (bei Verwendung derselben Browser-Version)

wird auch eine standardkonforme LDAP-Anfrage erzeugt, so dass hier

die CRL-Abfrage ordnungsgemäß stattfindet und die CRL (X.509 v1

oder v2 Format) korrekt ausgewertet wird.

Alternativ zur automatischen Abfrage der CRL aus dem Verzeichnis per

CRL Distribution Point kann eine CRL (X.509 v1 oder v2 Format)

manuell, d.h. durch Benutzeraktion, bezogen und lokal installiert

werden. In diesem Fall werden die entsprechenden Zertifikate korrekt

als revoziert erkannt.

• Windows NT wie auch Windows 2000 konnten in der verwendeten

Testumgebung ohne Microsoft Active Directory die im Wurzelzertifikat

verwendete LDAP-URL ohne Hostnamen nicht erfolgreich verarbeiten.


Daher wurde für die Tests mit MSIE und IIS eine Variante des

Wurzelzertifikats verwendet, deren „cRLDistributionPoints“-Erweiterung

die URL „ldap://ldap.test.de/cn=PCA-1-Test,o=PKI-1-Test,c=de

?authorityRevocationList“ (mit Hostnamen ldap.test.de) enthält.

• Der Netscape6 Browser in der getesteten Version 6.0 erkennt die von

Netscape4 verwendete MIME-Typ-Angabe für Download und Installation

einer CRL nicht korrekt und kann auf diese Weise keine CRL installieren.

Ein anderer Weg für die Installation von CRLs ist nicht angegeben.

Ab der Version 6.1 des Netscape Browsers ist ein grundlegend

überarbeitetes Personal Security Manager (PSM) Modul in den Browser

integriert, das dem Mozilla-Projekt entstammt. Dieser PSM kann laut

Dokumentation sowohl CRLs (X.509 v1 oder v2 Format) per Download

importieren als auch alternativ Online-Statusanfragen per OCSP für die

Validierung von Zertifikaten verwenden. Mit dem neuen PSM ab Netscape

6.1 ist zu erwarten, dass auch die beobachteten Abstürze beim Versuch des

Imports von PKCS#12-Dateien für die Clientauthentisierung verschwinden.

• Der Netscape4 Browser kann CRLs Version v1 über eine entsprechend

vorbereitete Webseite laden (und auswerten). Der Versuch eine CRL der

aktuellen (beispielsweise von ISIS-MTT geforderten) Version v2 auf diesem

Wege zu laden, führt zu einer Fehlermeldung, dass keine korrektes DER-

Kodierung vorliegt, und zum Abbruch.

• Bei der getesteten Version von Opera ist keine Möglichkeit vorhanden,

CRLs (gleich welcher Version) zu verwenden. Dies wurde auf Nachfrage

vom Support von Opera Software bestätigt.

A.6 Sperrlistenverarbeitung durch Server

Die Sperrlistenverarbeitung durch Server stellt sich weniger problematisch als

die Sperrlistenverarbeitung durch Clients dar:

• Der IIS kann Sperrlisten des Formats X.509 v1 oder v2 anhand der

„cRLDistributionPoints“-Erweiterung im Zertifikat automatisch per LDAP


beziehen. Zur Kompatibilität von IIS unter Windows NT bzw. Windows 2000

mit Standard-LDAP gilt das oben für den MSIE Browser gesagte.

Alternativ können Sperrlisten aus einer lokal vorliegenden Datei importiert

werden.

• Sowohl iPlanet als auch Apache können Sperrlisten des Formats X.509 v1

oder v2 aus einer lokal vorliegenden Datei importieren.

A.7 Schutz des privaten Schlüssels

Wie die getesteten Clients und Server intern den privaten Schlüssel zu ihren

SSL-Zertifikaten schützen, konnte im Rahmen der durchgeführten Tests nicht

verifiziert werden (hierzu wäre zumindest eine eingehende Code-Analyse

notwendig). Herstellerangaben und veröffentlichte Analysen ergeben folgendes

Bild:

• Laut [WinPro] und [KeyPro] wird der geheime Schlüssel bei den Microsoft-

Produkten (MSIE 5.5, MSIE 6.0 und IIS) verschlüsselt mit einem Schlüssel

abgespeichert, welcher sich in einem mehrstufigen Prozess aus dem

Passwort des jeweiligen Windows-Accounts (des Benutzer-Accounts beim

MSIE bzw. des Rechner-Accounts beim IIS) ableitet. Als Verschlüsselungs

algorithmus kommt RC4 oder Triple-DES zum Einsatz. Grundsätzlich kann

der geheime Schlüssel zum Zweck des Passwort-Rücksetzens auch vom

Windows-Domänencontroller (und damit von dessen Systemadministrator)


Der Benutzer kann dies für den MSIE (nicht für den IIS Server) verhindern,

indem er beim Import des privaten Schlüssels die Sicherheitsstufe „hoch“ für

den Schutz des privaten Schlüssels wählt und ein zusätzliches Passwort

vergibt. Dieses zusätzliche Passwort geht dann ebenfalls in den Schlüssel

ein, mit dem der private Schlüssel des Benutzers geschützt wird.

Einschränkend muss gesagt werden, dass sich die Darstellung in [WinPro]

ausschließlich auf Windows XP bezieht und kleinere Inkonsistenzen

zwischen den beiden Quellen [WinPro] und [KeyPro] existieren.


• Zum Umgang mit dem geheimen Schlüssel in Netscape4 und Netscape6

(beide Versionen verwenden hierfür dasselbe Dateiformat) ergibt die

Analyse in [Key3], dass der private Schlüssel des Benutzers verschlüsselt

mit einem Schlüssel abgespeichert wird, der sich aus dem Netscape

internen Sicherheitspasswort des Benutzers ableitet. Als Verschlüsselungs

algorithmus wird Triple-DES verwendet. Der Quellcode dieser Funktionen ist

mittlerweile im Rahmen des Mozilla-Projekts als Open Source verfügbar.

• Der iPlanet Webserver verwendet – soweit dies feststellbar ist – offenbar

dasselbe Dateiformat zur Speicherung der geheimen Schlüssel wie die

Netscape Browser („key3.db“) und somit auch dieselben Sicherheits

mechanismen.

• Zum Schutz des privaten Schlüssels in Opera machte der Hersteller auf

Anfrage per E-Mail die Angabe, dass der private Schlüssel des Benutzers

verschlüsselt mit einem Schlüssel abgespeichert. wird, der sich aus dem

Opera-internen Sicherheitspasswort des Benutzers ableitet. Als Verschlüs

selungsalgorithmus wird demzufolge Triple-DES verwendet.

• Bei Apache/mod_SSL können die geheimen Schlüssel verschlüsselt mit

Triple-DES abgespeichert werden. Der Schlüssel hierfür wird aus einem

speziell dafür vergebenen Passwort abgeleitet. Der Quellcode dieser

Funktionen entstammt OpenSSL und ist somit als Open Source verfügbar.

A.8 Dezentrale Schlüsselgenerierung durch Browser

Alle getesteten Browser können über eine entsprechend gestaltete Webseite

zur Generierung eines Schlüsselpaars und zum Stellen des Zertifizierungs

antrags für den öffentlichen Schlüssel dieses Schlüsselpaars veranlasst

werden.

Beim MSIE ist dazu die Benutzung der VisualBasicScript Sprache in der

betreffenden Webseite erforderlich, über die die entsprechenden Funktionen

des Windows-Betriebssystems (die sogenannte „CEnroll“-API) aufgerufen

werden. Als Format für den Zertifizierungsantrag wird PKCS#10 verwendet. Der


Antrag kann als Datei abgespeichert oder online über die Webschnittstelle

übertragen werden.

Netscape und Opera können Schlüsselpaare veranlasst durch eine Webseite

aufgrund des „<KEYGEN>“ HTML-Tags generieren. Der entsprechende

Zertifizierungsantrag wird dabei immer online im von Netscape in [SPKAC]

definierten „SignedPublicKeyAndChallenge“-Format übertragen.

Online-Übertragung des Zertifikatsantrags bedeutet in diesem Zusammenhang

nicht zwingend, dass die Zertifizierungsinstanz selbst online verfügbar sein

muss. Es reicht im allgemeinen aus, wenn die Registrierungsinstanz über eine

Online-Schnittstelle Zertifizierungsanträge entgegennimmt, die anschließend

offline weiterverarbeitet werden.

Alle getesteten Browser können ein als Resultat des jeweiligen Antrags

ausgestelltes Zertifikat anschließend im PKCS#7-Format per Web-Schnittstelle

importieren und automatisch dem dezentral generierten Schlüsselpaar

zuordnen.

A.9 Sicherheitsbetrachtungen zu SSL 2.0

Die Protokollvariante SSL 2.0 hat gegenüber SSL 3.0 und TLS 1.0 zwei

markante Protokollschwächen, aufgrund derer vom Einsatz von SSL 2.0

grundsätzlich abzuraten ist (z.B. empfiehlt [GSHB] Maßnahme M 5.66 explizit

SSL 3.0 oder neuer zu verwenden). Diese beiden Protokollschwächen sind:

• Durch eine „Man-in-the-Middle-Attacke“ kann ein aktiver Angreifer erreichen,

dass Client und Server sich bei der Aushandlung der zu verwendeten Cipher

Suite auf eine Cipher Suite mit schwacher Verschlüsselung und schwachem

Integritätsschutz einigen („kleinster gemeinsamer Nenner“), obwohl beide,

Client und Server, stärkere Verfahren unterstützen würden.

Durch diese Attacke kann ein Angreifer im zweiten Schritt versuchen, durch

vollständige Schlüsselsuche die kurzen Sitzungsschlüssel der schwachen

Verfahren zu ermitteln und so Vertraulichkeit und Integrität der in der


betreffenden SSL-Sitzung übermittelten Nutzdaten (HTTP-Anfragen,

Webseiten, Formulare, übertragene Dateien etc.) zu kompromittieren.

• Ein aktiver Angreifer kann durch Manipulation der angegebenen Anzahl von

Padding Bytes („Füll-Daten“ beim Einsatz von Blockchiffren) erreichen, dass

einzelne Bytes am Ende von Nachrichtenblöcken aus dem empfangenen

Datenstrom gelöscht werden und so in beschränktem, nicht-willkürlichem

Rahmen die Integrität der übermittelten Daten (HTTP-Anfragen, Webseiten,

Formulare, übertragene Dateien etc.) kompromittieren.

Zur Relevanz und Tragweite dieser beiden Protokollschwächen lässt sich

einschränkend feststellen:

• Beide Attacken sind nur sinnvoll anwendbar in Szenarien, in denen der

Angreifer weder Server noch Client, sondern ein Dritter ist.

• Keine dieser Attacken beeinflusst die von Client oder Server verwendeten

Zertifikate oder ermöglicht Rückschlüsse auf die zu den Zertifikaten

gehörigen geheimen Schlüssel. Insofern ist das Sicherheitsniveau anderer

PKI-Anwendungen durch eine eventuelle Verwendung von SSL 2.0 nicht

beeinflusst. Insbesondere ist es nicht möglich, über die Protokollschwächen

von SSL 2.0 eine E-Mail-Anwendung anzugreifen, selbst wenn für diese die

selben Zertifikate benutzt werden wie für SSL.

• Die „Man-in-the-Middle-Attacke“ kommt nicht zum Tragen, wenn der Server

so konfiguriert ist, dass er ausschließlich Cipher Suites mit starken

Kryptoverfahren unterstützt.

Letzteres ist nach dem vorliegenden Konzept stets vorgesehen (vgl. die

Betrachtungen zu den zulässigen Cipher Suites in 4.1).

• Die Manipulation der Padding-Länge kommt nicht zum Tragen, wenn die

über SSL betriebene web-basierte Anwendung die Löschung von Bytes aus

dem Datenstrom erkennen kann (z.B. durch Plausibilitätsprüfung der

empfangenen Daten).


• Durch einen speziellen Mechanismus in SSL 3.0 und TLS 1.0 wird selbst

ein aktiver Angreifer daran gehindert, eine Verwendung von SSL 2.0 zu

erzwingen, wenn Client und Server beide SSL 3.0 bzw. TLS 1.0

unterstützen („Anti-Version-Rollback“). D.h. keine der Attacken kommt zum

Tragen, wenn Client und Server beide so konfiguriert sind, zusätzlich zu

SSL 2.0 auch SSL 3.0 bzw. TLS 1.0 zu unterstützen.

Letzteres ist die Standard-Konfiguration bei allen getesteten Browser- und

Serverprodukten.


ssl-studie - bsi - bund.de

Documents