Längerfristiger Zugriff auf verschlüsselte Daten bei Smartcard

Technische Universität Darmstadt
Diplomarbeit
Längerfristiger Zugriff auf
verschlüsselte Daten bei
Smartcard-basierten
PKI-Lösungen
Ralf Schweickert
Betreuer:
Dipl. Ing. Vangelis Karatsiolis
Dr. Kornel Knöpfle
März 2007
Fachgebiet Theoretische Informatik
Prof. Johannes Buchmann
Eidesstattliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und
nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner
Prüfungsbehörde vorgelegen.
Darmstadt, März 2007
Ralf Schweickert
III
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Verschlüsselung . . . . . . . . . . . . . .
2.1.1 Symmetrische Verschlüsselung .
2.1.2 Asymmetrische Verschlüsselung
2.1.3 Hybride Verschlüsselung . . . .
2.2 Digitale Signatur . . . . . . . . . . . . .
2.3 Public Key Infrastrukturen . . . . . . . .
2.3.1 Digitale Zertifikate . . . . . . . .
2.3.2 Keybackup . . . . . . . . . . . .
2.3.3 Zertifizierungsstelle . . . . . . .
2.3.4 Registrierungsstelle . . . . . . .
2.3.5 Sperrinformationen . . . . . . . .
2.3.6 Verzeichnisdienst . . . . . . . . .
2.3.7 Beschreibende Dokumente . . .
2.4 Public Key Cryptography Standards . .
2.4.1 PKCS#1 . . . . . . . . . . . . . .
2.4.2 PKCS#7 . . . . . . . . . . . . . .
2.4.3 PKCS#10 . . . . . . . . . . . . . .
2.4.4 PKCS#11 . . . . . . . . . . . . . .
2.4.5 PKCS#12 . . . . . . . . . . . . . .
2.5 Anwendungen . . . . . . . . . . . . . . .
2.5.1 E-Mail Sicherheit . . . . . . . . .
2.5.2 Dateiverschlüsselung . . . . . .
1
1
2
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
8
9
10
10
11
11
12
12
13
13
14
14
14
14
15
15
16
16
17
3 Konzepte
3.1 Gateway- vs. Ende-zu-Ende-Verschlüsselung von E-Mails
3.1.1 Verschlüsselung auf Sicherheitsgateways . . . . . .
3.1.2 Ende-zu-Ende-Verschlüsselung . . . . . . . . . . . .
3.2 Vier-Augen-Prinzip . . . . . . . . . . . . . . . . . . . . . . .
3.3 Secret Sharing . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
20
21
22
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
Inhaltsverzeichnis
3.4
Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Verfahren
4.1 Parallele Nutzung alter und neuer Smartcards
4.2 Umschlüsselung . . . . . . . . . . . . . . . . . .
4.2.1 Umschlüsselung von E-Mails . . . . . .
4.2.2 Umschlüsselung von Dateien . . . . . .
4.3 Key History . . . . . . . . . . . . . . . . . . . .
4.3.1 Key History in Software PSE . . . . . .
4.3.2 Key History auf Smartcards . . . . . . .
4.4 Secure E-Mail Gateway . . . . . . . . . . . . . .
4.5 Managed Decryption . . . . . . . . . . . . . . .
23
.
.
.
.
.
.
.
.
.
25
25
25
26
27
28
28
30
30
32
.
.
.
.
.
.
.
.
35
35
35
37
39
40
41
41
42
6 Anforderungen und Auswahl eines Verfahrens
6.1 Kriterien und deren Gewichtung . . . . . . . . . . . . . . . . . .
6.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Gewähltes Verfahren . . . . . . . . . . . . . . . . . . . . . . . . .
45
46
47
53
7 Design und Implementierung
7.1 Anpassung der Prozesse . . . . . . . . . . . . . . . . . . . . .
7.1.1 Aufgabe des Vier-Augen-Prinzips . . . . . . . . . . .
7.1.2 Enrollment-Prozess mit Key-Backup . . . . . . . . . .
7.1.3 Prozess der Erst-Beantragung für neue Mitarbeiter .
7.1.4 Prozess der Verlängerung . . . . . . . . . . . . . . . .
7.1.5 Prozess bei Verlust/Defekt der Smartcard . . . . . . .
7.1.6 Prozess zur Erstellung einer Backupkarte . . . . . . .
7.1.7 Prozess bei Namensänderung . . . . . . . . . . . . . .
7.2 Anpassungen im Trustcenter . . . . . . . . . . . . . . . . . .
7.2.1 Datenbankschema für Keybackups . . . . . . . . . . .
7.2.2 Anpassungen an der Webschnittstelle . . . . . . . . .
7.3 Anpassungen an der RA . . . . . . . . . . . . . . . . . . . . .
7.3.1 Hardwareanpassungen für Registrator-Arbeitsplätze
7.3.2 Key-Backup-Modul . . . . . . . . . . . . . . . . . . . .
55
55
55
57
57
57
59
59
60
61
61
62
66
66
67
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Beschreibung der T-Online PKI
5.1 Trustcenter . . . . . . . . . . . . . . . . . . . . . . .
5.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . .
5.3 Smartcards . . . . . . . . . . . . . . . . . . . . . . .
5.4 Keybackup . . . . . . . . . . . . . . . . . . . . . . .
5.5 Enrollment-Prozess . . . . . . . . . . . . . . . . . .
5.6 Prozess der Erst-Beantragung für neue Mitarbeiter
5.7 Prozess der Verlängerung . . . . . . . . . . . . . .
5.8 Prozess bei Verlust/Defekt der Smartcard . . . . .
VI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
7.4
7.5
7.3.3 ActiveX-Komponente für Key-Recovery . .
Anpassungen an den Smartcards . . . . . . . . . .
7.4.1 Freigabe nicht benötigten Speichers . . . .
7.4.2 Definition der zusätzlichen Speicherplätze
Anpassungen an den Clients . . . . . . . . . . . .
7.5.1 CSP . . . . . . . . . . . . . . . . . . . . . . .
8 Proof-of-Concept
8.1 Testphase . . . . . . . . . . . . . . . .
8.1.1 Test des angepassten CSP . .
8.1.2 Prüfung der RA-Schnittstelle
8.2 Migration . . . . . . . . . . . . . . . .
8.3 Ergebnis . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
69
70
70
70
70
.
.
.
.
.
75
75
75
76
81
83
9 Fazit
87
A Literaturverzeichnis
89
B Abbildungsverzeichnis
93
C Tabellenverzeichnis
95
VII
1 Einleitung
Zur Sicherung vertraulicher Daten werden in Unternehmen immer häufiger
PKIs (Public Key Infrastrukturen) eingesetzt, die auf dem X.509v3-Standard
basieren. Dabei werden zur Verschlüsselung von E-Mails oder Dateien Schlüsselpaare verwendet, die aus jeweils einem öffentlichen, allgemein bekannten
Verschlüsselungsschlüssel und einem privaten, nur dem Inhaber bekannten
Entschlüsselungsschlüssel bestehen. Der öffentliche Schlüssel wird dabei in
Form eines digitalen Zertifikats veröffentlicht, das eine Bindung zwischen öffentlichem Schlüssel und der Identität des Inhabers des Schlüsselpaares herstellt. Der private Schlüssel ist nur dem Inhaber zugänglich (in der Regel über
ein Passwort oder eine PIN gesichert).
1.1 Motivation
Das Unternehmen T-Online nutzt in seiner internen IT-Infrastruktur seit 2003
ebenfalls eine PKI nach X.509v3-Standard. Die privaten Schlüssel und Zertifikate werden hier (wie auch in vielen weiteren Unternehmen) auf Smartcards
ausgeliefert – dadurch wird sichergestellt, dass die einmal aufgebrachten privaten Schlüssel die Smartcard nicht mehr verlassen können. Die Sicherheit der
PKI wird dadurch entscheidend verbessert, weil zur Nutzung des privaten
Schlüssels zum einen der Besitz der Smartcard und zum anderen das Kennen der Smartcard-Geheimnummer (PIN) notwendig ist. Man spricht daher
auch von einer Zwei-Faktor-Authentifizierung. Um dem Verlust der privaten Verschlüsselungsschlüssel vorzubeugen, wird bei T-Online ein sogenanntes Keybackup durchgeführt. Dabei wird eine Sicherung des privaten Verschlüsselungsschlüssels an einem besonders gesicherten Ort gespeichert, um
ihn im Bedarfsfall wiederherstellen zu können (man spricht dann von „KeyRecovery“).
In einem solchen Szenario ist es in der Praxis oft schwierig, den dauerhaften Zugriff auf die mit diesen Smartcards verschlüsselten Daten sicherzustellen, denn bei Wechsel der Smartcard ist der Zugriff auf alte verschlüsselte
Daten zunächst nicht möglich. Bei Verlust oder Defekt der Smartcard eines
Mitarbeiters wurde bei T-Online bisher eine Recovery-Karte erstellt (d.h. eine
vorhandene Sicherung des privaten Verschlüsselungsschlüssels samt Zertifikat wurde auf eine neue Smartcard aufgebracht) und eine aufwändige Umschlüsselung (d.h. Entschlüsselung mittels Recovery-Karte und anschließende
1
1 Einleitung
Verschlüsselung mittels neuer Smartcard) der Daten durchgeführt. Das Vorgehen hat sich als sehr zeitaufwändig und auch fehleranfällig erwiesen.
Für die ausstehende Verlängerung der ca. 2000 bei T-Online eingesetzten
Smartcards musste eine praktikable Lösung für das Problem gefunden werden, denn eine Umschlüsselung für eine solch große Nutzerzahl ist mit einem
beträchtlichen Ressourceneinsatz verbunden.
1.2 Aufgabenstellung
Ziel der vorliegenden Diplomarbeit war die Analyse von Verfahren zur Realisierung des längerfristigen Zugriffs auf verschlüsselte Daten, die Bewertung der
Verfahren anhand der spezifischen Anforderungen bei T-Online und schließlich die Implementierung eines passenden Verfahrens bei T-Online unter Einsatz der vorhandenen und ggf. zu modifizierenden Smartcard-basierten PKI.
Unter längerfristigem Zugriff ist die Möglichkeit zu nahtlosem Weiterarbeiten bei Wechsel des kryptographischen Schlüssels sowie die Verlängerung des
Nutzungszeitraumes von verschlüsselten Daten über mehrere Generationen
von Schlüsseln hinweg zu verstehen.
Das gesuchte Verfahren sollte unabhängig vom Typ der verschlüsselten Daten sein, damit der Nutzungsbereich der Zertifikate nicht eingeschränkt, sondern alle denkbaren Anwendungen unterstützt werden. Kryptographie nach
dem X.509v3-Standard unterstützt diese Anforderung, denn in den dort verwendeten Zertifikaten werden lediglich Schlüssel und zu verwendende Verschlüsselungsverfahren definiert. In welchem Format die Daten dabei vorliegen, ist weitestgehend unerheblich. Dadurch ist gewährleistet, dass die Schlüssel zur Ver- und Entschlüsselung verschiedenster digitaler Daten verwendet
werden können, also z.B. für E-Mails und Dateien.
Durch den Einsatz von Smartcards zum Speichern von Zertifikaten und
Schlüsselmaterial wurde die Zahl der in Frage kommenden Verfahren weiter eingegrenzt, denn der sensible private Schlüssel wird in einem Bereich der
Smartcard gespeichert, der grundsätzlich nicht ausgelesen werden kann. Im
Normalfall existiert der private Schlüssel also nur auf dem Chip in der Smartcard. Dies verhindert eine weitere Nutzung des privaten Schlüssels nach Verlust oder Defekt der Smartcard. Deshalb wurde bei T-Online bisher ein Keybackup durchgeführt, das bei Bedarf wiederhergestellt werden konnte. Ein
passendes Verfahren musste weiterhin den Einsatz einer Smartcard unterstützen, wenn möglich auch unter Verwendung der bestehenden Keybackups.
Um eine detaillierte Analyse der bestehenden Verfahren vornehmen zu können, sollten zunächst die Grundlagen zur Verschlüsselung unter Einsatz einer
Public Key Infrastruktur nach X.509v3-Standard vermittelt werden. Dazu gehören die Verschlüsselungsmethoden, die Komponenten und die Funktionsweise einer hierarchischen PKI nach dem X.509v3-Standard sowie Protokolle,
2
1.2 Aufgabenstellung
Dateiformate und Anwendungen zur Verschlüsselung.
Es gibt viele Konzepte, die beim Einsatz einer PKI zur Sicherung von Vertraulichkeit umgesetzt werden können. Nicht alle dieser Konzepte eignen sich
ohne Einschränkungen oder Anpassungen zum Einsatz in einem Unternehmen, andere sind speziell für diese Zwecke entwickelt worden. Zum Beispiel
bietet das Konzept der Ende-zu-Ende-Verschlüsselung beim E-Mail-Versand
eine hohe Sicherheit. Verliert ein Mitarbeiter jedoch seinen privaten Schlüssel,
so ist im schlimmsten Fall die Information für das Unternehmen verloren. Es
sollten daher einige dieser Konzepte vorgestellt und Ihre Vor-und Nachteile
bezüglich des Einsatzes in einem Unternehmen beleuchtet werden.
Wie bereits angedeutet, ist die Sicherung des erlaubten Zugriffs auf vertrauliche Daten ein wichtiges Problem beim Einsatz von Verschlüsselung, vor allem, über längere Zeiträume hinweg. Einmal verschlüsselte Daten können nur
mit den zum Zeitpunkt der Verschlüsselung verwendeten Schlüsseln wiederhergestellt werden – sind diese Schlüssel nicht mehr zugreifbar, so gilt dies
auch für alle damit verschlüsselten Daten. Die bekannten und im Einsatz befindlichen Verfahren zur Sicherung des längerfristigen oder dauerhaften Zugriffs auf verschlüsselte Daten waren aufzulisten und zu erläutern.
Im Rahmen der Diplomarbeit sollte ein passendes Verfahren gefunden werden, das bei T-Online zum Einsatz kommen kann. Die PKI bei T-Online ist
seit nunmehr über drei Jahren im Einsatz. Sie sollte für die Umsetzung eines Verfahrens angepasst werden. Daher werden zunächst die Struktur und
Funktionsweise der von T-Online eingesetzten PKI und Ihrer Komponenten
wie Trustcenter, Registratur, Smartcards usw. erläutert. Dazu gehören auch die
Prozesse zur Beantragung, Verlängerung und Verlust der Smartcard.
Es war eine Bewertung der ermittelten Verfahren zur Sicherung des längerfristigen Zugriffs auf verschlüsselte Daten hinsichtlich der Einsetzbarkeit bei
T-Online vorzunehmen und eine Wahl eines zu implementierenden Verfahren
zu treffen. Dabei war die bestehende Struktur der bei T-Online eingesetzten
PKI ebenso zu beachten wie die Vorgaben des Managements.
Das gewählte Verfahren war zu implementieren. Dazu waren die notwendigen Anpassungen in den Prozessen und den einzelnen Komponenten zu
lokalisieren und zu erläutern. Wo es sinnvoll erschien, wurden Skizzen, Diagramme oder Quellcode-Zitate eingesetzt.
Die praktische Umsetzung des Verfahrens sollte erläutert werden. Dazu gehörten Tests und Prüfprotokolle zur Abnahme von Teilkomponenten und der
Ablauf von der Migration bis zum Wirkbetrieb der neuen Lösung. Die Ergebnisse der Umsetzung und erste Erfahrungen mit dem Einsatz des Verfahrens
waren, soweit vorhanden, darzustellen.
3
1 Einleitung
1.3 Gliederung
In Kapitel 2 werden zunächst Grundlagen zum Verständnis von X.509 Kryptographie und hierarchischen Public Key Infrastrukturen vorgestellt. Es geht
hierbei nicht um die mathematischen Details der dabei zum Einsatz kommenden kryptographischen Verfahren oder historische Fragen zur Geschichte der
Kryptographie, sondern ganz konkret um die im Rahmen dieser Diplomarbeit
verwendeten Begriffe, Standards und Protokolle. Für tiefergehende mathematische Details empfiehlt sich die Lektüre von [Buc04], wer mehr über die Historie der Kryptographie erfahren will, ist mit [Sch04] gut beraten.
Kapitel 3 stellt Konzepte zur Sicherung der Vertraulichkeit vor, welche in
Hinblick auf die spätere Verwendbarkeit ausführlicher diskutiert und analysiert werden.
In Kapitel 4 werden bekannte und im Einsatz befindliche Verfahren zur Sicherung der längerfristigen Verfügbarkeit von verschlüsselten Daten vorgestellt. Darunter befinden sich auch spezielle Lösungen einzelner Anbieter, für
die es bisher keine allgemeinen Bezeichnungen gibt.
Kapitel 5 widmet sich der ausführlichen Beschreibung der Prozesse und
Komponenten der T-Online PKI vor Einführung des neuen Verfahrens unter
Zuhilfenahme von UML-Diagrammen und Skizzen.
In Kapitel 6 werden die Anforderungen an ein zu T-Online passendes Verfahren vorgestellt und eine Bewertung der zuvor ermittelten Verfahren mittels
einer Nutzwertanalyse vorgenommen.
In Kapitel 7 werden die für den Einsatz des zuvor gewählten Verfahrens notwendigen Änderungen und Erweiterungen an Prozessen und Komponenten
der bei T-Online eingesetzten PKI beschrieben.
Kapitel 8 widmet sich dem Prozess der Umsetzung des Verfahrens von der
Testphase über die Migration bis zum Einsatz bei T-Online. Über erste Erfahrungen mit dem neuen Verfahren wird berichtet.
In Kapitel 9 werden abschließend die gemachten Erfahrungen resümiert.
4
2 Grundlagen
In diesem Kapitel werden die notwendigen Grundlagen zum Thema der Diplomarbeit gebildet. Dabei werden verschiedene Verschlüsselungsverfahren
beschrieben, der Aufbau und die Funktionsweise von hierarchischen Public
Key Infrastrukturen wird erläutert, die wichtigsten Dateiformate und Protokolle, welche bei der X.509-Kryptographie zum Einsatz kommen, sowie Anwendungen der X.509-Kryptographie zur Verschlüsselung werden eingeführt.
2.1 Verschlüsselung
Unter Verschlüsselung versteht man allgemein das Umwandeln eines Klartextes (also die unverschlüsselte Repräsentation von Information) in einen Chiffretext (verschlüsselte Information) mit Hilfe eines Schlüssels unter Verwendung einer Verschlüsselungsfunktion (diese definiert, wie Klartext und Schlüssel verknüpft werden, um den Chiffretext zu erhalten).
Eine einfache Methode, einen digitalen Klartext in einen digitalen Chiffretext umzuwandeln, ist die Verwendung der Exklusiv-Oder-Funktion (XOR)
mit einem Schlüssel, der genauso lang ist wie der zu verschlüsselnde Klartext.
Das ist natürlich nicht optimal, denn dann benötigt man unter Umständen
sehr lange Schlüssel. Der häufig verwendete Verschlüsselungs-Algorithmus
DES1 verwendet ebenfalls die XOR-Funktion, allerdings wird der Klartext
hier in Blöcke fester Länge aufgeteilt und diese Blöcke jeweils mit einem, vom
tatsächlichen Schlüssel abgeleiteten Rundenschlüssel verknüpft. Der Schlüssel hat bei diesem Verfahren also eine feste Länge. Ein kurzes Beispiel für die
einfache XOR-Verschlüsselung:
Klartext ⊕ Schlüssel
A
⊕
k
01000001 ⊕ 01101011
1
= Chiffretext
= ∗
= 00101010
(ASCII)
(bin)
(2.1)
Data Encryption Standard (DES), siehe [Buc04], Seite 103ff
5
2 Grundlagen
Die Entschlüsselung des Geheimtextes erfolgt dann analog durch eine XORVerknüpfung des Chiffretextes mit dem Schlüssel:
Chiffretext ⊕ Schlüssel
∗
⊕
k
00101010 ⊕ 01101011
= Klartext
=
A
= 01000001
(ASCII)
(bin)
(2.2)
Wie man sieht, benötigt man zu jeder Verschlüsselungsfunktion eine passende Entschlüsselungsfunktion. Bei dem oben angegebenen Beispiel sind diese
Funktionen identisch, das muss aber nicht so sein. Bei den Verschiebechiffren
ROT-n, einer Klasse von sehr schwachen Verschlüsselungsverfahren (siehe z.B.
[Sch96], Seite 11) werden beispielsweise zur Verschlüsselung alle Buchstaben
des Alphabets um n Zeichen vorwärts rotiert, bei der Entschlüsselung dann
wieder n Zeichen zurück rotiert. Der Verschiebechiffre ROT-13 ist damit ein
Sonderfall, denn hier kann auf Grund der Tatsache, dass das Alphabet 26 Zeichen hat, Ver- und Entschlüsselung mit der gleichen Funktion vorgenommen
werden. Eine doppelte ROT-13-Verschlüsselung entspricht damit einer Entschlüsselung, genauso wie eine doppelte XOR-Verknüpfung wieder die Originaldaten erzeugt.
Sichere Verschlüsselungsverfahren zeichnen sich dadurch aus, dass
• die Sicherheit des Verfahrens nicht von dessen Geheimhaltung abhängig
ist, sondern nur von der Geheimhaltung des Schlüssels,
• sich ohne Kenntnis des Schlüssels aus dem Chiffretext nur schwer der
zugehörige Klartext ermitteln lässt,
• auch unter Verwendung von bekanntem Klar- und zugehörigem Chiffretext der Schlüssel nicht einfach zu berechnen ist.
2.1.1 Symmetrische Verschlüsselung
Die oben genannten Verschlüsselungsverfahren DES und ROT-n haben gemein, dass zur Verschlüsselung der gleiche Schlüssel verwendet wird wie zur
Entschlüsselung. Man spricht in diesen Fällen von symmetrischer Verschlüsselung (siehe Abb. 2.1). Somit entspricht diese Art der Verschlüsselung dem, was
wir in der realen Welt mit der Funktionsweise von Schlüsseln und Schlössern
verbinden. Die symmetrische Verschlüsselung hat den Vorteil, dass sie mit wenig Rechenaufwand durchgeführt werden kann und ist damit optimal für die
Echtzeitverschlüsselung oder die Verschlüsselung von großen Datenmengen
geeignet.
Allerdings ist symmetrische Verschlüsselung bei vertraulicher Kommunikation zwischen entfernten Personen nur schwer umzusetzen. Zum einen, weil
die Kommunikationspartner den zu verwendenden, geheimen Schlüssel vor
6
2.1 Verschlüsselung















Abbildung 2.1: Symmetrische Verschlüsselung
der eigentlichen Kommunikation über einen sicheren Kanal austauschen müssen (was nicht immer einfach ist). Zum Anderen muss für jeden einzelnen
Kommunikationspartner ein solcher Schlüsselaustausch stattfinden, was bei
einer Gruppe von n Personen den paarweisen Austausch von n ∗ (n − 1)/2
Schlüsseln erfordert (dieses Problem wird daher in der Literatur auch Schlüsselaustauschproblem genannt).
2.1.2 Asymmetrische Verschlüsselung
Die asymmetrische Verschlüsselung (auch als Public-Key Verschlüsselung bezeichnet) behebt das Schlüsselaustauschproblem, indem für die Verschlüsselung ein anderer Schlüssel verwendet wird als bei der Entschlüsselung. Der
Verschlüsselungsschlüssel, auch öffentlicher Schlüssel oder Public Key genannt,
kann für jeden zugänglich zum Beispiel in einem Verzeichnis abgelegt werden. Der Absender kann den Schlüssel dort beziehen, ohne vorher mit dem
Empfänger kommuniziert zu haben.

















Abbildung 2.2: Asymmetrische Verschlüsselung
Nach erfolgter Verschlüsselung kann außer dem Inhaber des geheimen Entschlüsselungsschlüssels (auch privater Schlüssel oder Private Key genannt) niemand die Nachricht mit vertretbarem Aufwand entschlüsseln. Das gilt dann
7
2 Grundlagen
auch für den Absender der Nachricht. Der private Schlüssel lässt sich bei diesen Verfahren des Weiteren auch nicht einfach aus dem öffentlichen Schlüssel
berechnen.
Allerdings haben asymmetrische Verschlüsselungsverfahren auch Nachteile: sie sind nicht so effizient wie symmetrische Verfahren. Größere Datenmengen damit zu verschlüsseln ist also nicht praktikabel. Des Weiteren werden
die öffentlichen Schlüssel in der Regel in einem Verzeichnis abgelegt. Der Absender muss die Authentizität der Daten in diesem Verzeichnis überprüfen
können – andernfalls besteht für einen Angreifer die Möglichkeit, einen eigenen öffentlichen Schlüssel (zu dem er auch den privaten Schlüssel besitzt) in
dem Verzeichnis unter falschem Namen zu veröffentlichen. Vertrauliche Daten
könnte der Angreifer so, nachdem Sie abgefangen wurden, problemlos entschlüsseln.
2.1.3 Hybride Verschlüsselung
Um Vorteile der symmetrischen und der asymmetrischen Verschlüsselung zu
kombinieren, verwendet man häufig ein sogenanntes hybrides Verschlüsselungsverfahren. Dabei wird vom Absender ein symmetrischer Sitzungsschlüssel (der
also nur für eine Nachricht gilt) erzeugt und die Nachricht mit diesem Sitzungsschlüssel verschlüsselt. Da die symmetrischen Verfahren sehr effizient
sind, läuft diese Verschlüsselung zügig ab. Unter Verwendung eines asymmetrischen Verfahrens wird dann der Sitzungsschlüssel mit dem in einem Verzeichnis frei verfügbaren öffentlichen Schlüssel des Empfängers verschlüsselt
und zusammen mit den symmetrisch verschlüsselten Daten übertragen.











@






@





Abbildung 2.3: Hybride Verschlüsselung
Der Empfänger entschlüsselt zunächst mit Hilfe seines privaten Schlüssels
den verschlüsselten Sitzungsschlüssel. Diesen kann er im Anschluss verwenden, um die Nachricht effizient zu entschlüsseln.
8
2.2 Digitale Signatur
2.2 Digitale Signatur
Um bei Empfang einer Nachricht prüfen zu können, ob diese auf dem Weg
zum Empfänger verändert wurde und ob die Nachricht auch wirklich vom
angegebenen Absender kommt, können Daten digital unterschrieben (signiert)
werden. Digitale Signaturen können heute bereits verwendet werden, um die
handschriftliche Unterschrift teilweise zu ersetzen (siehe [sig05]).
Sie werden unter Verwendung eines asymmetrischen Schlüsselpaares und
einer kryptographischen Hashfunktion erzeugt. Kurz gesagt berechnet eine solche Hashfunktion zu jeder Ihr übergebenen Nachricht oder Datei beliebiger
Länge einen Wert fester Länge, der keine Rückschlüsse auf die ursprünglichen Daten zulässt. Eine wichtige Eigenschaft dieser Funktionen ist, dass es
sehr schwer ist, eine zweite Nachricht oder Datei zu erzeugen, die den selben
Hashwert ergibt (man nennt dies Kollisionsfreiheit). Sonst könnte ein Angreifer
versuchen, eine Nachricht zu generieren, die mit dem öffentlichen Schlüssel
einer anderen Person als gültig signiert geprüft werden kann. Eine häufig eingesetzte kryptographische Hashfunktion ist z.B. SHA-1 ([Int01]).
























Abbildung 2.4: Digitale Signatur
Zur Erzeugung einer digitalen Signatur wendet der Absender zunächst eine kryptographische Hashfunktion auf die zu signierenden Daten an. Es wird
dann eine mathematische Operation2 auf diesen Hashwert unter Verwendung
des privaten Signaturschlüssels durchgeführt. Die Daten werden dann mit der
Signatur zusammen versendet bzw. gespeichert. Zur Überprüfung der Signatur muss der Empfänger zunächst ebenfalls den Hashwert der signierten Daten berechnen. Der in der Signatur enthaltene Hashwert wird unter Verwen2
Beim weitverbreiteten RSA-Verfahren entspricht diese mathematische Operation der dort
verwendeten Entschlüsselungsfunktion.
9
2 Grundlagen
dung des öffentlichen Schlüssels des Absenders wiederhergestellt.3 Die Signatur ist gültig, wenn die beiden Hashwerte identisch sind.
Jeder, der Zugriff auf ein digital signiertes Dokument hat, kann diese Signatur prüfen, denn die Überprüfung wird mittels des öffentlichen Schlüssels des
Absenders durchgeführt. Der Absender kann diese Signatur später nicht mehr
bestreiten (diese Eigenschaft wird Nichtabstreitbarkeit genannt).
2.3 Public Key Infrastrukturen
Um asymmetrische Verschlüsselung und digitale Signatur nach X.509 Standard mit größeren Benutzergruppen vernünftig einsetzen zu können, müssen
alle öffentlichen Schlüssel an einer zentralen, für alle Benutzer zugänglichen
Stelle verwaltet und veröffentlicht werden. Diese Aufgaben übernimmt eine
Public Key Infrastruktur (PKI). Wesentliche Bestandteile einer PKI sind digitale Zertifikate, Zertifizierungsstelle, Registrierungsstelle(n), Verzeichnisdienst,
Sperrinformationen und beschreibende Dokumente. Sie werden in den folgenden Absätzen erläutert.
2.3.1 Digitale Zertifikate
Öffentliche Schlüssel werden in einer PKI in Form von digitalen Zertifikaten
verwaltet. Ein Zertifikat besteht im Wesentlichen aus
• einem öffentlichen Schlüssel eines asymmetrischen Schlüsselpaares,
• einer digitalen Signatur der ausstellenden Zertifizierungsstelle,
• Daten zur Identifizierung seines Inhabers (z.B. Name, Anschrift . . . ),
• Daten zur Identifizierung der ausstellenden Zertifizierungsstelle, sowie
• Angaben zum Gültigkeitszeitraum.
Die genauen Details zu den Inhalten eines Zertifikates nach X.509v3 Standard
können in [Int02] nachgelesen werden. Der private Schlüssel des asymmetrischen Schlüsselpaares ist nicht Teil eines Zertifikats. Der Inhaber verwahrt seine privaten Schlüssel in der Regel in einem speziell gesicherten Bereich, z.B.
auf einer Smartcard.
Ein Zertifikat stellt eine Verknüpfung zwischen seinem Inhaber (das kann
z.B. eine Person oder ein Rechner sein) und dessen öffentlichem Schlüssel her.
Die Signatur der ausstellenden Zertifizierungsstelle ermöglicht es jedem, der
3
Bei der Prüfung einer RSA-Signatur wird dazu die RSA-Verschlüsselungsfunktion verwendet.
10
2.3 Public Key Infrastrukturen
dieser Zertifizierungsstelle vertraut, die Korrektheit der Daten eines solchen
Zertifikates zu prüfen. So kann man sicherstellen, dass Daten für den richtigen Empfänger verschlüsselt werden bzw. prüfen, ob Daten wirklich vom angegebenen Absender signiert wurden. Die Angaben zum Gültigkeitszeitraum
sorgen dafür, dass der Nutzungszeitraum durch den Aussteller begrenzt werden kann. Dies geschieht unter anderem, um bei fortschreitender technischer
Entwicklung weiterhin die Sicherheit von Zertifikaten gewährleisten zu können (beispielsweise durch Vergrößerung der Schlüssellänge oder Wechsel des
Verschlüsselungsverfahrens).
Digitale Zertifikate sind also vergleichbar mit den Funktionen eines Personalausweises oder Reisepasses. Der Ausweis verknüpft dabei das Passfoto
(und zukünftig auch biometrische Merkmale wie Fingerabdrücke)4 einer Person mit ihren persönlichen Daten. Auch hier wird von einer vertrauenswürdigen Instanz (dem Einwohnermeldeamt) garantiert, dass die Daten korrekt
sind. Personalausweis und Reisepass haben ebenfalls begrenzte Gültigkeit, um
ggf. Anpassungen bei weiteren technischen Fortschritten (wie z.B. die oben genannten biometrischen Merkmale) machen zu können.
2.3.2 Keybackup
Als sogenanntes Keybackup bezeichnet man die Sicherung des privaten Schlüssels von asymmetrischen Schlüsselpaaren, um diesen bei Bedarf wiederherstellen zu können. Bei Smartcard-basierten PKIs muss dazu der Schlüssel außerhalb der Karte erzeugt und gesichert werden, bevor er auf die Smartcard
aufgebracht wird.
Ein Backup von privaten Verschlüsselungs-Schlüsseln ermöglicht im Falle
des Verlusts oder Defektes eines kryptographischen Tokens (z.B. Smartcard,
USB-Dongle) die Wiederherstellung des Schlüssels und garantiert damit den
Zugriff auf verschlüsselte Daten über die Lebenszeit eines kryptographischen
Tokens hinaus.
Keybackups von Signatur- oder Authentifikationsschlüsseln werden nicht
durchgeführt. Zum einen stellt das Vorhandensein einer Schlüsselkopie in diesen Fällen ein unnötiges Sicherheitsrisiko dar, zum anderen lassen sich diese
Schlüssel bei Verlust oder Defekt des kryptographischen Tokens einfach durch
neue Schlüssel ersetzen, ein Keybackup ist also auch nicht notwendig.
2.3.3 Zertifizierungsstelle
Die Zertifizierungsstelle (Certification Authority, CA) einer PKI unterschreibt
die Zertifikate von Personen, Institutionen, untergeordneten CAs oder Rechnern, die sich bei Ihr zertifizieren lassen, mit Hilfe der digitalen Signatur. Sie
4
Siehe Verordnung (EG) Nr. 2252/2004 des Rates der Europäischen Union vom 13.12.2004.
11
2 Grundlagen
selbst besitzt dazu ein Zertifikat inklusive zugehörigem privaten Schlüssel.
Zertifizierungsanträge werden von Ihr entgegengenommen, bearbeitet und es
werden Zertifikate ausgegeben.
In einer PKI nach X.509-Standard kann es mehrere CAs geben, die hierarchisch aufgebaut sind. So werden z.B. Zertifikate für die Studenten der TUDarmstadt ausgestellt von der „TUD-CCA“, deren Zertifikat von der „TUDCA“ ausgestellt wurde, welches wiederum von der „DFN Toplevel Certification Authority“ ausgestellt wurde. Die Wurzel einer Hierarchie von Zertifizierungsstellen bezeichnet man als Root-CA. Ein solches Zertifikat stellt die
jeweilige CA dann selbst aus, d.h. der Name des Antragstellers ist bei solchen
Zertifikaten mit dem Namen des Ausstellers identisch und die Signatur wird
mit dem eigenen Signaturschlüssel durchgeführt.
Eine CA prüft die Anträge dabei höchstens auf syntaktische Korrektheit, die
Rechtmäßigkeit des Antrages wird in der Regel nicht von Ihr geprüft, sondern
von der Registrierungsstelle.
2.3.4 Registrierungsstelle
Die Registrierungsstelle (Registration Authority, RA) einer PKI nimmt Zertifizierungsanfragen entgegen, prüft diese auf Zulässigkeit und generiert aus den
Ihr übergebenen Daten einen Zertifizierungsantrag. Bei Personen ist z.B. die
Prüfung der Daten des Personalausweises oder des Führerscheins denkbar. Eine einfachere (und damit bei weitem nicht so sichere) Methode ist die Bestätigung der E-Mail-Adresse über eine Geheimnummer, die per E-Mail zugestellt
wird und dann der Authentifizierung dient.
Um Zertifizierungsanträge abzugeben und erstellte Zertifikate entgegenzunehmen, muss die Registrierungsstelle mit der CA kommunizieren. Die Kommunikation läuft gesichert ab, um Daten vor Manipulationen zu schützen.
Je nach Design einer PKI kann die Registratur zentral oder dezentral vorgenommen werden. Eine zentrale Registratur bietet die bessere Kontrolle, bedeutet aber mehr Verwaltungsaufwand. Die dezentrale Registratur kann effizienter arbeiten, allerdings müssen Abstriche bei der Sicherheit gemacht werden.
2.3.5 Sperrinformationen
Es kann verschiedene Gründe geben, warum ein Zertifikat vor Ende seines
Gültigkeitszeitraumes nicht mehr benutzt werden darf. Wenn z.B. die Gefahr
besteht, dass jemand unrechtmäßig Zugriff auf den privaten Schlüssel erlangt
(bei Verlust oder Diebstahl). Oder wenn ein Mitarbeiter das Unternehmen, das
die Zertifikate ausstellt, verlässt. Ein weiterer Grund für eine Sperrung kann
sein, dass die Daten im Zertifikat nicht mehr aktuell sind (Inhaber hat geheiratet und der Nachname hat sich geändert oder ein Mitarbeiter wechselt in eine
12
2.3 Public Key Infrastrukturen
andere Abteilung).
Um in solchen Fällen eine weitere Nutzung der Zertifikate zu unterbinden,
können diese gesperrt werden. Man spricht dann von einer Sperrung oder
auch Revokation5 .
Die Sperrinformationen werden in der Regel in einer sog. Zertifikatsperrliste (Certificate Revocation List, CRL) [Int02] abgelegt, die alle bisher gesperrten Zertifikate aufführt und über Netzwerkverbindungen abgerufen werden
kann. Eine solche CRL hat wie die Zertifikate eine begrenzte Gültigkeit und ist
vom Aussteller signiert.
Eine andere Möglichkeit zur Prüfung der Sperrinformationen ist die Nutzung eines Dienstes, der Zertifikate auf Anfrage in Echtzeit prüft. Dabei wird
häufig das Online Certificate Status Protocol (OCSP) [Int99a] eingesetzt. Dabei
werden dem Dienst Zertifikate zur Prüfung übergeben, die er mit einer signierten Statusmeldung beantwortet.
Damit man vor Verwendung eines Zertifikates zur Verschlüsselung oder bei
der Prüfung einer Signatur feststellen kann, ob das Zertifikat gesperrt wurde,
muss man zunächst die Sperrinformation erhalten. Dazu werden Verteilpunkte (CRL Distribution Points, CDP) für Sperrlisten in den Zertifikaten hinterlegt
und/oder Zugriffspunkte für OCSP-Dienste im Attribut Authority Information
Access (AIA) der Zertifikate gespeichert.
2.3.6 Verzeichnisdienst
Der Verzeichnisdienst dient innerhalb einer PKI als zentraler Zugriffspunkt
für alle Teilnehmer. Dort können Zertifikate abgerufen und häufig auch Sperrinformationen in Form von Sperrlisten bezogen werden. Die Zertifikate und
Sperrlisten werden nach Erzeugung in einer Datenbank abgelegt, welche dann
über Netzwerkprotokolle abgefragt werden kann. Dazu wird in der Regel das
Lightweight Directory Access Protocol (LDAP) [Int97] eingesetzt.
2.3.7 Beschreibende Dokumente
Da eine PKI nach individuellen Zwecken und Wünschen aufgebaut wird, ist
es für Außenstehende meist schwierig zu erkennen, nach welchen Richtlinien
sie Zertifikate ausstellt und welche Sicherheitsvorkehrungen zum Schutz der
PKI eingesetzt werden. Um Entscheiden zu können, ob man einem Aussteller
von Zertifikaten vertraut, werden daher häufig sogenannte Certificate Practice
Statements (CPS) angefertigt. Der X.509v3-Standard sieht dazu ein Attribut im
Zertifikat vor, unter dem ein URL6 zum Auffinden des CPS verzeichnet ist.
5
6
Im Englischen Revocation.
Ein Uniform Ressource Locator (URL) beschreibt das Protokoll und den Pfad zum Auffinden
einer Information im Netzwerk.
13
2 Grundlagen
2.4 Public Key Cryptography Standards
Die Public Key Cryptography Standards sind eine Ansammlung von Protokollen,
Algorithmen und Dateiformaten die seit 1991 von den RSA Laboratories in Zusammenarbeit mit anderen Sicherheits-Unternehmen entwickelt wurden mit
dem Ziel, die Entwicklung von X.509-Kryptographie zu beschleunigen.
2.4.1 PKCS#1
Dieser Standard [RSA02] ist die Grundlage für die RSA-Standards und gibt
Empfehlungen für die Implementierung des bei der X.509-Kryptographie zum
Einsatz kommenden Public-Key Verschlüsselungsverfahrens RSA7 . Es wird
die Struktur von öffentlichen und privaten Schlüsseln definiert, und Funktionen für Ver- und Entschlüsselung sowie Signatur und Signaturprüfung werden beschrieben.
2.4.2 PKCS#7
Der Cryptographic Message Syntax Standard PKCS#7 [RSA93] ist eine Weiterentwicklung des PEM-Standards (Privacy Enhanced Mail) zur Sicherung von
Vertraulichkeit und Authentizität bei E-Mails, welcher nie richtig zum Einsatz
kam.
Der PKCS#7 Standard erlaubt die hybride Verschlüsselung von Daten und
Zertifikaten sowie die Verbindung von Daten und Zertifikaten mit ihren digitalen Signaturen in „Umschlägen“ (engl. „Envelopes“). Die Umschläge können ineinander verschachtelt sein, so dass komplexe Datenstrukturen gebildet werden können. Das Datenformat eignet sich gut für den Transport von
Zertifikaten in Form von Dateien und wird häufig zur Sicherung der Kommunikation zwischen CA und RA eingesetzt. Dateien in diesem Format werden
oft unter den Dateierweiterungen .p7m (m für Message), .p7c (c für Certificate) oder einfach unter .p7 abgespeichert. Die mittels PKCS#7 erzeugten Daten
sind allerdings nicht immer direkt für den E-Mail-Versand geeignet.
2.4.3 PKCS#10
Zertifizierungsanträge werden in der Regel nach dem Certification Request Syntax Standard PKCS#10 [RSA00] erzeugt. Ein Zertifizierungsantrag besteht dabei aus den Daten des zu erstellenden Zertifikats (Name, öffentlicher Schlüssel, weitere Attribute wie E-Mail-Adresse usw.) und der Signatur des Antragstellers. Dateien in diesem Format werden in der Regel unter der Dateiendung
.p10 abgespeichert.
7
Siehe [Buc04], Seite 137ff.
14
2.4 Public Key Cryptography Standards
2.4.4 PKCS#11
Der Cryptographic Token Interface Standard PKCS#11 [RSA04] stellt eine generische Programmierschnittstelle zur Nutzung eines kryptographischen Tokens
(z.B. einer Smartcard) zur Verfügung. PKCS#11 erlaubt auch den Zugriff auf
ein kryptographisches Endgerät durch mehrere Programme gleichzeitig. Der
Hersteller eines kryptographischen Tokens muss nur die Middleware, also die
Schnittstelle zwischen dem Gerätetreiber und der PKCS#11-Schnittstelle programmieren. Jede Anwendung, die PKCS#11 unterstützt, kann dann auf dieses Token zugreifen. Die Web-Browser und E-Mail Programme der MozillaFoundation8 unterstützen beispielsweise diesen Standard.
2.4.5 PKCS#12
Um Zertifikate incl. ihres privaten Schlüssels sicher zu transportieren oder
dauerhaft zu speichern wird meist eine Datei im PKCS#12-Format verwendet. Der Personal Information Exchange Syntax Standard [RSA99] bietet dazu die
Möglichkeit, die zu schützenden Zertifikate und Schlüssel verschlüsselt und
vor unbemerkten Veränderungen geschützt zu speichern. Im Standard werden dafür die Begriffe privacy mode und integrity mode verwendet.
Um Vertraulichkeit zu gewährleisten, kann eine Datei im PKCS#12 Format
symmetrisch mit einem Passwort (password privacy mode) oder asymmetrisch
mit einem Zertifikat (public-key privacy mode) verschlüsselt werden (die tatsächliche Verschlüsselung nutzt ein hybrides Verfahren mit einem Session-Key, der
für das Zertifikat verschlüsselt wird). Um die Integrität prüfen zu können,
kann ein MAC9 (symmetrisches Verfahren, password integrity mode) oder eine
digitale Signatur (asymmetrisches Verfahren, public-key integrity mode) eingesetzt werden.
Alle Kombinationen von privacy modes und integrity modes können kombiniert werden. PKCS#12-Dateien können verschiedene Inhalte haben: Zertifikate, private Schlüssel, Sperrlisten, Geheimnisse (wie z.B. Passwörter), und auch
eine beliebige Kombination dieser Daten. Dateien in diesem Format werden
unter der Dateiendung .p12 oder .pfx abgespeichert.
8
9
http://www.mozilla.org
Message Authentication Codes (MAC) verwenden einen zusätzlichen Parameter, um symmetrische Geheimnisse in einen kryptographische Hash einbauen zu können. Nur wer dieses
Geheimnis kennt, kann überprüfen, ob der Hashwert korrekt ist und somit keine Veränderung auf dem Transportweg stattgefunden hat (Siehe auch [Buc04], Seite 200-201).
15
2 Grundlagen
2.5 Anwendungen
Für die X.509-Kryptographie gibt es viele Anwendungen, die praktisch eingesetzt werden. Am bekanntesten ist die E-Mail-Sicherheit, bei der Verschlüsselung und digitale Signaturen zum Einsatz kommen. Häufiger noch werden
X.509-Zertifikate zur Authentifikation, z.B. von Webservern bei gesicherten
Browser-Sitzungen (SSL/TLS) eingesetzt. Im Rahmen dieser Diplomarbeit stehen Anwendungen zur Verschlüsselung von E-Mails und Dateien im Vordergrund, welche nachfolgend erläutert werden.
2.5.1 E-Mail Sicherheit
E-Mail-Sicherheit stellt eine der wichtigsten Funktionen zur Sicherung von
Vertraulichkeit bei der elektronischen Kommunikation dar. Weit verbreitete
Standards sind PGP10 bzw. OpenPGP11 und S/MIME. PGP und sein freies Pendant OpenPGP verwenden keine X.509-Zertifikate und verwenden ein Vertrauensmodell, dass für Unternehmen und Behörden im allgemeinen nicht geeignet ist (Web of Trust)12 . S/MIME ist eine Erweiterung des MIME-Standards,
welcher in allen gängigen E-Mail Clients implementiert ist.
MIME
In dem immer noch aktuellen Standard für das E-Mail Format aus dem Jahre 1982 ist es zunächst unmöglich, Daten wie Bilder oder Musik mitzuschicken – die E-Mails bestehen aus reinem 7 Bit ASCII-Text (siehe [Uni82], Kapitel 3.1). Die Multipurpose Internet Mail Extensions ermöglichen eine Kodierung
von verschiedensten Datentypen (den sogenannten „Content-Types“) und garantieren dabei die fehlerfrei Übertragung durch für E-Mails geeignete Kodierung (das sogenannte „Content-Transfer-Enconding“). So wird das Senden
und Empfangen von Bildern und Musikdateien, Videos und anderen Dateien ermöglicht, welche sogar auf Empfängerseite automatisch interpretiert und
ausgeführt werden können.
S/MIME
Auch die Secure / Multipurpose Internet Mail Extensions (S/MIME) gehören zu
den MIME Standards. Ursprünglich von den RSA Laboratories entwickelt, waren Sie eine Erweiterung von MIME unter Verwendung von PKCS#7. Die ak10
http://www.pgpi.org
http://www.ietf.org/html.charters/openpgp-charter.html
12
Das Vertrauen in die Korrektheit eines Schlüssels basiert beim Web of Trust auf dem Vertrauen der Nutzer untereinander, d.h. die Nutzer signieren Ihre Schlüssel gegenseitig, um Ihr
Vertrauen auszudrücken.
11
16
2.5 Anwendungen
tuelle Version von S/MIME ist im Wesentlichen in den Dokumenten [Int04b]
und [Int04a] beschrieben. S/MIME ermöglich die digitale Signatur und /oder Verschlüsselung von E-Mails mittels X.509-Zertifikaten. E-Mail Programme erkennen die MIME-Typen in der Regel automatisch und prüfen vor bzw.
während des Anzeigens der Nachricht die Signatur bzw. stoßen die Entschlüsselung der Nachricht an.
S/MIME-Verschlüsselung
Bei der E-Mail Verschlüsselung mit S/MIME werden alle in der ursprünglichen E-Mail enthaltenen MIME-Teile zusammen verschlüsselt, also auch eventuell vorhandene Attachments. Dadurch ist auch eine beliebige Schachtelung
von verschlüsselten und signierten Bestandteilen einer E-Mail möglich. Einzig
die Kopfzeilen einer S/MIME-verschlüsselten E-Mail werden unverschlüsselt
übertragen. Dies ist erforderlich, um einen problemlosen Transport der Nachrichten zu gewährleisten.
Die Daten werden mit einem zufällig gewählten Session-Key unter Verwendung eines symmetrischen Verfahrens verschlüsselt, welcher seinerseits für alle Empfänger mit deren öffentlichem Schlüssel verschlüsselt wird. Es wird also
eine hybride Verschlüsselung verwendet. Die verschlüsselte Nachricht wird
samt der verschlüsselten Session-Keys in eine PKCS#7-Struktur eingebettet,
welche dann mit dem Content-Type „application/pkcs7-mime“ versehen in
die ursprüngliche Nachricht eingefügt und versendet werden kann.
2.5.2 Dateiverschlüsselung
Mit PKCS#7 gibt es nur einen allgemein verwendbaren Standard der sich zur
Dateiverschlüsselung mittels X.509-Zertifikaten eignet. Scheinbar hat sich aber
bisher kein interoperabler Standard herausbilden können, oder es wird nicht
die Notwendigkeit dafür gesehen. Es gibt zwar viele Anbieter von Verschlüsselungssoftware für Dateien oder auch virtuelle Laufwerke, die teilweise auch
X.509-Zertifikate nutzen. Welche Mechanismen zur Verschlüsselung verwendet werden, wird häufig jedoch nicht offengelegt. Aufgrund der schlechten
Performanz von asymmetrischen Verschlüsselungsverfahren ist allerdings davon auszugehen, dass bei Verwendung von X.509-Zertifikaten immer eine hybride Verschlüsselung zum Einsatz kommt. Die bei T-Online eingesetzte Dateiverschlüsselungssoftware der Firma Kobil13 nutzt den PKCS#7-Standard.
13
http://www.kobil.de
17
3 Konzepte
Häufig handelt es sich bei vertraulichen Informationen auch um sehr wichtige
Informationen, deren Verlust ebenso schwer wiegt wie die Möglichkeit, dass
Sie der Konkurrenz in die Hände fallen. Um in einem Unternehmen Verschlüsselung zur vertraulichen Kommunikation und sicheren Dateiablage einsetzen
zu können, bedarf es nach Konzepten, die die speziellen Anforderungen nach
Schutz vor unerlaubtem Zugriff auf vertrauliche Daten einerseits und Schutz
vor Verlust von Information andererseits erfüllt. Die Darstellung der Vor- und
Nachteile dieser Konzepte soll klären, welche sich für den Einsatz unter diesen
speziellen Anforderungen eignen und welche eher nicht.
3.1 Gateway- vs. Ende-zu-Ende-Verschlüsselung
von E-Mails
Etwa 80 Prozent der verschlüsselten Daten bei T-Online sind E-Mails, Dateiverschlüsselung ist momentan noch nicht flächendeckend verfügbar und wird
daher auch nicht so häufig eingesetzt. Es ist also sinnvoll, auch Konzepte und
Verfahren zu betrachten, die ausschließlich bei vertraulichem E-Mail-Verkehr
zum Einsatz kommen.
Grundsätzlich trennt man bei Sicherheitsbetrachtungen von Computernetzwerken zwischen potentiell unsicheren, fremden Netzen und eigenen Netzen.
Werden Netzwerkpakete im eigenen Netz weitergeleitet, so sind Sie dort in der
Regel durch Überwachungsmechanismen geschützt und passieren nur vertrauenswürdige Netzwerkteilnehmer wie Workstations, Server und Router. Im
Internet ist die Steuerung des Netzwerkverkehrs durch den Absender meist
nicht möglich, d.h. bei der Weiterleitung eines Paketes durch das Internet zu
seinem Empfänger ist nicht vorhersagbar, welchen Weg das Paket nimmt. Ein
Angreifer kann sogar gezielt Pakete abfangen, bevor er Sie beim Empfänger
abliefert (z.B. über eine DNS-Spoofing-Attacke1 ) und damit unbemerkt Netzwerkverkehr belauschen. Das eigene Netz ist in der Regel vor solchen Angriffen geschützt, außerdem steht meist die Geheimhaltung vertraulicher Daten
gegenüber Dritten im Vordergrund – ein besonderer Schutz des Netzwerktraffics im eigenen Netz scheint daher häufig nicht erforderlich.
1
Siehe dazu „Sicherheitsprobleme des Domain Name Systems (DNS)“ in [Eck06], Seite 109ff.
19
3 Konzepte
Ein Beispiel: In den meisten Unternehmen läuft die gesamte Netzwerkkommunikation auf der Transportschicht und den darunterliegenden Netzwerkschichten komplett unverschlüsselt ab. Auf den Schichten darüber arbeiten einige Protokolle mit Verschlüsselung (z.B. HTTP über SSL/TLS), andere nicht
(z.B. HTTP und SMTP). Wenn sich der Rechner eines Mitarbeiters also im eigenen Netz befindet, so wird der Netzwerkverkehr weitestgehend unverschlüsselt ablaufen. Befinden sich Rechner von Mitarbeitern in anderen, nicht als vertrauenswürdig definierten Netzen (z.B. ein Außendienstmitarbeiter, der sich
von unterwegs mit dem Laptop durch das Internet zu dem Firmennetz verbindet), so kommt meist eine Virtual Private Network (VPN) zum Einsatz. Im
Falle von Layer 2 Tunneling Protocol (L2TP) [Int99b] in Kombination mit IPSec
[Int98], einer weitverbreitete VPN-Lösung, wird der komplette Netzwerkverkehr auf den Schichten 2 und 3 verschlüsselt und authentifiziert, und kann
somit nicht abgehört werden. Die Authentifikation, die Entschlüsselung des
Eingangsverkehrs und die Verschlüsselung des Ausgangsverkehrs übernimmt
dabei das VPN-Gateway.
Es liegt also nahe, für die vertrauliche E-Mail-Kommunikation ebenfalls ein
Gatewaysystem einzusetzen. Auch hier scheint es in manchen Fällen sinnvoll,
E-Mail-Verkehr erst an den Grenzen des eigenen Netzwerkes zu verschlüsseln,
bzw. eingehende, verschlüsselte E-Mails bei Ankunft im eigenen Netzwerk zu
entschlüsseln. Die Verschlüsselung/Entschlüsselung an der Grenze der Netzwerke übernimmt dabei ein sogenanntes Sicherheitsgateway.
Eine Konzept, das im Gegensatz dazu die Vertraulichkeit einer E-Mail vom
Versand beim Absender bis zum Empfang beim endgültigen Empfänger garantiert, ist die Ende-zu-Ende Verschlüsselung. Für die vertrauliche E-Mail
Kommunikation wird in den meisten Fällen bisher dieses, auch bei Netzwerkprotokollen zum Einsatz kommendes Konzept (z.B. bei dem oben angeführten
HTTP über SSL/TLS), verwendet. Dabei wird die E-Mail auf dem Rechner des
Versenders verschlüsselt, bevor Sie diesen auf dem Weg zum Empfänger verlässt. Die Verschlüsselung kann dann nur noch vom Empfänger aufgehoben
werden.
Diese beiden Konzepte haben spezifische Vor- und Nachteile, die je nach
Anwendungszusammenhang für die eine oder die andere Variante sprechen
(vgl. Maßnahme M 4.101 in den IT-Grundschutz-Katalogen, [it-05]).
3.1.1 Verschlüsselung auf Sicherheitsgateways
Ein Sicherheitsgateway für den verschlüsselten E-Mail-Verkehr muss alle Verund Entschlüsselungsaufgaben selbständig übernehmen. Lösungen am Markt
sind z.B. „PGP Universal Gateway Email“2 und die unter der GPL erhältli2
http://www.pgp.com/products/universal_gateway_email/index.html
20
3.1 Gateway- vs. Ende-zu-Ende-Verschlüsselung von E-Mails
che Software „GEAM“3 . Da die E-Mail-Verschlüsselung nach wie vor nicht flächendeckend eingesetzt wird, und es auch bisher keinen Standard für das Auffinden von Verschlüsselungszertifikaten von potentiellen Empfängern gibt,4
kann das Gateway nur für eine begrenzte, speziell definierte Empfängergruppe die automatische Verschlüsselung übernehmen. Außerdem werden ohne
weitere Sicherungsmaßnahmen die sensiblen Daten dann unverschlüsselt auf
dem Rechner des Empfängers abgelegt.
Ein Vorteil wäre, dass der Endnutzer im eigenen Netz hinter dem Gateway
nicht mehr mit verschlüsselten Daten und Zertifikaten hantieren muss, denn er
käme mit verschlüsselten Daten gar nicht mehr in Kontakt. Da die Verschlüsselung nur kurze Zeit aufrecht erhalten werden muss (vom Versand beim Absender bis zur Entschlüsselung am Gateway), ist des Weiteren der Wechsel des
kryptographischen Schlüssels weitestgehend unproblematisch. Dadurch, dass
eingehende E-Mails im Gateway entschlüsselt vorliegen, können diese dort
zusätzlich auf Viren und andere Schädlinge geprüft werden.
Dieses Konzept behebt das Problem des längerfristigen Zugriffs auf verschlüsselten Daten jedoch nicht. Es zielt ausschließlich auf die Sicherung der
Vertraulichkeit von Daten während des Transports vom Absender zum Empfänger ab. Die Vertraulichkeit der transportierten E-Mails oder Dateien bei der
anschließenden Lagerung auf den Rechnern wird durch dieses Konzept nicht
geschützt. Wenn es aber ausschließlich auf die Sicherung der Daten auf dem
Transportweg ankommt, kann die Verschlüsselung auf Sicherheitsgateways eine Möglichkeit sein, Zugriffsprobleme auf verschlüsselte E-Mails zu umgehen.
3.1.2 Ende-zu-Ende-Verschlüsselung
Unter Verwendung des Konzeptes der Ende-zu-Ende-Verschlüsselung würde
ein Angreifer im eigenen Netz oder im Internet die E-Mail zwar manipulieren oder unterdrücken, aber nicht entschlüsseln können. Somit ist die Vertraulichkeit auch im eigenen Netzwerk gesichert. Wenn die Nachricht beim
Empfänger verschlüsselt abgespeichert wird, dann bleibt diese auch dauerhaft vor unberechtigtem Zugriff geschützt. Das Konzept der Ende-zu-EndeVerschlüsselung kommt bei den beiden wichtigsten Verfahren zur Sicherung
der Vertraulichkeit von E-Mails, PGP und S/MIME, zum Einsatz. Die E-Mails
werden dabei in verschlüsselter Form gespeichert und müssen bei jedem erneuten Anzeigen wieder entschlüsselt werden.
Weil die E-Mails erst beim Empfänger entschlüsselt werden, kann eine Überprüfung der E-Mails auf Viren oder Trojaner nicht am Rande des eigenen Netzes (z.B. der Firewall) oder auf dem Mailserver durchgeführt werden. Das
3
4
http://www.g10code.de/p-geam.html
Es gibt zwar erste Protokolle, die solch eine Funktionalität bieten, diese sind aber bisher
noch weitestgehend unbekannt. Zu nennen sind dabei Public Key Association [Koc06] und
DNS-CERT [Int06].
21
3 Konzepte
erschwert den Schutz vor Schadprogrammen, denn ein solcher Schutz sollte dann auf allen Rechnern im eigenen Netz implementiert werden, die verschlüsselte E-Mails empfangen. Umfangreicher werden auch die Aufgaben
der PKI, weil jeder Teilnehmer an der verschlüsselten Kommunikation mit
Zertifikaten ausgestattet werden muss und die komplette Infrastruktur der
PKI etabliert werden muss (Registratur, Verzeichnisse, Sperrschnittstellen und
-listen, Keybackup und Wiederherstellungsmöglichkeiten etc.).
Die Ende-zu-Ende Verschlüsselung von E-Mails hat den Nachteil, dass die
notwendigen Schlüssel zur Entschlüsselung dauerhaft verfügbar sein müssen.
Um also den längerfristigen oder dauerhaften Zugriff auf die Daten zu gewährleisten, muss immer der passende Entschlüsselungsschlüssel zur Verfügung stehen.
3.2 Vier-Augen-Prinzip
Dieses Prinzip wird in verschiedenen Berufsfeldern verwendet, wenn zum
Beispiel wichtige Entscheidungen nicht nur von einer einzelnen Person getroffen werden dürfen, sondern mindestens zwei Personen zustimmen müssen. Allgemein dient es dem Schutz vor Fehlern oder Missbrauch. In der Medizin wird dieses Prinzip z.B. bei der Diagnose von schweren Erkrankungen
eingesetzt – man bezeichnet dies dann auch als das Einholen einer Zweitmeinung. So sichert sich der Arzt vor einer fehlerhaften Behandlung oder einem
unnötigen chirurgischen Einriff ab. Im Geschäftsumfeld wird das Vier-AugenPrinzip häufig zur Freigabe großer Geldbeträge eingesetzt, um das Unternehmen vor Fehlinvestitionen und Korruption zu schützen.
Bei Public Key Infrastrukturen, in denen ein Keybackup durchgeführt wird,
dient das Vier-Augen-Prinzip dem Schutz des zuvor gesicherten Verschlüsselungsschlüssels vor unrechtmäßiger Wiederherstellung. Dazu wird in der
Regel der Verschlüsselungsschlüssel bei Herstellung des Keybackups so verschlüsselt, dass zwei Geheimnisse notwendig sind, um aus dem Keybackup
wieder den privaten Verschlüsselungsschlüssel rekonstruieren zu können. Das
eine Geheimnis ist nur einer Person (oder Personengruppe) bekannt, das andere Geheimnis einer anderen Person (oder einer disjunkten Personengruppe).
Zur Wiederherstellung des Keybackups müssen dann zwei Personen zusammenarbeiten. Eine unrechtmäßige Wiederherstellung ist somit nur möglich,
wenn diese zwei Personen (oder bei mehreren Geheimnisträgern je ein Mitglied der beiden Personengruppen) gemeinsam den Diebstahl eines Schlüssels
planen. In der Regel werden die Personen oder Personengruppen, die als Geheimnisträger dienen, aus unterschiedlichen Abteilungen ausgewählt, so dass
ein kollaborativer Angriff eher unwahrscheinlich ist.
In Bezug auf den längerfristigen Zugriff auf verschlüsselte Daten kann es erforderlich sein, den Zugriff auf die vorliegenden Keybackups weitgehend zu
22
3.3 Secret Sharing
automatisieren oder gar vollkommen transparent für den User zu gestalten.
Das Vier-Augen-Prinzip steht dem entgegen, bietet aber eine größere Sicherheit vor Kompromittierung von verschlüsselten Daten als der Schutz durch
ein einziges Geheimnis. Im Einzelfall ist abzuwägen, ob ein Verzicht auf den
Einsatz des Vier-Augen-Prinzips vertretbar ist.
3.3 Secret Sharing
Dieses Konzept kann als eine Verallgemeinerung des Vier-Augen-Prinzips angesehen werden. Ein bekanntes Secret Sharing Verfahren, das Shamir-SecretSharing-Schema [Sha79], ist in [Buc04] auf den Seiten 235 bis 238 ausführlich
beschrieben. Im Gegensatz zum Vier-Augen-Prinzip kann beim Secret Sharing
das Keybackup (oder andere mittels Secret Sharing verschlüsselte Daten) unter
Verwendung einer Teilmenge der Gesamtzahl an Geheimnissen n, die größer
oder gleich einem bei Erstellung der Geheimnisse gewählten Schwellwert t ist,
wiederhergestellt werden. Um die Struktur eines Secret Sharing Schemas zu
beschreiben, spricht man daher von einem (t, n)-Secret-Sharing-Schema. Das
Vier-Augen-Prinzip ist somit ein Sonderfall des Secret Sharing, nämlich ein
(2,2)-Secret-Sharing-Schema. Durch den Einsatz von t < n wird eine höhere
Stabilität erreicht, denn beim Vier-Augen-Prinzip (t = n = 2) kann der Ausfall eines Geheimnisses nicht kompensiert werden. Auch kann die Sicherheit
durch Erhöhung der Zahl an benötigten Geheimnissteilen gesteigert werden.
Aufgrund der höheren Stabilität eines Secret Sharing Verfahrens mit t < n
eignet es sich besser zur sicheren Aufbewahrung von Keybackups als das klassische Vier-Augen-Prinzip. Trotzdem bleibt auch bei Verwendung eines solchen Secret Sharing Verfahrens das Problem der Automatisierung und Transparenz von Keyrecovery-Vorgängen ungelöst.
3.4 Roaming
In vielen Bereichen ist es erforderlich, dass die Mitarbeiter innerhalb ihres Unternehmens jeden beliebigen Rechnerarbeitsplatz nutzen können, d.h. individuelle Einstellungen werden idealerweise zentral gespeichert und sind dann
an jedem Arbeitsplatz abrufbar. Diese Funktionalität wird als Roaming bezeichnet. Dem Wortlaut nach bedeutet „to roam“ soviel wie wandern, umherstreifen, schlendern. Im Bereich der Telekommunikation versteht man darunter
beispielsweise die Nutzung eines Mobiltelefons in einem fremden Netz. In
dieser Diplomarbeit wird der Begriff verwendet für die Möglichkeit, die Verund Entschlüsselungsverfahren an einem beliebigen Rechner innerhalb (idealerweise auch außerhalb) des Unternehmens ohne großen Konfigurationsaufwand oder gar Softwareinstallation einsetzen zu können. Man bezeichnet das
23
3 Konzepte
Roaming mit digitalen Identitäten auch als PKI-Roaming.
Da sich Smartcard-Reader und Smartcards häufig in Konfiguration und Programmierung unterscheiden, ist ein Roaming außerhalb der unternehmenseigenen Infrastruktur meist nicht umzusetzen. Um die Nutzung der Zertifikate auch außerhalb des Unternehmens zu ermöglichen, verwenden bekannte
Verfahren servergespeicherte Zertifikate, die über meist spezielle Netzwerkprotokolle abgerufen oder genutzt werden können. Die dazu erforderliche
Authentifikation gegenüber dem Server wird meist mittels Benutzerkennung
und Passwort durchgeführt. Ein solches Verfahren zur Sicherung von privaten Schlüsseln ist natürlich deutlich schwächer als die Authentifikation mittels kryptographischem Token. Zusätzlich werden in solchen Fällen Geheimnisse über ein potentiell unsicheres Netzwerk übertragen. Natürlich werden
diese durch Verschlüsselungsmechanismen geschützt, aber trotzdem werden
dadurch die Schlüssel zusätzlichen Risiken ausgesetzt.
Roaming für kryptographische Schlüssel sollte nur mit Bedacht eingesetzt
werden. Soll Roaming auch außerhalb eines Unternehmens eingesetzt werden
und ist dazu der Verzicht auf kryptographischen Token als Speichermedium
für die privaten Schlüssel erforderlich, so ist von einer deutlichen Schwächung
der Sicherheit für die verschlüsselten Daten auszugehen. Ob die Vorteile des
Roaming in einem solchen Fall überwiegen, ist individuell zu entscheiden.
24
4 Verfahren
In diesem Kapitel werden die Verfahren zur Realisierung des längerfristigen
Zugriffs auf verschlüsselte Daten in Smartcard-basierten PKIs nach X.509v3Standard erläutert. Einige davon sind ebenso einfach wie unpraktisch, andere
sehr komplex und daher nur schwer umzusetzen. Verfahren, bei denen der
Einsatz von Smartcards nicht möglich ist oder keine X.509-Zertifikate zu Einsatz kommen, werden hier nicht diskutiert.
4.1 Parallele Nutzung alter und neuer Smartcards
Die denkbar einfachste Methode, bei Wechsel des auf eine Smartcard aufgebrachten privaten Schlüssels den Zugriff auf bisher verschlüsselte Daten nicht
zu verlieren, ist die Weiternutzung der vorhandenen Smartcard zur Entschlüsselung alter Daten neben der Nutzung der neuen Smartcard, um aktuelle Daten entschlüsseln zu können. Ein Keybackup ist hier dringend erforderlich,
denn die Gefahr eines Defektes einer Smartcard nimmt mit deren Alter stetig
zu. Bei jedem Wechsel des privaten Schlüssels (also bei Verlust einer Smartcard wie auch bei der Verlängerung) muss eine zusätzliche Karte in Betrieb
genommen werden. Eine größere Anzahl an Smartcards ist schlecht zu managen, denn in der Regel geben Anwendungen beim Entschlüsseln von Daten
keine bis wenig Information über die benötigten Entschlüsselungsschlüssel.
Im Zweifel bleibt also nur das Ausprobieren mehrerer Smartcards, was durch
unterschiedliche PINs noch erschwert werden kann. Werden alte Daten nur
zu Archivierungszwecken verwendet und in der Regel nicht mehr benötigt, so
kann dieses Verfahren jedoch trotzdem seinen Zweck erfüllen. Allerdings ist
zu beachten, dass alte Verschlüsselungsverfahren mit schwächeren Schlüsseln
mit den Jahren unsicherer werden, und die Daten dann anderweitig geschützt
werden müssen oder ggf. doch eine Umschlüsselung durchzuführen ist.
4.2 Umschlüsselung
Eine andere naheliegende Möglichkeit zur Realisierung eines längerfristigen
Zugriffs auf verschlüsselte Daten ist, die alten Daten umzuschlüsseln. Das
heißt, man entschlüsselt die bisherigen verschlüsselten Daten, und verschlüsselt diese anschließend wieder für den neuen Verschlüsselungsschlüssel. Der
25
4 Verfahren
Vorteil dieses Verfahrens ist, dass man nach erfolgter Umschlüsselung immer
nur einen, nämlich den aktuellen Verschlüsselungsschlüssel benötigt. Die alte Smartcard mit dem alten Schlüssel kann dann vernichtet werden. Das gilt
natürlich nur, wenn sichergestellt werden kann, dass alle vorhandenen Daten
umgeschlüsselt wurden. Wurden verschlüsselte Dokumente oder E-Mails bei
der Umschlüsselung vergessen (z.B. weil Sie immer an unterschiedlichen Speicherorten abgelegt werden), und wird dies erst später festgestellt, so sind die
Daten zunächst nicht zugreifbar. Ein möglicherweise vorhandenes Keybackup
kann dann zwar wiederhergestellt werden, es muss aber in der Regel eine neue
Chipkarte dafür verwendet werden.
Entscheidender Nachteil der Umschlüsselung ist, dass diese, genau wie die
Ver- und Entschlüsselung an sich, applikationsabhängig ist. Das jeweilige Programm, in dem Daten ver- und entschlüsselt werden, muss eine entsprechende Funktion zur Umschlüsselung bieten. Alternativ kann auch ein eigens zur
Umschlüsselung der Daten entwickeltes Programm verwendet werden – dieses muss dann allerdings die benutzte Datenstruktur und die verwendeten
Verschlüsselungsalgorithmen kennen.
4.2.1 Umschlüsselung von E-Mails
Die Verschlüsselung von E-Mails erfolgt nach dem S/MIME-Standard, wenn
X.509-Zertifikate verwendet werden. Dabei wird hybride Verschlüsselung verwendet, das heißt zunächst wird die Nachricht mit einem zufälligen, nur für
diese Nachricht verwendeten Schlüssel symmetrisch verschlüsselt (z.B. mit
Triple-DES, RC2 oder AES). Anschließend wird der verwendete symmetrische Schlüssel für jeden Empfänger mit dessen öffentlichen Verschlüsselungsschlüssel mittels RSA oder Diffie-Hellmann verschlüsselt. E-Mail Programme
speichern die so verschlüsselten E-Mails, die dann aus reinem ASCII-Text bestehen, in einer Datenstruktur ab. Diese Datenstruktur kann von Programm zu
Programm unterschiedlich sein. So verwendet Mozilla Thunderbird das aus
der Unix-Welt bekannte mbox-Format [Int05], während Microsoft Outlook das
proprietäre Personal Store-Format (PST) einsetzt, welches sich sogar von Version zu Version unterscheidet1 .
Beide Softwarehersteller bieten keine Umschlüsselungsmechanismen an –
weder in der Anwendung integriert noch als zusätzliches Programm. Daher
ist man zur Umschlüsselung auf Software von Drittherstellern angewiesen –
für Outlook sind dem Autor nur zwei Lösungen bekannt, nämlich FlexiTrust
3.0 ReCrypt Tool for MS Outlook2 der FlexSecure GmbH und Mailumschlüsselung
für Outlook (UfO) [DA06], eine Auftragsarbeit von fun communications GmbH3
1
http://support.microsoft.com/kb/830336/
http://www.flexsecure.de/assets/downloads/FlexiTrust_Outlook_ReCrypt.pdf
3
www.fun.de
2
26
4.2 Umschlüsselung
für T-Online. Für die Mozilla-Anwendungen sind dem Autor keine Umschlüsselungstools bekannt (vgl. [Str05], Seite 82).
Die bisherige Erfahrung mit dem Umschlüsselungstool UfO bei T-Online
hat gezeigt, dass die Umschlüsselungsvorgänge extrem lange dauern können
(abhängig von Anzahl und Größe der E-Mails wurden durchschnittlich ungefähr 4000 E-Mails/Std. bzw. 200 MB/Std. umgeschlüsselt). Da einige Abteilungen dazu verpflichtet sind, sämtlichen Schriftverkehr aufzubewahren und
zu archivieren, sind Postfächer mit mehreren Gigabyte Größe keine Seltenheit.
Während dieser Zeit muss zumindest der alte private Entschlüsselungsschlüssel zur Verfügung stehen, das heißt, die alte Smartcard muss während des
Umschlüsselungsprozesses an dem jeweiligen Rechner im Smartcard-Reader
stecken. Der Inhaber der Smartcard, dessen Postfach umgeschlüsselt wird,
sollte also während der Umschlüsselung zum Schutze seiner Smartcard vor
Missbrauch anwesend sein. Des Weiteren greift UfO auf die Messaging API
(MAPI)4 zu. Der Hersteller des Umschlüsselungstools empfiehlt aus diesem
Grund, während der Umschlüsselung nicht mit dem E-Mail-Programm zu arbeiten. Faktisch ist der Mitarbeiter also während der (unter Umständen recht
langwierigen) Umschlüsselung gezwungen, sich anderweitig zu beschäftigen.
Dass dies nicht im Interesse des Unternehmens ist, liegt auf der Hand.
4.2.2 Umschlüsselung von Dateien
Für die Dateiverschlüsselung gibt es viele verschiedene Ansätze: Verschlüsselung kann auf Dateiebene, mit Hilfe von verschlüsselten virtuellen Laufwerken und Containern oder mit verschlüsselten Dateisystemen umgesetzt werden.
In Microsoft Betriebssystemen ist beispielsweise seit Windows 2000 ein verschlüsseltes Dateisystem namens Encrypted File System (EFS) enthalten. Dabei kommt hybride Verschlüsselung zum Einsatz, die X.509-Zertifikate verwendet. Um den Verlust aller verschlüsselten Daten bei Verlust des privaten
Schlüssels abzufangen, kann ein zusätzlicher Entschlüsselungsschlüssel definiert werden, der im Notfall die Wiederherstellung von verschlüsselten Daten ermöglicht. Eine Umschlüsselung ist hier aber nicht vorgesehen. Sollte also ein privater Schlüssel kompromittiert worden sein, so müssen die Dateien
mit dem zusätzlichen Entschlüsselungsschlüssel oder einem ggf. vorhandenen Keybackup entschlüsselt und anschließend mit einem neuen Verschlüsselungsschlüssel wieder verschlüsselt werden.5
Eine Anwendung für Verschlüsselung auf Basis einzelner Dateien, die einen
Umschlüsselungsassistenten bietet, ist die bei der T-Online eingesetzte File4
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/exchanchor/
htms/msexchsvr_mapi.asp
5
http://www.microsoft.com/germany/technet/datenbank/articles/900941.mspx
27
4 Verfahren
Security der Firma Kobil. Zusätzlich ist hier auch die digitale Signatur der Dateien möglich. Dabei kommt die Cryptographic Message Syntax (CMS) [RSA93]
zum Einsatz. Der Umschlüsselungsassistent durchsucht die gewählten Verzeichnisse nach mit dem alten Verschlüsselungszertifikat verschlüsselten Dateien und schlüsselt diese um. Sind die verschlüsselten Daten allerdings an
unterschiedlichen Orten gespeichert (z.B. im Home-Verzeichnis des Besitzers,
in Projekt- und Abteilungs-Verzeichnissen), dann wird es schwer sicherzustellen, dass alle Daten umgeschlüsselt werden. Außerdem kann es auch hier bei
umfangreichen Datenbeständen zu langen Umschlüsselungsvorgängen kommen.
Zusammenfassend bleibt also zu sagen, dass nur eine geringe Zahl an Anwendungen existiert, für die es Umschlüsselungsmechanismen gibt, und diese sind aus den unterschiedlichsten Gründen nicht praktikabel einsetzbar. Am
schwersten wiegt jedoch, dass dieses anwendungsabhängige und für jede Verschlüsselungsanwendung einzeln durchzuführende Verfahren dem grundlegenden Prinzip der X.509-Standards widerspricht, welche prinzipiell anwendungsunabhängig konzipiert sind.
4.3 Key History
Häufig wird, wie auch bei T-Online, ein Keybackup des Verschlüsselungsschlüssels durchgeführt. Die alten Verschlüsselungsschlüssel können dann bei
Bedarf wiederhergestellt werden. Man bezeichnet die Summe der alten Verschlüsselungsschlüssel auch als „Schlüsselhistorie“ (auf englisch „Key History“).
Der Gedanke hinter diesem Verfahren ist nun, diese Keyhistory nicht nur
zu Wiederherstellungszwecken zu nutzen, sondern generell verfügbar zu machen. Dazu müssen Anwendungen, die mit diesem Verfahren funktionieren
sollen, mit mehr als einem Verschlüsselungszertifikat zur Entschlüsselung arbeiten können. In der Regel tun Sie das auch – beim Entschlüsseln erfolgt dann
der Zugriff auf einen Schlüsselcontainer (z.B. Windows-Zertifikatsspeicher),
aus dem automatisch das passende Zertifikat samt Schlüssel ausgewählt wird.
Der Zugriff geschieht häufig transparent für den User.
4.3.1 Key History in Software PSE
Die bereits in Software, häufig im PKCS#12-Format, vorliegenden Keybackups
werden bei diesem Verfahren im Falle eines Schlüsselwechsels in einem zentralen Schlüsselcontainer gespeichert. Der Zugriff auf diesen Schlüsselcontainer muss dabei so gestaltet sein, dass ihn alle benötigten Anwendungen zur
Entschlüsselung nutzen können.
28
4.3 Key History
Unter Microsoft Windows Betriebsystemen kommt dabei meist der Windows Zertifikat Manager zum Einsatz. Er erlaubt die Speicherung von Zertifikaten aus verschiedenen Quellen (z.B. Software-PSE, Smartcards, USB-Tokens)
und bildet die zentrale Schnittstelle für Applikationen, die Zertifikate einsetzen. Wird ein Software-Zertifikat mit privatem Schlüssel im Zertifikatsspeicher gespeichert, so kann der spätere Export des privaten Schlüssels verhindert werden, indem der Schlüssel als nicht exportierbar markiert wird. Des
Weiteren kann der Zugriff auf den privaten Schlüssel so abgesichert werden,
dass der Anwender jeder Nutzung zustimmen muss oder, in der höchsten
Sicherheitsstufe, ein Kennwort eingeben muss, um den Zugriff zu erlauben.
Diese Schutzmechanismen sind aber letztendlich Kosmetik, denn die privaten Schlüssel liegen bei den Windows-Betriebsystemen ab Windows 2000 als
Dateien in einem bestimmten Verzeichnis, verschlüsselt mit dem sogenannten
User Master Key. Kennt ein Angreifer diesen Schlüssel, so kann er alle privaten Schlüssel, die unter dem Benutzerprofil gespeichert sind, entschlüsseln.
Der User Master Key wird auf einem Rechner bei der ersten Anmeldung eines Benutzers erzeugt und alle 60 Tage automatisch erneuert. Alte Versionen
von Windows 2000, die keine starke Verschlüsselung zulassen, sichern den
User Master Key vergleichsweise schwach mit einem symmetrischen 40- bzw.
56-Bit-Schlüssel. Neuere Betriebsysteme setzen Triple-DES ein, was einem Verfahren mit zeitgemäßer Schlüssellänge entspricht. Aber auch hier gibt es Wege,
an die privaten Schlüssel zu kommen: Hat ein Angreifer Administratorrechte
auf dem Rechner, so kann er das Kennwort des Benutzers zurücksetzen. Windows wird dann einen neuen User Master Key erzeugen und damit die privaten Schlüssel verschlüsseln. Der Angreifer kann sich anschließend nicht nur
mit dem Benutzerkonto seines Opfers am Rechner anmelden, sondern auch
sämtliche privaten Schlüssel des Benutzerkontos verwenden (vgl. [Wöh04]).
Der Windows-Zertifikatsspeicher ist also nur bedingt geeignet, alte Verschlüsselungsschlüssel sicher aufzubewahren.
Andere Betriebssysteme bieten teilweise ähnliche Mechanismen (unter Mac
OS X z.B. der „Schlüsselbund“) – oder die Applikationen kümmern sich selbst
um die Schlüsselverwaltung, indem Sie eigene, untereinander inkompatible
Implementierungen eines Schlüssselcontainers verwenden (z.B. die Anwendungen der Mozilla-Foundation), was die Pflege der Key History bei Einsatz
mehrerer Anwendungen zu einem komplizierten Unterfangen machen kann.
Allgemein kann gesagt werden, dass ein privater Schlüssel in einem Schlüsselcontainer nie so effektiv geschützt werden kann wie auf einer Smartcard.
Gegen eine Key History in Software PSE spricht des Weiteren, dass bei einem
Wechsel des Rechners immer dafür Sorge getragen werden muss, dass die Key
History auch auf dem neuen Rechner zur Verfügung steht. Um die privaten
Schlüssel nicht unnötigen Gefährdungen auszusetzen, sollte darüber hinaus
sichergestellt werden, dass die Key History auf alten Rechnern sicher gelöscht
wird. Roaming wird mit diesem Verfahren also schwierig umzusetzen sein.
29
4 Verfahren
4.3.2 Key History auf Smartcards
Das Roaming-Problem kann beseitigt werden, wenn die Key History direkt
auf der Smartcard gespeichert wird. Der Anwender trägt die Key History dann
immer bei sich, und kann Sie an jedem Rechner einsetzen, an dem die Smartcard genutzt werden kann. Allerdings müssen auch bei diesem Verfahren einige Vorraussetzungen erfüllt sein.
Das größte Problem bei der Speicherung einer Key History auf einer Smartcard ist der begrenzte Speicherplatz. Smartcards können meist nur wenige Zertifikate gleichzeitig speichern. So sind z.B. auf den bei T-Online verwendeten
Smartcards momentan maximal 5 Zertifikate zu speichern. Allerdings ist abzusehen, dass der Speicherplatz bei zukünftigen Modellen ansteigen wird.
Wie oben bereits erwähnt, gilt auch für die Key History auf Smartcards, dass
Anwendungen auf die zusätzlichen Zertifikate zugreifen können müssen. Unter Windows wird dazu eine Softwarekomponente, ein sogenannter Cryptographic Service Provider (CSP) eingesetzt, der die Struktur der Smartcard kennt und
so bei Anfragen die passenden privaten Schlüssel zur Entschlüsselung verwenden kann. Da die Anwendungen in der Regel nicht direkt auf die Smartcard zugreifen, kommt häufig auch hier wieder der Windows Zertifikat Manager zum Einsatz. Allerdings können auch Anwendungen mit eigenem Zertifikatsmanagement wie z.B. die der Mozilla-Foundation die Smartcard nutzen,
wenn hierfür die notwendige Softwarekomponente (ein PKCS#11-Modul passend zur verwendeten Smartcard) zur Verfügung steht.
Der Zugriff auf neue wie alte verschlüsselte Daten ist mit diesem Verfahren einfach und transparent möglich. Auch Roaming innerhalb des Unternehmens ist kein Problem, wenn nötige Softwarekomponenten und die Smartcardreader flächendeckend verfügbar sind. Das Verfahren zeichnet sich auch,
wie oben bereits erwähnt, durch seine weitgehende Anwendungsunabhängigkeit aus. Reicht der Platz auf der Smartcard nicht mehr aus, dann wird
es allerdings schwierig: Entweder die verschlüsselten Daten müssen mühsam
umgeschlüsselt werden, oder ein Teil der Zertifikate wird in Software-PSE verfügbar gemacht – beides mit den bekannten Nachteilen. Das Verfahren eignet
sich also nicht zur Umsetzung des dauerhaften, sehr wohl aber zur Sicherung
des längerfristigen Zugriffs auf verschlüsselte Daten.
4.4 Secure E-Mail Gateway
Wird ein Secure E-Mail Gateway eingesetzt, so werden an den Grenzen zum
eigenen Netz eingehende vertraulichen Nachrichten entschlüsselt und ausgehende vertrauliche Nachrichten verschlüsselt, so dass die Nutzer nie mit verschlüsselten E-Mails in Kontakt kommen. Das E-Mail Gateway arbeitet also als
eine Art Poststelle für E-Mails und wird daher auch Virtuelle Poststelle genannt.
30
4.4 Secure E-Mail Gateway
Unter der fachlichen Leitung des Bundesamtes für Sicherheit in der Informationstechnik (BSI) wurde eine solche unter dem Namen Virtuelle Poststelle
des Bundes6 entwickelt, die auch bereits bei einigen Bundesämtern im Einsatz
ist.7
Ein Secure E-Mail Gateway benötigt zum Entschlüsseln ankommender Nachrichten einen oder mehrere private Schlüssel. Diese müssen sicher verwahrt
und vor unrechtmäßigem Zugriff besonders geschützt werden. Zwar kann
man die privaten Schlüssel durch den Einsatz von Hardware Security Modulen
(HSM)8 oder Smartcards wirksam vor Diebstahl schützen, allerdings müssen
auf dem Gateway Anwendungen laufen, die diese Schlüssel zur Entschlüsselung verwenden, und diese Anwendungen sind potentiell angreifbar. Ein Angreifer kann so unter Umständen nicht nur die E-Mails eines einzelnen Opfers
entschlüsseln, sondern alle durch das Gateway verschlüsselten E-Mails.
Bei der herkömmlichen Ende-zu-Ende Verschlüsselung von E-Mails mittels
S/MIME ist es oft schwierig bzw. unmöglich, Vertretungsregelungen umzusetzen, denn jeder potentielle Vertreter müsste beim Versand einer E-Mail bereits als Empfänger angegeben werden. Im Gegensatz dazu können Secure
E-Mail Gateways nach Entschlüsselung entsprechende Vertreterregelungen anwenden. Auch der Versand von verschlüsselten E-Mails im Auftrag eines Anderen lässt sich damit umsetzen. Dadurch, dass die E-Mails nach Entschlüsselung im Klartext vorliegen, können auch eventuell vorhandene Viren und
Trojaner entdeckt und entfernt werden, bevor die Nachricht Ihr Ziel erreicht.
Die zentralisierte Verwaltung von Schlüsseln ermöglicht ein deutlich vereinfachtes Management der PKI-Lösung. Da die Verschlüsselung nur auf dem
Transportweg durchgeführt wird, kann so unter Umständen ein Keybackup
komplett entfallen, oder die alten Schlüssel müssen nur für kurze Übergangszeiten vorgehalten werden. Zertifikate von externen Empfängern können einmalig zentral gespeichert und dann durch alle internen User verwendet werden. Sperrmechanismen können unter Umständen sogar komplett entfallen,
indem ein häufiger Schlüsselwechsel auf dem Gateway stattfindet.
Applikationsunabhängige Verschlüsselung ist mit diesem Verfahren jedoch
nicht umzusetzen, es eignet sich in der Regel nur für E-Mails. Zwar bietet
z.B. die Virtuelle Poststelle des Bundes optional den Austausch von verschlüsselten Dateien mittels einer Weboberfläche, eine verteilte Speicherung der so
verschlüsselten Dateien ist aber prinzipbedingt nicht möglich.
6
http://www.virtuelle-poststelle-bund.de
Eine Liste der Behörden kann unter http://www.bsi.bund.de/fachthem/vps/tech.htm
eingesehen werden.
8
Hardware Security Module sind in der Regel Steckkarten oder an einen Computer angeschlossene externe Geräte, auf denen private Schlüssel generiert, gespeichert und verwendet werden können. Sie besitzen zur Beschleunigung von Entschlüsselungsvorgängen
häufig spezielle Prozessoren, die kryptographische Operationen sehr effizient durchführen
können.
7
31
4 Verfahren
Das Verfahren bietet des Weiteren keine Ende-zu-Ende-Verschlüsselung und
somit auch keine Vertraulichkeit im lokalen Netz. Ist auch ein hohes Maß an
Vertraulichkeit im lokalen Netz zu gewährleisten, so müssen andere Sicherungsmaßnahmen eingesetzt werden, die eine vertrauliche und authentifizierte Übermittlung der E-Mails zum endgültigen Empfänger ermöglichen.
Bezogen auf die Problemstellung des längerfristigen Zugriffs auf verschlüsselte Daten stellt dieses Verfahren keine wirkliche Lösung dar, denn die Daten selbst sind nach Ankunft auf dem Zielsystem nicht mehr verschlüsselt,
also nicht mehr vor unrechtmäßigem Zugriff geschützt (zumindest nicht mittels hybrider Verschlüsselung nach X.509-Standard). Ziel ist es aber, gerade die
verschlüsselte Daten weiterhin sicher aufzubewahren und gleichzeitig längerfristig zugreifbar zu halten.
4.5 Managed Decryption
Bei diesem Verfahren wird bei Entschlüsselungsvorgängen die Wahl des passenden Entschlüsselungsschlüssels von einer speziellen Software übernommen. Liegt ein benötigter privater Schlüssel nicht lokal vor (z.B. weil es nicht
der aktuelle Verschlüsselungsschlüssel ist), so kommuniziert diese Software
mit einem zentralen Server, der die Keyhistory der Anwender aufbewahrt
und bei Bedarf wiederherstellt. Der Server übermittelt den wiederhergestellten Schlüssel an den Rechner des Anwenders, wo die Daten dann entschlüsselt
werden können. In Ermangelung eines Fachbegriffs für dieses Verfahren wurde der Begriff Managed Decryption gewählt. Eine bekannte Implementierung
R
ist in der Lösung EntelligenceTM von Entrust
enthalten9 .
Die zugehörige Softwarekomponente auf den Anwender-Rechnern (ClientApplikation) kann auf Windows-PC’s z.B. die Rolle eines Cryptographic Service Providers (CSP) übernehmen, der bei fehlenden privaten Schlüsseln eine Verbindung zum Server aufnimmt, um den passenden Schlüssel zu beziehen. Dazu findet idealerweise eine beiderseitige Authentifikation zwischen
Client-Applikation und Server statt, auf Anwenderseite z.B. eine Smartcard
mit einem Authentifikationszertifikat. Die Kommunikation zwischen ClientApplikation und Server läuft dann unter Verwendung von starker Verschlüsselung ab. Die wiederhergestellten Schlüssel kann die Client-Applikation im
Windows-Zertifikatspeicher in Form eines Software-PSE dauerhaft speichern,
um so nachfolgende Anfragen ohne einen Zugriff auf den Server bedienen zu
können.
Der zentrale Server speichert in seiner Datenbank alle jemals ausgestellten
Verschlüsselungsschlüssel und stellt diese bei Bedarf wieder her. Zusätzlich
kann er auch andere Aufgaben zum Zertifikatsmanagement übernehmen, so
9
http://www.entrust.com/entelligence
32
4.5 Managed Decryption
z.B. das erstmalige Enrollment oder die automatische Verlängerungen von
Zertifikaten. Der Server muss also stark abgesichert werden, um einen unrechtmäßigen Zugriff auf die Keybackups zu verhindern.
Durch die Verlagerung des Keymanagements in einen zentralen Server bei
gleichzeitigem Verbleib des Entschlüsselungsvorgangs beim Anwender werden Nachteile der Ende-zu-Ende-Verschlüsselung kompensiert und trotzdem
wird weitreichende Vertraulichkeit realisiert. Das System kann für den User
sehr transparent gehalten werden, er braucht sich um keine Belange des Keymanagements kümmern. Solange der Server erreichbar ist, kann sich der Benutzer an jedem mit Client-Software und ggf. Kartenleser ausgestatteten Rechner anmelden und benötigte Zertifikate bei Bedarf automatisch vom Server
laden. Andererseits stellt eine Serverkomponente, die von allen Teilnehmern
einer PKI erreichbar sein muss, eine große Angriffsfläche dar. Dazu kommt,
dass die Speicherung der Zertifikate in Software-PSE zwar die Nutzung bereits heruntergeladener Zertifikate und Schlüssel auch bei Ausfall der Netzverbindung ermöglicht, der Schutz der privaten Schlüssel fällt aber geringer
aus als bei der Speicherung auf Smartcards.
Dieses Verfahren bietet gute Ergebnisse im Hinblick auf das gewünschte
Ziel, allerdings ist der Implementierungsaufwand als relativ hoch einzuschätzen. Die Einschränkung der Smartcardnutzung alleine auf die Authentifikation bei gleichzeitiger Speicherung der Verschlüsselungszertifikate in SoftwarePSE bedeutet insgesamt einen deutlichen Verlust an Sicherheit.
Man könnte den Schutz der privaten Schlüssel in diesem Verfahren gegebenenfalls erhöhen, indem man diese nur auf dem Server vorhält und sämtliche
Entschlüsselungsoperationen auch auf dem Server durchführen lässt. Dann
ist allerdings eine dauerhafte Netzwerkverbindung zwingend notwendig, um
Entschlüsselungsvorgänge durchführen zu können. Von einer derartigen Implementierung hat der Autor allerdings keine Kenntnis erlangt.
33
5 Beschreibung der T-Online PKI
Dieses Kapitel beschreibt die Struktur und Funktionsweise der bei T-Online
eingesetzten PKI zum Zeitpunkt der Projektierung eines praktikableren Verfahrens für die Verlängerung der Zertifikate, während der diese Diplomarbeit
angefertigt wurde.
T-Online ist eine Geschäftseinheit von T-Com, welche wiederum ein Unternehmen der Deutschen Telekom AG mit deutschlandweit ca. 2000 Mitarbeitern ist. Diese verteilen sich auf die Standorte Darmstadt, Kiel, Oldenburg und
Ulm. Die PKI wurde nach einem längeren Planungsverfahren im Jahre 2003 in
Betrieb genommen. Mit einer Zertifikats-Laufzeit von drei Jahren wurde daher
für einen Großteil der Mitarbeiter in der Zeit zwischen Juli 2006 und Februar
2007 eine Verlängerung erforderlich, für die (soweit im Zeitrahmen machbar)
bereits das neue Verfahren eingesetzt werden sollte.
5.1 Trustcenter
Zum Einsatz kommt ein ausgelagertes Trustcenter der T-Systems TeleSec, wobei die TeleSec als Dienstleister den Betrieb und die Wartung des Trustcenters
in einem eigenen Rechenzentrum durchführt. Die Beantragung von Zertifikaten wird zentral im Accountmanagement am Standort Darmstadt durchgeführt.1 Die Bedienung der Registration Authority erfolgt dabei mittels einer
Web-Applikation über eine SSL-gesicherte Web-Schnittstelle. Der Verzeichnisdienst ist über ein LDAP-Verzeichnis realisiert, das sich ebenfalls im Trustcenter befindet und mittels LDAP- bzw. LDAP-S-Protokoll abgefragt werden
kann.
5.2 Zertifikate
Jeder Mitarbeiter bei T-Online erhält eine Benutzerkennung für die WindowsDomäne, ein E-Mail-Postfach und drei Zertifikate, jeweils eines für die Verwendungszwecke Authentifikation, Signatur und Verschlüsselung. Alle drei
1
Vor der Umstellung auf das neue Verfahren befanden sich in Kiel und Oldenburg ebenfalls
Registration Authorities, diese wurden aber aus Gründen der Sicherheit und der Praktikabilität aufgegeben. Mehr dazu im Kapitel „Design und Implementierung“.
35
5 Beschreibung der T-Online PKI
Zertifikate enthalten als persönliche Angaben den Namen und die E-MailAdresse ihres Eigentümers, das Authentifikationszertifikat enthält zusätzlich
den User Principal Name (UPN), welcher eine Benutzerkennung innerhalb einer Domäne eindeutig identifiziert. Die drei Zertifikate werden gleichzeitig
ausgestellt und können auch nur gemeinsam revoziert werden (wir sprechen
daher auch von einem „Zertifikatstriple“).












Abbildung 5.1: Aufbau der T-Online Zertifikatshierarchie
Ausgestellt werden die Zertifikate von einer T-Online-eigenen CA, die unterhalb der Root-Zertifizierungsstelle der Deutschen Telekom AG angesiedelt
ist (siehe Abb. 5.1). Feste Mitarbeiter erhalten Zertifikate mit dreijähriger Laufzeit, Zertifikate für externe Mitarbeiter verlieren nach einem Jahr ihre Gültigkeit.
Gewöhnlich werden die Zertifikate danach unter Beibehaltung des Schlüssels verlängert, es findet also eine Rezertifizierung desselben Schlüssels statt.
Im Gegensatz dazu ist bei T-Online keine Verlängerung im klassischen Sinne
vorgesehen, stattdessen wird bei einer Verlängerung eine neue Chipkarte mit
neuen Zertifikaten und Schlüsseln ausgegeben. Dies hat folgende Gründe:
• die Prozesse für Verlängerung und Vorgehen bei Verlust, Defekt oder
Diebstahl lassen sich so vereinheitlichen,
• nach drei Jahren Nutzungsdauer sind die Smartcards oft physikalisch
defekt,
• die Wahrscheinlichkeit eines Defekts ist bei einer 4 Jahre alten Karte erheblich höher als bei einer ein Jahr alten Karte,
• da die Smartcards bei T-Online unter anderem auch als sichtbar zu tragender Unternehmensausweis fungieren, sind abgenutzte Bedruckungen und veraltete Passbilder nicht akzeptabel,
36
5.3 Smartcards
• die steigenden Sicherheitsanforderungen sowie die Fortschritte in der
Kryptographie erfordern einen Wechsel des Chipkartenmaterials in kürzeren Zeitabständen.
Damit nach Verlust, Defekt oder Diebstahl der Smartcard der Zugriff auf bereits mit dem Verschlüsselungszertifikat verschlüsselte Daten nicht verloren
geht, wird von diesem inklusive dem zugehörigen Schlüsselpaar eine Sicherung erstellt (ein sogenanntes Keybackup). Eine Sicherung der Schlüssel für
Authentifikations- und Signaturzertifikat ist nicht sinnvoll, denn diese Schlüssel sollen aus Sicherheitsgründen eindeutig und nicht reproduzierbar sein. Es
brächte aber auch keinen Mehrwert, denn die Authentifikation oder Signatur
kann auch mit einem dann neu zu erstellenden Zertifikat geschehen – ein Verlust von Information ist bei diesen Verwendungszwecken nicht zu befürchten.
5.3 Smartcards
Die Smartcard dient bei T-Online nicht nur als Personal Security Environment
(PSE), sondern übernimmt zusätzlich die Funktionen eines Unternehmensausweises (durch eine entsprechende Bedruckung mit Name und Passfoto), eines Zutrittstokens und eines bargeldlosen Bezahlungsmittels im MitarbeiterRestaurant (beides durch einen weiteren, kontaktlosen Chip, der nicht sichtbar
integriert ist). Wir konzentrieren uns bei der weiteren Betrachtung auf das für
unsere Zwecke wichtige PSE, das der Aufnahme von Zertifikaten und kryptographischen Schlüsseln dient.
Für das PSE werden Chips von T-Systems TeleSec für „E4 NetKey V2.0“Smartcards mit dem Smartcard-Betriebsystem TCOS 2.0, Release 3 eingesetzt
[T-S04a]. Chip und Betriebssystem sind nach ITSEC2 E4, Mechanismenstärke
„hoch“ evaluiert. Die Fähigkeiten des Kryptoprozessors und des Betriebssystems beschränken die maximale Schlüssellänge für die verwendeten kryptographischen Schlüssel auf 1024 Bit. Der Zugriff auf sicherheitskritische Dateien
und Operationen ist durch eine Persönliche Identifikationsnummer (PIN) gesichert, die bei der Personalisierung der Smartcard festgelegt wird. Bei Verlust
oder dreifacher Falscheingabe der PIN kann diese unter Eingabe eines zweiten
Geheimnisses, des sogenannten Personal Unblocking Keys (PUK), neu vergeben werden. Dieser PUK wird bei der Produktion auf der Karte generiert und
kann bei der Personalisierung der Smartcard ausgelesen und dann gelöscht
werden.
Die Smartcards verfügen über 32 KB Speicher, der zu großen Teilen mit dem
Betriebssystem und Dateien für verschiedene Applikationen (Signaturzertifi2
„Information Technology Security Evaluation Criteria“ (ITSEC) ist ein europäischer Standard zur Zertifizierung von Software und Hardware bezüglich der Daten- und Computersicherheit.
37
5 Beschreibung der T-Online PKI
kat nach SigG3 , NetKey, TeleSec Watermark, Zutritt, Gleitzeit, One Time Password) vorbelegt ist. Bei T-Online findet von diesen vorinstallierten Anwendungen nur die Applikation „NetKey“ [T-S04b] Verwendung. Darin befinden
sich im Auslieferungszustand öffentliche und private Schlüssel (die Schlüssel
sind dabei nicht auslesbar gespeichert) sowie leere Zertifikats-Speicherplätze
für die Verwendungszwecke Authentifikation, Signatur und Verschlüsselung
(siehe Abb. 5.2). Die bereits vom Hersteller aufgebrachten Zertifikate mit den



































































Abbildung 5.2: Logische Kartenstruktur vor der Umstellung der T-Online PKI
File-IDs C000, C100 und C200 (in der Grafik als NetKey-Zertifikate bezeichnet) werden bei T-Online nicht genutzt und können auch nicht überschrieben
werden. Es werden aber in Teilen die bei der Produktion erzeugten Schlüssel
verwendet. Zur Speicherung der Zertifikate für Authentifikation und Signatur
werden die in der NetKey-Applikation vorgesehenen Reservespeicherplätze
für die Verwendungszwecke Verschlüsselung und Signatur genutzt. Die für
die Authentifikation vorgesehenen Dateien und Speicherplätze werden bei TOnline nicht verwendet.
3
Das „Gesetz über Rahmenbedingungen für elektronische Signaturen“ (SigG) regelt den
rechtlichen Rahmen für die Erstellung und Verwendung elektronischer Signaturen sowie
für die Erbringung von Signatur- und Zertifizierungsdiensten, siehe [sig05].
38
5.4 Keybackup
Der verfügbare freie Platz auf den Smartcards (bei dem aktuellen Modell
ca. 9 KB) kann für eigene Zwecke verwendet werden. Bei T-Online wird dieser zur Speicherung der „External Key“-Applikation verwendet, welche bei
der Personalisierung der Smartcard angelegt wird. In der Applikation wird
ein Zertifikat für den Verwendungszweck Verschlüsselung inklusive dem zugehörigen öffentlichen und privaten Schlüssel abgelegt. Da ein Überschreiben
der privaten Schlüssel der NetKey-Applikation nicht möglich ist, wurde die
„External Key“-Applikation erforderlich, um neben den bereits bei der Produktion aufgebrachten Schlüsseln auch extern erzeugte Schlüsselpaare auf die
Smartcard aufbringen zu können. Dies ermöglicht erst die Erstellung von Keybackups für die auf der Smartcard gespeicherten Zertifikate.
5.4 Keybackup
Um bei Verlust, Defekt oder Diebstahl einer Smartcard nicht den Zugriff auf
bereits mit dem Verschlüsselungszertifikat verschlüsselte Daten zu verlieren,
wird (wie weiter oben bereits kurz angerissen) bei T-Online ein sogenanntes
Keybackup durchgeführt (siehe Abb. 5.3).
Dazu wird das Verschlüsselungsschlüsselpaar außerhalb der Chipkarte erzeugt, um es extern zu sichern, bevor es auf der Smartcard gespeichert und
anschließend wieder aus dem Arbeitsspeicher des erzeugenden Rechners entfernt wird.
Das Keybackup wird dabei zunächst in Form eines PKCS#12-Containers
[RSA99] verschlüsselt gespeichert. Der Container wird mit einem Passwort
gesichert, welches mittels eines Zufallsgenerators erzeugt und mit einem Zertifikat verschlüsselt (dem „RecoveryAdmin1“-Zertifikat) als Datei im PKCS#7
Format [RSA93] gespeichert wird. Ebenso wird der PKCS#12-Container mit
dem Keybackup in einer PKCS#7-Datei gespeichert, die ihrerseits mit einem
anderen Verschlüsselungszertifikat (dem „RecoveryAdmin2“-Zertifikat) verschlüsselt wird. Beide RecoveryAdmin-Zertifikate wurden auf verschiedene
Smartcards aufgebracht und sind an verschiedenen Orten und nur für disjunkte Personengruppen zugreifbar hinterlegt. Man spricht bei diesem Verfahren auch von einem Vier-Augen-Prinzip, denn es müssen mindestens zwei
Personen zusammenarbeiten, um einen Schlüssel wiederherstellen zu können.
Damit benötigt ein potentieller Angreifer Zugriff auf vier Dinge, um an den
privaten Schlüssel eines Opfers zu kommen: den verschlüsselten PKCS#12Container, die verschlüsselte Datei mit dem Passwort für den Container, die
RecoveryAdmin1-Karte und die RecoveryAdmin2-Karte.
39
5 Beschreibung der T-Online PKI
5.5 Enrollment-Prozess
Beim Enrollment-Prozess findet zunächst eine beiderseitige SSL-Authentifizierung zwischen Webschnittstelle und RA-Administrator statt (letzterer verwendet dazu ein Zertifikat auf Smartcard). Im nächsten Schritt füllt der Registrator
ein Formular mit den Daten des zu beantragenden Zertifikatstriples aus. Beim
Klicken auf den „Beantragen“-Button des Formulars wird zuerst die Personalisierung der Smartcard durch Initialisierung der PIN eingeleitet, denn vor
der Vergabe einer PIN kann keine andere Funktion der NetKey-Karte verwendet werden. Dieser, „Null-PIN-Verfahren“ genannte Mechanismus dient dem
Schutz vor unbemerkten Manipulationen, z.B. bei Versand über den Postweg.
Dabei muss die Null-PIN (000000) an die Karte übergeben werden. Lässt sich
der Zugriff auf die Karte damit nicht freischalten, ist eine Manipulation der
Smartcard zu vermuten und die Karte wird nicht akzeptiert. Andernfalls wird
auf dem Rechner eine 6-stellige Zufallszahl generiert und als neue PIN gesetzt.
Der PUK wird ausgelesen und es wird ein versiegelter „PIN/PUK-Brief“ gedruckt, der die beiden Geheimnisse so enthält, dass sie auf für den Registrator
nicht lesbar sind. Ein Schlüsselpaar für das Verschlüsselungszertifikat wird in
Software generiert und die öffentlichen Schlüssel für Authentifikations- und
Signaturzertifikat, die sich ja bereits auf der Smartcard befinden, werden abgefragt. Anschließend werden die Informationen aus dem Formular zusammen
mit den ermittelten bzw. erzeugten öffentlichen Schlüsseln in Form von drei
signierten Zertifizierungsanfragen (nach PKCS#10 [RSA00]) an das Trustcenter übermittelt. Dort werden die nach Antragsprüfung erzeugten Zertifikate
im Verzeichnis veröffentlicht und gleichzeitig zur Registratur zurückgesendet.
Am Registrator-Arbeitsplatz werden die drei Zertifikate dann inklusive der
Schlüssel für das Verschlüsselungsschlüsselpaar automatisch auf die Smartcard gespeichert; dabei wird auch die „External Key“-Applikation angelegt.
Die Smartcard ist damit fertig, anschließend wird noch das Keybackup des
Verschlüsselungsschlüssels wie oben angegeben erzeugt, was ebenfalls automatisch geschieht. Der resultierende PKCS#12-Container wird über einen beiderseitig authentifizierten SSL-gesicherten Kanal per HTTP an das Trustcenter übermittelt, welches das Keybackup in einer Datenbank ablegt. Das verschlüsselte Passwort wird auf einem eigens nur für diesen Zweck eingerichteten Netzlaufwerk der Registration-Authority von T-Online gespeichert. Somit
ist auch eine räumliche Trennung der benötigten Daten zur Wiederherstellung
eines Schlüssels sichergestellt. Die Speicherbereiche, die zur temporären Ablage der Schlüsseldaten auf dem RA-Arbeitsplatz dienten, werden sicher gelöscht. Am Ende des Enrollmentprozesses wird ein vom Trustcenter erzeugtes
Sperrformblatt angezeigt und ausgedruckt. Um Missbrauch bei Verlust oder
Diebstahl der Smartcard zu verhindern, kann der Inhaber der Smartcard damit eine Sperrung seiner Zertifikate veranlassen. Der Enrollmentprozess ist
damit abgeschlossen.
40
5.6 Prozess der Erst-Beantragung für neue Mitarbeiter
5.6 Prozess der Erst-Beantragung für neue
Mitarbeiter
Ein neuer Mitarbeiter bei T-Online wird in der Regel an seinem ersten Arbeitstag im Accountmanagement vorstellig. Das Personal prüft die Identität des
neuen Kollegen durch einen Abgleich der Daten des Personalausweises mit
Daten in der Personalverwaltungssoftware. Sind die Daten korrekt, so wird
ein Foto für den Unternehmensausweis aufgenommen. Eine Smartcard wird
als Unternehmensausweis für den neuen Mitarbeiter bedruckt und der Enrollmentprozess durchgeführt. Die Smartcard, der PIN/PUK-Brief, das Sperrformblatt und die Zugangsdaten für die Rechnernutzung werden gegen Quittung ausgehändigt.
5.7 Prozess der Verlängerung
Das Accountmanagement prüft über eine Schnittstelle des Trustcenters regelmäßig, ob Zertifikate eines Mitarbeiters auslaufen. Betroffene Mitarbeiter erhalten zusätzlich automatisch 30 Tage vor Ablauf der Zertifikate eine Benachrichtigung des Trustcenters über das Auslaufen der Zertifikate. Ist eine Verlängerung erforderlich, so wird rechtzeitig vor Ablauf der alten Zertifikate eine
neue Smartcard ausgerollt. Der Mitarbeiter kann diese dann im Accountmanagement abholen.
Die alte Smartcard muss dabei möglichst schnell eingezogen werden, damit sich keine Dubletten von Unternehmensausweisen (ggf. sogar mit Zutrittsfunktion) im Umlauf befinden. Da der Mitarbeiter dadurch den Zugriff auf mit
der alten Smartcard verschlüsselte E-Mails und Dateien verliert, muss zeitnah
eine Umschlüsselung der Daten durchgeführt werden. Die dafür notwendige Software muss zunächst auf dem Rechner des Mitarbeiters installiert werden. Nach erfolgter Installation (durch automatische Softwareverteilung oder
durch Service-Personal vor Ort) kann die Umschlüsselung der Daten stattfinden. Bei Bedarf assistiert dabei ein Kollege des Service Desk. Ist die Umschlüsselung abgeschlossen, muss der alte Unternehmensausweis im Accountmanagement abgegeben und vernichtet werden.
Der Umschlüsselungsvorgang ist sehr komplex und häufig aufgrund der
zu durchforstenden Datenfülle sehr zeitaufwändig (mehrere Gigabyte an EMails in den drei Jahren Laufzeit eines Verschlüsselungszertifikates sind leider erfahrungsgemäß keine Seltenheit). Dies schreckt viele Mitarbeiter ab und
führt dazu, dass häufig von einer Umschlüsselung abgesehen wird. Als Alternative zur Umschlüsselung wird daher in manchen Fällen eine so genannte
Backupkarte oder Recoverykarte ausgegeben. Der Prozess zur Erstellung einer
solchen Karte wird im nächsten Abschnitt beschrieben.
41
5 Beschreibung der T-Online PKI
5.8 Prozess bei Verlust/Defekt der Smartcard
Ist die Smartcard gestohlen worden oder muss aufgrund des Verlustes Missbrauch vermutet werden, dann müssen die Zertifikate umgehend gesperrt
werden. Dies geschieht durch den Inhaber selbst unter Verwendung des Sperrformblattes über eine Webschnittstelle des Trustcenters oder durch einen Mitarbeiter des Accountmanagements am RA-Arbeitsplatzrechner.
In allen Fällen erhält ein Mitarbeiter, dessen Smartcard defekt ist, verloren oder gestohlen wurde zunächst eine neue Smartcard, die im normalen
Enrollment-Prozess im Accountmanagement erzeugt und ausgegeben wird.
Zusätzlich wird vom Personal des Accountmanagements eine sogenannte Backup- oder Recovery-Karte erstellt. Dabei handelt es sich um eine kostengünstigere, aber ansonsten baugleiche E4 NetKey Karte ohne speziellen
Aufdruck und ohne den kontaktlosen Chip, welche mit dem Keybackup des
letzten Verschlüsselungsschlüssels der betroffenen Person bestückt wird. Dazu sucht der Registrator zunächst die Referenznummer des entsprechenden
Keybackups durch Abfrage der Backup-Datenbank des Trustcenters über die
Webschnittstelle heraus. Ist die entsprechende ID gefunden, kann mit einem
Programm für die Wiederherstellung von Keybackups, welches auf den RAArbeitsplatzrechnern installiert ist, nach dem Vier-Augen-Prinzip das alte Verschlüsselungszertifikat wiederhergestellt werden. Nach Eingabe der ID werden die beiden zur Wiederherstellung erforderlichen, verschlüsselten Dateien geladen. Dann wird die Smartcard des RecoveryAdmin1 angefordert und
nach der Eingabe der PIN durch den einen Mitarbeiter des Accountmanagements wird der PKCS#12-Container wiederhergestellt. Anschließend muss
der andere Accountmanagement-Mitarbeiter seine RecoveryAdmin2-Karte in
das Lesegerät stecken und seinerseits durch Eingabe der zugehörigen PIN die
Entschlüsselung der Passwortdatei veranlassen. Das Programm entpackt anschließend den PKCS#12-Container unter Zuhilfenahme des Passwortes. Die
neue Smartcard zur Aufnahme des Keybackups wird analysiert, die Null-PIN
gebrochen und ein PIN/PUK-Brief wird wie im gewöhnlichen EnrollmentProzess erzeugt. Dann wird das Keybackup auf die Smartcard aufgebracht.
Am Ende der Smartcard-Erzeugung steht die Löschung der vertraulichen Daten aus dem Speicher.
Natürlich ist auch hier eine Umschlüsselung anzuraten, bzw. im Fall eines
möglichen Missbrauchs einer abhandengekommenen Smartcard sogar dringend erforderlich. Die Backupkarte wird nach erfolgter Umschlüsselung vernichtet.
42





































5.8 Prozess bei Verlust/Defekt der Smartcard
Abbildung 5.3: Keybackup-Prozess vor der Umstellung der T-Online PKI
43
6 Anforderungen und Auswahl
eines Verfahrens
In diesem Kapitel werden die konkreten Anforderungen an eine für T-Online
passende Lösung zur Realisierung des längerfristigen Zugriffs auf verschlüsselte Daten erarbeitet, eine Bewertung verschiedener Verfahren vorgenommen
und schließlich die Wahl eines Verfahrens zur Implementierung getroffen. Es
ist zu beachten, dass dieses Ergebnis nicht für jedes Unternehmen zutreffend
ist, denn die Kriterien selbst, wie auch ihre Gewichtung, sind individuell für TOnline bestimmt worden. Das Auswahlverfahren lässt sich aber entsprechend
an eigene Bedürfnisse anpassen.
Die Entscheidungsfindung wird durch ein Nutzwertverfahren unterstützt.
Diese Verfahren wurden entwickelt, da man erkannte, dass bei komplexen betriebswirtschaftlichen Fragestellungen die Betrachtung nur eines Ziels (häufig die Minimierung der Kosten oder die Maximierung des Gewinns) nicht
ausreicht [Lil92]. Es gibt verschiedene dieser Nutzwertverfahren, einige davon sind sehr komplex (z.B. Analytic Hierarchy Process, AHP), andere sind zu
simpel und damit zu abhängig von subjektiven Einschätzungen (z.B. Direct
Choice)1 . Ein relativ gut objektiviertes Verfahren stellt die Nutzwertanalyse
dar. Dieses Verfahren wurde Anfang der 70er Jahre von Christof Zangemeister erstmals in Deutschland vorgestellt. Zangemeister definiert in [Zan70] die
Nutzwertanalyse als eine „Analyse einer Menge komplexer Handlungsalternativen mit dem Zweck, die Elemente dieser Menge entsprechend den Präferenzen des Entscheidungsträgers bezüglich eines multidimensionalen Zielsystems zu ordnen. Die Abbildung der Ordnung erfolgt durch die Angabe der
Nutzwerte (Gesamtwerte) der Alternativen.“ Die einzelnen Kriterien, die der
Entscheidungsfindung dienen, werden dabei üblicherweise je nach Priorität
unterschiedlich gewichtet. Die Gewichtung kann individuell für jedes Kriterium festgelegt werden, allerdings birgt das die Gefahr, dass Kriterien zu subjektiv und damit falsch gewichtet werden. Ein besseres Ergebnis erzielt man
zum Beispiel indem man die Kriterien in einen hierarchisch geordneten Baum
einsortiert (wichtige Kriterien stehen weiter oben im Baum, weniger wichtige Kriterien weiter unten). Eine andere und hier verwendete Vorgehensweise
ist der paarweise Vergleich der Kriterien. Dabei wird für jedes Kriterienpaar
ermittelt, welches der beiden Kriterien wichtiger ist. Das jeweils als wichtiger
1
siehe dazu auch die Ergebnisse von Vergleichsexperimenten in [Lil92], S. 168-170.
45
6 Anforderungen und Auswahl eines Verfahrens
erachtete Kriterium erhält dann einen Punkt. Die ermittelte Gesamtpunktzahl
wird dann zur Gewichtung herangezogen. Um nun zu bestimmen, welche Alternative den besten Nutzen darstellt, müssen die Kriterien für jede Alternative einzeln bewertet werden. Die Bewertung erfolgt dabei in einer Skala von
1 (Kriterium sehr schlecht erfüllt) bis 5 (Kriterium voll erfüllt). Durch Multiplikation der Bewertungen mit den berechneten Gewichtungen ergeben sich
dann die Teilnutzen, die für jede Alternative addiert werden. Diese Summe
ergibt den Nutzwert der Alternative. Die Alternative mit dem größten berechneten Nutzwert wird am Ende der Nutzwertanalyse für die Implementierung
ausgewählt.
6.1 Kriterien und deren Gewichtung
Die Ermittlung von Kriterien und deren Gewichtung geschieht im Team der
Projektbeteiligten auf Grundlage von den Forderungen, die bei der initialen
Planung drei Jahre zuvor definiert wurden, und den Erfahrungen, die mit der
T-Online PKI bisher gemacht wurden. Zunächst werden die zur Bewertung
herangezogenen Kriterien kurz erläutert.
Damit möglichst alle Mitarbeiter bei der nun anstehenden Verlängerung das
neue Verfahren nutzen können, ist die Dauer der Umsetzung für T-Online
besonders kritisch. Eine Verzögerung würde bedeuten, dass Personen, deren
Zertifikate schon auslaufen, für die Übergangszeit mit neuen Zertifikaten ausgestattet werden müssten, die sie nur eingeschränkt oder mit weniger Komfort
nutzen könnten. Dann wären umständliche Verfahren zur Sicherung des Zugriffs auf bereits vorhandene verschlüsselte Daten einzusetzen, und sobald das
neue Verfahren zur Verfügung stünde, müssten nochmals neue Zertifikate erstellt werden. Eine möglichst zügige Umsetzung ist also in diesem speziellen
Fall als wichtig einzustufen.
Ein wichtiges Kriterium für die Auswahl sind immer auch die Kosten –
hier wird zwischen den initialen Aufwendungen für die Umsetzung (geringer
Aufwand Umsetzung) und den im täglichen Betrieb anfallenden, laufenden
Kosten (geringer Aufwand Betrieb) unterschieden. In diese Kriterien einbezogen sind die Aufwendungen für das Personal im Accountmanagement, die
je nach Komplexität der Lösung auch hohe Kosten produzieren können.
Ein Kriterium, welches auch als wichtig erachtet wurde, ist die Benutzerfreundlichkeit für den Endnutzer (Mitarbeiter). Dieses kann unterteilt werden
in die Usability2 der Anwenderschnittstelle, also den Teil der Lösung, mit der
der Mitarbeiter zu tun hat (z.B. GUI-Frontends, Programmabläufe) und dem
2
Auch „Gebrauchstauglichkeit“, nach Definition in den DIN Standards (z.B. DIN EN ISO
9241 Teil 11) handelt es sich dabei um „die Eignung eines Produktes bei der Nutzung durch
bestimmte Benutzer in einem bestimmten Benutzungskontext die vorgegebenen Ziele effektiv, effizient und zufriedenstellend zu erreichen“.
46
6.2 Bewertung
Teil, der transparent, d.h. für den User nicht sichtbar abläuft und Ihn damit
entlastet (Transparenz).
Das zu wählende Verfahren soll selbstverständlich weiterhin die Nutzung
einer Smartcard beinhalten. Wichtiges Kriterium ist also, inwieweit die Smartcard weiterhin die Funktion einer Zwei-Faktor-Authentifizierung gegenüber
dem Verschlüsselungsschlüssel gewährleistet (Smartcardnutzung).
Da die PKI bereits seit nahezu drei Jahren in Betrieb ist, sind mittlerweile
größere Mengen verschlüsselte Daten in Form von E-Mails oder Dateien des
verwendeten Dateiverschlüsselungsprogramms angehäuft worden, die selbstverständlich weiterhin benötigt werden. Es muss also sichergestellt werden,
dass diese – entweder in einem Migrationsprozess oder direkt – nach Etablierung des neuen Verfahrens weiterhin zugreifbar sind. Dies wird in dem Kriterium Weiternutzung vorhandener Daten bewertet.
Ein weiteres, sehr wichtiges Kriterium ist die Sicherheit des Verfahrens. Ein
Verfahren, das alle anderen genannten Kriterien erfüllt, aber eine miserable
Sicherheit für die privaten Schlüssel oder verschlüsselte Daten bietet, ist abzulehnen. Ein passendes Verfahren muss also die Sicherheit von verschlüsselten
Daten aus Vergangenheit und Zukunft genauso gewährleisten wie die Sicherheit des Entschlüsselungsschlüssels an sich.
Als letztes Kriterium wird das Roaming eingeführt (siehe Kapitel „Konzepte“). Zumindest innerhalb des Unternehmens ist Roaming wichtig, da die Mitarbeiter z.B. der Lage sein sollen, in Konferenzräumen auf Ihre verschlüsselten
Daten zugreifen zu können.
Die soeben definierten Kriterien werden in Tabelle 6.1 paarweise verglichen.
Das wichtigere Kriterium beim Einzelvergleich bekommt dabei einen Punkt.
Die Punktsumme für jedes Kriterium wird berechnet, indem für jedes Kriterium die Nullen in den Zeilen und die Einsen in den Spalten addiert werden
(siehe letzte Spalte in der Tabelle). Um eine bessere Lesbarkeit zu erreichen,
wurde die Tabelle im Anschluss an die Gewichtung sortiert.
Somit ergibt sich folgende Gewichtungsreihenfolge (von wichtig nach unwichtig): Smartcardnutzung (8), Weiternutzung vorhandener Daten (7), Sicherheit (6), Usability (4), Geringer Aufwand Betrieb und Zügige Umsetzung
(3), Roaming und Transparenz (2) sowie Geringer Aufwand Umsetzung (1).
Im nächsten Absatz widmen wir uns der Bewertung einiger der in Kapitel 4
vorgestellten Verfahren.
6.2 Bewertung
Zunächst ist anzumerken, dass nicht alle in Kapitel 4 erläuterten Verfahren bei
der Bewertung berücksichtigt wurden. Der Grund dafür ist, dass das Verfahren Secure E-Mail Gateway vom Prinzip her die Nutzung einer Smartcard für
47
6 Anforderungen und Auswahl eines Verfahrens
Smartcardnutzung
Weiternutzung vorh. Daten
Sicherheit
Usability
Geringer Aufwand Betrieb
Zügige Umsetzung
Roaming
Transparenz
Geringer Aufwand Umsetzung
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
0
1
1
1
0
1
1
1
Gewichtung (=Summe)
Geringer Aufwand Umsetzung
Transparenz
Roaming
Zügige Umsetzung
Geringer Aufwand Betrieb
Usability
Sicherheit
Weiternutzung vorhandener Daten
Wenn das Kriterium in der
Spalte als wichtiger erachtet
wird als das Kriterium in der
Zeile, dann steht am
Kreuzungspunkt
eine 1;
wenn das Kriterium in der
Spalte als unwichtiger erachtet
wird als das Kriterium in der
Zeile, dann steht am
Kreuzungspunkt
eine 0.
Smartcardnutzung
Tabelle 6.1: Paarweiser Vergleich der Kriterien zur Ermittlung der Gewichtung
8
7
6
4
3
3
2
2
1
den Endnutzer ausschließt. Da dies aber eine zwingende Vorgabe ist (ein sogenanntes „KO-Kriterium“), werden nur die verbleibenden Verfahren betrachtet.
Smartcardnutzung: Bewertet wird die Qualität der Smartcardnutzung in den
Stufen sehr schlecht (Wertung=1), schlecht (Wertung 2), mittel (Wertung 3),
gut (Wertung 4), sehr gut (Wertung 5).
Die meisten Verfahren verwenden zum Zugriff auf den Schlüssel weiterhin die Zwei-Faktor-Authentifizierung mittels Smartcard, sind also diesbezüglich mit „sehr gut“ zu bewerten. Managed Decryption kann zwar
eine Smartcard zur Authentifizierung gegenüber dem Server, der die
Schlüssel bereithält, einsetzen, allerdings ist der Schlüssel dann nicht so
gut vor Angriffen über andere Kanäle gesichert wie bei der Verwahrung
auf der Smartcard seines Inhabers, weshalb die Lösung mit „gut“ zu bewerten ist. Bei der Keyhistory in Software-PSE werden alte Verschlüsselungsschlüssel deutlich schlechter gesichert als der aktuelle Schlüssel,
daher erhält das Verfahren die Bewertung „schlecht“.
Weiternutzung vorhandener Daten: Bewertet wird die Möglichkeit zur pro-
48
6.2 Bewertung
Umschlüsselung
Keyhistory Software-PSE
Keyhistory auf Smartcards
Managed Decryption
Kriterien
Smartcardnutzung
Weiternutzung vorhandener Daten
Sicherheit
Usability
Geringer Aufwand Betrieb
Zügige Umsetzung
Roaming
Transparenz
Geringer Aufwand Umsetzung
Parallele Nutzung der Smartcards
Tabelle 6.2: Bewertung der Verfahren
5
4
5
2
3
5
5
1
5
5
3
4
1
1
5
5
2
5
2
5
3
3
3
3
1
4
4
5
5
4
4
4
2
4
4
3
4
5
2
5
4
1
3
5
1
blemlosen Weiternutzung vorhandener, bereits verschlüsselter Daten in
den Stufen sehr schlecht (Wertung=1), schlecht (Wertung 2), mittel (Wertung 3), gut (Wertung 4), sehr gut (Wertung 5).
Bei den Keyhistory-Verfahren und der Managed Decryption ist dies sehr
gut gewährleistet, bei der parallelen Nutzung von Smartcards kommt es
manchmal zu Problemen mit der richtigen Zuordnung, was zur Abwertung führt. Bei der Umschlüsselung ist die Weiternutzung nicht immer
gewährleistet, da immer die Gefahr besteht, dass beim Umschlüsseln Daten vergessen werden, welche dann nicht zugreifbar sind.
Sicherheit: Bewertet wird die Sicherheit in den Stufen sehr unsicher (Wertung=1), unsicher (Wertung 2), zufriedenstellende Sicherheit (Wertung 3),
sicher (Wertung 4), besonders sicher (Wertung 5).
Das Verfahren der parallelen Nutzung bietet besonders hohe Sicherheit,
denn hier sind Schlüssel und verschlüsselte Daten zu jedem Zeitpunkt
optimal geschützt. Bei der Umschlüsselung ist der Schutz für die privaten Schlüssel immer gegeben, die alten Daten werden jedoch beim
49
6 Anforderungen und Auswahl eines Verfahrens
Umschlüsseln kurzzeitig entschlüsselt und bieten damit zumindest eine
kleine Angriffsfläche. Das Verfahren Keyhistory auf Smartcards ist ebenfalls als sicher zu betrachten, der einzige Angriffspunkt ist die zunehmende Schwächung der Sicherheit der alten Verschlüsselungsschlüssel,
denn auf alle Verschlüsselungsschlüssel kann mit der gleichen PIN zugegriffen werden. Eine gerade noch zufriedenstellende Sicherheit erreicht
das Verfahren Keyhistory in Software-PSE, denn die alten Verschlüsselungsschlüssel und damit auch die alten verschlüsselten Daten sind hier
deutlich schwächer geschützt. Am schlechtesten schneidet das Verfahren
Managed Decryption ab, denn hier sind Schlüssel nur mit Benutzername
und Passwort geschützt. Es muss daher im Vergleich als unsicher bewertet werden.
Usability: Bewertet wird die Usability (Gebrauchstauglichkeit in den Stufen
sehr schlecht (Wertung=1), schlecht (Wertung 2), mittel (Wertung 3), gut
(Wertung 4), sehr gut (Wertung 5).
Da die Umschlüsselung neben des hohen Zeitaufwandes auch ein komplexer, für den Benutzer schwer zu durchschauender Prozess ist, der
für jede Anwendung des Verschlüsselungsschlüssels ein eigenes Tool (in
der Regeln auch mit eigenem Graphical User Interface (GUI)) benötigt,
wird die Usability des Verfahrens als sehr schlecht bewertet. Die Parallele Nutzung von alten und neuen Smartcards gestaltet sich schwierig, weil die Anwendungen in der Regel wenig bis gar keine Informationen über die benötigte Smartcard bzw. das benötigte Zertifikat zum
Entschlüsseln anzeigen. Häufig ist dann ein Durchprobieren der vorhandenen Karten notwendig. Daher wird hier die Usability als schlecht
bewertet. Die Keyhistory-Verfahren sind beide weitestgehend gebrauchstauglich, die Nutzung von Roaming ist bei Keyhistory in Software-PSE
allerdings wenn dann nur sehr eingeschränkt möglich. Dies führt zur
Bewertung „mittel“ im Falle der Software-PSE-Lösung, Keyhistory auf
Smartcards wird mit „gut“ bewertet. Die Managed Decryption erlaubt
eine einfache Bedienung und erhält somit eine sehr gute Bewertung.
geringer Aufwand Betrieb: Bewertet wird der geschätzte Aufwand zum Betrieb des entsprechenden Verfahrens in den Stufen sehr hoch (Wertung=1),
hoch (Wertung 2), mittel (Wertung 3), mittel bis gering (Wertung 4), sehr gering (Wertung 5).
Der Aufwand im Berieb ist bei der Umschlüsselung am größten, weil
diese durch den Inhaber einer Smartcard, ggf. mit Unterstützung durch
einen Supporter, unter großem Zeitaufwand durchgeführt werden muss.
Bei paralleler Nutzung von alten und neuen Smartcards ist zwar zunächst von einem geringen Aufwand auszugehen. Allerdings wird der
Supportaufwand durch irrtümliche Verwendung von Smartcards sowie
50
6.2 Bewertung
durch versehentlich gesperrte Smartcards voraussichtlich stark ansteigen, so dass insgesamt von mittleren Aufwendungen auszugehen ist.
Auch bei der Keyhistory in Software-PSE sind ungefähr mittlere Supportaufwendungen zu erwarten, denn die Installation von alten Schlüsseln und Zertifikaten auf den jeweiligen Rechnern ist fehleranfällig und
bietet (zumindest ohne weitere Modifikationen) kein Roaming. Keyhistory auf Smartcards und Managed Decryption sorgen dafür, dass Roaming gewährleistet ist und der User möglichst wenig Kontakt mit den
verschiedenen Schlüsseln hat. Daher ist der Aufwand im Betrieb bei diesen Lösungen als mittel bis gering einzustufen.
Zügige Umsetzung: Bewertet wird die geschätzte Dauer bis zur Umsetzung
in den Stufen mehr als 6 Monate (Wertung=1), 4-6 Monate (Wertung=2),
1-2 Monate (Wertung=3), ca. 1 Monat (Wertung=4), sofort einsetzbar (Wertung=5).
Das Kriterium der zügigen Umsetzung wird von den Verfahren Parallele Nutzung und Umschlüsselung am besten erfüllt, denn diese Verfahren sind sofort einsetzbar. Die Umsetzung eines Keyhistory-Verfahrens
benötigt mehr Entwicklungszeit, wobei sich die Umsetzung mit Smartcards aufwändiger gestaltet als die mit Software-PSE, denn die Struktur
der Smartcard muss zur Aufnahme weiterer Schlüsselpaare angepasst
werden. Für den Einsatz von Managed Decryption wird eine komplette
Umstrukturierung sowohl auf Seite der PKI als auch auf Clientseite erforderlich, somit ist hier mit der langwierigsten Umsetzung zu rechnen.
Roaming: Bewertet wird die Möglichkeit von Roaming in den Stufen sehr
schlecht (Wertung=1), schlecht (Wertung 2), mittel (Wertung 3), gut (Wertung 4), sehr gut (Wertung 5).
Die Parallele Nutzung und auch die Umschlüsselung bieten sehr gute
Roaming-Eigenschaften, denn es wird immer nur ein Verschlüsselungsschlüssel pro Smartcard verwendet, der sich immer an der gleichen Stelle auf der Smartcard befindet. Sobald ein Rechner mit der notwendigen
Middleware ausgestattet ist, kann die Smartcard dort genutzt werden.
Bei der Keyhistory auf Smartcards werden mehrere Verschlüsselungsschlüssel auf einer Smartcard gespeichert, was eher unüblich ist und daher immer eine angepasste Middleware erfordert, was zur leichten Abwertung bezüglich des Roamings führt. Managed Decryption erfordert
neben spezieller Software auch immer eine Netzwerkverbindung zum
Server, was Roaming erschwert und zur Bewertung „mittel“ führt. Das
Roaming bei der Keyhistory in Software-PSE ist als sehr schlecht zu bewerten, weil nur der aktuelle Schlüssel auf der Smartcard zu finden ist.
Alte Schlüssel müssen manuell über spezielle Verfahren oder ggf. mit
51
6 Anforderungen und Auswahl eines Verfahrens
Verbindung zu einem Server auf den jeweiligen Rechner gebracht werden, um dort genutzt zu werden.
Transparenz: Bewertet wird die Transparenz in den Stufen sehr schlecht (Wertung=1), schlecht (Wertung 2), mittel (Wertung 3), gut (Wertung 4), sehr gut
(Wertung 5).
Die Transparenz der Managed Decryption ist sehr gut, denn das komplette Schlüsselmanagement kann automatisiert ablaufen (z.B. können
Verschlüsselungszertifikate bei Ablauf automatisch verlängert werden,
ohne dass der User dies merkt). Die Keyhistory-Verfahren bieten eine gute Transparenz, allerdings muss hier eine explizite Verlängerung durchgeführt werden. Umschlüsselung und parallele Nutzung von Smartcards
bieten schlechte Transparenz, wobei die Umschlüsselung noch ein wenig
besser zu bewerten ist, da nach dem wenig transparenten Umschlüsselungsvorgang ohne Zugriff auf alte Schlüssel gearbeitet werden kann.
geringer Aufwand Umsetzung: Bewertet wird der geschätzte Aufwand zur
Umsetzung des entsprechenden Verfahrens in den Stufen sehr hoch (Wertung=1), hoch (Wertung 2), mittel (Wertung 3), mittel bis gering (Wertung
4), sehr gering (Wertung 5).
Kosten und Personalaufwendungen korrelieren zwar eng mit einer zügigen Umsetzung, trotzdem sind die Aufwendungen nicht unbedingt mit
dem Zeitbedarf zur Umsetzung gleichzusetzen. Für die parallele Nutzung von alter und neuer Smartcard sowie die Umschlüsselung besteht
kein Aufwand zur Umsetzung. Die zu erwartenden Aufwendungen für
die beiden Keyhistory-Verfahren sind höher anzusiedeln. Am teuersten
ist die Umsetzung der Managed Decryption einzuschätzen.
Nachdem die Gewichtung der Kriterien und die Bewertung der Verfahren
abgeschlossen ist, kann der Nutzwert berechnet werden. Dazu werden zunächst für jedes Kriterium K die Bewertungen BK mit den Gewichtungen GK
multipliziert, um den Teilnutzen TK des Verfahrens bezogen auf das Kriterium
K zu berechnen.
TK = BK ∗ GK
(6.1)
Die Teilnutzen TK für jedes Kriterium werden dann zum Nutzwert N des
Verfahrens zusammenaddiert.
N=
X
TK
(6.2)
K
Diese Berechnungen werden für jedes Verfahren durchgeführt. In Tabelle 6.3
ist das Ergebnis der Nutzwertanalyse abzulesen.
52
6.3 Gewähltes Verfahren
Umschlüsselung
Keyhistory Software-PSE
Keyhistory auf Smartcards
Managed Decryption
8
7
6
4
3
3
2
2
1
Parallele Nutzung der Smartcards
Kriterien
Smartcardnutzung
Weiternutzung vorhandener Daten
Sicherheit
Usability
Geringer Aufwand Betrieb
Zügige Umsetzung
Roaming
Transparenz
Geringer Aufwand Umsetzung
Nutzwert
Gewichtung
Tabelle 6.3: Nutzwerte der Verfahren
40
28
30
8
9
15
10
2
5
147
40
21
24
4
3
15
10
4
5
126
16
35
18
12
9
9
2
8
4
113
40
35
24
16
12
6
8
8
3
152
32
35
12
20
12
3
6
10
1
131
In der Literatur zur Nutzwertanalyse findet sich häufig der Hinweis, dass in
einem letzten Schritt eine Sensitivitätsanalyse durchzuführen sei. Dabei werden nochmals Bewertungsunsicherheiten und Fehlergrenzen betrachtet. Dies
war im vorliegenden Fall nicht notwendig, da die Bewertung schon ausreichend diskutiert und reflektiert wurde. Das Ergebnis kann somit als robust
betrachtet werden. Das Verfahren mit dem höchsten Nutzwert für T-Online ist
somit das Verfahren Keyhistory auf Smartcard.
6.3 Gewähltes Verfahren
Die Gewichtung bei der Nutzwertanalyse hat gezeigt, dass die Kriterien Smartcardnutzung, Weiternutzung vorhandener Daten und Sicherheit die wichtigsten
bei der Einführung einer Lösung für T-Online sind. Beim Verfahren Keyhistory
auf Smartcard ist die Nutzung des freien Speichers für alte Zertifikate problemlos möglich, solange die Smartcard ausreichend Platz bietet. Da das Medium
Smartcard in diesem Fall gleich bleibt, ist auch die Weiternutzung der vor-
53
6 Anforderungen und Auswahl eines Verfahrens
handenen Daten gesichert. Die zusätzlichen Schlüssel müssen allerdings von
der Middleware zugreifbar sein. Auch werden bei der Sicherheit Abstriche
gegenüber der bisherigen Vorgehensweise gemacht werden müssen. In den
folgenden Kapiteln wird die Implementierung dieses Verfahrens bei T-Online
beschrieben.
54
7 Design und Implementierung
Das Ergebnis der vorangegangenen Evaluation war das Verfahren Keyhistory
auf Smartcard. Zur Einführung des Verfahrens werden in diesem Kapitel die
notwendigen Änderungen an Prozessen und Komponenten der T-Online PKI
ermittelt und deren Umsetzung erläutert. Dabei wird auch auf Punkte eingegangen, die bei der vorangehenden Beschreibung der T-Online PKI nicht im
Detail besprochen wurden und auf besondere Probleme, die erst bei der Umsetzung entstanden und dann gelöst werden mussten.
7.1 Anpassung der Prozesse
Innerhalb einer PKI gibt es zahlreiche Abläufe (wie z.B. Beantragungs- und
Verlängerungsprozesse), die spezifiziert werden müssen. Dies dient der Vermeidung von Fehlern und fördert die Nachvollziehbarkeit der durch das Personal der Registration Authority durchgeführten Arbeiten. Das ist insbesondere wichtig, damit eventuell im Certificate Practice Statement (CPS) zugesicherte Vorgehensweisen auch überprüfbar eingehalten werden. Auf den nächsten
Seiten soll erläutert werden, inwieweit Prozesse angepasst werden müssen
und welche Konsequenzen diese Anpassungen für die Struktur und das Niveau der Sicherheit der PKI insgesamt haben.
7.1.1 Aufgabe des Vier-Augen-Prinzips
Das im Kapitel „Konzepte“ eingeführte Vier-Augen-Prinzip kam bisher innerhalb der T-Online PKI, wie bereits erwähnt, bei der Wiederherstellung von
Keybackups zum Einsatz. Bei der anstehenden Verlängerung der Zertifikate bei T-Online sollen nun im gewählten Verfahren neben neuen Zertifikaten
auch die alten Verschlüsselungs-Zertifikate auf Smartcards aufgebracht werden. Bei Verwendung neuer Smartcards für die Verlängerungen bedeutet das,
dass zusätzlich zu den neu zu erstellenden Zertifikaten die vorhandenen Keybackups nach dem Vier-Augen-Prinzip unter relativ hohem Aufwand wiederhergestellt und auf die neuen Smartcards aufgebracht werden müssten.
Bei der großen Zahl der in kurzer Zeit zu erstellenden Karten sind diese
Personalanforderungen praktisch nicht zu erfüllen. Eine Folge wäre, dass bei
der täglichen Arbeit die beiden zur Wiederherstellung von Keybackups notwendigen RecoveryAdmin-Smartcards die meiste Zeit parallel im Einsatz wä-
55
7 Design und Implementierung
ren. Dadurch wird in letzter Konsequenz der gewünschte Effekt der doppelten
Kontrolle stark reduziert.
Auch sind die RecoveryAdmin-Smartcards durch die Einführung des neuen Verfahrens einem deutlich erhöhten Verschleiß ausgesetzt, vor allem, wenn
sich die RecoveryAdmin-Karten wie bisher einen Smartcardreader teilen müssen, also bei jeder Wiederherstellung eines Keybackups nacheinander gesteckt
werden. Alternativ könnte man die Registrator-Arbeitsplätze mit zusätzlichen
Kartenlesegeräten ausstatten, was allerdings bedeuten würde, dass die Trennung der beiden Autoritäten zur Wiederherstellung eines Keybackups vollkommen verschwindet.
So stellte sich die Frage, ob die Beibehaltung des Vier-Augen-Prinzips in
diesem Fall sinnvoll ist, oder ob nicht besser nach alternativen Wegen gesucht
werden sollte, die unrechtmäßige Wiederherstellung von Keybackups festzustellen oder, idealerweise, auch zu verhindern. Nach eingehender Diskussion wurde die Aufgabe des Vier-Augen-Prinzips beschlossen. Dem teilweisen
Verlust an Kontrolle und dem damit einhergehenden erhöhten Risiko für die
Sicherheit der Keybackups soll in der angepassten PKI durch die folgenden
Maßnahmen entgegengewirkt werden:
Zentralisierung der RA
Bisher wurden Smartcards für neuen Mitarbeiter in der Zentrale in Darmstadt
sowie an den Standorten Kiel und Oldenburg personalisiert. In Darmstadt
wurden dazu Smartcards mit Passfoto und Name des Inhabers bedruckt, an
die Standorte versendet und erst in Kiel bzw. Oldenburg personalisiert. Keyrecovery wurde nur in Darmstadt durchgeführt, und auch nur dort waren
die notwendigen Recovery-Smartcards vorhanden. Eine Personalisierung der
verlängerten Smartcards an den Standorten würde bedeuten, dass auch hier
RecoveryAdmin-Karten nötig wären, um die vorhandenen Keybackups aufbringen zu können. Dies wird aus verständlichen Gründen abgelehnt. Zum
einen würden damit mehr sicherheitskritische Smartcards in Umlauf gebracht.
Zum anderen würde sich die Zahl der zum Keyrecovery berechtigten Personen verdreifachen, und somit wäre die Kontrolle der sensiblen Geheimnisse
zu breit gestreut und nur noch schwer zu kontrollieren.
Stattdessen werden die Smartcards zukünftig immer in Darmstadt bedruckt
und personalisiert. Es wird dann nur eine einzige RecoveryAdmin-Karte, und
zwar in der Zentrale in Darmstadt, benötigt. Mitarbeiter an den Standorten
können Ihre neuen, verlängerten oder wiederhergestellten Smartcards entweder persönlich in Darmstadt abholen, oder die Smartcards und PIN/PUKBriefe werden in zwei getrennten, zeitversetzt aufgegebenen Einschreiben an
den jeweiligen Standort verschickt.
56
7.1 Anpassung der Prozesse
Benachrichtigungsfunktionen des Trustcenters
Eine weitere Maßnahme, die die Aufgabe des Vier-Augen-Prinzips kompensieren soll, ist die Erweiterung der Benachrichtigungsfunktionen des Trustcenters. Bei jeder Anforderung eines Keybackups durch die RA wird zukünftig
der Inhaber des wiederherzustellenden Zertifikats automatisiert per E-Mail
über diesen Vorgang informiert. Dadurch, dass der Versand der E-Mail direkt
durch das Trustcenter erfolgt, kann einer eventuellen Manipulation am Mailsystem um die Benachrichtigung abzufangen entgegengewirkt werden.
Zusätzlich wird eine Kopie dieser Benachrichtigungsmail an ein extra zu
diesem Zweck erstelltes Funktionspostfach übermittelt. Zugriff auf das Postfach haben der Leiter der IT-Security, der Leiter der Unternehmenssicherheit
und der Datenschutzbeauftragte des Unternehmens. In regelmäßigen Reviews
kann so ein eventueller Missbrauch aufgedeckt und verfolgt werden.
7.1.2 Enrollment-Prozess mit Key-Backup
Die Beantragung der Zertifikate und das Aufbringen auf die Smartcard können bei diesem Verfahren weitestgehend unverändert bleiben. Bei der Speicherung der Keybackups in der Datenbank des Trustcenters wurden zwar Änderungen nötig (diese werden weiter unten besprochen), der Prozess an sich
bleibt jedoch für den Registrator (also nach Außen hin) gleich.
7.1.3 Prozess der Erst-Beantragung für neue Mitarbeiter
Kommt ein neuer Mitarbeiter in das Unternehmen, so wird er mit einer Smartcard mit jeweils einem Zertifikat für die Verwendungszwecke Authentifikation, Signatur und Verschlüsselung ausgestattet. Da in einem solchen Fall noch
keine Keybackups zur Identität des Mitarbeiters existieren, kann die Erstellung der Smartcard genauso erfolgen wie vor der Umstellung des Verfahrens.
Auch dieser Prozess, der den Enrollmentprozess beinhaltet, muss somit nicht
angepasst werden.
7.1.4 Prozess der Verlängerung
Der Verlängerungsprozess wurde durch die Wahl des Verfahrens deutlich verändert. Die bisher verfolgte Praxis, Smartcards bei Verlängerungen auszutauschen, wird aus den in Kapitel 5 genannten Gründen (Vereinheitlichung der
Prozesse, Verschleiß und Anfälligkeit für Defekte, Abnutzung der Beschriftung, technische Anforderungen) beibehalten.
Die Erstellung der dann notwendigen neuen Authentifikations- Signatur
und Verschlüsselungszertifikate wird identisch zu der Erst-Beantragung für
neue Mitarbeiter durchgeführt; auf der Web-Oberfläche wird dazu auch der
57
7 Design und Implementierung
gleiche Menüpunkt gewählt. Dieses Design wurde gewählt, um diese neue
Funktionalität möglichst unkompliziert und leicht bedienbar zu integrieren.
Die zusätzlichen Schritte zum Aufbringen der Keybackups werden dann bei
Bedarf (also wenn zur Identität gehörende Backups in der Datenbank existieren) am Ende des Erstellungsprozesses automatisch durchgeführt. Dabei
werden, ebenfalls zur Vereinfachung, die beiden jüngsten Keybackups auf die
Karte aufgebracht. Es müssen also bereits bestehende Backups automatisch
gesucht, wiederhergestellt und auf der Smartcard in den zusätzlichen Speicherplätzen gespeichert werden.
Diese Aufgaben kann die eingesetzte Software zum Keyrecovery nach aktuellem Stand nicht erfüllen, und selbst mit Änderungen ließe sich die Anwendung nicht so in den Beantragungsprozess einbauen, dass Sie im Browser
abläuft.
Es wird also eine Lösung benötigt, wie die in der Datenbank gespeicherten
Keybackups auf einem sicheren Weg auf die Ziel-Smartcard gelangen. Ein Ansatz ist es, die Parameter und Daten der aufzubringenden Keybackups durch
den Webserver der RA-Schnittstelle aus dem Trustcenter zum RA-Arbeitsplatz
zu übertragen. Dort werden die eingebetteten Daten auslesen, mit Hilfe der
RecoveryAdmin-Smartcard entschlüsselt und auf die Ziel-Smartcard aufgebracht.
Eine bestehende Lösung, die einen Großteil der benötigten Funktionen bereits bietet, ist die von der Firma Kobil für ein anderes Produkt (SecOVID) entwickelte ActiveX-Komponente – also eine Anwendung, die im Browser abläuft
und auf die in der Webseite eingebetteten Daten zugreifen kann. Diese Komponente kann mit einem Smartcardreader kommunizieren und beherrscht alle
zum Enrollment benötigten Funktionen. Die Kommunikation mit einem zusätzlichen Smartcardreader zur Entschlüsselung der Keybackups beherrscht
die ActiveX-Komponente allerdings nicht und muss daher nachgerüstet werden.
Um die Anpassungen an den bestehenden Softwarekomponenten möglichst
gering zu halten, wurde entschieden, die Suche nach passenden Keybackups
am Ende des regulären Erstellungsprozesses automatisch auf der Datenbank
des Trustcenters durchzuführen und das Ergebnis an die Browser-Sitzung des
RA-Rechners per eingebettetem Java-Script zurückzugeben. Die Wiederherstellung und die Speicherung der auf diesem Wege übermittelten Zertifikate
übernimmt die eingebundene ActiveX-Komponente; die Funktionsweise wird
weiter unten beschrieben.
Am Ende des Verlängerungsprozesses wird ein Popup-Fenster angezeigt,
welches das Ergebnis der Kartenerstellung dokumentiert und gegebenenfalls
auf entstandene Fehler hinweist.
Reicht der Platz auf der Smartcard nicht aus, um alle vorhandenen Verschlüsselungszertifikate einer Person aufzunehmen (bei der aktuellen Lösung
wären das drei Keybackups und ein neues Verschlüsselungszertifikat), ist in
58
7.1 Anpassung der Prozesse
der Regel eine Umschlüsselung durchzuführen. Dabei müssen alle Daten, die
mit dem jeweils ältesten Zertifikat verschlüsselt wurden, auf das neueste Zertifikat umgeschlüsselt werden. Der Aufwand für die Umschlüsselung steigt
also durch die Verwendung einer Keyhistory nicht an. Es kann sogar angenommen werden, dass nach (im Idealfall) neun Jahren, also nach 3 Generationen von Verschlüsselungsschlüsseln mit jeweils 3 Jahren Laufzeit, ein Zugriff
auf die ältesten, verschlüsselten Daten nur in seltenen Ausnahmefällen nötig
ist. Eine Entschlüsselung der Daten wäre dann nur bei Bedarf unter Erstellung
einer Backupkarte durchzuführen.
7.1.5 Prozess bei Verlust/Defekt der Smartcard
Auch unter Einsatz eines Keyhistory-Verfahrens müssen zunächst die Zertifikate auf verlorenen oder gestohlenen Smartcards gesperrt werden, um eine
unrechtmäßige Nutzung der darauf gespeicherten Zertifikate zu verhindern.
Besteht keine Gefahr, dass die alten Schlüssel in falsche Hände gelangt sind
(z.B. weil die Karte einen Defekt hat und ordnungsgemäß entsorgt wurde),
kann die Sperrung unterbleiben.
Anschließend genügt es jedoch, im Gegensatz zur bisherigen Vorgehensweise (also der Erstellung einer reinen Backupkarte und zusätzlich einer neuen Smartcard), eine „Verlängerung“ durchzuführen. Das heißt, es wird eine
neue Smartcard mit neuen Zertifikaten für Authentifikation, Signatur und Verschlüsselung erstellt, die zusätzlich die letzten beiden Verschlüsselungszertifikate, also auch das verlorene/gestohlene/defekte, enthält.
Nachdem durch die Verlängerung die alten Verschlüsselungsschlüssel wiederhergestellt und ein neues Verschlüsselungsschlüsselpaar erzeugt wurden,
kann eine Umschlüsselung der alten, verschlüsselten Daten durchgeführt werden. Dies ist aber nur dann notwendig, wenn von einer tatsächlichen Kompromittierung des Schlüsselmaterials auszugehen ist. Aber auch in diesem Fall
wird keine zusätzliche Backupkarte benötigt.
7.1.6 Prozess zur Erstellung einer Backupkarte
Reine Backupkarten werden durch die Keyhistory-Funktion weitestgehend
überflüssig, denn neue Smartcards enthalten automatisch die beiden letzten
Keybackups. Der Prozess wurde aber dennoch implementiert – vor allem, um
bestimmte Funktionen abbilden zu können, die in der PKI bisher so nicht vorgesehen waren.
Beispielsweise wurde mehrfach eine Stellvertreter-Funktion für die Smartcards gefordert. Sekretariate sollen in bestimmten Fällen auf die verschlüsselten E-Mails Ihrer Chefs zugreifen können. Wurden die Sekretariate bei der
Adressierung einer E-Mail nicht einbezogen, so können Sie diese nicht öff-
59
7 Design und Implementierung
nen, auch wenn Sie grundsätzlichen Zugriff auf das Postfach haben. Mit einer Backupkarte, die Verschlüsselungszertifikate und Entschlüsselungsschlüssel des Chefs enthält, könnten die Sekretariate verschlüsselte Nachrichten, die
ausschließlich an Ihren Chef adressiert sind, öffnen. Oder man könnte die Verschlüsselungszertifikate des Chefs zusätzlich auf die persönlichen Smartcards
der MitarbeiterInnen der Sekretariate aufbringen.
Ein anderer Grund zum Einsatz dieser Funktion könnte sein, dass ein Mitarbeiter zwar mittlerweile vier Verschlüsselungszertifikate hat, das Zertifikat
des jüngsten Backups jedoch faktisch nie zur Verschlüsselung benutzt wurde.
Auf der aktuellen Smartcard wären jedoch nur die letzten beiden Keybackups
zu finden, denn diese werden automatisch aufgebracht. Das möglicherweise dringender benötigte, älteste Keybackup befände sich zunächst nicht auf
der Smartcard. Mit der Funktion zur Erstellung einer Backupkarte könnte das
nicht benötigte, jüngste Backup-Zertifikat mit dem benötigten, ältesten Verschlüsselungszertifikat überschrieben werden.
Es kann also durchaus sinnvoll sein, auch bei Verwendung einer Keyhistory auf Smartcards die Option zu haben, reine Backupkarten zu erstellen.
Für die Erstellung einer reinen Backupkarte (also mit bis zu drei Verschlüsselungszertifikaten) kann das bisherige Programm zur Keyrecovery ebenfalls
nicht genutzt werden, da es nur ein Zertifikat auf der Smartcard speichern und
keine Suche auf der Datenbank durchführen kann. Die bereits für den Verlängerungsprozess verwendete ActiveX-Komponente lässt sich aber auch für die
Herstellung einer Backupkarte nutzen und wird daher zu diesem Zweck eingesetzt. Der genaue Ablauf und die Funktionsweise der ActiveX-Komponente
werden in Kapitel 7.3.3 erläutert.
7.1.7 Prozess bei Namensänderung
In bestimmten Fällen ändern sich die in den Zertifikaten enthaltenen, persönlichen Daten und es müssen neue Zertifikate ausgestellt werden. Die betroffenen Personen sollen natürlich weiterhin auf Ihre alten, verschlüsselten Daten
zugreifen können, aber auch neue Zertifikate mit korrigiertem Inhalt erhalten. Bei Änderungen am Zertifikatsinhalt muss also eine Art außerplanmäßige
Verlängerung durchgeführt werden. Eine Namensänderung, z.B. bei Heirat1 ,
führte bisher bei T-Online zur Erstellung einer neuen Smartcard, bei der die
persönlichen Daten (Name und E-Mail-Adresse) angepasst wurden. Natürlich
war auch hier im Anschluss eine Umschlüsselung notwendig, um den Zugriff
auf alte, verschlüsselte Daten sicherzustellen.
Eine Umschlüsselung ist zwar bei dem gewählten Verfahren Keyhistory auf
1
Der Prozess bei „Namensänderung“ ist grundsätzlich auch dann erforderlich, wenn sich
nur die E-Mail-Adresse einer Person ändert, z.B. weil Sie von oder zu einem Tochterunternehmen von T-Online wechselt.
60
7.2 Anpassungen im Trustcenter
Smartcard nicht notwendig, es taucht aber ein anderes Problem auf: Zur Identifizierung zugeordneter Keybackups wird zukünftig die E-Mail-Adresse seines
Inhabers herangezogen (mehr dazu in Kapitel 7.2.1). Würde eine Namensänderung in der Datenbank nicht berücksichtigt, so würde eine fehlerhafte Keyhistory erzeugt. Die Keybackups unter dem alten Namen bzw. der alten EMail-Adresse würden nicht mit dem neuen Zertifikat verknüpft, und somit
würde bei Verlängerungen ein Teil der benötigten Keybackups nicht wiederhergestellt. Um das Problem zu vermeiden, musste die Tabellenstruktur der
Datenbank angepasst werden, so dass eine Zuordnung von alten Zertifikaten
zu einem neuen Zertifikat vorgenommen werden kann.
Um bei zukünftigen Verlängerungen eine Namensänderung anzeigen zu
können, wurde daher in das Formular zur Zertifikatsbeantragung das zusätzliche Feld „Alte E-Mail-Adresse“ eingefügt. Alle Zertifikate in der BackupDatenbank, die diese E-Mail-Adresse enthalten, werden mit dem im Verlängerungsprozess erstellten Zertifikat zu einer gemeinsamen Keyhistory verknüpft
und gegebenenfalls gleich auf die neue Smartcard aufgebracht.
7.2 Anpassungen im Trustcenter
Wie bei der Überarbeitung der Prozesse deutlich wurde, waren im Trustcenter
sowohl Änderungen am Backend (Anpassung des Datenbankschemas, Erweiterung der Benachrichtigungsfunktionen) als auch am Frontend (Webschnittstelle) durchzuführen.
7.2.1 Datenbankschema für Keybackups
Bisher wurden Keybackups in der Datenbank des Trustcenters eindeutig anhand einer fortlaufend vergebenen Indizierungsnummer (ID) identifiziert. Zur
Wiederherstellung eines Keybackups musste diese ID zunächst ermittelt werden. Dazu konnte an der Webschnittstelle nach Zertifikatsseriennummern, Namen, E-Mail-Adressen und anderen Merkmalen gesucht werden. Anschließend wurden alle zur Suchauswahl passenden Keybackups samt Ihrer IDs angezeigt. Durch Eingabe der ID im Keyrecovery-Programm konnte dann ein
Keybackup wiederhergestellt werden.
Für die bei der Verlängerung notwendige automatisierte Wiederherstellung
von Keybackups musste dieser Prozess angepasst werden. Dazu war zunächst
zu bestimmen, wie Keybackups eindeutig den Inhabern zugeordnet werden
können. Aus datenschutzrechtlichen Gründen schied die für jeden Mitarbeiter
eindeutige Personalnummer als eindeutiges Merkmal aus. Als Alternative zur
Identifizierung wurde die im Zertifikat enthaltene E-Mail-Adresse gewählt,
denn diese ist bei T-Online für jeden Mitarbeiter zu jeder Zeit eindeutig. Wäre
61
7 Design und Implementierung
dies nicht der Fall, so könnten bei Verlängerungen falsche Zertifikate ausgegeben werden, wie folgendes Beispiel deutlich macht:
Angenommen, es existiert ein Keybackup für Hans Müller unter der E-MailAdresse h.mueller@t-online.net, Herr Müller hat mittlerweile jedoch das Unternehmen verlassen. Nach einiger Zeit wird ein anderer Mitarbeiter mit dem
gleichen Namen eingestellt. Bekäme er nun die gleiche E-Mail-Adresse (also
ebenfalls h.mueller@t-online.net), so würde Ihm automatisch das Keybackup einer fremden Person zugeordnet und dieses auf seiner Smartcard gespeichert.
Hätte er Zugriff auf verschlüsselte Daten des ehemaligen Kollegen, so könnte er diese auch entschlüsseln. Da diese Adresse bereits in der Vergangenheit
vergeben wurde, erhält der neue Kollege jedoch eine andere, eineindeutige EMail-Adresse wie z.B. hans.mueller@t-online.net.
Da (wie wir bereits gesehen haben) die E-Mail-Adresse von Mitarbeitern
im Laufe der Zeit unter Umständen auch geändert werden muss, war ein
Mechanismus zu schaffen, der die Zuordnung von Keybackups zu E-MailAdressen erlaubt. Dazu wurde die Datenbank für die Ablage der Keybackups
im Trustcenter durch eine zusätzliche Tabelle erweitert. Diese „Zuordnungs“Tabelle besteht aus zwei Spalten: Die erste Spalte enthält die eindeutigen ID’s
von Keybackup-Datensätzen aus der bisherigen Keybackup-Tabelle, die zweite Spalte enthält durch Namensänderungen zugeordnete E-Mail-Adressen. Bei
jeder Namensänderung wird zusätzlich zum Eintrag des Keybackups in die
Keybackup-Tabelle ein Eintrag in die „Zuordnungs“-Tabelle gemacht, bei dem
die ID des Keybackups mit der alten E-Mail-Adresse des Inhabers verknüpft
wird. Wird nun eine Suche nach zugeordneten Keybackups durchgeführt, so
wird zunächst anhand der E-Mail-Adresse in der Keybackup-Tabelle gesucht.
Anschließend werden die gefundenen IDs von passenden Keybackups in der
„Zuordnungs“-Tabelle gesucht, um zugeordnete alte E-Mail-Adresse zu finden. Diese werden abschließend ebenfalls in der Keybackup-Tabelle gesucht.
So ergibt sich eine vollständige Liste aller einer Person zugeordneten Keybackups.
7.2.2 Anpassungen an der Webschnittstelle
Das Webfrontend muss den funktionalen Anpassungen und Erweiterungen
Rechnung tragen, und bedarf daher einiger Änderungen, die im Folgenden
näher erläutert werden.
Zunächst wurde der Workflow bei Beantragung von Zertifikaten den neuen Gegebenheiten angepasst. Das Eingabeformular für die Zertifikatsbeantragung erhielt das zusätzliche Eingabefeld „alte E-Mail-Adresse“ (siehe Abbildung 7.1), um bei Namensänderungen eine Zuordnung zu ermöglichen. Dadurch, dass der Aufruf dieser Webseiten nur für authentifizierte Registratoren möglich ist, kann diese Zuordnung ohne gesonderte Autorisation durch-
62
7.2 Anpassungen im Trustcenter
Abbildung 7.1: Überarbeitetes Formular zur Beantragung
geführt werden. Mit dem Speichern des Keybackups in der Datenbank wird
dann die gewünschte Verknüpfung durchgeführt. Um Fehler zu vermeiden,
werden am Ende des regulären Beantragungsprozesses und vor der Wiederherstellung eventuell vorhandener Keybackups die wichtigsten Informationen
zu den wiederherzustellenden Zertifikaten angezeigt (Zertifikatsseriennummer, E-Mail-Adresse, Name). Nach der Betätigung der „Zertifikate abholen“Schaltfläche wird das in die Webseite eingebettete ActiveX-Control gestartet,
um eine automatisierte Wiederherstellung der Keybackups durchzuführen.
Anschließend wird eine Zusammenfassung der auf die neue Smartcard aufgebrachten Zertifikate angezeigt (siehe Abbildung 7.2).
Wie oben bereits erwähnt, wurde die Erstellung von Backupkarten, die bisher mit einem gesonderten Programm durchzuführen war, in die Webschnittstelle integriert. Dazu wurde ein neuer Menüpunkt „Zertifikate wiederherstellen“ in das Hauptmenü der Webschnittstelle eingebaut. Der folgende Dialog erlaubt die Eingabe von mehreren E-Mail-Adressen (siehe Abbildung 7.3).
Standardmäßig werden bei der Suche auch alle mit den angegebenen E-MailAdressen verknüpfte Keybackups zurückgeliefert. Die Deselektion des standardmäßig aktivierten Kontrollkästchens „zugeordnete Zertifikate anzeigen“
erlaubt, die Suche nur auf tatsächlich angegebene E-Mail-Adressen einzugrenzen. Nach erfolgter Suche werden die gefundenen Keybackups in einer Liste
angezeigt und können den vorhandenen Speicherplätzen (wir sprechen hier
von „Slots“) zugeordnet werden (siehe Abbildung 7.4). Die bereits für Ver-
63
7 Design und Implementierung
Abbildung 7.2: Zusammenfassung der aufgebrachten Zertifikate
längerungen verwendete ActiveX-Komponente entschlüsselt die Keybackups
dann unter Zuhilfenahme der RecoveryAdmin-Karte und schreibt die Zertifikate in der gewünschten Reihenfolge auf die Smartcard.
Eine Funktion, die von vornherein notwendig war und daher auch zum
Zeitpunkt der Umstellung zur Verfügung stand, ist der so bezeichnete „Umschlüsselungsassistent“.
Da die bereits vorhandenen Keybackups mit Zertifikaten verschlüsselt sind,
die zukünftig nicht mehr zum Einsatz kommen sollen (es soll ja zukünftig nur
noch ein Zertifikat zur Wiederherstellung von Keybackups benötigt werden),
wurde dieser Assistent erforderlich. Wenn das RecoveryAdmin-Zertifikat abläuft, muss ebenfalls eine Umschlüsselung der Keybackups für das dann neu
ausgegebene RecoveryAdmin-Zertifikat erfolgen, damit weiterhin nur ein Zertifikat zur Wiederherstellung von unterschiedlich alten Keybackups benötigt
wird. Der Umschlüsselungsassistent bietet den Download sämtlicher im Trustcenter gespeicherter Keybackups in Form eines komprimierten ZIP-Archivs
sowie den Upload eines solchen Archivs an (siehe Abbildung 7.5). Das herunterladbare Archiv enthält alle verschlüsselten PKCS#7-Dateien, die in der
Datenbank des Trustcenters gespeichert sind. Diese können dann offline entschlüsselt und für das gewünschte neue Zertifikat verschlüsselt werden. Die
resultierenden Dateien werden dann wieder in ein ZIP-Archiv gepackt und
64
7.2 Anpassungen im Trustcenter
Abbildung 7.3: Eingabeformular für die Erstellung einer Backupkarte
über die Webschnittstelle an das Trustcenter übermittelt. Im Trustcenter werden vor Zurückspielen der Keybackups einige Prüfungen durchgeführt, um
eine Zerstörung der Keybackup-Datenbank auszuschließen. Da die Backups
über den verschlüsselten und authentifizierten SSL-Tunnel übertragen werden
und die Keybackups bei der Übertragung ohnehin verschlüsselt sind, stellt
dies keine besondere Gefährdung für die Keybackups dar. Die Umschlüsselung an sich muss allerdings auf einem besonders geschützten Rechner ohne
Netzwerkverbindung durchgeführt werden. Um möglicherweise auf der Festplatte des Rechners zurückbleibende entschlüsselte Keybackups vor unrechtmäßigem Zugriff zu schützen, wird die Festplatte im Anschluss an diesen Prozess mit einem sicheren Verfahren gelöscht.
Um eventuelle Fehler bei der Zuordnung von Keybackups im Rahmen von
Namensänderungen korrigieren zu können, werden auch Funktionen zur Korrektur von Zuordnungen bereitgestellt. Diese Funktionalität wurde noch nicht
in der Webschnittstelle realisiert und kann daher bis auf weiteres nur durch
den Operator des Trustcenters durchgeführt werden. Es ist jedoch geplant,
diese Funktion zu einem späteren Zeitpunkt in die Webschnittstelle zu integrieren.
65
7 Design und Implementierung
Abbildung 7.4: Zuordnung der Zertifikate zu den Slots auf der Smartcard
7.3 Anpassungen an der RA
An den Registratorarbeitsplätzen selbst waren Änderungen an der installierten Software und auch an der Hardware durchzuführen, die im Folgenden
detailliert beschrieben werden.
7.3.1 Hardwareanpassungen für Registrator-Arbeitsplätze
Die Registrator-Arbeitsplätze an den Standorten Kiel und Oldenburg wurden
aus den zuvor angegebenen Gründen außer Betrieb genommen. Die verbleibenden beiden Registrator-Arbeitsplätze wurden durch aktuelle Hardware ersetzt. Da die bisherigen Smartcardreader über veraltete, serielle Schnittstellen angebunden und verglichen mit aktuellen Lesegeräten sehr langsam sind,
wurden diese gegen aktuelle Lesegeräte mit USB-Schnittstelle ausgetauscht.
Die Registrator-Arbeitsplätze wurden mit jeweils einem zusätzlichen, dritten
Smartcardreader ausgestattet, der zukünftig die RecoveryAdmin-Smartcard
aufnimmt und für die direkte Kommunikation mit der ActiveX-Komponente
ausgewählt wird.
66
7.3 Anpassungen an der RA
Abbildung 7.5: Umschlüsselungsassistent
7.3.2 Key-Backup-Modul
Das DLL-Modul zur Realisierung des Keybackup-Prozesses verbat bisher im
Konfigurationsdialog die Auswahl ein und desselben Zertifikats für die Verschlüsselung der Passwort- und der Keybackup-Datei. Dies diente dem Schutz
vor Fehlkonfigurationen. Da zukünftig für beide Verschlüsselungsvorgänge
das gleiche Zertifikat benutzt werden soll, wurde diese Sperre in einem leicht
geänderten Modul aufgehoben. Eine weitere, notwendige Anpassung am bestehenden Keybackup-Modul ist die Weitergabe von Informationen zu einer
in der Datenbank durchzuführenden Verknüpfung bei Namensänderungen.
Die Informationen werden im gesendeten HTTP-Befehl als Parameter an den
URL angehängt und vom empfangenden Perl-Script ausgewertet. Treten dabei
Fehler auf, so wird die vom Trustcenter zurückgesendete, in eine Webseite eingebettete Fehlermeldung in der Browsersitzung interpretiert und angezeigt.
67
7 Design und Implementierung
7.3.3 ActiveX-Komponente für Key-Recovery
Die ActiveX-Komponente für die automatisierte Wiederherstellung von Keybackups bei der Verlängerung oder bei Erstellung einer Backupkarte wurde
auf Basis einer bestehenden AciveX-Komponente für alle Smartcard-basierten
Operationen aus dem Hause Kobil entwickelt. Das ActiveX-Control kann Zertifikate auf den NetKey-Smartcards speichern, Schlüsseloperationen durchführen und Zertifikate löschen. Das Control läuft in eine Webseite eingebettet
und wird über VBScript2 , eine interpretierte, auf Microsoft Visual Basic basierende, untypisierte Scriptsprache, angesteuert.
Das ActiveX-Control musste für die geplanten Einsatzzwecke entsprechend
angepasst werden. Zwar war es schon in der ursprünglichen Version in der
Lage, auf die zusätzlichen Speicherplätze, die für das Speichern von mehreren Verschlüsselungszertifikaten benötigt werden, zuzugreifen. Um jedoch die
durch den Web-Browser übermittelten Keybackups entschlüsseln zu können,
muss das Control mit einem Smartcardreader kommunizieren können. Dieser
Smartcardreader dient dann zur Aufnahme der RecoveryAdmin-Smartcard,
die das zur Entschlüsselung der Keybackups notwendige Zertifikat enthält.
Wird das Control zur Entschlüsselung eines Keybackups aufgerufen, so wird
in einem Dialog die PIN zur Freigabe des Entschlüsselungsauftrages auf der
RecoveryAdmin-Smartcard abgefragt. Um bei mehreren aufeinanderfolgenden Kartenerstellungsprozessen nicht jedes mal die PIN für den Zugriff auf die
RecoveryAdmin-Smartcard eingeben zu müssen, wird die Geheimnummer im
Arbeitsspeicher des Rechners so lange verschlüsselt zwischengespeichert, wie
die Browser-Sitzung aktiv ist. Damit das Control die PIN auch entschlüsseln
kann, ist in der Software der zugehörige Entschlüsselungsschlüssel gespeichert. Konnte das übergebene Zertifikat erfolgreich wiederhergestellt werden,
so wird es auf dem gewünschten Speicherplatz auf der Ziel-Smartcard gespeichert.
Der Funktion des ActiveX-Controls zur Rekonstruktion und anschließenden Speicherung eines Keybackups auf einer Smartcard hat folgende Signatur
(sämtliche Angaben sind [Kob06] entnommen):
Int NetkeyKeyBackup ( String CSPName , String Slot , String encryptedP12 , String
origCardNo , String origLabel )
Die Parameter haben dabei folgende Bedeutung:
CSPName Name des CSPs, über den importiert werden soll. Hier ist standardmäßig der angepasste Kobil-CSP für den Kartenleser mit der zu beschreibenden Smartcard ausgewählt.
Slot Slot innerhalb der Karte, auf den das Keybackup geschrieben werden
soll. Hier wird ein Text-String angegeben, der den jeweiligen Speicherplatz auf der zu beschreibenden Smartcard definiert. Dieser kann von
2
http://msdn2.microsoft.com/en-us/library/t0aew7h6.aspx
68
7.4 Anpassungen an den Smartcards
CSP zu CSP unterschiedlich sein; im Falle des bei T-Online verwendeten
CSP wären das die Slots „TCOS certificate 00“ (Slot 1), „TCOS certificate
01“ (Slot 2) und „TCOS certificate 02“ (Slot 3).
encryptedP12 In diesem String wird die PKCS#7-verschlüsselte PKCS#12Datei referenziert, die das zu rekonstruierende Keybackup enthält. Der
String muss Base64-kodiert sein.
origCardNo Enthält die Seriennummer der Smartcard, auf der das zu rekonstruierende Zertifikat ursprünglich gespeichert wurde. Diese Angabe ist
notwendig, damit die zugehörige verschlüsselte Passwortdatei aufgefunden werden kann.
origLabel Enthält ein optionales Label, das an den Namen der Passwortdatei angehängt wird. Diese Angabe ist also ebenfalls zum Auffinden der
benötigten Passwortdatei erforderlich.
Das Control liefert je nach Ergebnis des Aufrufs folgende Rückgabewerte:
0: Operation erfolgreich abgeschlossen.
-1: Fehler beim Zugriff auf den RecoveryAdmin-Smartcardreader
-2: Fehler beim Lesen des Backuppfades aus der Windows-Registry.
-3: Passwortdatei konnte nicht gefunden werden.
-4: PKCS#12-Datei konnte nicht entschlüsselt werden.
-5: PKCS#7-Datei konnte nicht entschlüsselt werden.
-6: Zertifikat / Schlüssel konnten nicht auf die Zielkarte geschrieben werden.
7.4 Anpassungen an den Smartcards
Die Smartcards werden, wie bei der Beschreibung der T-Online PKI bereits
erläutert wurde, mit einer bestimmten, vorkonfigurierten Dateistruktur ausgeliefert. Ein Teil dieser Dateien wird nicht benötigt, diese können daher gelöscht werden. Der freiwerdende Speicher wird dann für die spezielle „External Key“-Applikation verwendet, in der die drei Verschlüsselungszertifikate
gespeichert werden können.
69
7 Design und Implementierung
7.4.1 Freigabe nicht benötigten Speichers
Die Smartcard enthält mehrere nicht benötigte Reserve-Zertifikatsfiles für die
NetKey-Applikation. Diese Dateien (0x4371, 0x4332, 0x43B2, 0x4372) sind mit
einer festen Größe von 1536 Bytes angelegt, jedes Byte dieser Dateien hat bei
Auslieferung den Wert 0xFF. Da diese Dateien nicht benötigt werden, wohl
aber der dadurch belegte Speicherplatz, können diese vor dem Aufbringen
von zusätzlichen Zertifikaten gelöscht werden.
7.4.2 Definition der zusätzlichen Speicherplätze
Für die bei T-Online verwendeten Verschlüsselungszertifikate wurde bisher ja
schon eine eigene Applikation angelegt (die „External Key“-Applikation). Diese wird um zwei zusätzliche Schlüsselpaare und Zertifikate erweitert. Als Bezeichnung für die verschiedenen Verschlüsselungsschlüsselpaare wurde der
Begriff "Slot" gewählt. Auf den Smartcards wird Slot 1 mit den File-IDs 0x5103,
0x4E03 und 0x4352 für das jeweils aktuellste Verschlüsselungszertifikat auf
dem Speicherplatz des bisherigen Verschlüsselungszertifikats angelegt. Slot 2
mit den File-IDs 0x5104, 0x4E04 und 0x4353 dient der Speicherung des vorhergehenden Verschlüsselungszertifikats (falls vorhanden), und Slot 3 mit den
File-IDs 0x5105, 0x4E05 und 0x4354 nimmt das drittälteste Verschlüsselungszertifikats seines Inhabers auf. Einen Überblick über die neue Kartenstruktur
bietet Abbildung 7.6.
7.5 Anpassungen an den Clients
Die notwendigen Anpassungen an den Arbeitsplatzrechnern der Mitarbeiter
fallen durch das verwendete Verfahren relativ gering aus. Die zusätzlichen
Slots für die Keyhistory müssen dem CSP bekannt gemacht werden. Weitere
Anpassungen sind nicht notwendig.
7.5.1 CSP
Der eingesetzte Cryptographic Service Provider „TCSP“ entnimmt die Speicherstruktur eines Smartcard aus einer in XML formulierten Konfigurationsdatei, die den Namen „cards.xml“ trägt und im Programmverzeichnis des
TCSP („C:\Programme\TCSP“) gespeichert wird. Die Datei kann verschiedene Smartcard-Typen enthalten, die anhand ihrer ATR unterschieden werden. ATR ist die Abkürzung für „Answer to Reset“. Bei der Initialisierung des
Kartenzugriffs sendet jede Smartcard eine solche ATR an das Kartenterminal.
Die ATR enthält Informationen, wie mit der Smartcard kommuniziert werden
70
7.5 Anpassungen an den Clients





























































































Abbildung 7.6: Logische Kartenstruktur nach Umstellung der T-Online PKI
auf das Keyhistory-Verfahren
kann, sie kann aber wie im vorliegenden Fall auch verwendet werden, um Typen von Smartcards zu unterscheiden.
In der Konfigurationsdatei werden zu jeder Smartcard zunächst ein Label
zur Identifizierung (Zeile 7) sowie die File-IDs für den Personal Unblocking
Key (PUK) und das Verzeichnis für die auf der Smartcard vorhandenen Applikationen angegeben (Zeilen 8 und 9):
7
8
9
< card Label = " E4 Netkey V2 .0 " Manufacturer = " Telesec " Name = " netkey " >
< puk id = " 0 x4350 " access = " O " / >
< efdir id = " 0 x2F00 " access = " C " / >
Die unter „access“ aufgeführten Zeichen beschreiben die Berechtigungen und
Verwendungszwecke der Dateien (siehe dazu auch [fun06]).
Darauf folgt die Definition der ATR des Kartentyps. Dabei kann eine „Maske“ über die ATR gelegt werden, so dass nur die relevanten Bits der ATR verglichen werden. Es können also Gruppen von ATR mit einem Smartcard-Profil
verbunden werden:
71
7 Design und Implementierung
10
11
12
< atr >
< seq mask = " 0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 xFF ,0 xFF ,0 xFF ,0 xFF ,0
xFF ,0 xFF ,0 xFF ,0 xFF ,0 xFF ,0 xFF ,0 x00 " bytes = " 0 x00 ,0 x00 ,0 x00 ,0 x00 ,0 x00 ,0
x00 ,0 x00 ,0 x00 ,0 x00 ,0 x64 ,0 x05 ,0 x7B ,0 x02 ,0 x03 ,0 x31 ,0 x80 ,0 x90 ,0 x00 ,0 x00
"/>
</ atr >
Im folgenden Teil „allapplications“ der XML-Datei können nun die auf der
Smartcard zur Verfügung stehenden Applikationen definiert werden. An der
Netkey-Applikation mussten keine Veränderungen vorgenommen werden, in
die „External Key“-Applikation mussten dafür die zusätzlichen Slots definiert
werden. Die Applikation wurde ursprünglich als „TOI Special“ bezeichnet,
daher wird sie in der Konfigurationsdatei auch so genannt:
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
< allapplications >
< application id = " 0 x4101 " name = " TOI Special " aid = " 0 xD2 ,0 x76 ,0 x00 ,0 x01 ,0
x05 ,0 x00 ,0 x02 " access = " " >
< sk_pk_certs text = " Encryption Recoverbar 01 " >
< cert id = " 0 x4352 " label = " EF . C . CH . CSP3 " access = " WEON " / >
< pk id = " 0 x4E03 " label = " EF . PK . CH . CSP3 " access = " WEO " / >
< sk id = " 0 x5103 " label = " EF . SK . CH . CSP3 " access = " WEO " ii = " 0 x00 " ik = " 0
x83 " ip = " 0 x5000 " / >
</ sk_pk_certs >
< sk_pk_certs text = " Encryption Recoverbar 02 " >
< cert id = " 0 x4353 " label = " EF . C . CH . CSP4 " access = " WEO " / >
< pk id = " 0 x4E04 " label = " EF . PK . CH . CSP4 " access = " WEO " / >
< sk id = " 0 x5104 " label = " EF . SK . CH . CSP4 " access = " WEO " ii = " 0 x00 " ik = " 0
x84 " ip = " 0 x5000 " / >
</ sk_pk_certs >
< sk_pk_certs text = " Encryption Recoverbar 03 " >
< cert id = " 0 x4354 " label = " EF . C . CH . CSP5 " access = " WEO " / >
< pk id = " 0 x4E05 " label = " EF . PK . CH . CSP5 " access = " WEO " / >
< sk id = " 0 x5105 " label = " EF . SK . CH . CSP5 " access = " WEO " ii = " 0 x00 " ik = " 0
x85 " ip = " 0 x5000 " / >
</ sk_pk_certs >
</ application >
< application id = " 0 xDF01 " name = " NKS V2 .2 " aid = " 0 xD2 ,0 x76 ,0 x00 ,0 x00 ,0 x03 ,0
x01 ,0 x02 " access = " C " >
< sk_pk_certs text = " Netkey Logon - Certificate " >
< cert id = " 0 x43b1 " label = " EF . C . CH . CSP1 " access = " WSEDL " / >
< pk id = " 0 x45b1 " label = " EF . PK . CH . CSP1 " access = " SE " / >
< sk id = " 0 x53b1 " label = " EF . SK . CH . CSP1 " access = " SE " ii = " 0 x00 " ik = " 0 x81
" ip = " 0 x5000 " / >
</ sk_pk_certs >
< sk_pk_certs text = " Netkey Sign - Certificate " >
< cert id = " 0 x4331 " label = " EF . C . CH . CSP2 " aid = " 0 xD2 ,0 x76 ,0 x00 ,0 x00 ,0 x03
,0 x01 ,0 x02 " access = " WSOM " / >
< pk id = " 0 x4531 " label = " EF . PK . CH . CSP2 " access = " S " / >
< sk id = " 0 x5331 " label = " EF . SK . CH . CSP2 " access = " S " ii = " 0 x00 " ik = " 0 x80 "
ip = " 0 x5000 " / >
</ sk_pk_certs >
</ application >
</ allapplications >
</ card >
Zeile 14 beschreibt die „External Key“-Applikation. Der Application-Identifier
(AID) der Applikation lautet 0xD276000105000 und ist auf der Smartcard unter der File-ID 0x4101 zu finden. Ein solcher AID dient der weltweit eindeutigen Identifikation einer Applikation. Er besteht aus einem 5 Byte großen RID
und einer optionalen, bis zu 9 Byte großen PIX (siehe ISO/IEC 7816-5). Der
72
7.5 Anpassungen an den Clients
RID (Registered Identifier) ist eine von nationalen oder international Behörden vergebe Identifikationsnummer, die aus Informationen über das Herstellungsland, der Kategorie der Anwendung und einer Nummer zur eindeutigen Identifizierung des Herstellers besteht. Die PIX (Proprietary Application
Identifier Extension) kann vom Kartenhersteller benutzt werden, um eigene
Applikationen zu unterscheiden; bei dieser Applikation wurde für die PIX der
Wert 0x0002 gewählt.
Die nachfolgenden Zeilen beschreiben die Speicherplätze für die bis zu drei
Verschlüsselungszertifikate, die in der Applikation gespeichert werden können. Ein Speicherplatz wird durch das XML-Tag „sk_pk_certs“ eingeleitet.
Nachfolgend werden die File-IDs für das Zertifikat („cert“), den öffentlichen
(„pk“) und den privaten Schlüssel („sk“) definiert (z.B. Zeilen 16-18). Dabei
erhält jeder Slot eine Kennzeichnung („label“), damit die Anwendung, die mit
dem CSP kommuniziert, den gewünschten Datensatz referenzieren kann. Der
Eintrag zum geheimen Schlüssel enthält zusätzlich Informationen, unter welcher File-ID auf der Smartcard die zur Authentifizierung des Zugriffs benötigte PIN geprüft wird (hier unter der File-ID 0x5000).
Die durch die beiden zusätzlichen „sk_pk_certs“-Einträge (Zeilen 20-29) erweiterte Konfigurationsdatei kann nun verwendet werden, um auf die zusätzlichen Verschlüsselungszertifikate zuzugreifen. Dabei ist es kein Problem,
wenn diese zusätzlichen Slots nicht belegt sind: Der TCSP prüft bei jedem Aufruf, welche Zertifikate vorhanden sind, und meldet auch nur diese an die aufrufende Anwendung zurück.
73
8 Proof-of-Concept
Nachdem die notwendigen Anpassungen zur Umsetzung der Keyhistory auf
Smartcards innerhalb der T-Online PKI ermittelt und implementiert wurden,
konnten die im Folgenden aufgeführten erste Tests und Prüfungen der Schnittstellen in Angriff genommen werden. Im weiteren Verlauf des Kapitels wird
die Migration zur neuen Lösung beschrieben. Abschließend werden die bisherigen Erfahrungen bei der Umsetzung und im Betrieb erläutert.
8.1 Testphase
In der Testphase wurde eine vom Aufbau her identische CA betrieben, um
Tests unter möglichst realen Bedingungen durchführen zu können. Dafür wurde auch ein zusätzlicher Test-Arbeitsplatz für die Registratur bei T-Online aufgebaut, der den später im Betrieb einzusetzenden Rechnern gleicht. An diesem
Rechner wurden auch bereits die neuen Smartcardreader mit USB-Anschluss
verwendet. Die Anpassungen an den Client-Arbeitsplätzen wurden beispielhaft an einem Standard-Arbeitsplatz getestet.
8.1.1 Test des angepassten CSP
Beim Test des auf den Client-Arbeitsplatzrechnern eingesetzten T-CSP war es
besonders wichtig, die Funktion des CSP nicht nur mit den neuen, sondern
auch den alten Smartcards zu überprüfen, denn die Verlängerung der Smartcards ist ein längerer Prozess, während dem ein Parallelbetrieb von alten und
neuen Smartcards möglich sein muss. Einen Auszug der wichtigsten Punkte
aus dem Prüfprotokoll zeigt Tabelle 8.1.
Die bei T-Online eingesetzte VPN-Lösung nutzt zur Authentifikation ebenfalls ein Zertifikat auf den Smartcards (das Authentifikationszertifikat), benutzt zum Zugriff darauf allerdings nicht die CSP-Schnittstelle, sondern greift
am CSP vorbei direkt auf die Smartcard zu. Bei Tests kam es bei solchen konkurrierenden Zugriffen zu Problemen, so dass entweder die VPN-Software
oder der T-CSP nicht mehr auf die Karte zugreifen konnte. Problem war, dass
ein alter, ganz zu Beginn des Rollouts 2003 eingesetzter Smartcard-Typ in der
Konfigurationsdatei für den CSP nicht mehr eingetragen war. Dies führte dazu, dass der T-CSP den Zugriff auf Karten dieses Typs komplett blockierte.
75
8 Proof-of-Concept
Der Fehler wurde behoben, indem in der Konfigurationsdatei wieder dieser
alte Kartentyp eingetragen wurde.
Des Weiteren musste das Verhalten der auf den CSP zugreifenden Anwendungen überprüft werden. Dadurch, dass bestehende, alte Verschlüsselungszertifikate bei der Verlängerung auf einen anderen Slot gespeichert werden,
kommt es bei jeder Verlängerung zu einer Positionsverschiebung von Verschlüsselungszertifikaten auf der Smartcard. Tests haben gezeigt, dass dabei
die alten Verweise vom Windows-Zertifikatsspeicher auf die bisherigen Verschlüsselungszertifikate auf der Smartcard nicht gelöscht werden und es daher
Fehler beim Zugriff auf diese Zertifikate gibt (d.h. die alten Zertifikate werden
auf der Smartcard nicht gefunden). Es ist also erforderlich, vor Nutzung der
neuen Smartcard die alten Referenzen auf Smartcard-Zertifikate im WindowsZertifikatsspeicher zu löschen.
Ebenso müssen die neuen Signatur- und Verschlüsselungszertifikate in Microsoft Outlook und Kobil File-Security ausgewählt werden. Zwar nutzt Outlook automatisch die neuen Zertifikate, sobald die alten Zertifikate abgelaufen
sind. Haben die alten Verschlüsselungszertifikate allerdings noch nicht Ihre
Gültigkeit verloren, so werden diese weiterhin beim Versand von signierten
oder verschlüsselten E-Mails mitgeschickt, was nicht wünschenswert ist. Auch
werden die neuen Zertifikate nicht in den Outlook-Sicherheitseinstellungen
eingetragen. Würde beim E-Mail-Versand versehentlich nochmals eine alte
Smartcard genutzt, so würden auch in diesem Fall die alten Zertifikate verwendet. Es ist also sinnvoll, diese Einstellungen anzupassen. Bei der Filesecurity hingegen ist es unerlässlich, Verschlüsselungs- und Signaturzertifikat
neu auszuwählen, andernfalls verweigert die Applikation Signatur- bzw. Verschlüsselungsaktionen, weil Sie die eingestellten Zertifikate nicht finden kann.
Zum Löschen der Zertifikate aus dem Zertifikatsspeicher und den notwendigen Einstellungen wird zusammen mit verlängerten Smartcards ein Flyer
ausgegeben, der diese nur vom Anwender selbst durchführbaren Aufgaben
Schritt für Schritt erläutert.
8.1.2 Prüfung der RA-Schnittstelle
Aufgrund der Änderungen am Trustcenter und an der Webschnittstelle zur
Registration Authority wurden alle bereits vorher bestehenden Funktionen
der Webschnittstelle und insbesondere die Neuerungen ausführlich getestet
(Auszüge der wichtigsten Punkten siehe Tabelle 8.2). Im Folgenden werden
die bei Tests aufgedeckten Fehler erläutert und deren Behebung geschildert.
Bei Prüfung der Wiederherstellungsfunktionen der Webschnittstelle wurde
festgestellt, dass im Fehlerfall kein Keybackup wiederhergestellt wurde. Wenn
z.B. die RecoveryAdmin-Smartcard nicht im dafür vorgesehenen Smartcardreader steckte, so wurde der Wiederherstellungsvorgang abgebrochen. Auch
76
8.1 Testphase
Tabelle 8.1: Auszug aus dem Prüfprotokoll des T-CSP
Test
Erwartetes Ergebnis
Testergebnis
Verwendung
einer Authentifikationszertifikat OK
bisherigen Smartcard nutzbar, Signaturzertifikat
nutzbar,
Verschlüsselungszertifikat
nutzbar,
PIN lässt sich ändern,
Karte lässt sich mit PUK
freischalten.
Verwendung
ei- Authentifikationszertifikat OK
ner Smartcard mit nutzbar, Signaturzertifikat
Keyhistory
nutzbar, Verschlüsselungszertifikate Slot 1 bis Slot
3 nutzbar, PIN lässt sich
ändern, Karte lässt sich
mit PUK freischalten.
Nutzung der VPN- Paralleler Einsatz von OK (nach AnpassunSoftware
VPN-Authentifikation
gen, siehe Text)
und Nutzung der Smartcard mit dem TCSP ist
möglich.
Wechsel bei Verlän- Wird eine verlängerte Löschen der Zertifigerung
Smartcard
ausgegeben, kate im Windowsdann ist der Zugriff auf Zertifikatspeicher
neue und alte Verschlüs- und
Prüfung
selungszertifikate
ohne der
OutlookAnpassungen möglich.
Sicherheitssowie
der
File-SecurityEinstellungen
notwendig (siehe Text).
77
8 Proof-of-Concept
bei Falscheingabe der PIN wurde diese nicht wieder angefordert. Um das Problem zu beseitigen, wurde im VBScript-Code der Webseite eine Programmschleife um den Aufruf der für die Wiederherstellung von Keybackups verwendeten ActiveX-Komponente gelegt, die im Fehlerfall den jeweiligen Fehler
anzeigt und auch eine Wiederholung der Aktion ermöglicht.
Beim Wiederherstellen von Zertifikaten über die neu in die Webschnittstelle
integrierte Funktion „Zertifikate wiederherstellen“ wurden die Slots der Zielkarten nicht wie ausgewählt beschrieben. Dieser Fehler entstand durch unterschiedliche Zählweisen bei der Vergabe der Slotnummern (es wurde mit 1 statt
mit 0 begonnen zu zählen) und die fehlerhafte Nutzung einer Funktion zur relativen Adressierung der zu benutzenden Slots. Dieser Fehler konnte durch
kleine Korrekturen im VBScript-Code der Webseite korrigiert werden.
Tabelle 8.2: Auszug aus dem Prüfprotokoll der RA-Schnittstelle
Test
Erwartetes Ergebnis
Testergebnis
Administrative Tätigkeiten bzgl. des Trustcenters
Umschlüsselung der Backup-File kann über OK (Sperrung des
Backups
die
Web-Schnittstelle Beantragungsproangefordert
werden, zesses ist allerdings
Beantragungsprozess
noch nicht impleist dann gesperrt, Um- mentiert)
schlüsselung mit Kobil
File-Security bei T-Online
funktioniert, Umgeschlüsselte Files können in die
Backup-DB hochgeladen
werden, Hochgeladener
File wird in die Backup-DB
korrekt integriert, Mit neuem
Recovery-Zertifikat
können die regulären
Beantragungsprozesse
durchgeführt
werden,
Mit neuem RecoveryZertifikat können alte
Backups wiederhergestellt
werden
78
8.1 Testphase
(Fortsetzung Tabelle 8.2)
Test
Erwartetes Ergebnis
Testergebnis
Funktionalität der RA-Software
Recovery-Zertifikat
Das
Recovery-Zertifikat OK
hinterlegen
kann hinterlegt werden,
Das
Recovery-Zertifikat
wird
erfolgreich
zur
Verschlüsselung
von
Passwort-Datei
und
Keybackup-Datei verwendet
Aufbringen der alten Die
alten
Zertifikate OK (Fehler bei nicht
Schlüssel/Zertifikate werden auf die Karte gesteckter Recoveryaufgebracht,
Backups Karte wurde korriwerden korrekt wegge- giert (siehe Text).
schrieben, P12-File wird
korrekt
verschlüsselt
und in die Datenbank
der TeleSec geschrieben,
Passwort-File wird korrekt
verschlüsselt und auf das
T-Online
Netzlaufwerk
weggeschrieben
Beantragung von Zertifikaten bei Namensänderung
Input-Prüfung alte E- Bei falschen Eingaben, z.B. OK
Mail-Adresse
Name@@Domain wird darauf hingewiesen und die
Null-Pin der Karte wird
noch nicht gebrochen
Erstellung von Zerti- Bei korrekter Eingabe OK
fikaten
werden Zertifikate erzeugt
und auf die Karte geschrieben, Aufbringen der alten
Schlüssel/Zertifikate, Die
alten Zertifikate zur alten
E-Mail Adresse werden
auf die Karte aufgebracht.
79
8 Proof-of-Concept
(Fortsetzung Tabelle 8.2)
Test
Erwartetes Ergebnis
Testergebnis
Backups werden kor- P12-File wird korrekt OK
rekt weggeschrieben verschlüsselt und in die
Datenbank der TeleSec
geschrieben, Passwort-File
wird korrekt verschlüsselt
und auf das T-Online
Netzlaufwerk
weggeschrieben, Die Zertifikate
zur alten E-Mail-Adresse
werden in der BackupDatenbank bei der TeleSec
korrekt der neuen E-MailAdresse zugeordnet
Zertifikate wiederherstellen: Nachträgliches Aufbringen von Backups
Auswahl
der Eine oder mehrere E- OK
Backups
Mail-Adressen
können
eingegeben
werden,
Nach Absenden der EMail-Adressen
werden
die möglichen Backups
angezeigt, Backups können Slots auf der Karte
zugeordnet werden
Aufbringen
der Es wird die PIN der Karte OK
(Anfänglich
Backups
abgefragt, Die Backups wurden
Zertifikawerden erfolgreich in te in falsche Slots
die angegebenen Slots geschrieben;
diegeschrieben
ser Fehler wurde
behoben, siehe Text).
Zertifikate wiederherstellen: Erstellung reine Backup-Karte
Auswahl
der Eine oder mehrere E- OK
Backups
Mail-Adressen
können
eingegeben
werden,
Nach Absenden der EMail-Adressen
werden
die möglichen Backups
angezeigt, Backups können Slots auf der Karte
zugeordnet werden
80
8.2 Migration
Test
Aufbringen
Backups
der
PIN-Handling
(Fortsetzung Tabelle 8.2)
Erwartetes Ergebnis
Es wird eine PIN für
die Karte erzeugt, Die
Backups werden erfolgreich in die angegebenen
Slots geschrieben
PIN-Brief wird ordnungsgemäß gedruckt, PIN der
Karte kann mit TCSP geändert werden.
Testergebnis
OK
(Anfänglich
wurden
Zertifikate in falsche Slots
geschrieben;
dieser Fehler wurde
behoben, siehe Text).
OK
8.2 Migration
Die Migration zur angepassten und erweiterten PKI-Lösung wurde zeitgleich
im Trustcenter und bei T-Online durchgeführt. In der Vorbereitung zur Migration wurden im Trustcenter zunächst Backups von den bisherigen Systemen
(Webserver, Datenbankserver, LDAP-Server) erstellt, um diese bei Schwierigkeiten während der Migration wiederherstellen zu können. Bei T-Online wurden entsprechend dem im Test benutzten Registrator-Arbeitsplatzrechner drei
neue Rechner vorkonfiguriert; davon zwei für den Betrieb, einer als Migrationsrechner. Des Weiteren wurde aus Sicherheitsgründen ein Backup der auf
einem Netzlaufwerk gespeicherten, zur Wiederherstellung von Keybackups
benötigten Passwort-Dateien angelegt.
Trustcenter
Die Migration begann mit dem Aufspielen der neuen Software im Trustcenter.
Dazu war ein Installationspaket erstellt worden, welches die notwendigen Änderungen an Datenbankschema, Webseiten und Scripten durchführte. Die Abarbeitung der Änderungen wurde dabei protokolliert und durch das Personal
des Trustcenters überwacht. Nach der Erfolgmeldung der Umstellung durch
das Trustcenter konnte die Umschlüsselung der Keybackups vorgenommen
werden.
Umschlüsselung der Keybackups
Zunächst wurde der Migrationsrechner bei T-Online in Betrieb genommen.
Der Migrationsrechner wurde speziell zur Umschlüsselung der Keybackups
und Erstellung eines neuen RecoveryAdmin-Zertifikats benötigt. Da die Gefahr bestand, dass nach den Arbeiten an diesem Rechner Spuren der hochsen-
81
8 Proof-of-Concept
siblen vertraulichen Schlüsseldaten zurückbleiben, musste die Festplatte des
Rechners anschließend mit einem sicheren Verfahren (siehe [Arb04]) gelöscht
werden.
Zunächst wurde am Migrationsrechner über die Webschnittstelle des Trustcenters das ZIP-Archiv mit allen dort gespeicherten Keybackups heruntergeladen. Die Keybackups wurden unter Verwendung der alten RecoveryAdminZertifikate und der bei T-Online auf einem Netzlaufwerk verschlüsselt abgelegten Passwortdateien mit Hilfe der File-Security-Software entschlüsselt. Anschließend wurde ein neues RecoveryAdmin-Zertifikat beantragt, in Form einer PKCS#12-Datei lokal gespeichert und auf drei Smartcards sowie eine CDROM gespeichert. Die zwei zusätzlichen Smartcards und die CD-ROM werden
für die Wiederherstellung in Notfällen benötigt und wurden in einem Bankschließfach hinterlegt. Die mittlerweile entschlüsselt vorliegenden PKCS#12Schlüsseldaten und Passwort-Dateien wurden dann unter Verwendung der
File-Security-Software mit dem neuen RecoveryAdmin-Zertifikat verschlüsselt. Die Keybackup-Dateien wurden in einem ZIP-Archiv zusammengefasst
und über die Webschnittstelle wieder in das Trustcenter hochgeladen. Dort
wurden die Keybackups wieder in die Datenbank integriert. Die umgeschlüsselten Passwort-Dateien wurden auf das dafür vorgesehene Netzlaufwerk kopiert. Nach stichprobenartiger Prüfung des Zugriffs auf die Keybackups über
die neue Funktion „Zertifikate wiederherstellen“ der Webschnittstelle konnte
von einer erfolgreichen Migration ausgegangen werden und die Festplatte des
Migrationsrechners wurde, wie oben bereits erwähnt, sicher gelöscht.
Manuelles Einpflegen bisheriger Namensänderungen
Um die im bisherigen Betrieb bereits aufgetretenen Namensänderungen (z.B.
durch Heirat oder Wechsel von/zu einem Tochterunternehmen) abzubilden,
wurden die notwendigen Informationen aus der im Accountmanagement vorliegenden Historie extrahiert und in die Datenbank integriert. Somit werden
bei Verlängerungen der Zertifikate von betroffenen Personen alle bereits für
Sie bestehenden Keybackups wiederhergestellt, auch wenn diese eine andere
E-Mail-Adresse enthalten.
Übergabe in den Wirkbetrieb
Das System wurde nach Abschluss der Migrationsarbeiten in den Wirkbetrieb
übergeben. Die beiden vorbereiteten Registrator-Arbeitsplatzrechner wurden
mit jeweils drei Smartcardreadern ausgestattet und installiert. Die zur Nutzung durch das Personal des Accountmanagements erforderliche Registrierung der Registrator-Zertifikate im Windows-Zertifikatspeicher wurde durchgeführt und das Personal wurde eingewiesen.
82
8.3 Ergebnis
Verlängerte Zertifikate wurden immer 2 bis 4 Wochen vor Ablauf der alten
Zertifikate erstellt. Die Zahl der zu erstellenden, verlängerten Ausweise wurde
dabei zunächst gering gehalten (max. 30 Verlängerungen pro Woche), um die
Auswirkungen eventuell vorhandener, verborgener Fehler in der veränderten
PKI-Lösung zu minimieren. Nach und nach konnte die Zahl der erstellten
Smartcards auf bis zu 120 Stück wöchentlich erhöht werden. Nennenswerte
Fehler sind hierbei nicht mehr aufgetreten.
8.3 Ergebnis
Die angepasste und erweiterte PKI-Lösung ist bei T-Online mittlerweile einige Monate in Betrieb, und so konnten erste Erfahrungen im Betrieb einer
Keyhistory-Lösung auf Smartcards gemacht werden.
Dadurch, dass neue Smartcards immer mindestens zwei Wochen vor Ablauf
der alten Zertifikate ausgegeben werden und bei Ausgabe nur minimale Anpassungen an den Client-Rechnern durchgeführt werden müssen, kommt ein
für den Anwender nahezu transparenter, unterbrechungsfreier Übergang zu
den neuen Zertifikaten zustande.
Auch das Roaming innerhalb des Unternehmens ist durch flächendeckende Verfügbarkeit von Smartcardreadern und CSP mit den Smartcards möglich; allerdings muss der User an allen Rechnern, an denen er zuvor eine alte
Smartcard genutzt hat, die entsprechenden Schritte zur Nutzung der neuen
Smartcard durchführen.
Durch die Anwendungsunabhängigkeit der Verschlüsselung mittels X.509Zertifikaten können unterschiedlichste Applikationen Vertraulichkeit für nahezu beliebige Daten realisieren. Voraussetzung ist die Nutzung des integrierten Windows-Zertifikatspeichers oder der direkte Zugriff auf die Smartcard
(auch unter anderen Betriebssystemen möglich).
Die Weiternutzung von bereits vorhandenem Schlüsselmaterial ist durch
das Verfahren gewährleistet, außer der einmaligen Umschlüsselung aller Keybackups und dem Einpflegen von Namensänderungen waren auch keine weiteren Migrationsschritte notwendig.
Eine zeit- und personalaufwändige Umschlüsselung von E-Mails oder Dateien bei Verlängerungen oder Defekten von Smartcards kann auf längere Sicht
entfallen. Auch ist das Erstellen einer Backupkarte in der Regel nicht mehr notwendig, denn das Backup der alten/defekten Smartcard wird in diesem Verfahren automatisch mit auf die neue Smartcard aufgebracht. Auf längere Sicht
stellt dieses Verfahren allerdings keine vollständige Lösung des Problems dar,
denn der auf den Smartcards zur Verfügung stehende Speicherplatz ist begrenzt, und so muss vermutlich spätestens 2012 (wenn der vierte Verschlüsselungsschlüssel mit drei Jahren Gültigkeit erstellt wird) bei Verlängerungen
umgeschlüsselt werden. Abgeschwächt wird das Problem allerdings dadurch,
83
8 Proof-of-Concept
dass dann zumindest ein Großteil der E-Mails aus den Jahren 2003 bis 2006
nicht mehr für den direkten Zugriff benötigt werden, und nur bei wirklichem
Bedarf z.B. eine Backupkarte erstellt werden muss. Außerdem könnten dann
die bereits erhältlichen NetKey 3.0 Smartcards zum Einsatz kommen, die größeren Speicherplatz (72 KB) bieten. Zu bedenken ist dann, dass das Einlesen
einer vollgepackten Smartcard unter Umständen deutlich länger dauert – darunter würde wiederum die Akzeptanz der Smartcard leiden.
Die Änderungen an der Webschnittstelle zum Trustcenter und an den Prozessen zur Ausgabe, Verlängerung usw. halten sich in Grenzen, so musste z.B.
die Bedienung der Registratur nur leicht modifiziert werden. Beides erleichtert den Umstieg sowohl für das Personal des Accountmanagements als auch
für die Mitarbeiter. Zusätzlich wurde durch die Integration der Wiederherstellungsfunktionen in die Webschnittstelle die Bedienung für die Registratoren
vereinfacht.
Die Betriebskosten konnten durch geringere Kosten bei Austausch von defekten Smartcards gesenkt werden (es muss nur noch eine Smartcard erstellt
werden und eine Umschlüsselung kann entfallen). Vor allem aber konnte bei
der Verlängerung der ca. 2000 Smartcards der T-Online Mitarbeiter komplett
auf die aufwändige Umschlüsselung verzichtet werden, was vermutlich sehr
hohe Kosten produziert hätte. Auch der Aufwand für die Service-Abteilung
hat abgenommen, weil in der Vergangenheit öfters aufgetretene Verwechslungen von Smartcards oder PIN/PUK-Briefen bei Personen, die eine oder sogar
zwei Backupkarten nutzten, durch die Reduktion auf in der Regel eine Smartcard pro Mitarbeiter seltener geworden sind.
Zwar ist die Aufgabe des 4-Augen-Prinzips ein nicht zu vernachlässigender
Einschnitt in die Sicherheit der Keybackups, es sind jedoch erste Anzeichen
auszumachen, dass die Akzeptanz durch die Steigerung der Bedienbarkeit
(keine Umschlüsselung mehr, alles auf einer Smartcard, unproblematischer
Kartenwechsel bei der Verlängerung) zunimmt, und somit auch die Sicherheit sensitiver Daten im Unternehmen gesteigert werden kann. Auf der anderen Seite ist ein gewisser Kontrollverlust bezüglich der Wiederherstellung von
Keybackups durch den Verzicht auf eine zweite RecoveryAdmin-Smartcard
sowie die erweiterte Funktionalität der Webschnittstelle zu verzeichnen, der
höheres Vertrauen von Vorgesetzten und Mitarbeitern in das Personal der Registration Authority erfordert. Darüber hinaus wurde festgestellt, dass die Erweiterung der Benachrichtigungsfunktionen des Trustcenters zur Verbesserung der Sicherheit gegenüber der bisherigen Lösung beiträgt, denn bis zur
Umstellung wurden die Inhaber von im Trustcenter gesicherten Verschlüsselungszertifikaten nicht automatisch über die Wiederherstellung Ihrer Keybackups benachrichtigt.
Zusammenfassend kann die Aussage getroffen werden, dass die Umsetzung
einer „Keyhistory auf Smartcards“ für das Szenario bei T-Online insgesamt
eine gute Lösung ist. Zwar bleiben als Wermutstropfen die zu erwartenden
84
8.3 Ergebnis
Schwierigkeiten wenn der Platz auf den Smartcards nicht mehr ausreicht und
die höheren Anforderungen an das Personal der Registration Authority. Der
betriebene Aufwand ist jedoch im geforderten Rahmen geblieben, der mit hohen Kosten behaftete Aufwand für Umschlüsselungen während der umfangreichen Verlängerungen konnte gar komplett entfallen. Darüber hinaus wurde
die Akzeptanz bei den Mitarbeitern gesteigert, Kompromisse bei der Sicherheit werden so durch breitere Nutzung der Smartcard weitestgehend wettgemacht.
85
9 Fazit
Ausgehend von der nicht zufriedenstellenden Praxis, bei Schlüsselwechsel in
Smartcard-basierten PKI-Lösungen eine Umschlüsselung aller Daten durchzuführen, wurde nach anderen Lösungsansätzen für die Problematik des längerfristigen Zugriffs auf verschlüsselte Daten gesucht. Die gefundenen Lösungen
wurden vorgestellt und diskutiert. Nach eingehender Vorstellung der eingesetzten PKI musste festgestellt werden, dass keines der bekannten Verfahren
eine in allen Punkten optimale Lösung für die ausstehende Verlängerung der
Mitarbeiterzertifikate bei T-Online darstellt.
Im Rahmen einer Nutzwertanalyse wurden Kriterien zur Bewertung von
Verfahren zur längerfristigen Verfügbarkeit von verschlüsselten Daten erarbeitet und anhand der spezifischen Vorraussetzungen und Anforderungen bei
T-Online gewichtet. Im Ergebnis wurde mit der „Keyhistory auf Smartcards“,
wie im vorigen Kapitel zu lesen war, eine passende Lösung gefunden.
Wenn man die ungewichtete Bewertung der Verfahren in Tabelle 6.2 analysiert, und dabei die Kriterien zur Umsetzung außer Betracht lässt, so wird
deutlich, dass unter allgemeinen Gesichtspunkten die Lösung „Managed Decryption“ mit 28 Punkten nahezu gleichauf mit der für T-Online gewählten
„Keyhistory auf Smartcards“ mit 30 Punkten liegt. Eine solche Client/Serverbasierte PKI-Lösung bietet entscheidende Vorteile bezüglich der Usability und
Transparenz. Das sind beides Faktoren, die bei den meisten bisher im Einsatz
befindlichen PKI-Lösungen nicht ausreichend Beachtung finden (siehe dazu
auch [Str05]), was zu mangelnder Akzeptanz bei den Usern führt.
Wird „Managed Decryption“ noch zusätzlich kombiniert mit einer rein serverbasierten Entschlüsselung (d.h. der Schlüssel verlässt den Server nie) und
starker Authentifizierung (z.B. per Smartcard), so kann die Managed Decryption durchaus erste Wahl für Neuplanungen von unternehmensweiten PKILösungen sein. Die auch bei den Keyhistory-Lösungen vorhandene Schlüsselproblematik wird so komplett auf einen Server ausgelagert. Damit können
Benutzer Ihre Schlüssel nicht mehr verlieren, die Schlüssel können nicht kompromittiert werden (solange der Server ausreichende Sicherheit bietet), und
auch Roaming ist grundsätzlich möglich. Somit bietet sich „Managed Decryption“ auch als Lösung für die weit verbreiteten Webmail-Dienste an, die Ihren
Kunden bisher zum größten Teil keine Verschlüsselungsfunktionen anbieten.
Für Zertifikate, die ausschließlich zur Signatur oder Authentifikation verwendet werden, müssen nach wie vor Security-Token wie z.B. Smartcards als
die einzig wirklich sicheren Medien zur Aufbewahrung von privaten Schlüs-
87
9 Fazit
seln angesehen werden. Dienen Zertifikate zur Authentifizierung von Entschlüsselungsvorgängen (wie z.B. bei einer „Managed Decryption“-Lösung),
so sollten auch nur diese Medien in Betracht gezogen werden.
Die Komplexität von X.509-basierten PKI-Lösungen lässt sich leider nicht
wesentlich reduzieren, man kann nur versuchen, möglichst viel davon vom
Anwender fernzuhalten. Dies erlaubt dem Anwender, sich auf die wesentlichen Operationen zu konzentrieren, und eine PKI auch ohne tiefes Verständnis
der internen Abläufe sicher zu bedienen. Praktikable Lösungen zur längerfristigen Verfügbarkeit von verschlüsselten Daten, wie sie im Rahmen dieser Diplomarbeit vorgestellt wurden, unterstützen die Transparenz und Bedienbarkeit von X.509-basierter Verschlüsselung und unterstützen so die Akzeptanz
von moderner Kryptographie im Alltag.
88
A Literaturverzeichnis
[Arb04] A RBEITSKREIS „T ECHNISCHE UND ORGANISATORISCHE D ATEN SCHUTZFRAGEN “ DER K ONFERENZ DER D ATENSCHUTZBEAUF TRAGTEN DES B UNDES UND DER L ÄNDER : Orientierungshilfe „Sicheres
Löschen magnetischer Datenträger“, Oktober 2004.
[Buc04] B UCHMANN , J OHANNES: Einführung in die Kryptographie. SpringerVerlag Berlin, 3., erweiterte Auflage, 2004.
[DA06] D IRK A RNOLD , R ALF K UNOTH: Betriebshandbuch Mailumschlüsselung
für Outlook (UfO). fun communications GmbH, Karlsruhe, Juni 2006.
[Eck06] E CKERT, C LAUDIA: IT-Sicherheit. Konzepte - Verfahren - Protokolle. Oldenbourg Wissenschaftsverlag, 4.,überarbeitete Auflage, 2006.
[fun06]
G MB H: Betriebshandbuch T-Online Cryptographic Service Provider (TCSP) Version 0.55.0044, Juni 2006.
[Int97]
T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 2251:
Lightweight Directory Access Protocol (v3), Dezember 1997.
[Int98]
T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 2401:
Security Architecture for the Internet Protocol, November 1998.
FUN COMMUNICATIONS
[Int99a] T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 2560:
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol
- OCSP, Juni 1999.
[Int99b] T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 2661:
Layer Two Tunneling Protocol „L2TP“, August 1999.
[Int01]
T HE I NTERNET S OCIETY: RFC 3174: US Secure Hash Algorithm 1
(SHA1), September 2001.
[Int02]
T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 3280:
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.
[Int04a] T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 3850:
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling, Juli 2004.
89
A Literaturverzeichnis
[Int04b] T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 3851:
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
Message Specification, Juli 2004.
[Int05]
T HE I NTERNET S OCIETY, N ETWORK W ORKING G ROUP: RFC 4155:
The application/mbox Media Type, September 2005.
[Int06]
T HE I NTERNET S OCIETY: RFC 4398: Storing Certificates in the Domain
Name System (DNS), März 2006.
[it-05]
IT-Grundschutz-Kalaloge. Bundesanzeiger Verlag, 7. Auflage, 2005.
[Kob06] K OBIL S YSTEMS G MB H: T-Online RA Erweiterung: Spezifikation OCX
Control Version 1.1, Juni 2006.
[Koc06] K OCH , W ERNER: Public Key Association. Technischer Bericht, g10 Code, Februar 2006.
[Lil92]
L ILLICH , L OTHAR: Nutzwertverfahren. Physica-Verlag Heidelberg,
1992.
[RSA93] RSA L ABRATORIES: PKCS #7 v1.5: Cryptographic Message Syntax Standard, November 1993.
[RSA99] RSA L ABRATORIES: PKCS #12 v1.0: Personal Information Exchange
Syntax, Juni 1999.
[RSA00] RSA L ABRATORIES: PKCS #10 v1.7: Certification Request Syntax Standard, Mai 2000.
[RSA02] RSA L ABRATORIES: PKCS #1 v2.1: RSA Cryptography Standard, Juni
2002.
[RSA04] RSA L ABRATORIES: PKCS #11 v2.20: Cryptographic Token Interface
Standard, Juni 2004.
[Sch96] S CHNEIER , B RUCE: Applied Cryptography. Wiley, 2. Auflage, 1996.
[Sch04] S CHMEH , K LAUS: Die Welt der geheimen Zeichen. W3L GmbH, 2004.
[Sha79] S HAMIR , A.: How to Share a Secret. ACM, 22(11):612–613, November
1979.
[sig05]
Gesetz über Rahmenbedingungen für elektronische Signaturen. BGBl. I
2005, Seite 1970, Juli 2005.
[Str05]
S TRAUB , T OBIAS: Usability Challenges of PKI. Doktorarbeit, TU Darmstadt, Dezember 2005.
90
A Literaturverzeichnis
[T-S04a] T-S YSTEMS I NTERNATIONAL G MB H, T-T ELE S EC: Kartenfunktionalität des Produktes E4 NetKey V2.0 / Produktnr. 723, September 2004.
[T-S04b] T-S YSTEMS I NTERNATIONAL G MB H, T-T ELE S EC: Struktur der Applikation NetKey (NKS V2.2), März 2004.
[Uni82] U NIVERSITY OF D ELAWARE: RFC 822: Standard for ARPA Internet Text
Messages, August 1982.
[Wöh04] W ÖHLER , U WE: Schlüsselverschlüssler. <kes> – Die Zeitschrift für
Informations-Sicherheit, (1):17, Januar 2004.
[Zan70] Z ANGEMEISTER , C HRISTOF: Nutzwertanalyse in der Systemtechnik.
Wittemann, 1970.
91
B Abbildungsverzeichnis
2.1
2.2
2.3
2.4
Symmetrische Verschlüsselung .
Asymmetrische Verschlüsselung
Hybride Verschlüsselung . . . . .
Digitale Signatur . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
9
5.1
5.2
5.3
Aufbau der T-Online Zertifikatshierarchie . . . . . . . . . . . . .
Logische Kartenstruktur vor der Umstellung der T-Online PKI .
Keybackup-Prozess vor der Umstellung der T-Online PKI . . .
36
38
43
7.1
7.2
7.3
7.4
7.5
7.6
Überarbeitetes Formular zur Beantragung . . . . . . . . . . . . .
Zusammenfassung der aufgebrachten Zertifikate . . . . . . . . .
Eingabeformular für die Erstellung einer Backupkarte . . . . . .
Zuordnung der Zertifikate zu den Slots auf der Smartcard . . .
Umschlüsselungsassistent . . . . . . . . . . . . . . . . . . . . . .
Logische Kartenstruktur nach Umstellung der T-Online PKI auf
das Keyhistory-Verfahren . . . . . . . . . . . . . . . . . . . . . .
63
64
65
66
67
71
93
C Tabellenverzeichnis
6.1
6.2
6.3
Paarweiser Vergleich der Kriterien zur Ermittlung der Gewichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bewertung der Verfahren . . . . . . . . . . . . . . . . . . . . . . .
Nutzwerte der Verfahren . . . . . . . . . . . . . . . . . . . . . . .
48
49
53
8.1
8.2
Auszug aus dem Prüfprotokoll des T-CSP . . . . . . . . . . . . .
Auszug aus dem Prüfprotokoll der RA-Schnittstelle . . . . . . .
77
78
95