Implementierung eines Selbstbedienungsclients für eine

Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet Theoretische Informatik - Kryptographie und Computeralgebra
Prof. Dr. Johannes Buchmann
Implementierung eines Selbstbedienungsclients für
eine dezentral administrierbare Trustcenter-Lösung
Diplomarbeit
von
Iskra Tomova
Studiengang: Informatik (Diplom)
Betreuer: Marcus Lippert (FlexSecure GmbH)
Dezember 2007
Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig und nur mit den
angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den
Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat
in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 21. Dezember 2007
Iskra Tomova
ii
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 ActiveX . . . . . . . . . . . . . . . .
2.1.1 Einbindung in Webseiten . . .
2.1.2 Zugriff auf ActiveX-Objekte .
2.1.3 Sicherheit . . . . . . . . . . .
2.1.4 Unterstützte Plattformen . . .
2.2 Applet . . . . . . . . . . . . . . . . .
2.2.1 Einbindung in Webseiten . . .
2.2.2 Kommunikation zwischen dem
2.2.3 Sicherheit . . . . . . . . . . .
2.2.4 Unterstützte Plattformen . . .
2.3 ActiveX versus Applets . . . . . . . .
2.4 Standardisierte Kartenschnittstellen .
2.4.1 PKCS#11 . . . . . . . . . . .
2.4.2 PC/SC . . . . . . . . . . . . .
2.4.3 OCF . . . . . . . . . . . . . .
3 Ist- und Soll-Analyse
3.1 FlexiTrust Identity Management . .
3.1.1 Komponentenüberblick . . .
3.1.2 Smartcardoperationen . . .
3.1.3 Die OCX-Komponente . . .
3.2 FlexCardAdmin . . . . . . . . . . .
3.2.1 Funktionale Anforderungen
3.2.2 Qualitätsanforderungen . . .
3.2.3 Sicherheitsanforderungen . .
.
.
.
.
.
.
.
.
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Applet und der
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Webseite
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
6
7
7
9
9
11
13
13
14
15
16
16
.
.
.
.
.
.
.
.
18
18
20
22
24
25
26
29
29
4 Designentstehung
31
4.1 Analyse des Frameworks SmartcardServices . . . . . . . . . . . . . . . . . 31
4.1.1 Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2 Kartenoperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
iii
Inhaltsverzeichnis
4.2
4.3
4.1.3 Referenzieren von Objekten auf der Karte . . . . . . .
Analyse der Kartenschnittstellen . . . . . . . . . . . . . . . . .
4.2.1 Anforderungen an die Umgebung . . . . . . . . . . . .
4.2.2 Auswahl der Kartenschnittstelle . . . . . . . . . . . . .
4.2.3 Auswahl des Kartenlesers . . . . . . . . . . . . . . . .
4.2.4 Auswahl der Chipkarte . . . . . . . . . . . . . . . . . .
4.2.5 Die Verknüpfung Kartenschnittstelle - Kartenoperation
Kommunikation mit dem Enrollment-Server . . . . . . . . . .
5 Technisches Konzept und Implementierung
5.1 Aufbau der Software . . . . . . . . . . . . . . . . . . . . .
5.2 Die Benutzeroberfläche . . . . . . . . . . . . . . . . . . . .
5.2.1 Wizard . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 WizardPanel . . . . . . . . . . . . . . . . . . . . .
5.2.3 WizardPanelDescriptor . . . . . . . . . . . . . . . .
5.3 Das Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Verwaltung der Kartenschnittstellendaten . . . . .
5.3.2 Verwaltung der Kartenleserdaten . . . . . . . . . .
5.3.3 Verwaltung der Smartcard-Daten . . . . . . . . . .
5.4 Der Controller . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Personalisieren einer Smartcard . . . . . . . . . . .
5.4.2 Entsperren der Smartcard . . . . . . . . . . . . . .
5.4.3 Löschen der Karteninhalte . . . . . . . . . . . . . .
5.4.4 PIN ändern . . . . . . . . . . . . . . . . . . . . . .
5.5 Schnittstelle zum Enrollment-Server . . . . . . . . . . . . .
5.5.1 Allgemeine Applet-Parameter . . . . . . . . . . . .
5.5.2 Datenaustausch bei der Smartcard-Personalisierung
5.5.3 Zertifikat auslesen . . . . . . . . . . . . . . . . . . .
5.6 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Allgemeine Parameter . . . . . . . . . . . . . . . .
5.6.2 Kartenlesertreiber . . . . . . . . . . . . . . . . . . .
5.6.3 Referenzen auf Kartenobjekten . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
35
37
38
39
40
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
44
45
47
49
49
53
53
54
54
58
58
58
58
59
59
62
62
62
68
69
6 Zusammenfassung
72
7 Ausblick
7.1 Weiterentwicklung der Software . . . . . . . . . . . .
7.1.1 Hinzufügen neuer Karten . . . . . . . . . . . .
7.1.2 Hinzufügen neuer Kartenschnittstellen . . . .
7.1.3 Hinzufügen neuer Kartenleser . . . . . . . . .
7.1.4 Hinzufügen neuer Sprachen . . . . . . . . . .
7.1.5 Hinzufügen neuer Betriebssysteme . . . . . . .
7.1.6 Das Applet als eigenständige Webanwendung
74
74
74
75
76
76
77
78
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
7.2
Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A Benutzeroberfläche
79
Literaturverzeichnis
85
v
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
Einbinden von ActiveX-Controls in Webseiten . . . . . . .
Appletlebenszyklus (entnommen aus [Lud07]) . . . . . . .
Der HTML-Tag <APPLET> zum Einbinden von Applets
Zugriffsrechte von Applets auf Systemeigenschaften . . . .
3.1
Komponenten von FlexiTrust und FlexiTrust Identity Management . . . . 21
4.1
Smartcardoperationen und die Kartenschnittstellenunterstützung . . . . . . 34
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.16
Model-View-Controller-Pattern . . . . . . . . . . . . . . . . . . . . . . .
Der Aufbau des Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht der WizardPanels . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht der WizardPanelDescriptors . . . . . . . . . . . . . . . . . .
Die Klasse WizardPanelDescriptor mit ihren Methoden . . . . . . . . .
Die Klasse Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Klasse Loader mit den wichtigsten Methoden . . . . . . . . . . . . .
Die Klasse ObjectIdentifier mit den wichtigsten Methoden . . . . . .
Die Klassen von Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Action-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Datenaustausch zwischen dem Enrollment-Server, FlexCardAdmin und der
Smartcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das HTML-Formular CertRequestForm und die JavaScript-Funktion
submitForm() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenpersonalisierung (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenpersonalisierung (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration von FlexCardAdmin in der ES-Seite beim Löschen oder Entsperren einer Smartcard . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfigurationsparameter zum Referenzieren der Objekte auf der Karte .
A.1
A.2
A.3
A.4
A.5
Zwei der möglichen Varianten des ConfigurationPanels(1)
Zwei der möglichen Varianten des ConfigurationPanels(2)
Die zwei Varianten des PersonaliseCardPanels . . . . . . .
Die zwei Varianten vom DeleteCardPanel . . . . . . . . . .
Die zwei Varianten vom ResetPINPanel . . . . . . . . . . .
5.12
5.13
5.14
5.15
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
. 8
. 9
. 13
.
.
.
.
.
.
.
.
.
.
44
45
46
47
48
50
51
53
55
56
. 63
. 64
. 65
. 66
. 67
. 71
.
.
.
.
.
79
80
81
82
83
Abbildungsverzeichnis
A.6 Die zwei Varianten vom ChangePINPanel . . . . . . . . . . . . . . . . . . . 84
vii
Kapitel 1
Einleitung
Heutzutage leben wir in einer Welt der Digitalisierung. Die Digitalisierung hat den Alltag
erfasst. In allen Bereichen wird die Datenverwaltung in Papierform durch die elektronische
Datenverarbeitung ersetzt.
Die Verfahren der Personenidentifizierung und der Willenserklärung haben sich auch
dementsprechend geändert. Normalerweise gilt der Personalausweis als Mittel der Identifizierung und die Unterschrift ist ein anerkannter Vorgang zur Willensbekundung. Wenn
aber eine Person über ein elektronisches Kommunikationsnetz wie das Internet identifiziert werden soll oder eine unverwechselbare Willenserklärung abgeben möchte, sind diese
Mittel nicht anwendbar. Heute werden andere Lösungen nötig, die auch von Maschinen
interpretiert werden können. Man spricht von der digitalen Identität. Drei Technologien
haben bei der Entstehung der digitalen Identität eine entscheidende Rolle gespielt: die
Kryptographie, die Chipkartentechnologie und die Public-Key-Infrastrukturen (PKI).
Die digitale Identität besteht aus Daten, welche die Nutzung von verschiedenen PKIDiensten wie Authentifikation, vertrauliche Kommunikation oder die digitale Unterzeichnung elektronischer Dokumente ermöglichen. Diese Daten können Zertifikate oder
Schlüssel sein, die zur Authentifikation, zur Erstellung und Verifikation digitaler Signaturen oder zur Ver- und Entschlüsselung von Daten dienen. Da es sich um sensible Daten
handelt, die nicht jedem zugänglich sein dürfen, müssen diese in einer sicheren Umgebung aufbewahrt werden. Chipkarten bieten das benötigte Sicherheitsniveau und werden
deswegen als Träger geheimer Informationen benutzt.
Die Chipkartentechnologie hat sich parallel zur Ausweitung der elektronischen Datenverarbeitung entwickelt und verspricht hohe Manipulationssicherheit und Zuverlässigkeit
sowie große Flexibilität. Mit dem eingebauten Speicher ermöglicht die Chipkarte die
Aufbewahrung von Informationen, die maschinenlesbar sind. Sie bietet eine sichere
Umgebung für Geheimnisse, da diese physikalisch von der Außenwelt abgeschottet sind
und nie die Karte verlassen. Außerdem sind Chipkarten klein und einfach zu benutzen,
so dass sie von jedem im täglichen Leben eingesetzt werden können.
Immer mehr Unternehmen setzen Chipkarten im Rahmen der Unternehmens-PKI ein. Die
Einführung und die Administration der Chipkarten in einem relativ großen Unternehmen
bringt viel Aufwand mit sich, wenn die Chipkartenverwaltung ausschließlich zentral
erfolgt. Bei einer großen Anzahl von Mitarbeitern nimmt dies viel Zeit in Anspruch,
weil jede Chipkarte einzeln personalisiert werden muss. Wenn ein Mitarbeiter seine
1
KAPITEL 1. EINLEITUNG
Karte vergisst oder verliert oder diese nicht mehr funktioniert, wäre es nicht akzeptabel,
dass er deswegen nicht weiter arbeiten kann. Es soll möglich sein, eine Ersatzkarte
einfach und schnell auszustellen. Ansonsten werden die Geschäftsprozesse verlangsamt.
All dies spricht dafür, dass nicht nur die Nutzung der Chipkarten und der durch ihnen
ermöglichten PKI-Dienste dezentral und selbstbedient erfolgen soll, sondern auch ihre
Administration. Dies umfasst:
•
•
•
•
•
•
den Roll-out (Personalisierung und Verteilung) der Chipkarten
die Verlängerung der Schlüssel- und somit der Kartengültigkeit
das Handling von Notfall- und Ersatzkarten
die Verwendung von Vertreterkarten
das Löschen der Karteninhalte
das Key-Backup von Verschlüsselungsschlüsseln
Um diese Anforderungen zu erfüllen werden Anwendungen benötigt, die die Administration der Chipkarten ermöglichen und von den PKI-Teilnehmern bedient werden können.
1.1 Aufgabenstellung
Im Rahmen dieser Diplomarbeit soll eine Client-Anwendung implementiert werden, im folgenden FlexCardAdmin genannt, die die oben beschriebenen Anforderungen erfüllt. Diese
soll in der Lage sein, die Administrationsdienste unter Einbeziehung der Chipkarten der
Teilnehmer bereitzustellen. Ein solches System namens FlexiTrust Identity Management
wurde schon von FlexSecure [fle] zusammen mit der Firma Kobil [kob] entworfen. Dieses ist derzeit auf TCOS-2.0-Karten [PTT01] und CardOS-4.1-Karten [Sie] eingeschränkt
und verwendet eine OCX-Komponente, die in den Internet-Explorer installiert wird. Die
Lösung ist also an Windows gebunden. Das Ziel ist, die bestehende OCX-Lösung durch
eine neue zu ersetzen, die viel mehr Flexibilität bietet.
Diese Arbeit soll alle Phasen der Entstehung der Software wiedergeben, angefangen von
der Analyse der Anforderungen und dem Konzeptaufbau bis zur Implementierung. Es soll
klar dargestellt werden welche Entscheidungen getroffen wurden und warum.
1.2 Gliederung
Der Inhalt dieser Arbeit ist in folgenden Kapiteln aufgeteilt:
Im Kapitel 2, Grundlagen, werden die Technologien vorgestellt, auf die die bestehende
und die neue Lösung basieren. Durch den direkten Vergleich können die Nachteile der
bestehenden Lösung besser hervorgehoben werden und die Notwendigkeit für eine neue
Anwendung begründet werden.
Im Kapitel 3, Ist- und Sollanalyse, wird die Funktionalität von FlexiTrust Identity Mana-
2
KAPITEL 1. EINLEITUNG
gement beschrieben. Diese dient als Basis zur Spezifikation der Funktionalität von FlexCardAdmin, die als Nächstes in diesem Kapitel beschrieben wird.
Das Kapitel 4, Designentstehung, beschreibt wie das Konzept der Anwendung entstanden
ist, welche Entscheidungen im Laufe der Zeit getroffen wurden und welche die Gründe
dafür gewesen sind.
Im Kapitel 5, Technisches Konzept und Implementierung, wird auf die technische Umsetzung der Anforderungen eingegangen.
Das Kapitel 6, Zusammenfassung, beschreibt abschließend was durch diese Arbeit erreicht
wurde und gibt einen Überblick über das Endergebnis.
Im Kapitel 7, Ausblick, wird ein Blick in die Zukunft geworfen und erklärt, wie die Software weiterentwickelt werden kann und worauf man dabei achten soll.
3
Kapitel 2
Grundlagen
In diesem Kapitel werden die Technologien vorgestellt, die bei der Erstellung von FlexCardAdmin verwendet werden und auch diejenigen, auf die die bestehende Lösung FlexiTrust Idenitity Management basiert. Diese Grundlagen sollen zum besseren Verständnis
der Arbeit dienen. Zuerst wird eine kurze Einführung in der ActiveX-Technologie dargeboten, die in FlexiTrust Identity Management eingesetzt wurde. Es werden die Nachteile
vorgestellt und die Gründe erläutert, warum die Notwendigkeit besteht, diese Lösung
durch eine neue zu ersetzen. Anschließend werden Applets eingeführt. Am Ende des Kapitels wird noch auf die standardisierten Kartenschnittstellen eingegangen, da die Implementierung von FlexCardAdmin auf diesen basiert.
2.1 ActiveX
ActiveX [acta] [actb] ist ein Technologiestandard, der von Microsoft erstmals Anfang 1996
vorgestellt wurde und ein allgemeines Standardverfahren zur Integration von ausführbarem Programmcode in Internet-Anwendungen, Webseiten oder generell in Microsoftorientierten Anwendungen beschreibt. Mit Hilfe von ActiveX werden die Anwendungen
in aktive Anwendugen verwandelt. ActiveX ist ein Überbegriff für verschiedene SoftwareKomponenten. Alle diese Komponenten basieren auf dem sogenannten Component Object
Model (COM). Die ActiveX-Steuerelemente (oder ActiveX-Controls) sind vorkompilierte
wiederverwendbare Komponenten, die ähnlich wie Java-Applets, in Webseiten integriert
werden können. Somit werden die Webseiten dynamisch, was bei den statischen HTMLSeiten nicht der Fall ist. Wenn die Webseite mit dem ActiveX-Control aufgerufen wird,
wird der ActiveX-Control aus dem Internet geladen (nachdem der Anwender bestätigt
hat, dass er das möchte) und auf dem Clientrechner installiert. Der Programmcode wird
clientseitig ausgeführt.
Da ActiveX-Controls nicht eigenständig lauffähig sind, benötigen sie einen so genannten
ActiveX-Container, in den sie geladen und wo ihre Funktionen ausgeführt werden können.
Ein ActiveX-Container nimmt ActiveX-Objekte, wie beispielsweise ActiveX-Controls, auf
und kann ihre öffentliche Eigenschaften (Objektvariablen) und Methoden (Objektfunktionen) ansprechen. Wenn das Control in einer Webseite integriert wird, ist der Webbrowser
der Container.
4
KAPITEL 2. GRUNDLAGEN
ActiveX-Controls sind die Nachfolger der VBX- und OCX-Steuerelemente. Was heute als
ActiveX-Control bezeichnet wird, hieß früher OLE-Control (OLE steht für Object Linking
and Embedding). OLE-Controls wurden umstrukturiert und umbenannt und in ActiveXControls umgewandelt. Die OLE-Controls mußten eine Vielzahl von Methoden implementieren. Dadurch wurden sie in der Regel sehr groß. Solange sie nur von Containern wie
Visual Basic geladen wurden, war dies nicht wichtig. Seitdem die Möglichkeit besteht, sie
über das Internet in einen Browser zu laden, hat ihre Größe enorm an Bedeutung gewonnen. Deswegen hat Microsoft den Namen geändert und ActiveX-Controls so konzipiert,
daß diese nur die Methoden zu implementieren brauchen, die sie auch tatsächlich benötigen. Somit sind ActiveX-Controls auf das Wesentliche reduziert und verglichen mit ihren
Vorgängern bedeutend kleiner, sparsamer konzipiert und auf Geschwindigkeit und Größe
optimiert.
2.1.1 Einbindung in Webseiten
ActiveX-Controls lassen sich mit dem <OBJECT>-HTML-Tag in Webseiten einbinden
(siehe Abbildung 2.1) und werden mit Microsofts Skriptsprachen (VB-Skript oder JavaScript) mit Bedienungslogik versorgt. Der Anwender benotigt allerdings einen ActiveXfahigen Web-Browser.
<OBJECT id="cenroll1" codebase="xenroll.dll"
classid="clsid:127698E4-E730-4E5C-A2b1-21490A70C8A1">
<PARAM name="[Bezeichner]" value="[Wert]">
<PARAM name="[Bezeichner]" value="[Wert]">
...
</OBJECT>
Abbildung 2.1: Einbinden von ActiveX-Controls in Webseiten
Das classid-Attribut ist die weltweit eindeutige ActiveX-ID für das ActiveX-Control: ein
eindeutiger 128-Bit-Wert, der dem Ersteller eines Controls bei der Registrierung seines
Controls von einer Lizensierungsorganisation zugeteilt wird. Jedes Control muss normalerweise die Klassen-ID spezifizieren, denn beim Laden des Controls vom Server wird die
Klassen-ID verwendet, um das Control zu authentifizieren. Es wird überprüft, ob das
Control zertifiziert wurde und ob das Zertifikat noch gültig ist. Wenn dies nicht der Fall
ist, zeigt der Browser bei entsprechender Sicherheitseinstellung eine Warnung. Dann kann
der Benutzer entscheiden, ob die Installation fortgesetzt werden soll oder nicht.
Die Klassen-ID kann auch als Identifikation dienen, über die von einer Skriptsprache aus
auf das Objekt zugegriffen werden kann. Üblicher ist jedoch der Zugriff über die NamensID.
Das codebase-Attribut wird dafur verwendet, das Control aus dem Netz zu laden, wenn
es auf dem lokalen System fehlt.
5
KAPITEL 2. GRUNDLAGEN
Für jedes ActiveX-Control können beliebige zusätzliche Attribute mittels <PARAM>Tags definiert werden. Jedes Attribut besitzt einen Namen und einen Wert.
2.1.2 Zugriff auf ActiveX-Objekte
Grundsätzlich hat man aus einer Webseite heraus zwei Möglichkeiten für den Zugriff auf
ein ActiveX-Control:
• mittels der Objektattribute definiert innerhalb der <PARAM>-Tags, deren genaue
Ausprägung der Dokumentation jedes einzelnen ActiveX-Controls zu entnehmen ist.
• mittels Skript-Routinen, welche über die übliche Punktnotation ([Objekt ].[Eigenschaft/Methode]) auf die vom Control nach aussen dokumentierten Schnittstellenelemente zugreifen.
Der einfachste Zugriff auf ein Objekt funktioniert über eine VBScript-Procedure mit dem
Namen <Objekt-ID> Click. Diese wird automatisch bei jedem Mausklick auf das Control
aufgerufen. Die flexiblere Zugriffsmöglichkeit verwendet Ereignisse und Eventhandler, die
eine VBScript-Routine aufrufen. Bei beiden Varianten kann innerhalb des VBScriptcodes
via des Namens vom Objekt und des jeweiligen Namens der Eigenschaft, jede Eigenschaft
des Objektes angesprochen werden. Dabei ist zu beachten, dass die Namen der Eigenschaften identisch zu den Angaben im <PARAM>-Bereich des <OBJECT>-Containers
sind.
2.1.3 Sicherheit
Wenn man ein ActiveX-Control auf seinem Rechner erlauben möchte, sollte man sicher
stellen, dass das Control signiert ist. Signierte ActiveX-Controls sollten immer bevorzugt
werden. Mit der Signatur kann der Anwender des Controls sicher stellen, dass das Control tatsächlich von dem angegebenen Entwickler stammt und daß es nachträglich nicht
verändert wurde. Es gibt keine Garantie, dass die Ausführung des Controls trotz Signatur
nicht schädlich für den Client ist. Die Signatur zeigt nur, dass das ActiveX-Control bei
einer von Microsoft lizensierten Organisation registriert wurde (z.B. die Firma VeriSign).
Falls aber die Software Schaden auf dem Rechner einrichtet, haftet der Entwickler des
Controls. Ausserdem führen die Lizensierungsorganisationen mit hoher Wahrscheinlichkeit verschiedene Überprüfungen durch, bevor eine Signatur ausgestellt wird. Somit wird
die signierte Software viel vertrauenswürdiger als diejenige, die nicht signiert ist.
Die tiefgreifenden Manipulationsmöglichkeiten auf fremden Rechnern über ActiveXControls aus einer Webseite heraus sind insbesondere aus Gründen der Sicherheit sehr
bedenklich. Viele Anwender lassen deswegen überhaupt keine ActiveX-Steuerelemente bei
ihren Browsereinstellungen zu. Falls jedoch ein ActiveX-Control in einer Webseite erlaubt
ist und noch nicht auf dem Clientrechner installiert ist, wird es automatisch, nach Anfrage
oder überhaupt nicht (je nach Sicherheitseinstellungen im Browser) auf dem Rechner
aus der angegebenen Quelle installiert. Somit bekommt das ActiveX-Control Zugriff auf
den Clientrechner und kann verschiedene Operationen ausführen, die auch schädlich
6
KAPITEL 2. GRUNDLAGEN
sein könnten. Die Rechte des Controls auf dem Clientrechner sind uneingeschränkt.
Es besteht keine Möglichkeit festzulegen, dass das Control nur bestimmte Operationen
ausführen darf und andere nicht. Das Control bekommt entweder alle Rechte oder keine.
Läuft das ActiveX-Programm erst einmal, dann ist sein Funktionsumfang in keiner Weise
eingeschränkt oder kontrollierbar. Es läuft mit allen Rechten des angemeldeten Benutzers
- ohne jede Einschränkung. Es ist demnach leicht, private oder sicherheitsrelevante Daten
auszulesen, zu löschen, zu manipulieren, den Rechner umzukonfigurieren, einen Virus
oder ein Trojanisches Pferd zu installieren.
2.1.4 Unterstützte Plattformen
ActiveX-Controls wurden für die Windows-Welt konzipiert. Im Laufe der Zeit wurden
einige Versuche gemacht, ActiveX-Controls auch in anderen Betriebssystemen ausführbar
zu machen.
• ActiveX unter Macintosh: Ende 1996 veröffentlichte Microsoft ein Software Development Kit (SDK) für die Erstellung von ActiveX-Controls auf Apple MacintoshPlattformen. Diese ActiveX-Controls liefen im Internet Explorer für MacintoshPlattformen ab Version 2. Die Macintosh ActiveX-Implementierung beruht auf einer
vereinfachten COM-Bibliothek. ActiveX-Controls werden hier nicht als eigenständiger Prozess außerhalb des Web-Browsers ausgeführt, sondern verbleiben in der WebBrowser-Umgebung. Der Einsatz von ActiveX-Controls ist hier demnach nicht so
gefährlich wie unter Windows. Jedoch wird von Microsoft nur noch die Version 5
des Internet Explorers für den Macintosh unterstützt, eine Weiterentwicklung des
Web-Browsers für Macintosh-Umgebungen ist nicht geplant.
• ActiveX unter Linux: Auch für UNIX-Plattformen arbeitet Microsoft zusammen mit
mehreren anderen Herstellern an einer ActiveX-Unterstützung. Unabhängig hiervon
bestehen auch Implementierungen unter dem UNIX-Derivat Linux, um ActiveXControls ausführen zu können. Für den unter Linux lauffähigen Web-Browser Konqueror gibt es Bibliotheken, mit denen ActiveX-Controls ausgeführt werden können.
Da durch diese der Zugriff auf die lokalen Daten möglich ist, ist auch hier ein großes
Gefahrenpotential zu sehen.
Derzeit ist der Internet Explorer von Microsoft ab Version 3.0 der einzige Browser, der ohne Zusatz als ActiveX-Container eingesetzt werden kann. Der Netscape Navigator, Mozilla
und der Konqueror können durch ein entsprechendes ActiveX-Plug-In erweitert werden,
damit auch hier ActiveX-Controls genutzt werden können.
2.2 Applet
Die folgende Beschreibung von Applets wurde aus [app] und [Lud07] entnommen und
hier zusammengefasst. Applets sind ausführbare Java-Programme, die in eine Webseite
7
KAPITEL 2. GRUNDLAGEN
Abbildung 2.2: Appletlebenszyklus (entnommen aus [Lud07])
eingebettet werden. Wenn die Webseite aufgerufen wird, wird das dort enthaltene Applet
automatisch gestartet. Der Programmcode des Applets wird dabei aus dem Internet
geladen und auf dem lokalen Rechner ausgeführt.
Jedes Applet muss von der Klasse java.applet.Applet erben, die die Schnittstelle
zwischen dem Applet und dem Browser bereitstellt. Die meisten Applets haben eine
graphische Oberfläche, die die Interaktion mit dem Benutzer ermöglicht. Für die Applets,
die diese GUI mit Swing-Komponenten aufbauen, bietet das Swing-Framework eine
spezielle Unterklasse von java.applet.Applet, nämlich javax.swing.JApplet, die als
Oberklasse solcher Applets benutzt werden soll.
Da Applets im Browser laufen, wird das Appletverhalten vom Browser gesteuert. Der
Browser ruft zu bestimmten Zeitpunkten der Appletausführung verschiedene Methoden
der Klasse Applet auf und bestimmt somit dessen Lebenszyklus. Diese Methoden sind
(siehe auch Abbildung 2.2):
• init(): wird beim Laden des Applets aufgerufen, um das Applet zu initialisieren.
• start(): wird automatisch nach jedem Aufruf von init() sowie bei jedem erneuten
Besuch der Webseite mit dem Applet aufgerufen.
• stop(): wird automatisch aufgerufen, wenn der Benutzer die Webseite mit dem
Applet verlässt, um eine andere Webseite aufzumachen, oder wenn der Browser geschlossen wird. stop() hält die Appletausführung an, so dass keine Systemresourcen
verbraucht werden, wenn das Applet gerade nicht verwendet wird.
• destroy(): wird aufgerufen, wenn der Browser geschlossen wird (nach jedem Aufruf
von stop()).
Die Methoden init() und destroy() werden ein einziges Mal während des Lebenszyklus
des Applets aufgerufen; die anderen zwei Methoden können mehrfach aufgerufen werden.
Alle vier Methoden können von den Unterklassen von Applet überschrieben werden, um
das Appletverhalten zu spezifizieren.
8
KAPITEL 2. GRUNDLAGEN
2.2.1 Einbindung in Webseiten
Applets lassen sich mit dem <APPLET>-HTML-Tag in Webseiten einbinden (siehe Abbildung 2.3). Dieser Tag hat folgende Attribute, die spezifiziert werden müssen:
• code: hier muss der Name der Applet-Klasse (inklusiv Paketbezeichnung) angegeben
werden, z.B. de.mypackage.MyApplet.class.
• codebase: hier wird die URL angegeben, von der das Applet heruntergeladen werden
kann, wenn noch nicht auf dem Clientrechner vorhanden.
• archive: hier müssen alle jar-Bibliotheken aufgelistet werden, die das Applet
braucht.
• name: hier wird der Name des Applets spezifiziert, mit dem das Applet innerhalb
der HTML-Seite angesprochen werden kann.
• width: hier wird die Breite der Applet-GUI in der Webseite festgelegt.
• height: hier wird die Höhe der Applet-GUI in der Webseite festgelegt.
Für jedes Applet können zusätzliche Attribute mittels des <PARAM>-Tag definiert werden. Jedes Attribut besitzt einen Namen und einen Wert.
<APPLET code="’MyApplet.class"’
codebase="’http://www.tu-darmstadt.de/applets"’
archive="myapplet1.jar,myapplet2.jar"
name="’MyApplet"’
width="400" height="400">
<PARAM name="color" value="0xFF0000">
...
</APPLET>
Abbildung 2.3: Der HTML-Tag <APPLET> zum Einbinden von Applets
2.2.2 Kommunikation zwischen dem Applet und der Webseite
Oft ist es notwendig, dass das Applet Daten mit der HTML-Seite austauscht. Java ist in
der Hinsicht nicht flexibel genug und bietet nicht viele Möglichkeiten an. Skriptsprachen
wie JavaScript dagegen wurden dafür entwickelt, auf die einzelnen HTML-Elemente einer
Webseite zuzugreifen und verschiedene Operationen darauf auszuführen. Wenn man Java
und JavaScript kombiniert wird die Interaktion zwischen dem Applet und der Webseite möglich und die Appletfähigkeiten werden erweitert [Mor97]. Um die Kommunikation
zwischen Java und JavaScript zu ermöglichen, hat Netscape die LiveConnect-Technologie
[liv] entwickelt. Mit LiveConnect wird es möglich, über JavaScript auf Java-Objekte, Methoden und -Variablen zuzugreifen und umgekehrt können JavaScript-Funktionen von
einer Java-Anwendung aufgerufen werden.
Mit JavaScript kann das Appletverhalten beeinflusst werden. Das Applet kann dazu gebracht werden, auf verschiedene Ereignisse in der HTML-Seite zu reagieren, indem die
9
KAPITEL 2. GRUNDLAGEN
Appletmethoden aufgerufen werden. JavaScript kann auf alle öffentlichen Methoden oder
Attribute des Applets zugreifen. Dafür müssen diese öffentlichen Methoden und Attribute
des Applets dem Entwickler bekannt sein. Im <APPLET>-Tag muss außerdem der Appletname spezifiziert werden, weil das Applet über seinen Namen angesprochen wird. Die
Funktionen oder Attribute des Applets können ebenso über den Appletnamen aufgerufen
bzw. abgefragt werden. Um eine Applet-Methode aufzurufen wird folgende Syntax verwendet: document.appletName.methodName(arg1,..., argx). Im Folgenden wird gezeigt wie ein Applet durch das Anklicken von Buttons auf der Webseite gestartet und
angehalten werden kann.
<APPLET code="de.flexsecure.flexiTrust.flexcardadmin.FlexCardApplet.class"
name="FlexCardApplet" width=60 height=60>
</APPLET>
<FORM>
<INPUT type="button" value="Start" onClick="document.FlexCardApplet.start()">
<INPUT type="button" value="Stop" onClick="document.FlexCardApplet.stop()">
</FORM>
Für die Kommunikation von Java zu JavaScript stellt Netscape drei Java-Klassen zur
Verfügung:
• netscape.javascript.JSObject
• netscape.javascript.JSException
• netscape.plugin.Plugin
Will man von Java aus auf ein Objekt einer JavaScript-Anwendung zugreifen, so verhüllt
JavaScript dieses Objekt in einer Instanz der Klasse netscape.javascript.JSObject.
Jede Instanz von JSObject repräsentiert eine DOM-Entität in der JavaScript-Welt.
Als Erstes braucht man eine Referenz auf das JavaScript-Window-Objekt, welches das
Applet beinhaltet. Die statische JSObject-Methode getWindow(Applet applet) liefert
diese Referenz, verhüllt in einer JSObject-Instanz. Nachdem man diese Referenz bekommen hat, kann das Applet in die Webseite navigieren und mit der Methode getMember()
auf einzelne Elemente zugreifen. getMember() liefert das nächste Element in der Hierarchie der HTML-Elemente. Das oberste Element in dieser Hierarchie ist das windowObjekt. Seine Kinder sind document, location und history. Die Kinder von document
sind Formulare, Links und Applets. Mit der Methode getMember() wird diese Hierarchie
gelesen. Im Folgenden wird gezeigt wie die vorgestellten Methoden verwendet werden, um
bestimmte HTML-Elemente auszulesen.
import netscape.javascript.*;
import java.applet.*;
class MyApplet extends Applet {
public void init() {
JSObject win = JSObject.getWindow(this);
JSObject doc = (JSObject) win.getMember("document");
10
KAPITEL 2. GRUNDLAGEN
JSObject requestForm = (JSObject) doc.getMember("request");
JSObject nameField = (JSObject) requestForm.getMember("name");
JSOBject numberField = (JSObject) requestForm.getMember("number");
String nameValue = (String) nameField.getMember("value");
Float numberValue = (Float) numberField.getMember("value");
}
}
In dem Beispiel wird der Inhalt der zwei Eingabefelder name und number im Formular
request ausgelesen.
Um JavaScript-Werte zu ändern, gibt es die Methode setMember(String elementName,
String value). Die Methode bekommt den Namen des Elements, dessen Wert geändert
werden soll, und den neuen Wert übergeben.
import netscape.javascript.*;
import java.applet.*;
class MyApplet extends Applet {
public void init() {
JSObject win = JSObject.getWindow(this);
JSObject doc = (JSObject) win.getMember("document");
JSObject requestForm = (JSObject) doc.getMember("request");
JSObject nameField = (JSObject) requestForm.getMember("name");
nameField.setMember("value","MyName");
}
}
JSObject bietet die zwei Methoden call(String methodName, Object[] params) und
eval(String expression) an, mit denen JavaScript-Methoden vom Applet heraus aufgerufen werden können. Bei der ersten Methode werden der JavaScript-Methodenname
und ihre Argumente separat übergeben. Die zweite Methode bekommt den Methodenaufruf als String übergeben. Dies kann z.B. so aussehen:
eval("document.writeln(\"Hier wird ein Text angezeigt.\");")
Aus Sicherheitsgründen ist die Benutzung von JSObject standardmäßig nicht zugelassen.
Um JSObject verwenden zu können, muss das Applet mit dem zusätzlichen Attribut
MAYSCRIPT versehen werden. Wenn dieses Attribut im Applet fehlt, ist die Benutzung
von JSObject nicht möglich.
<APPLET code="MyApplet.class" width=50 height=50 NAME="Preview" MAYSCRIPT>
2.2.3 Sicherheit
Ähnlich wie die ActiveX-Controls, könnten Applets auf dem Clientrechner Schaden anrichten. Sie werden über das Internet geladen und gestartet und könnten verwendet werden, um Daten auf dem lokalen Rechner zu verändern, löschen oder zu lesen, ohne dass
11
KAPITEL 2. GRUNDLAGEN
der Betrachter der Webseite, die das Applet enthält, dies merkt. Um das zu verhindern
und die sichere Ausführung von Applets zu ermöglichen, werden die Rechte des Applets
beschränkt. Dazu wird das Applet in einem speziellen Bereich ausgeführt, in dem nur
bestimmte Operationen zugelassen sind. Dieser Bereich wird als Sandkasten oder Sandbox bezeichnet. Versucht das Applet Operationen außerhalb der Sandbox auszuführen,
wird dies erkannt und unterbunden. Normalerweise gelten folgende Einschränkungen für
Applets:
• Es dürfen keine Operationen auf Dateien wie Lesen, Schreiben oder Umbenennen
durchgeführt werden. Außerdem dürfen keine neuen Dateien angelegt werden und
auch nicht geprüft werden, ob eine bestimmte Datei existiert.
• Es dürfen keine externen Programme auf dem Clientrechner gestartet werden. Daher
ist der Aufruf der Methoden System.exec() und Runtime.exec() verboten.
• Ein Applet darf nicht auf alle Systemeigenschaften oder Umgebungsvariablen zugreifen. Abbildung 2.4 gibt eine Übersicht.
• Netzwerkverbindungen werden nur zu dem Rechner erlaubt, von dem das Applet
stammt. Der Kontakt zu anderen Rechnern oder zu Applets, die von einem anderen
Rechner stammen, ist verboten.
• Systemthreads können von Applets weder gestartet, gestoppt, unterbrochen, noch
kann ihre Priorität geändert werden. Manipulationen an den Threads in der eigenen
virtuellen Maschine, in der das Applet läuft, sind jedoch möglich.
• Der Aufruf nativer Methoden ist verboten. Eine Ausnahme stellen einige Methoden
des JDK dar.
• Applets dürfen keine Bibliotheken, beispielsweise mittels System.loadLibrary(),
laden.
Durch diese restriktive Politik wird auch gutartigen Applets die Möglichkeit genommen,
ausgeführt zu werden. Deswegen wurden die Sicherheitsmaßnahmen bei Applets so angepasst, dass bestimmte Applets mehr Rechte bekommen, wenn sie entweder digital signiert sind und vom Benutzer als vertrauenswürdig eingestuft wurden, oder lokal auf dem
Rechner in einem CLASSPATH-Verzeichnis installiert sind. Für solche Applets sind die
Einschränkungen aufgehoben.
Damit ein Java-Applet digital signiert werden kann, benötigt der Entwickler ein Zertifikat. Das Zertifikat kann bei einem Zertifikatsaussteller erworben werden. Es enthält
Signaturprüfdaten, die Aufschluss über den Inhaber des Zertifikats (hier: den Entwickler)
geben, sowie eine digitale Signatur der Zertifizierungsstelle. Letztere ist die Unterschrift
der Zertifizierungsstelle und stellt sicher, dass das Zertifikat echt ist. Mit diesem Zertifikat
werden die entwickelten Java-Applets vom Entwickler signiert und in ein Archiv abgelegt.
Das Archiv wird auf dem Webserver des Anbieters abgelegt und in einer HTML-Seite referenziert. Fordert der Web-Browser des Anwenders eine solche HTML-Seite an, so wird
zunächst die digitale Signatur des Archivs geprüft. Anschließend erscheint eine Meldung
im Web-Browser, die die Signaturprüfdaten des Zertifikats anzeigt und erfragt, ob der
Anwender dem Applet mehr Rechte erteilen will. Bestätigt der Anwender diese Meldung
12
KAPITEL 2. GRUNDLAGEN
Systemeigenschaft
Beschreibung
file.separator
java.class.version
java.vendor
java.vendor.url
java.version
line.separator
os.arch
os.name
path.separator
java.class.path
java.home
Dateienseparator (z.B. /“)
”
Version der Java-Klasse
Java-Vendor-spezifischer String
URL des Java-Vendors
Java-Version
Zeilenseparator
Architektur des Betriebssystems
Name des Betriebssystems
Pfadseparator (z.B. :“)
”
Java-Classpath
Verzeichnis mit der JavaInstallation
Arbeitsverzeichnis des Benutzers
Home-Verzeichnis des Benutzers
Loginname das Benutzers
user.dir
user.home
user.name
Kann von Applets ausgelesen werden?
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
nein
nein
nein
nein
Abbildung 2.4: Zugriffsrechte von Applets auf Systemeigenschaften
positiv, wird das digital signierte Java-Applet mit den entsprechend eingeforderten Rechten im Web-Browser ausgeführt.
2.2.4 Unterstützte Plattformen
Webseiten mit Applets können mit einem Java-fähigen Browser betrachtet werden. Alle
aktuellen Browser verfügen über eine Java-Virtual-Machine, sind Java-fähig und somit in
der Lage, Java-Applets auszuführen.
2.3 ActiveX versus Applets
Wenn man sich zwischen ActiveX und Applets entscheiden soll, spricht einiges für die
Applets. Ihre Hauptvorteile sind:
• Applets sind plattformunabhängig. Da sie in Java geschrieben werden, sind sie in
jedem Betriebssystem ausführbar. ActiveX-Controls dagegen laufen nur unter Windows.
• Applets werden von mehreren Browsern unterstützt. Der einzige Browser dagegen,
der ohne Zusatz als ActiveX-Container eingesetzt werden kann, ist Internet Explorer. Die restlichen Browser müssen zuerst durch einen ActiveX-Plugin erweitert
werden.
13
KAPITEL 2. GRUNDLAGEN
• Die Sicherheitsmaßnahmen bei Applets sind viel besser. Applets werden in einer
Sandbox ausgeführt, in der nur bestimmte Operationen zugelassen sind. Möchte
man einem Applet mehr Rechte vergeben, kann man das tun, indem dieses signiert
oder lokal auf dem Rechner in einem CLASSPATH-Verzeichnis installiert wird. Bei
ActiveX-Controls dagegen hat man diese Kontrolle über die zulässigen Operationen
nicht. Das Control bekommt entweder alle Rechte oder keine, unabhängig davon ob
es signiert ist oder nicht. Damit erweist sich die Systemsicherheit als großes ActiveXProblem. ActiveX-Komponenten haben vollen Zugriff auf das System und empfindliche Speicherbereiche. So bietet sich eine Angriffsfläche für Viren und Online-Spione.
Der einzige Schutzmechanismus ist eine Herkunftskennung. Anhand eines Zertifikats
sollen sich Programmierer von ActiveX-Controls ausweisen und erklären, dass ihr
Code bedenkenlos laufen kann.
Sicherlich hat auch ActiveX gewisse Vorteile:
• In Sachen Geschwindigkeit haben ActiveX-Controls ihren Java-Konkurrenten einiges voraus. Die Unabhängigkeit vom Betriebssystem und Prozessor erkauft sich Java
mit Geschwindigkeitsverlusten. Die Übersetzung des Java-Zwischencodes in der Virtual Machine kostet Zeit. Zudem kann Java wegen der Sicherheitsbeschränkungen
nicht alle Raffinessen eines Betriebssystems oder Prozessors ausnutzen. Bei ActiveX
verzichtete man auf den Zwischencode, da es ActiveX nur für Windows gibt. Die
Controls sind bereits in Maschinensprache für Intel und Windows übersetzt und
somit auf Geschwindigkeit und Größe optimiert.
Alles in allem haben beide Technologien Vor- und Nachteile. Bevor man die Entscheidung
trifft, welche von beiden Technologien einzusetzen, muss man auch den konkreten Anwendungsfall analysieren. In bestimmten Fällen wird es besser sein, ActiveX zu verwenden,
in anderen werden Applets die geeignetere Wahl sein. Wenn man aber auf die Sicherheit
und die Plattformunabhängigkeit Wert legt, sind Applets zu bevorzugen.
2.4 Standardisierte Kartenschnittstellen
Wenn Smartcards als Träger der digitalen Identität im Rahmen von Public-KeyInfrastrukturen eingesetzt werden, werden sie im Normalfall über einen Kartenleser mit
einem Rechner verbunden und mithilfe von Software, die auf diesem Rechner installiert
ist, verwaltet. Im Laufe der Zeit sind viele Anwendungen entstanden, die diese Interaktion
ermöglichen und man hat gemerkt, dass eine einheitliche Basis definiert werden muss. In
Folge dessen wurden Standards entwickelt, die die Schnittstelle zwischen Smartcards und
PCs spezifizieren. Drei davon werden hier vorgestellt, da diese der Implementierung von
FlexCardAdmin zu Grunde liegen.
14
KAPITEL 2. GRUNDLAGEN
2.4.1 PKCS#11
Der Public Key Cryptography Standard 11 (PKCS#11) [RSA04] ist eine der Spezifikationen von der Familie von Spezifikationen Public Key Cryptography Standards (PKCS), die
von RSA Laboratories spezifiziert wurde, um die Kompatibilität und Interoperabilität
zwischen verschiedenen kryptographischen Anwendungen zu erreichen. PKCS#11,
auch Cryptoki“ (Abkürzung für cryptographic token interface) genannt, stellt eine
”
C-Schnittstelle zu Geräten zur Verfügung, die kryptographische Daten aufbewahren
oder kryptographische Funktionen ausführen. Diese können zum Beispiel Smartcards,
USB-Tokens oder Handheld-PCs sein. Alle solche kryptographische Geräte werden als
ein sogenanntes kryptographisches Token betrachtet. Kartenleser dagegen werden als
sogenannte Slots aufgefasst. Das Ziel von PKCS#11 ist, die Unabhängigkeit der Anwendungen von der verwendeten Hardware zu erreichen. Durch das Token-Konzept werden
alle Geräte als logisch gleich gesehen. PKCS#11 ist also eine High-Level-Schnittstelle,
die vom Smartcardbetriebssystem und Smartcardkommandos abstrahiert (im Fall, dass
das verwendete Token eine Smartcard ist). Dieses hohe Abstraktionsniveau ist ein
wesentlicher Vorteil von PKCS#11, da man lediglich zu den verwendeten Kartenlesern
und Kartentypen passende PKCS#11-Treiber braucht, die Schnittstelle aber immer
gleich bleibt.
Auf der anderen Seite kann die hohe Unabhängigkeit auch als Nachteil interpetiert
werden, weil für den Benutzer viele Aspekte transparent und unbeeinflussbar bleiben.
Man wird mit den Einschränkungen von PKCS#11 konfrontiert.
In der PKCS#11-Spezifikation ist keine PIN und keine PUK vorgesehen. Stattdessen
unterscheidet man zwischen den zwei Benutzerrollen Security Officer (SO) und User,
die jeweils ein Passwort zum Einloggen auf die Karte haben. Die Rolle vom Security
Officer ist, das Token zu initialisieren und das Userpasswort (PIN) zu setzen. Nur wenn
der Security Officer eingeloggt ist, kann das Passwort vom User gesetzt werden. Der
User darf sich erst dann auf die Karte einloggen, nachdem sein Passwort vom Security
Officer gesetzt wurde. Das Passwort des Security Officers kann man also als die PUK
der Karte betrachten und das Userpasswort - als die PIN. Nur beim Kenntnis der
PUK kann die PIN gesetzt werden. Das fehlende PIN / PUK-Konzept bereitet einige
Schwierigkeiten, weil nicht alle benötigten PIN-/PUK-Operationen in den bekannten
PKCS#11-Implementierungen verfügbar sind. Es ist zum Beispiel nicht möglich, die
PIN und die PUK der Karte zu löschen. Dadurch kann eine Smartcard nicht vollständig
gelöscht und nicht erneut personalisiert werden.
Um die C-Funktionen der PKCS#11-Schnittstelle aus einer Java-Umgebung aufrufen zu können, wurden verschiedene Java-Wrapper entwickelt. In dieser Arbeit wird
der Java-PKCS#11-Provider [Cor00] verwendet, der als Ergebnis der Diplomarbeit von
Vlad Koroama an der TU Darmstadt entstanden ist. Java-PKCS#11-Provider stellt eine
objektorientierte Schnittstelle zu Funktionen einer nativen PKCS#11-Bibliothek zur
Verfügung.
15
KAPITEL 2. GRUNDLAGEN
2.4.2 PC/SC
Der Personal Computer/Smartcard (PC/SC) Standard wurde von PC/SC Workgroup
entwickelt und spezifiziert eine C-Schnittstelle zur Interaktion zwischen Computersystemen und Chipkarten. Bei PC/SC handelt es sich um eine Low-Level-Schnittstelle, welche die Übermittlung von APDUs zur Smartcard übernimmt. Einerseits bedeutet dies,
dass man jeweils eine Implementierung pro Kartentyp benötigt; der Entwickler muss also alle Details des Kartenbetriebssystems verstehen und die Entwicklungszeiten sind im
Vergleich zu PKCS#11 wesentlich länger. Außerdem besteht die Gefahr, dass mit jedem
Kartenbetriebssystemupdate die Applikation angepasst werden muss, weil benutzte Funktionen nicht mehr verfügbar sind. Andererseits eröffnet die APDU-Welt die Möglichkeit,
die Smartcard-Funktionalität in vollem Umfang auszunutzen und Funktionen zu implementieren, die der eigenen Bedürfnissen und Anforderungen genau entsprechen. Um die
PC/SC-Schnittstelle zu benutzen, muss ein PC/SC-Treiber für den Kartenleser installiert
werden. Da der Standard weltweit hohe Verbreitung kennt, sind PC/SC-Treiber für die
meisten Lesegeräte verfügbar.
Um die PC/SC-Bibliothek aus einer Java-Umgebung anzusprechen, kann ein JavaWrapper für PC/SC von IBM (JPC/SC) [jpc] verwendet werden.
PC/SC wurde ursprünglich für Windows konzipiert, kann aber auf verschiedenen Plattformen eingesetzt werden. Von JPC/SC werden Windows- und Linux-Umgebungen unterstützt. Das Projekt MUSCLE [mus] bietet PC/SC-Kartenlesertreiber für Linux, Solaris
und MacOS.
2.4.3 OCF
Die folgende Beschreibung wurde aus [Dra06] entnommen:
OpenCard Framework (OCF) wurde von OpenCard Consortium ins Leben
gerufen und ist ein Java-basiertes Framework zur Entwicklung von SmartcardAnwendungen. Das Framework ist auf jeder Java-fähigen Plattform einsetzbar
und ist damit als solches unabhängig vom Betriebssystem des PC. Das ist ein
großer Vorteil von OCF. Wie PC/SC, braucht OCF jeweils eine Bibliothek
vom Smartcard-Hersteller und vom Hersteller des Kartenlesers (als CardServices und CardTerminals bezeichnet). Die Installation ist aber im Gegensatz
zu PC/SC nicht trivial, weil zusätzlich zu den Bibliotheken noch das Framework selbst installiert werden muss.
OCF bietet eine objekt-orientierte Smartcard-Schnittstelle, die Veränderungen
in Hardware oder im Smartcard-Betriebssystem vor der Anwendung verbirgt.
Das Framework definiert die Schnittstelle für die Anwendung als sogenannte
CardServices. Die Implementierung eines CardService ist für die Anwendung
transparent und kann jeder Zeit ausgetauscht werden.
OCF hat sich zum Standard im Java-Umfeld etabliert, es ist gut dokumentiert und von umfangreichen Tutorials begleitet. OCF-Treiber existieren al-
16
KAPITEL 2. GRUNDLAGEN
lerdings nur für wenige Kartenleser. Aus diesem Grund wurde ein OCFWrapper für PC/SC (ein PC/SC-CardTerminal [ocf]) entwickelt, so dass
das OCF-Framework im sogenannten PassThruModus“ mit jedem PC/SC”
Kartenlesertreiber benutzt werden kann. In diesem Fall agiert das OCFFramework als Java-Wrapper für die PC/SC-Schnittstelle, d.h. man kann aus
einer Java-Umgebung APDUs an die Smartcard senden. Durch die zusätzlichen Komponenten wird die Installation noch aufwändiger und benutzerunfreundlicher, unter anderem weil der Wrapper sich auf die Java Comm API
stützt.
17
Kapitel 3
Ist- und Soll-Analyse
In diesem Kapitel wird die bestehende Lösung FlexiTrust Identity Management vorgestellt. Ihre Struktur und Funktionen werden beschrieben. Da das Ziel dieser Arbeit ist,
eine der bestehenden Komponenten von FlexiTrust Identity Management durch eine neue
zu ersetzen, wird auf diese Komponente und ihre Nachteile detaillierter eingegangen. Anschließend werden die Anforderungen an die neue Komponente FlexCardAdmin spezifiziert.
3.1 FlexiTrust Identity Management
FlexiTrust Identity Management [Gmb06a] ist eine Webapplikation, welche die
Trustcenter-Software FlexiTrust [Gmb] erweitert und im Rahmen einer PKI sämtliche
Aufgaben übernimmt, die mit der dezentralen Personalisierung und Verwaltung von
Smartcards verbunden sind. Das System ermöglicht die selbstbediente Administration der
Smartcards. In jedem Unternehmen, das Chipkarten im Rahmen der Unternehmens-PKI
einsetzt, sind diese notwendige Operationen. Mit FlexiTrust Identity Management lässt
sich eine dezentrale und flexible Smartcard-Rollout-Infrastruktur aufbauen, die selbstbediente Verfahren unterstützt und den eigenen Bedürfnissen und Anforderungen genau
entspricht.
Folgende Operationen lassen sich mit FlexiTrust Identity Management ausführen:
• Selbstbediente Personalisierung von Smartcards: Nachdem ein neuer Mitarbeiter in
einem Unternehmen eingestellt wird, wird ein neues Benutzerkonto für ihn angelegt
und er muss seine Mitarbeiterkarte personalisieren. Er erhält eine leere, unpersonalisierte Smartcard und seine Authentifizierungsdaten. Nach einer erfolgreichen
Authentifikation dem System gegenüber kann er seine Karte personalisieren.
• Selbstbedientes Erneuern von Smartcards: Falls eine Karte nicht mehr benutzbar ist
(zum Beispiel wenn die Karte defekt ist), kann der Mitarbeiter eine Ersatzkarte für
sich ausstellen. Dafür erhält er eine leere Smartcard oder löscht vollständig seine
Vorgängerkarte. Nach einer erfolgreichen Benutzerauthentifikation wird die Karte
neu personalisiert, wobei ein Key-Recovery für gesicherte Schlüsselpaare und entsprechende Zertifikate stattfindet. Alle anderen Daten (Schlüsselpaare, Zertifikate,
Geheimnisse und Applikationsdaten) werden neu generiert und auf die Smartcard
18
KAPITEL 3. IST- UND SOLL-ANALYSE
geschrieben.
• Erstellung einer Notfallkarte: Falls ein Mitarbeiter seine Karte vergisst oder verlegt, kann vom PKI-Administrator eine Notfallkarte mit einer kurzen Gültigkeitsdauer erstellt werden. Gesicherte Schlüsselpaare und entsprechende Zertifikate werden übernommen, alle anderen Daten werden neu generiert. Nach dem Ablauf der
Gültigkeit müssen Notfallkarten zurückgegeben werden. Sie werden dann vom PKIAdministrator vollständig gelöscht.
• Selbstbedientes Entsperren der Karte und Neusetzen der Geheimzahl (PIN): Eine
Karte wird gesperrt, wenn die PIN mehrmals falsch eingegeben wird. Die Anzahl der
möglichen Fehlversuche bei der PIN-Eingabe ist konfigurierbar und wird beim Personalisieren der Smartcard gesetzt. Nach einer erfolgreichen Authentifikation dem
System gegenüber kann der Kartenbesitzer die Karte entsperren und seine PIN neu
setzen.
• Selbstbedientes Löschen der Karteninhalte: Wenn ein Mitarbeiter das Unternehmen
verlässt, gibt er seine Smartcard zurück und diese wird vollständig gelöscht. Nach
dem Löschen ist die Karte leer und kann neu personalisiert werden.
Für alle oben beschriebenen selbstbedienten Smartcard-Operationen ist eine Benutzerauthentifikation mit Benutzernamen, Passwort und Einmalpasswort (TAN) erforderlich. Diese findet über ein Webinterface statt. Die Benutzer bekommen Zugriff auf das System über
eine Webseite (die Enrollment-Seite), auf der sie sich mit ihrem Benutzernamen, Passwort
und der TAN authentifizieren müssen. Von dort aus können die Smartcardoperationen
ausgeführt werden.
Das TAN-Konzept trägt dafür Sorge, dass die ausgeführten Smartcardoperationen kontrolliert und verwaltet werden können. Mit der TAN kann eine Operation nur einmal und
nur von dem TAN-Besitzer ausgeführt werden. Das Einmalpasswort wird automatisch
generiert, nachdem der Benutzer einen Request für eine bestimmte Smartcardoperation
gestellt hat. Die TAN kann nur für diese spezifische Operation verwendet werden. Diese
wird dem Benutzer zum Beispiel in einem TAN-Brief zugeschickt oder auf einer sicheren
Webseite, auf die nur per Smartcard zugegriffen werden kann, angezeigt. Nachdem der
Benutzer die TAN bekommen hat, darf er die gewünschte Operation ausführen. Um die
Sicherheit zu erhöhen, ist die TAN zusätzlich an die Smartcard-Seriennummer gebunden
und hat eine begrenzte Gültigkeitsdauer. Für einen Benutzer darf immer höchstens eine
TAN freigeschaltet sein.
Jede Smartcard besitzt eine PIN und eine PUK. Die Smartcard-Administration ist bei
FlexiTrust Identity Management so konzipiert, dass die PUK dem Benutzer unbekannt
bleibt. Dies macht vor allem im Firmenumfeld besonders viel Sinn. Dadurch, dass die
PUK zentral gespeichert ist, wird vermieden, dass viele Smartcards durch Fehlbenutzung
unbrauchbar werden. Somit werden Kosten gespart. Ausserdem ermöglicht die Kenntnis
der PUK die zentrale Ausführung wichtiger Administrationsaufgaben. Jede zurückgegene
Karte (z.B. die Karte eines Mitarbeiters, der das Unternehmen verlässt, oder eine Notfallkarte) kann vom PKI-Administrator problemlos mit Hilfe der PUK vollständig gelöscht
werden.
19
KAPITEL 3. IST- UND SOLL-ANALYSE
3.1.1 Komponentenüberblick
Abbildung 3.1 gibt eine Übersicht der Komponenten der Trustcenter-Software FlexiTrust.
Die Komponenten, die zu FlexiTrust Identity Management gehören, sind rot markiert.
Diese sind:
• Anmeldeserver mit Benutzerschnittstelle (im Folgenden Enrollment-Server oder ES
genannt): Das Eingangsportal für die PKI-Teilnehmer. Es bietet eine HTML-Seite
an, auf der sich die PKI-Teilnehmer mit Benutzernamen, Passwort und TAN anmelden und selbstbediente Smartcardoperationen ausführen können.
• Datentransport (im Folgenden Enrollment Server Importer oder ESI genannt):
zuständig für den Datentransport zwischen dem Enrollment-Server und der
FlexiTrust-Zertifizierungsstelle, wie man in der Abbildung 3.1 sehen kann. Da die
Funktionen dieser Komponente für diese Arbeit nicht relevant sind, werden sie nicht
näher beschrieben.
• OCX-Komponente: zuständig für die Realisierung der Smartcardoperationen. Dies
ist eine ActiveX-Control-Komponente, die in der Enrollment-Seite eingebettet ist
und beim ersten Aufruf der Webseite auf dem Clientrechner installiert wird. OCX
übernimmt folgende Aufgaben:
– Personalisierung der Karte
∗ PIN/PUK mit Fehlbedienungszähler (FBZ) auf die Karte schreiben
∗ Verschlüsselungszertifikat bzw. Schlüsselbackup einspielen
– PIN der Chipkarte unter Benutzung der PUK zurücksetzen. Der FBZ der PIN
wird dabei zurückgesetzt.
– Komplette Karte mit Hilfe der PUK löschen. Dabei werden PIN, PUK und alle
Zertifikate gelöscht. Die Karte kann dann wieder neu personalisiert werden, wie
im Urzustand.
– Sonstige Hilfsoperationen
∗ PIN verifizieren
∗ Kartenseriennummer auslesen
∗ Personalisierungsstatus der eingelegten Chipkarte feststellen (leer oder initialisiert)
• Verwaltungskonsole (auch Management Console oder MC genannt): ermöglicht die
Verwaltung der:
– Benutzerkonten
– Administratorenkonten
– Chipkarten
– Zertifikaten
– Sperrlisten
Die Verwaltungskonsole wird hier nicht näher beschrieben, weil sie für diese Arbeit
irrelevant ist.
20
KAPITEL 3. IST- UND SOLL-ANALYSE
Abbildung 3.1: Komponenten von FlexiTrust und FlexiTrust Identity Management
21
KAPITEL 3. IST- UND SOLL-ANALYSE
3.1.2 Smartcardoperationen
Wie schon am Anfang dieses Kapitels erwähnt, sind folgende Operationen mit FlexiTrust
Identity Management möglich:
• selbstbediente Personalisierung von Smartcards (Prozess Neue Karte“)
”
• selbstbedientes Erneuern von Smartcards (Prozess Ersatzkarte“)
”
• Erstellung einer Notfallkarte (Prozess Notfallkarte“)
”
• selbstbedientes Entsperren der Karte und Neusetzen der Geheimzahl (PIN) (Prozess
PIN Reset“)
”
• selbstbedientes Löschen der Karteninhalte (Prozess Karte löschen“)
”
Im Folgenden werden sie detaillierter beschrieben.
Personalisierung einer Smartcard
Eine Karte muss in folgenden Fällen personalisiert werden:
• Ein neues Benutzerkonto wurde angelegt (z.B. nachdem ein neuer Mitarbeiter eingestellt wurde)
• Das Verschlüsselungszertifikat/Signaturzertifikat ist abgelaufen
• Alle Inhalte der alten Karte wurden gesperrt
• Der Benutzername des Karteninhabers hat sich geändert (z.B. durch Namensänderung)
Aus den oberen Anwendungsfällen wird klar, dass die Notwendigkeit besteht, eine Karte mehrmals personalisieren zu können. Dies wird von FlexiTrust Identity Management
sichergestellt.
Nachdem der Benutzer eine leere Smartcard und seine Authentifikationsdaten (Benutzername, Passwort und eine TAN für den Prozess Neue Karte“) erhalten hat, kann die
”
Karte personalisiert werden. Dazu sind folgende Arbeitsschritte notwendig:
1. Login: Der Benutzer meldet sich mit seinen Benutzerdaten auf der Enrollment-Seite
an. Der Enrollment-Server leitet die Daten weiter an das ESI.
2. Datenprüfung: ESI überprüft die Benutzerdaten mittels Datenbankabfragen sowie
Abfragen am LDAP-Server; ESI generiert zufällige PIN und PUK und schickt diese
zurück an den Enrollment-Server.
3. Kartenpersonalisierung Teil 1: Nach einer erfolgreichen Benutzeranmeldung erscheint eine Seite mit dem integrierten ActiveX-Control. Diese Seite zeigt die automatisch generierte PIN der Karte. Die PUK wird wie schon am Anfang des Kapitels
erwähnt, nicht angezeigt. Auf der Seite kann der Benutzer außerdem seine Antworten auf verschiedene vordefinierte Sicherheitsfragen eingeben. Durch das Betätigen
einer Taste auf der Seite wird die Smartcard über dem ActiveX-Control in einem
Schritt personalisiert. Folgende Schritte werden durchlaufen:
a) Ist die Seriennummer der Karte dem System bekannt, wird die Karte zuerst
22
KAPITEL 3. IST- UND SOLL-ANALYSE
vollständig gelöscht.
b) PIN und PUK werden zusammen mit dem Fehlbedienungszähler (FBZ) auf die
Karte geschrieben.
c) Die Schlüsselpaare für die elektronische Signatur und Windows-SmartcardLogon werden in der Karte erzeugt und damit PKCS#10-Zertifikatsanträge
[RSA00] erstellt.
d) Die Zertifikatsanträge werden an ESI geschickt.
e) Weitere Geheimnisse und Daten, die für verschiedene Anwendungen erforderlich sind (z.B. Kobil SecOVID OTP Generator), werden auf die Karte geschrieben.
4. Zertifikatserstellung: ESI leitet die Zertifikatanträge an die FlexiTrust-CA weiter. Da für das Verschlüsselungsschlüsselpaar ein Key-Recovery erwünscht ist, wird
es in der FlexiTrust-CA und nicht in der Karte erzeugt. FlexiTrust-CA erstellt das
zugehörige Verschlüsselungszertifikat, sowie die zwei beantragten Zertifikate (für Signatur und Windows-Smartcard-Logon). Das Verschlüsselungsszertifikat und das
zugehörige Schlüsselpaar werden als PKCS#12-Datei [RSA99] gesichert hinterlegt
(Key Backup). Außerdem löscht ESI die TAN und wartet anschließend bis die beantragten Zertifikate in die Datenbank geschrieben wurden, um diese zurück an den
Enrollment-Server zu schicken.
5. Kartenpersonalisierung Teil 2: Die drei Zertifikate werden bereitgestellt und auf
einer Import-Webseite ausgeliefert, die dem Benutzer angezeigt wird. Das ActiveXControl schreibt die Zertifikate und das Verschlüsselungsschlüsselpaar auf die Karte.
Erneuern einer Smartcard
Eine Karte muss in folgenden Fällen erneuert werden:
• Das Signatur- oder Windows-Logon-Zertifikat läuft ab.
• Die Karte ist defekt oder verloren gegangen.
• Die Position des Benutzers im Unternehmen hat sich geändert.
Der Benutzer kann seine Karte erneuern, wenn er seine alte oder eine leere Smartcard und eine TAN für den Prozess Ersatzkarte“ erhalten hat. Der Prozess, der bei der
”
Kartenpersonalisierung beschrieben wurde, wird hier wiederholt. Der Unterschied besteht
darin, dass das Verschlüsselungsschlüsselpaar und das Verschlüsselungszertifikat nicht neu
erzeugt werden. Für den Verschlüsselungsschlüssel findet ein Key-Recovery statt und das
zugehörige Zertifikat wird aus dem Archiv ausgelesen. Dadurch ist sichergestellt, dass der
Benutzer weiterhin auf seine verschlüsselten Daten zugreifen kann.
Erstellung einer Notfallkarte
Eine Notfallkarte wird dann erstellt, wenn der Benutzer seine Karte verlegt oder vergessen hat. Diese Karten werden vom Administrator erstellt und haben eine kurze Gültig-
23
KAPITEL 3. IST- UND SOLL-ANALYSE
keitsdauer (z.B. einen Tag). Die Karte wird personalisiert wie eine Ersatzkarte, d.h. das
Verschlüsselungsschlüsselpaar und das zugehörige Zertifikat werden nicht neu erzeugt.
Entsperren der Smartcard
Die Karteninhalte sind durch die PIN geschützt. Nach mehreren Falscheingaben der PIN,
wird die Karte gesperrt und kann nur mit Hilfe der PUK entsperrt werden. Der Benutzer
kennt die PUK nicht, ist aber trotzdem in der Lage, die Karte zu entsperren und die PIN
neu zu setzen.
Nachdem der Benutzer die TAN für den Prozess PIN Reset“ erhalten hat, kann er
”
seine Karte entsperren. Dazu muss er folgende Arbeitsschritte durchlaufen:
1. Login: Der Benutzer meldet sich auf dem Enrollment-Server (über das bereitgestellte Webinterface) mit seinem Benutzernamen, Passwort und der TAN an.
2. Datenprüfung: ESI überprüft die Benutzerdaten. Es wird außerdem überprüft,
ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der
Chipkarte übereinstimmt.
3. Karte entsperren: Durch das Betätigen einer Taste auf der angezeigten Webseite
wird die Karte über die OCX-Komponente mit Hilfe der PUK entsperrt. Eine neue
PIN wird generiert und im Browser angezeigt. Der Fehlbedienungszähler der PIN
wird dabei zurückgesetzt. Die neue PIN wird auf die Karte geschrieben.
Löschen der Karteninhalte
Karten müssen in folgenden Fällen gelöscht werden:
• Eine zurückgegeben Notfallkarte, um sie wieder zu verwenden
• Die zurückgegebene Karte eines Mitarbeiters, der das Unternehmen verlassen hat
Nachdem der Benutzer die TAN für den Prozess Karte löschen“ erhalten hat, kann er
”
die Karte löschen. Dazu sind folgende Schritte notwendig:
1. Login: Der Benutzer meldet sich auf dem Enrollment-Server (über das bereitgestellte Webinterface) mit seinem Benutzernamen, Passwort und der TAN an.
2. Datenprüfung: ESI überprüft die Benutzerdaten. Es wird außerdem überprüft,
ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der
Chipkarte übereinstimmt.
3. Karte löschen: Durch das Betätigen einer Taste auf der angezeigten Webseite wird
die Karte über die OCX-Komponente mit Hilfe der PUK komplett gelöscht.
3.1.3 Die OCX-Komponente
Die OCX-Komponente ist zuständig für die Realisierung der oben beschriebenen Smartcardoperationen. Sie wird auf dem Clientrechner installiert und übernimmt alle Aufgaben,
24
KAPITEL 3. IST- UND SOLL-ANALYSE
die mit der Kommunikation und Datenübertragung zur Smartcard verbunden sind. Leider
weist diese Komponente gewisse Nachteile auf:
• Sie wurde speziell für nur zwei Kartentypen (TCOS2.0 und CardOS) entwickelt. Alle
anderen Kartentypen werden nicht unterstützt. Diese fehlende Flexibilität schränkt
automatisch die Anzahl der potenziellen Anwender und Kunden ein. Die Hinzunahme neuer Kartentypen ist nicht trivial und nur mit hohem Aufwand realisierbar.
• Dadurch, dass die ActiveX-Technologie zu Grunde dieser Komponente liegt, ist
die Plattformunabhängigkeit nicht gewährleistet (siehe auch Kapitel 2). ActiveXControls sind nur unter Windows ausführbar und ihr Einsatz auf verschiedenen
Plattformen ist somit beschränkt. Die Hinzunahme neuer Betriebssysteme ist also
auch nicht möglich.
• ActiveX wird nicht von vielen Browsern unterstützt. Der einzige Browser, der ohne
Zusatz als ActiveX-Container eingesetzt werden kann, ist Internet Explorer. Die
restlichen Browser müssen zuerst durch einen ActiveX-Plugin erweitert werden.
Die OCX-Komponente ist also nicht flexibel genug und nicht erweiterbar. Es ist nicht
möglich, neue Komponenten in die Software hinzuzufügen. Es stellt sich die Frage welche
Technologie als Ersatz genommen werden kann, so dass alle diese Nachteile eliminiert
werden können. Im nächsten Kapitel wird diese Frage beantwortet.
3.2 FlexCardAdmin
Die neue Lösung, die die bestehende OCX-Komponente ersetzen soll und die im Folgenden
FlexCardAdmin genannt wird, soll alle vorhandene Probleme eliminieren und folgende
Bedingungen erfüllen:
• Die Plattormunabhängigkeit ist gewährleistet
• Die Software ist im Browser ausführbar und kann über das Internet geladen werden.
• Alle gängige Browser werden unterstützt.
• Das Sicherheitsniveau ist hoch genug.
• Die Software ist flexibel und um neue Komponenten erweiterbar.
Es gibt einige Java-Technologien zur Erstellung von Web-Anwendungen:
• Java WebStart-Anwendungen: Suns Java WebStart basiert auf dem Java Network
Loading Protocol (JNLP). Um eine Anwendung mit WebStart zu installieren,
müssen zwei Voraussetzungen gegeben sein. Erstens muss auf den zu installierenden Rechner Java und WebStart installiert sein und zweitens muss im Browser als
Hilfsanwendung für Dateien mit der Endung .jnlp das auführbare Programm javaws
eingetragen sein. Wenn nun der Benutzer im Browser auf einen Link klickt, hinter
dem sich eine JNLP-Datei verbirgt, so wird die Datei heruntergeladen und dann
automatisch WebStart aktiviert. WebStart lädt nun anhand der Einträge in der
JNLP-Datei die zur Anwendung gehörenden JAR-Archive herunter, erzeugt, wenn
gewünscht einen Desktopshortcut und startet dann die Anwendung. Für weitere
25
KAPITEL 3. IST- UND SOLL-ANALYSE
Starts der heruntergeladenen Anwendung ist dann meist keine Netzwerkverbindung
mehr nötig. WebStart-Anwendungen werden nicht im Browser ausgeführt. Da eine der Anforderungen an FlexCardAdmin ist, dass dieser im Browser läuft, ist die
WebStart-Technologie zur Realisierung der neuen Lösung nicht geeignet.
• Java Servlets: Servlets sind serverseitige Anwendungen, die nach einem vom Client
ausgelösten HTTP-Request dynamisch HTML-Seiten erzeugen und im Browser des
Clients anzeigen. Servlets bestehen aus Java-Klassen, die über einen Webserver mittels einer URL angesprochen werden. Servlets werden auf dem Server ausgeführt.
FlexCardAdmin soll aber eine clientseitige Anwendung sein, die auf dem Clientrechner installiert und dort ausgeführt wird. Somit können auch Servlets für die
Realisierung von FlexCardAdmin nicht verwendet werden.
• Java Server Pages (JSP): Eine Java Server Page is eine um Java-Code angereicherte HTML-Seite. Java Server Pages erlauben die Vermischung von regulärem,
statischem HTML mit dynamisch generierten Inhalten durch Java-Code. Anders
als bei Servlets, bei denen HTML in Java-Code eingebettet wird, ist bei JSP der
Java-Code in das HTML-Dokument eingefügt. Jede JSP wird automatisch zu einem
Servlet kompiliert und ausgeführt.
• Java Applets: ein Applet ist ein Java-Programm, das in einer HTML-Seite eingebettet ist und in einem Browser ausgeführt wird. Applets wurden schon ausführlich
im Kapitel 2 eingeführt. Nach Berücksichtigung der gestellten Anforderungen und
dem Vergleich mit den anderen Webtechnologien, haben sich Applets als die geeignete Technologie zur Erstellung von FlexCardAdmin erwiesen. Wie im Abschnitt
2.2 dargestellt, erfüllt die Java-Applet-Technologie die ersten drei der oben genannten Bedingungen. Darüber hinaus unterstützen die im Abschnitt 2.2.3 diskutierten
Merkmale dieser Technologie das Sicherheitsniveau der gesamten Anwendung in
hohem Maße, insbesondere bezogen auf die Sicherheit der eingebundenen Clients.
Das nachfolgend vorgestellte Design des Moduls FlexCardAdmin vervollständigt die
benötigten Sicherheitsmerkmale und garantiert darüber hinaus die Flexibilität und
Erweiterbarkeit.
3.2.1 Funktionale Anforderungen
FlexCardAdmin soll alle Smartcardoperationen, die FlexiTrust Identity Management
ermöglicht und die im Abschnitt 3.1.2 vorgestellt wurden, unterstützen. Die Smartcardfunktionen der OCX-Komponente werden durch das Betätigen einer Taste auf der
Enrollment-Webseite aufgerufen und anschließend ausgeführt. In der neuen Lösung wird
diese Taste entfernt und stattdessen das Applet in der Webseite eingebettet. Beim Öffnen
der Webseite wird das Applet automatisch geladen und ist einsatzbereit. FlexCardAdmin
soll eine passende Benutzeroberfläche anbieten, um z.B. die Smartcard-PIN eingeben zu
können. Durch die Interaktion mit der Benutzeroberfläche der Applets, kann ein Benutzer
eine bestimmte Smartcardoperation starten. Da Daten mit dem Enrollment-Server ausgetauscht werden müssen, soll außerdem eine Schnittstelle zur Kommunikation mit dem
26
KAPITEL 3. IST- UND SOLL-ANALYSE
Enrollment-Server vorhanden sein.
Im Folgenden wird jede Smartcardoperation genauer analysiert und die Funktionalität
vom FlexCard-Admin spezifiziert.
Personalisieren einer Smartcard
Im Abschnitt 3.1.2 wurde der bestehende Kartenpersonalisierungsprozess mit dem Einsatz
der OCX-Komponente beschrieben. Hier wird der Ablauf der Kartenpersonalisierung mit
dem Einsatz vom FlexCardAdmin geschildert. Die einzelnen Schritte bleiben größtenteils
unverändert. Trotzdem werden sie hier der Vollständigkeit halber nochmal aufgelistet:
1. Login: Der Benutzer meldet sich mit seinen Benutzerdaten auf der Enrollment-Seite
an. Der Enrollment-Server leitet die Daten weiter an das ESI.
2. Datenprüfung: ESI überprüft die Benutzerdaten mittels Datenbankabfragen sowie
Abfragen am LDAP-Server; ESI generiert zufällige PIN und PUK und schickt diese
zurück an den Enrollment-Server.
3. Kartenpersonalisierung Teil 1: Nach einer erfolgreichen Benutzeranmeldung erscheint eine Seite mit dem eingebetteten Applet. Diese Seite zeigt die automatisch
generierte PIN der Karte. Um die Karte zu personalisieren, gibt der Benutzer die
generierte PIN in den Applet-Eingabefeldern ein und startet den Personalisierungsprozess. Folgende Schritte werden durchlaufen:
a) Zuerst werden die PUK und die PIN zusammen mit Fehlbedienungszähler auf
die Karte geschrieben. Der Startwert des Fehlbedienungszählers soll konfigurierbar sein.
b) Die Schlüsselpaare für die elektronische Signatur und Windows-SmartcardLogon werden in der Karte erzeugt.
c) Mit den neuen Schlüsseln werden PKCS#10-Zertifikatsanträge erstellt und an
das ESI geschickt.
4. Zertifikatserstellung: Die beantragten Zertifikate, sowie ein Verschlüsselungszertifikat, werden von der FlexiTrust-CA, wie schon im Abschnitt 3.1.2 beschrieben,
erstellt.
5. Kartenpersonalisierung Teil 2: Eine neue Webseite wird geladen, in der das
Applet integriert ist. Der Enrollment-Server leiter die zwei erstellten Zertifikate,
sowie die PKCS#12-Datei, die das Verschlüsselungszertifikat und das zugehörige
Schlüsselpaar enthält, an FlexCardAdmin weiter. Das Applet schreibt diese auf die
Karte.
Bei der Erstellung einer Ersatz- oder Notfallkarte handelt es sich um einen speziellen Fall
der Kartenpersonalisierung. Die Operationen, die dort ausgeführt werden, sind identisch
zu den oben aufgelisteten.
27
KAPITEL 3. IST- UND SOLL-ANALYSE
Entsperren der Smartcard
Genauso wie in Abschnit 3.1.2 beschrieben, soll FlexCardAdmin in der Lage sein, eine
Karte zu entsperren. Diese sind die Schritte, die ein Benutzer durchlaufen muss, um seine
Karte mit FlexCardAdmin zu entsperren:
1. Login: Der Benutzer meldet sich auf dem Enrollment-Server (über das bereitgestellte Webinterface) mit seinem Benutzernamen, Passwort und der TAN an.
2. Datenprüfung: ESI überprüft die Benutzerdaten. Es wird außerdem überprüft,
ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der
Chipkarte übereinstimmt.
3. Karte entsperren: Nach einer erfolgreichen Benutzeranmeldung erscheint eine Seite mit dem eingebetteten Applet. Eine neue PIN wird generiert und im Browser
angezeigt. Der Benutzer gibt die neue PIN in den Eingabefeldern des Applets ein
und startet das Entsperren. Der Fehlbedienungszähler der PIN wird zurückgesetzt
und die neue PIN wird auf die Karte geschrieben.
Löschen der Karteninhalte
Mit FlexCardAdmin soll durch die Ausführung folgender Schritte möglich sein, eine Karte
zu löschen:
1. Login: Der Benutzer meldet sich auf dem Enrollment-Server (über das bereitgestellte Webinterface) mit seinem Benutzernamen, Passwort und der TAN an.
2. Datenprüfung: ESI überprüft die Benutzerdaten. Es wird außerdem überprüft,
ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der
Chipkarte übereinstimmt.
3. Karte löschen: Nach einer erfolgreichen Benutzeranmeldung erscheint eine Seite
mit dem eingebetteten Applet. Der Benutzer gibt die PIN in dem Eingabefeld des
Applets ein und die Karte wird mit Hilfe der PUK komplett gelöscht.
PIN ändern
Eine neue Funktion, die zur Zeit nicht von der OCX-Komponente angeboten wird,
soll mit FlexCardAdmin möglich sein, nämlich das Ändern der PIN. Ein neuer TANVerwendungszweck PIN ändern“ soll eingeführt werden. Nachdem der Benutzer die TAN
”
für den Prozess PIN ändern“ erhalten hat, kann er die PIN seiner Smartcard ändern.
”
Dazu sind folgende Arbeitsschritte notwendig:
1. Login: Der Benutzer meldet sich auf dem Enrollment-Server mit seinem Benutzernamen, Passwort und der TAN an.
2. Datenprüfung: ESI überprüft die Benutzerdaten. Es wird außerdem überprüft,
ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der
Chipkarte übereinstimmt.
3. PIN ändern: Nach erfolgreicher Anmeldung wird eine Seite mit dem integrierten
28
KAPITEL 3. IST- UND SOLL-ANALYSE
Applet angezeigt. Mit dem Applet kann der Benutzer die PIN ändern, indem er die
bisherige und die neue PIN eingibt.
3.2.2 Qualitätsanforderungen
Die Software soll folgende Eigenschaften haben:
• Flexibilität
– möglichst viele verschiedene Kartentypen sollen unterstützt werden
– möglichst viele verschiedene Kartenleser sollen unterstützt werden; die Anwendung soll mit gängigen Kartenlesern funktionieren, im Idealfall unabhängig
davon sein
– die Anwendung soll auf verschiedenen Plattformen laufen (mindestens Linux,
Windows 2000 und Windows XP)
• leichtes Deployment
– die Anwendung soll mit möglichst wenig Installationsaufwand (am besten mit
keinem) zur Verfügung stehen
– die Anwendung auf der Clientseite soll immer up-to-date sein
• Modularität
– die Benutzeroberfläche soll leicht austauschbar und anpassbar sein
• Benutzerfreundlichkeit
• Erweiterbarkeit: es soll möglichst einfach sein neue Komponenten in die Software
hinzuzufügen, wie zum Beispiel:
– Hinzunahme neuer Kartentypen
– Hinzunahme neuer Kartenschnittstellen
– Hinzunahme neuer Kartenleser
– Hinzunahme neuer Betriebssystemen
– Hinzunahme neuer Sprachen
3.2.3 Sicherheitsanforderungen
Da es sich bei der digitalen Identität um sensible Daten handelt, muss sichergestellt
werden, dass diese Daten geschützt vor unauthorisiertem Zugriff bleiben.
Sichere PIN-Eingabe
Die Daten auf der Karte werden durch die PIN vor unberechtigtem Zugriff geschützt.
Es gibt Kartenleser mit integrierter Tastatur, die eine sichere PIN-Eingabe (Secure PIN
Entry - SPE) ermöglichen, d.h. die PIN wird über die Kartenlesertastatur eingegeben.
Diese Art der PIN-Eingabe ist sicherer als die Eingabe über eine graphische Benutzeroberfläche, da die sensiblen Daten weder auf dem PC gespeichert, noch über die unsichere
PC/Kartenleser-Verbindung übertragen werden. Sie befinden sich ausschließlich innerhalb
29
KAPITEL 3. IST- UND SOLL-ANALYSE
der Karten/Leser-Umgebung. Die PIN wird direkt zu der Karte geschickt und somit ist
diese von Viren und Trojanern geschützt.
Wenn ein Kartenleser, der eine Tastatur besitzt, mit der Anwendung benutzt wird, sollte
es möglich sein, die PIN-Eingaben über die Kartenlesertastatur zu machen, um somit
höchste Sicherheit zu bieten. Für die sonstigen Kartenleser erfolgt die Eingabe über die
graphische Benutzeroberfläche.
30
Kapitel 4
Designentstehung
In diesem Kapitel wird beschrieben, wie das Design der Applikation entstanden ist. Das
Kapitel soll dazu dienen nachzuvollziehen, welche Entscheidungen im Rahmen der Erstellung der Arbeit getroffen wurden und warum.
4.1 Analyse des Frameworks SmartcardServices
Für die flexible Anbindung zu Smartcards wird das Framework SmartcardServices [Dra06]
verwendet. Da die FlexCardAdmin-Implementierung auf diesem Framework basiert, ist
es notwendig dieses zu analysieren, um zu wissen welche Funktionalität angeboten wird
und ob es irgendwelche Besonderheiten gibt, die berücksichtigt werden sollen.
4.1.1 Implementierungen
Das Framework SmartcardServices ist so konzipiert, dass es Interfaces zu den einzelnen Kartenoperationen definiert und für jede Kartenschnittstelle oder Kartentyp, die
unterstützt werden sollen, Implementierungen geliefert werden müssen. Einige Implementierungen existieren schon in der vorhandenen Frameworkversion.
Unterstützte Kartenschnittstellen Das Framework unterstützt in seiner jetzigen Version folgende Kartenschnittstellen:
• PC/SC
• OCF
• PKCS#11
Unterstützte Chipkarten Da die PKCS#11-Schnittstelle unabhängig von der verwendeten Chipkarte ist, können im Prinzip beliebige Kartentypen über diese Kartenschnittstelle angesprochen werden. Die anderen zwei Schnittstellen sind wiederum abhängig
vom Betriebssystem der Chipkarte und können nur dann benutzt werden, wenn eine
ApduChannelCard-Implementierung für diesen Kartentyp bereitgestellt wird. Die jetzige
Version des Frameworks bietet eine solche Implementierung für TCOS-2.0-Chipkarten.
31
KAPITEL 4. DESIGNENTSTEHUNG
4.1.2 Kartenoperationen
Es ist wichtig, dass das Framework alle Kartenoperationen unterstützt, die benötigt werden, um die gestellten Anforderungen zu erfüllen. Deswegen ist eine der Aufgaben dieser
Arbeit gewesen, eine Analyse durchzuführen und festzustellen, ob alle notwendigen Kartenoperationen vom Framework angeboten werden.
Kartenpersonalisierung Chipkarten können personalisiert werden, indem persönliche
Daten auf der Karte gespeichert werden. Voraussetzung für die Personalisierung ist, dass
die Karte leer ist. Prinzipiell ist es möglich und sinnvoll eine Karte mehrmals zu personalisieren. Das wäre notwendig, wenn z.B. ein Mitarbeiter das Unternehmen verlässt. Seine
Karte kann von einem anderen Mitarbeiter benutzt werden, nachdem sie erneut personalisiert wurde. Die PKCS#11-Implementierung, auf der das Framework SmartcardServices
aufbaut, unterstützt die mehrfache Kartenpersonalisierung nicht. Sobald eine Karte zum
ersten Mal personalisiert wurde, kann diese nicht ein zweites Mal personalisiert werden.
Auch wenn man die Karteninhalte vollständig löscht, wird die Karte als personalisiert
erkannt. Da die mehrfache Personalisierung eine Anforderung an den FlexCardAdmin
ist, bedeutet das, dass die Kartenpersonalisierung entweder über PC/SC oder über OCF
durchgeführt werden muss.
Die Kartenpersonalisierung umfasst mehrere Schritte:
• PIN und PUK der Karte setzen
• Schlüsselpaare auf der Karte generieren
• Zertifikatsanträge erstellen
• Schlüsselpaare und die zugehörigen Zertifikate auf die Karte schreiben
Das Setzen der PIN und PUK wird von allen Kartenschnittstellen unterstützt. Die Generierung von Schlüsselpaaren auf der Karte wird von TCOS-2.0-Karten nicht unterstützt.
Das Framework bietet aber trotzdem die Möglichkeit, Schlüsselpaare für TCOS-2.0Karten zu generieren, indem diese in einer sicheren Umgebung erzeugt und anschließend
auf die Karte geschrieben werden. Bei der Schlüsselgenerierung ist es außerdem wichtig,
anzugeben, wo genau auf der Karte die neuen Schlüssel geschrieben werden sollen. Wenn
mehrere Schlüsselpaare auf der Karte erzeugt werden sollen, müssen sie referenziert werden können. Diese Funktionalität fehlt in der PKCS#11-Schnittstelle. Man kann zwar
Schlüsselpaare erzeugen, aber man kann nicht angeben, wo die Schlüssel auf der Karte
zu speichern sind. Demzufolge werden generierte Schlüssel auf der Karte überschrieben,
wenn die Schlüsselgenerierung mehrmals durchgeführt wird, da die Schlüssel immer an
derselben Stelle auf der Karte gespeichert werden. Das ist noch ein Grund (genauso wie
die verhinderte mehrfache Kartenpersonalisierung), die PKCS#11-Implementierung bei
der Kartenpersonalisierung nicht zu verwenden.
Das Erstellen von Zertifikatsanträgen sowie das Schreiben von Schlüsselpaaren und Zertifikaten auf der Karte ist mit allen Kartenschnittstellen möglich. Um ein Zertifikat auf die
Karte zu schreiben, muss das zugehörige Schlüsselpaar auf der Karte vorhanden sein.
32
KAPITEL 4. DESIGNENTSTEHUNG
Löschen der Karteninhalte Bevor eine Karte erneut personalisiert werden kann, müssen
die vorhandenen Karteninhalte zuerst gelöscht werden. Die PKCS#11-Implementierung
unterstützt nicht das vollständige Löschen der Karte, weil die PIN und PUK nicht
gelöscht werden können. Die Konsequenz ist, dass man Karten über die PC/SC oder
OCF-Schnittstelle löschen muss.
Ändern und Entsperren der PIN Beide Operationen werden vom Framework unterstützt und können mit jeder Kartenschnittstellenimplementierung durchgeführt werden.
Abbildung 4.1 zeigt alle Kartenoperationen im Überblick und die Schnittstellen, die
diese Operationen unterstützen.
4.1.3 Referenzieren von Objekten auf der Karte
Die Daten auf der Karte müssen referenziert werden können. Wenn sich z.B. mehrere
Schlüssel auf der Karte befinden, muss es möglich sein, zu erkennen, welcher Schlüssel zur
Verschlüsselung und welcher zum Signieren benutzt wird, damit der richtige Schlüssel für
die entsprechende Operation verwendet werden kann.
Das Framework bietet Methoden an, um alle Zertifikate, alle Schlüssel (privat oder öffentlich) und alle sonstigen Datenobjekte, die sich auf der Karte befinden, auszulesen. Wie
erkennt man in dieser Liste das Objekt, das man sucht? Jedes Kartenobjekt ist mit einer
ID versehen und diese ID ist auch sichtbar für den Anwender. Die ID ist aber mit keiner
semantischen Bedeutung verknüpft; sie gibt keine Information über das Anwendungsgebiet des Objekts. Es besteht keine Möglichkeit zu erfahren, welches Objekt in einem
bestimmten Anwendungsfall benutzt werden soll. Wenn sich z.B. auf der Karte zwei Signaturschlüssel befinden, ist es unmöglich den richtigen Schlüssel zu erkennen. Man braucht
also eine zusätzliche Abstraktionsebene, die vom FlexCardAdmin angeboten werden soll
und die das Referenzieren von Objekten auf der Karte ermöglicht. Es muss eine Zuordnung
zwischen jedem Objekt auf der Karte und der Applikation, die dieses Objekt benutzt, hergestellt werden. Wird ein Objekt für eine bestimmte Applikation auf der Karte gesucht,
muss klar sein, wo dieses zu finden ist, so dass es ausgelesen werden kann. Wenn sich z.B.
mehrere Zertifikate auf der Karte befinden und man das Windows-Logonzertifikat sucht,
muss es möglich sein, dieses bestimmte Zertifikat eindeutig zu identifizieren. Es ist offensichtlich, dass wenn man eine Verknüpfung zwischen der Objekt-ID und der Applikation
herstellt, immer bekannt sein wird, welches Objekt für diese Applikation benutzt werden
soll.
Die Objekt-ID wird von den verschiedenen Kartenschnittstellen unterschiedlich dargestellt. Bei PKCS#11 wird die Benennung durch den Treiber festgelegt. Objekte werden
mit symbolischen Namen referenziert. So bedeutet zum Beispiel die Kennung TCOS1-00“
”
Objekt 00 auf der TCOS-Smartcard im Slot 1. Mehrere zusammengehörige Objekte, wie
ein Schlüsselpaar und das zugehörige Zertifikat, haben identische Kennung, können aber
33
KAPITEL 4. DESIGNENTSTEHUNG
Smartcardoperation
Smartcard personalisieren
- Mehfache Personalisierung
- PIN initialisieren
- PUK initialisieren
- Schlüsselpaar schreiben
- Zertifikat schreiben
- Zertifikatsantrag erstellen
- Schlüsselpaar generieren
Smartcard löschen
- PIN löschen
- PUK löschen
- Schlüsselpaare löschen
- Zertifikate löschen
- Sonstige Daten löschen
PIN ändern
PIN entsperren
Kartenschnittstelle
PC/SC, OCF
PC/SC, OCF
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF
PC/SC, OCF
PC/SC, OCF
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
PC/SC, OCF, PKCS#11
Abbildung 4.1: Smartcardoperationen und die Kartenschnittstellenunterstützung
anhand des Objekttyps (privater Schlüssel, öffentlicher Schlüssel, Zertifikat etc.) eindeutig identifiziert werden. Wenn es sich um keine TCOS-Karten handelt, sieht die Kennung
entsprechend anders aus. Bei PC/SC und OCF wird das Referenzieren auf der Kartenbetriebssystemebene gemacht. Objekte werden mit einem eindeutigen Pfad im Dateisystem
identifiziert, der gemäß dem Standard ISO 7816 gebildet wird und für TCOS-2.0-Karten
beispielsweise wie folgt aussieht: :3f00:4101:4e03.
Da sich die Objekt-IDs in Abhängigkeit von der Kartenschnittstelle und dem Kartentyp unterscheiden, muss FlexCardAdmin die Möglichkeit bieten, jeder Kombination aus
Applikation, Kartenschnittstelle, Kartentyp und Objekttyp eine spezifische Objekt-ID zuzuordnen, die in dieser Konstellation“ benutzt werden soll, um das Objekt auszulesen
”
oder auf der Karte zu schreiben.
4.2 Analyse der Kartenschnittstellen
Die Kommunikation mit der Chipkarte kann über verschiedene standardisierte SmartcardSchnittstellen realisiert werden. Damit die Flexibilität vom FlexCardAdmin gewährleistet
wird, sollte dieser in der Lage sein alle Kartenschnittstellen zu unterstützen. Das Framework SmartcardServices, das als Basis der Implementierung benutzt wird, hilft diese Aufgabe zu erfüllen, da sie eine Abstraktionsebene darstellt und die Chipkartenfunktionen
unabhänging von der verwendeten Kartenschnittstelle zur Verfügung stellt. Die eigentliche
Implementierung, die benutzt wird, bleibt für die Anwender transparent.
34
KAPITEL 4. DESIGNENTSTEHUNG
4.2.1 Anforderungen an die Umgebung
Obwohl das Framework eine gewisse Flexibilität mit sich bringt, bietet es keine Funktionalität zur Vorbereitung der Umgebung (in diesem Fall der Clientrechner) an, damit
die Kartenschnittstellen benutzbar sind. Die Kartenschnittstellen müssen nämlich zuerst
installiert und initialisiert werden, bevor sie einsatzbereit sind; sie stellen gewisse Anforderungen an die Umgebung. D.h. jede Anwendung, die das Framework SmartcardServices
benutzt, muss selbst sicherstellen, dass alle Vorbereitungen zur Kartenschnittstelleninitialisierung getroffen wurden. Um das zu vermeiden, muss ein übergreifendes Konzept
zur Kartenschnittstelleninitialisierung entwickelt und vom FlexCardAdmin realisiert werden, so dass kein zusätzlicher Aufwand von Benutzerseite verursacht wird. Dafür muss
analysiert werden, wie jede Kartenschnittstelle initialisiert wird, um Gemeinsamkeiten zu
finden, die für die Spezifizerung des Konzeptes wichtig sind.
Initialisierung der Framework-Schnittstelle zu PC/SC Um die FrameworkSchnittstelle zu PC/SC zu benutzen, ist folgendes notwendig:
• Java-Wrapper JPC/SC jpcsc.jar [7] im Java-Classpath und die dazugehörige
native Bibliothek für das verwendete Betriebssystem (jpcsc.dll, jpcsc.so) in
java.library.path.
• FlexiCoreProvider-1-1-5p3.signed.jar (oder eine andere Version des FlexiProviders) und codec.jar im Java-Classpath, um PKCS#10-Zertifikatsanträge zu erstellen
• eine native PC/SC-Bibliothek (Treiber) in java.library.path in Abhängigkeit
vom Betriebssystem für jeden Kartenleser, der unterstützt werden soll. Die meisten Kartenleser unterstützen PC/SC und keine zusätzliche Treiber müssen geladen
werden.
• Konfigurationsdateien und sonstige Daten, die vom Kartenleser benötigt werden,
z.B. smartkey.inf und ct32br.dll beim Kobil Kaan Advanced Kartenleser.
• die ApduChannelCard-Implementierung, die verwendet werden soll, muss angegeben
werden, z.B. de.tud.cdc.cardservices.tcos20.TCOS20Card
• Chipkartenspezifische Properties müssen geladen werden, z.B. tcos20.properties
für TCOS-2.0-Chipkarten.
Initialisierung der Framework-Schnittstelle zu PKCS#11 Um die FrameworkSchnittstelle zu PKCS#11 zu benutzen ist folgendes notwendig:
• der Java-PKCS#11-Provider p11.jar [1] im Java-Classpath und die zugehörige native Bibliothek für das verwendete Betriebssystem (nativepkcs11.dll,
libnativepkcs11.so) in java.library.path
• FlexiCoreProvider-1-1-5p3.signed.jar (oder eine andere Version des FlexiProviders) und codec.jar im Java-Classpath, um PKCS#10-Zertifikatsanträge zu erstellen
35
KAPITEL 4. DESIGNENTSTEHUNG
• eine native PKCS#11-Bibliothek (Treiber) in java.library.path in Abhängigkeit
vom Betriebssystem für jeden Kartenleser, der unterstützt werden soll. (z.B. die
Bibliothek für Kobil-Kartenleser kpkcs11hash.dll oder libkpkcs11hash.so)
• Konfigurationsdateien und sonstige Daten, die vom Kartenleser benötigt werden,
z.B. smartkey.inf und ct32br.dll beim Kobil Kaan Advanced Kartenleser.
• Die Chipkarte muss nicht spezifiziert werden, da PKCS#11 eine High-LevelKartenschnittstelle ist, die vom Betriebssystem der Smartcard abstrahiert. Dies bedeutet, dass die PKCS#11-Implementierung prinzipiell mit allen Smartcards funktionsfähig ist.
• Chipkartenspezifische Properties müssen geladen werden, z.B. tcos20.properties
für TCOS-2.0-Chipkarten.
Initialisierung der Framework-Schnittstelle zu OCF Um die Frameworkschnittstelle
zu OCF (über einen PC/SC-Treiber) zu benutzen, ist folgendes notwendig:
• OCF-Wrapper fur PC/SC pcsc-wrapper-2.0.jar [2] im Java-Classpath und die
zugehörige native Bibliothek für das verwendete Betriebssystem (ocfpcsc1.dll) in
java.library.path
• FlexiCoreProvider-1-1-5p3.signed.jar (oder eine andere Version des FlexiProviders) und codec.jar im Java-Classpath, um PKCS#10-Zertifikatsanträge zu erstellen
• eine native PC/SC-Bibliothek (Treiber) in java.library.path in Abhängigkheit
vom Betriebssystem für jeden Kartenleser, der unterstützt werden soll. Wie schon
erwähnt, unterstützen die meisten Kartenleser PC/SC und keine zusätzliche Treiber
müssen geladen werden.
• Konfigurationsdateien und sonstige Daten, die vom Kartenleser benötigt werden,
z.B. smartkey.inf und ct32br.dll beim Kobil Kaan Advanced Kartenleser
• Die ApduChannelCard-Implementierung, die verwendet werden soll, muss angegeben werden, z.B. de.tud.cdc.cardservices.tcos20.TCOS20Card für TCOS-2.0Chipkarten.
• Chipkartenspezifische Properties müssen geladen werden, z.B. tcos20.properties
für TCOS-2.0-Chipkarten.
• Die Konfigurationsdatei opencard.properties [3] muss sich in einem der folgenden
Verzeichnisse befinden:
– [java.home]/lib/opencard.properties
– [user.home]/.opencard.properties
– [user.dir]/opencard.properties
– [user.dir]/.opencard.properties
Basierend auf den obigen Informationen können die Daten, die benötigt werden, um
die Schnittstellen zu initialisieren, in folgende Kategorien aufgeteilt werden:
36
KAPITEL 4. DESIGNENTSTEHUNG
• Externe Bibliotheken
• Kartenschnittstellenspezifische Daten
– native Bibliotheken
– Konfigurationsdateien
– Kartenlesertreiber für die konkrete Kartenschnittstelle
• Kartenleserspezifische Daten
– native Bibliotheken (Kartenlesertreiber)
– Konfigurationsdateien
• Chipkartenspezifische Daten
– Konfigurationsdateien (Java-Property-Format)
Die externen Bibliotheken werden als zusätzliche Archive in der Applikation eingebunden, d.h. ihr Deployment verursacht keinen zusätzlichen Implementierungsaufwand. Beim
Starten des Applets werden sie vom Server auf den Clientrechner heruntergeladen und stehen dem Applet zur Verfügung. Die nativen Bibliotheken und die Konfigurationsdateien
der Kartenschnittstellen müssen wiederum zur Laufzeit geladen werden. Voraussetzung
ist, dass die zu verwendende Kartenschnittstelle bekannt ist, damit die entsprechenden
Bibliotheken geladen werden. Die Kartenlesertreiber und die Konfigurationsdateien der
Chipkarten können auch nur zur Laufzeit geladen werden, nachdem die Applikation ermittelt hat, welche Kartenleser und Chipkarte gerade verwendet werden. Wie erkennt
die Applikation die gerade verwendeten Kartenschnittstelle, Kartenleser und Karte? Die
folgenden Abschnitten befassen sich mit der Beantwortung dieser Frage.
4.2.2 Auswahl der Kartenschnittstelle
Beim Starten des Applets muss festgelegt werden welche Kartenschnittstelle benutzt
werden soll. Dies ist notwendig, damit die Applikation weiß, welche SmartcardServiceImplementierung zu verwenden ist. Zwei Möglichkeiten sind hier vorgesehen: der Benutzer
kann die Kartenschnittstelle auf der Benutzeroberfläche auswählen oder die Kartenschnittstelle wird vom Administrator als Konfigurationsparameter in der Konfigurationsdatei des
Applets angegeben. Die zweite Lösung ist besser aus der Sicht der Benutzer, weil die Benutzer die verschiedenen Kartenschnittstellen nicht kennen müssen und die Auswahl der
richtigen Kartenschnittstelle ist schwierig oder unmöglich. Diese Lösung hat aber auch
einen Nachteil. Wenn die Kartenschnittstelle einmal konfiguriert ist, wird diese für jede
Operation verwendet, die die Benutzer ausführen möchten. Es gibt allerdings Kartenschnittstellen, die nicht alle Operationen unterstützen, die mit dem Applet ausgeführt
werden sollen; z.B. eine Chipkarte kann über die PKCS#11-Schnittstelle nicht gelöscht
werden. Wenn ein Benutzer versucht, seine Karte zu löschen und die Applikation für
die PKCS#11-Kartenschnittstelle konfiguriert ist, würde die Operation fehlschlagen. Das
bedeutet, dass die angegebene Kartenschnittstelle nur als Defaultschnittstelle betrachtet
werden muss. Sobald eine Operation ausgeführt werden soll, die von dieser Kartenschnittstelle nicht unterstützt wird, muss das Applet im Hintergrund die Kartenschnittstelle mit
37
KAPITEL 4. DESIGNENTSTEHUNG
einer anderen austauschen, mit der die Operation ausführbar ist.
Sowohl die Angabe der Kartenschnittstelle als Konfigurationsparameter, als auch die
Angabe über die Benutzeroberfläche, soll mit dem Applet möglich sein, damit die Flexibilität erhalten bleibt. Die Angabe über die Benutzeroberfläche kann außerdem zu Testzwecken sehr praktisch sein. Wenn keine Kartenschnittstelle in der Konfigurationsdatei
des Applets angegeben wurde, soll auf der ersten Seite des Applets eine Liste mit den
unterstützten Kartenschnittstellen erscheinen. Der Benutzer kann die gewünschte Kartenschnittstelle auswählen. Falls die Kartenschnittstelle vorkonfiguriert wurde, wird die
Auswahlmöglichkeit auf der Benutzeroberfläche entfernt.
4.2.3 Auswahl des Kartenlesers
Die meisten Kartenschnittstellen können ohne Kenntnis des Kartenlesers, der verwendet
wird, initialisiert werden. Dies ist nur bei der PKCS#11-Kartenschnittstelle nicht der
Fall. Für die Kartenschnittstelleninitialisierung verlangt der Java-PKCS#11-Provider die
Angabe des PKCS#11-Kartenlesertreibers. Treiber sind kartenleserspezifisch, d.h es gibt
keinen Default-Treiber, der für alle Kartenleser benutzt werden kann. Man muss genau den
Treiber des Kartenlesers angeben, der gerade verwendet wird. Der verwendete Kartenleser muss also bekannt sein, bevor die Kartenschnittstelle initialisiert ist. Die automatische
Erkennung des Kartenlesers ist aber zu diesem Zeitpunkt nicht möglich, weil ohne initialisierte Kartenschnittstelle keine Vebindung zum Kartenleser aufgebaut werden kann und
somit keine Information über den Kartenleser verfügbar ist. Die einzige Möglichkeit, die
übrig bleibt, ist die Angabe des verwendeten Kartenlesers über die Benutzeroberfläche
oder als Parameter in der Konfigurationsdatei vom FlexCardAdmin, wenn man davon
ausgehen kann, dass immer derselbe Kartenlesertyp mit dem Applet verwendet wird. Je
nachdem welcher Kartenleser gewählt wurde, muss das Applet den entsprechenden Treiber finden und diesen dem Java-PKCS#11-Provider übergeben. Das bedeutet auch, dass
die (betriebssystemspezifischen) Treiber aller Kartenleser, die unterstützt werden sollen,
der Applikation bekannt und in dem Lieferpaket enthalten sein müssen.
Auf den ersten Blick könnte man sagen, dass die Kartenleserangabe für die anderen Kartenschnittstellen nicht notwendig ist und die Auswahl des Kartenlesers (über die Benutzeroberfläche oder in der Konfigurationsdatei) nur für die PKCS#11-Schnittstelle implementiert werden muss. Die restlichen Schnittstellen können ohne die Kartenleserangabe
bzw. ohne die Angabe eines konkreten Kartenlesertreibers initialisiert werden. Es kann
aber passieren, dass für den Kartenleser, der gerade verwendet wird, doch ein Treiber für
die Schnittstelle geladen werden muss, damit die Kommunikation mit dem Kartenleser
über diese Schnittstelle möglich ist.Dieses Problem kann folgendermaßen gelöst werden:
alle der Applikation bekannten Kartenlesertreiber werden bei der Initialisierung der Kartenschnittstelle geladen, ohne den konkreten Treiber zu kennen, der tatsächlich benötigt
wird. Der Kartenleser erkennt später den richtigen Treiber und verwendet ihn.
Bis jetzt spricht also alles dafür, die Kartenleserangabe nur für die PKCS#11-Schnittstelle
38
KAPITEL 4. DESIGNENTSTEHUNG
zu ermöglichen. Allerdings gibt es Fälle, in denen die Kartenschnittstelle mitten in der
Ausführung des Applets ausgetauscht werden muss. Dies ist notwendig, wenn die gewählte Kartenschnittstelle die auszuführende Smartcardoperation nicht unterstützt. In diesem
Fall wird die Kartenschnittstelle im Hintergrund gegen die Defaultschnittstelle ausgetauscht. Wenn die Default-Kartenschnittstelle beispielsweise PKCS#11 ist und die Angabe des verwendeten Kartenlesers verlangt, stößt man auf das Problem, dass das Applet den
richtigen Kartenlesertreiber nicht kennt, weil die urspünglich gewählte Kartenschnittstelle
diesen nicht kennt. Somit kann die Default-Kartenschnittstelle nicht initialisiert werden.
Um dieses Problem zu umgehen ist die Entscheidung gefallen, die Möglichkeit zur Auswahl
des Kartenlesers (auf der Benutzeroberfläche oder in der Konfigurationsdatei) für jede
Kartenschnittstelle anzubieten und nicht nur speziell für die PKCS#11-Schnittstelle.
Es bleibt nur noch zu klären, wie der richtige Treiber erkannt wird, nachdem ein Kartenleser ausgewählt wurde. Es muss eine Zuordnung zwischen dem Kartenleser und seinem
Treiber geben. Diese kann in der Konfigurationsdatei des Applets abgebildet werden.
Für jede Kombination aus Kartenleser, Kartenschnittstelle und Betriebssystem muss ein
Konfigurationsparameter angelegt werden, dessen Wert der Name der entsprechenden
Treiberdatei ist.
4.2.4 Auswahl der Chipkarte
Alle Kartenschnittstellen bis auf PKCS#11 verlangen bei ihrer Initialisierung die Angabe der verwendeten Chipkarte. Die ApduChannelCard-Implementierung, die verwendet werden soll, muss als Property der Kartenschnittstelle angegeben werden (z.B.
de.tud.cdc.cardservices.tcos20.TCOS20Card im Fall von TCOS-2.0-Chipkarten).
Die PKCS#11-Schnittstelle verlangt nicht die Kartenangabe, da sie eine High-LevelKartenschnittstelle ist, die vom Betriebssystem der Smartcard abstrahiert und prinzipiell mit allen Smartcards funktionsfähig ist. Trotzdem muss die verwendete Chipkarte
bekannt sein, damit die kartenspezifischen Properties geladen werden können. Genauso wie bei den Kartenlesern ist die automatische Erkennung der Karte nicht möglich,
weil keine Verbindung zu der Karte aufgebaut werden kann bevor die Kartenschnittstelle
initialisiert ist. D.h. der Typ der verwendeten Chipkarte muss angegeben werden. Hier
gibt es, wie bei der Auswahl der Kartenschnittstelle und des Kartenlesers, folgende zwei
Möglichkeiten: Die Chipkarte wird entweder auf der Benutzeroberfläche ausgewählt oder
als Konfigurationsparameter in der Konfigurationsdatei angegeben. Falls kein Konfigurationsparameter angegeben wurde, erscheint auf der ersten Seite des Applets eine Liste der
unterstützten Smartcards und der Benutzer muss diejenige auswählen, die zu seiner Karte
passt. Falls eine Smartcard in der Konfigurationsdatei angegeben wird, verschwindet die
Auswahlmöglichkeit aus der Benutzerobrfläche.
39
KAPITEL 4. DESIGNENTSTEHUNG
4.2.5 Die Verknüpfung Kartenschnittstelle - Kartenoperation
Es gibt Operationen, die nicht über jede beliebige Kartenschnittstelle realisierbar sind.
Das Applet muss flexibel genug sein, um zu erkennen, ob eine Operation mit der gewählten Kartenschnittstelle ausführbar ist und entsprechend reagieren. Die Operation muss
über die Kartenschnittstelle realisiert werden, über die dies möglich ist. D.h es muss eine Default-Kartenschnittstelle für jede Operation definiert werden. Abbildung 4.1 zeigt
welche Operation von welcher Kartenschnittstelle unterstützt wird.
4.3 Kommunikation mit dem Enrollment-Server
FlexCardAdmin soll mit der vorhandenen Lösung von FlexSecure interagieren, insbesondere mit dem Enrollment-Server. Um dies zu realisieren, müssen die möglichen Formen
der Appletintegration analysiert werden und die Schnittstellen, über die die Interaktion
stattfinden soll, definiert werden.
Das erste Szenario wäre, dass das Grundgerüst der bestehenden FlexSecure-Lösung
unverändert bleibt und lediglich der Teil, der die Kommunikation mit der Chipkarte
übernimmt, durch das neue Applet ersetzt wird. D.h. Benutzer loggen sich weiterhin über
die Enrollment-Seite ein und anschließend wird das Applet gestartet, das die Verbindung
zu der Karte aufbaut. Im Detail bedeutet dies, dass folgende Schritte durchlaufen werden:
• Schritt 1: Login über die Enrollment-Seite
Der Benutzer möchte eine bestimmte Operation mit seiner Chipkarte ausführen.
Er hat die notwendige TAN beantragt und bekommen. Er meldet sich mit seinem
Benutzernamen, Passwort und TAN auf der Login-Seite des Enrollment-Servers an,
um die Operation auszuführen. Der Enrollment-Server leitet die Daten weiter an
ESI.
• Schritt 2: Datenprüfung (ESI)
ESI überprüft die Benutzerdaten mittels Datenbankabfragen sowie Abfragen am
LDAP-Server.
• Schritt 3: Kommunikation mit der Chipkarte mittels FlexCardAdmin
An dieser Stelle wird das Applet aufgerufen. Je nachdem welche Operation ausgeführt wird, werden Daten auf die Karte geschrieben, aktualisiert oder gelöscht.
Daten, die das Applet eventuell benötigt, werden von der Enrollment-Webseite übergeben. Und umgekehrt alle Daten, die sich aus der Appletausführung ergeben, werden an die Enrollment-Seite weitergeleitet.
• Schritt 4: Datenübertragung (ESI)
Die Enrollment-Seite kümmert sich darum, dass die richtigen Empfänger (z.B. die
CA) diese Daten bekommen.
40
KAPITEL 4. DESIGNENTSTEHUNG
Die Schnittstelle zwischen dem Applet und der Enrollment-Seite muss spezifiziert
werden. Es muss festgelegt werden, wie das Applet Daten von der Seite übergeben
bekommt und umgekehrt wie das Applet Daten an die Seite schickt.
Jedes Mal, wenn eine Chipkartenoperation ausgeführt werden soll, muss sich der Benutzer
neu auf der Enrollment-Seite anmelden und das Applet wird neu gestartet. Beim Initialisieren des Applets werden alle benötigten Bibliotheken neu geladen. Dies kann einige
Sekunden dauern. Nachdem das Applet gestartet ist und auf der Benutzeroberfläche des
Applets die gewünschte Kombination aus Karte, Kartenleser und Kartenschnittstelle
gewählt wurde (falls dies nicht schon vorkonfiguriert war), werden zusätzlich die Kartenlesertreiber sowie alle Bibliotheken, die die Kartenschnittstellen benötigen, geladen.
D.h., die Wartezeiten zum Starten des Applets könnten steigen, wenn man mehrere
Operationen nacheinander ausführen möchte und das Applet mehrfach gestartet wird.
Um dieses Problem zu umgehen, könnte man das Einloggen am Enrollment-Server in
das Applet integrieren. Im Prinzip heisst das, dass die Enrollment-Seite in ein Applet
konvertiert wird. In diesem Fall würden folgende Schritte durchlaufen werden:
• Schritt 1: FlexCardAdmin starten
Wenn die Login-Seite des Enrollment-Servers aufgerufen wurde, wird das Applet
gestartet.
• Schritt 2: Login zum Enrollment-Server über das Applet
Der Benutzer meldet sich über die Benutzeroberfläche des Applets am EnrollmentServer mit seinem Benutzernamen, Passwort und TAN an. Hier muss die Logik
zum Aufbau der Verbindung zum Enrollment-Server aus der Login-Seite im Applet
übernommen werden.
• Schritt 3: Datenprüfung (ESI)
ESI überprüft die Benutzerdaten mittels Datenbankabfragen sowie Abfragen am
LDAP-Server.
• Schritt 4: Kommunikation mit der Chipkarte mittels FlexCardAdmin
Das Applet baut die Verbindung zu der Chipkarte auf und führt die gewünschte
Operation aus.
• Schritt 5: Datenübertragung (ESI)
Das Applet wird nur einmal gestartet, auch wenn man mehrere Operationen nacheinander ausführen möchte. Nach dem Initialisieren des Applets, während dessen alle benötigten Bibliotheken geladen werden, erscheint eine Benutzeroberfläche zum Einloggen, über
den der Benutzer sich am Enrollment-Server anmelden kann, bevor er eine Operation
ausführt. Um eine neue Operation auszuführen, muss man nur zu diese Login-Seite des
Applets zurückspringen und sich mit einer anderen TAN einloggen. Das Laden der Bibliotheken muss aber nicht wiederholt werden (solange man mit derselben Karte und
demselben Kartenleser arbeitet), somit werden die Wartezeiten verringert.
Das erste Szenario ist mit geringem Aufwand verbunden. Neben der Implementierung des
41
KAPITEL 4. DESIGNENTSTEHUNG
Applets selbst, muss die Schnittstelle zwischen dem Applet und der Enrollment-Seite definiert werden. Das Applet muss zusätzlich in der Seite integriert werden. Um das zweite
Szenario zu realisieren ist der Aufwand größer, weil man zusätzlich den kompletten Inhalt der Enrollment-Seite in das Applet übertragen muss. Wenn es oft vorkommt, dass
mehrere Chipkartenoperationen direkt nacheinander ausgeführt werden und wenn es vorgesehen ist, dass ein Benutzer mehr als eine TAN gleichzeitig besitzen darf, wäre die zweite
Lösung die bessere, ansonsten ist die erste Lösung akzeptabel. In dieser Arbeit wird das
erste Szenario umgesetzt.
42
Kapitel 5
Technisches Konzept und
Implementierung
Der Fokus dieses Kapitels ist auf die technische Umsetzung der Anforderungen gerichtet.
Die Software-Komponenten und deren Zusammenspiel werden dargestellt. Der Leser soll
somit befähigt werden, das verwendete Designprinzip zu verstehen und einen leichten
Einstieg zu finden, wenn Änderungen am System vorgenommen werden sollen.
5.1 Aufbau der Software
FlexCardAdmin ist ein Java-Applet, das in den HTML-Seiten des Enrollment-Servers integriert wird. Jedes Mal wenn die Webseite aufgerufen wird, wird der Appletcode auf
dem Clientrechner heruntergeladen und von der Java-Virtual-Machine des Browsers ausgeführt. Der Browser muss dafür Java-fähig sein. Neben der Anwendungslogik stellt das
Applet eine Benutzeroberfläche zur Verfügung. Der Aufbau und das Zusammenspiel dieser
Komponenten ist an das Model-View-Controller“-Pattern (MVC) angelehnt. Das MVC”
Pattern ist das Standardpattern für Anwendungen, die Benutzerinteraktion voraussetzen
und eine Schnittstelle zum Benutzer anbieten. MVC ermöglicht die klare Trennung der
Benutzeroberfläche von der Programmlogik. Durch diese Modularisierung lassen sich die
einzelnen Komponenten leicht austauschen, die Anwendung gewinnt an Flexibilität und
Wiederverwendbarkeit und kann leichter gewartet werden. MVC besteht aus den drei
Komponenten Model, View und Controller. Das Model enthält die Anwendungslogik, die
View repräsentiert die Benutzeroberfläche und der Controller definiert wie die Anwendung
auf Benutzereingaben reagieren soll (siehe Abbildung 5.1). In FlexCardAdmin übernehmen diese Komponenten folgende Aufgaben:
• Die View repräsentiert die Benutzeroberfläche des Applets, die in Form eines Wizards aufgebaut ist. Die wichtigsten Klassen der View sind Wizard, WizardPanel
und WizardPanelDescriptor.
• Das Model ist für die Initialisierung der Kartenschnittstellen zuständig und baut die
Verbindung zum Kartenleser und Smartcard über die gewählte Kartenschnittstelle
auf. Es ermöglicht das Laden verschiedener Bibliotheken und Properties, die von
den Kartenschnittstellen, Kartenlesern und Smartcards benötigt werden. Außerdem
43
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
lassen sich durch das Model die IDs der Kartenobjekte konstruieren, damit sie referenziert werden können. Die wichtigsten Klassen des Models sind Model, Loader,
CardPropLoader, CardReaderPropLoader und ObjectIdentifier.
• Die Hauptaufgabe des Controllers ist die Verarbeitung der Benutzereingaben
auf der Benutzeroberfläche und die Ausführung der Smartcardoperationen. Die
WizardPanelDescriptor-Klassen agieren als Vermittler zwischen der View und dem
Controller und leiten die Benutzereingaben an den Controller weiter. Der Controller
stellt für jede primitive Smartcardoperation eine Action-Klasse zur Verfügung. In
Abhängigkeit davon, welche Smartcardoperation ausgeführt werden muss, instanziiert der Controller eine der Action-Klassen, die für die Ausführung der Smartcardoperation zuständig ist.
In den folgenden Abschnitten werden diese drei Komponenten näher beschrieben.
Abbildung 5.1: Model-View-Controller-Pattern
5.2 Die Benutzeroberfläche
Die
Klassen
der
Benutzeroberfläche
befinden
sich
im
Paket
de.flexsecure.flexiTrust.flexcardadmin.view und seinen Unterpakete. Die
Benutzeroberfäche basiert auf dem Java-Swing-Framework und ist in Form eines Wizard
[wiz] aufgebaut.
5.2.1 Wizard
Die Klasse Wizard definiert den Rahmen des Wizards und ist der Container für verschiedene JPanels, die eingebunden werden können und die den Wizard mit Inhalt füllen. Die
zwei Tasten Weiter“ und Zurück“ dienen zur Navigation und zum Blättern durch die
”
”
Panels. Jedes Panel soll seinen Vorgänger und seinen Nachfolger spezifizieren. Unter bestimmten Bedingungen können sich der Nachfolger und der Vorgänger eines bestimmten
Panels ändern. Wenn das aktuelle Panel keinen Vorgänger hat, wird die Taste Zurück“
”
deaktiviert, und wenn kein Nachfolger vorhanden ist, ist die Weiter“-Taste inaktiv. Der
”
44
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Wizard enthält zusätzlich eine Dropdown-Liste zur Auswahl der gewünschten Sprache.
Der Wizard besitzt ein Model und einen Controller. WizardModel hält die Wizarddaten
und den Wizardzustand, z.B. kennt WizardModel das aktuell im Wizard angezeigte Panel. WizardController bearbeitet die Events, die vom Wizard kommen, wenn die Tasten
gedrückt werden.
5.2.2 WizardPanel
Die Panels, die in den Wizard hinzugefügt werden können, sind Unterklassen von
WizardPanel. WizardPanel definiert die einheitliche Struktur seiner Unterklassen. Jedes Panel besitzt einen Titel, der im oberen Teil angezeigt wird. Im unteren Teil ist
Platz für Fehlermeldungen vorgesehen. Am linken Rand befindet sich eine Leiste, die
die gerade ausgeführte Operation anzeigt. In der Mitte kann jede Unterklasse von
WizardPanel ihren spezifischen Inhalt anzeigen. Abbildung 5.2 zeigt den Aufbau des
Wizards. Das Template Method-Design-Pattern [GHJV95] findet hier Verwendung. Die
Methode initComponents() der Klasse WizardPanel ist die Template-Methode, die die
Komponenten jedes Panels erzeugt. Sie ruft zusätzlich die Methode getMainPanel() auf,
die von jeder Unterklasse implementiert werden muss und den panelspezifischen Inhalt
definiert.
Abbildung 5.2: Der Aufbau des Wizards
Abbildung 5.3 zeigt alle WizardPanel-Klassen im Überblick. Wenn das Applet gestartet wird, wird zuerst das ConfigurationPanel im Wizard angezeigt. Dieses bietet die
Möglichkeit, die verwendete Kartenschnittstelle, den Kartenleser und die Smartcard auszuwählen. Da diese Angaben auch vom Administrator vorkonfiguriert werden können,
müssen sie nicht immer über die Benutzeroberfläche gemacht werden. Deshalb hat das
ConfigurationPanel unterschiedliche Versionen, je nachdem was konfiguriert wurde und
45
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
was über die Benutzeroberfläche angegeben werden muss. Einige dieser Versionen sieht
man in Abbildungen A.1 und A.2 im Anhang A.
Abbildung 5.3: Übersicht der WizardPanels
Je nachdem welche Smartcardoperation ausgeführt werden soll, wird als nächstes das
Panel für diese Operation angezeigt. Für jede Smartcardoperation ist ein WizardPanel
vorgesehen:
• PersonaliseCardPanel: wird angezeigt, wenn eine Karte personalisiert werden soll
(auch wenn eine Notfall- oder Ersatzkarte erstellt wird). Der Benutzer muss die
Smartcard-PIN eingeben, bevor die Karte personalisiert werden kann. Der Inhalt
des Panels hängt davon ab, ob die PIN-Eingabe über den Kartenleser oder über die
Benutzeroberfläche gemacht wird. Im ersten Fall wird im Panel einen Text angezeigt,
der beschreibt, wieviel mal die PIN am Kartenleser angegeben werden muss. Im
zweiten Fall werden zwei Eingabefelder angezeigt, in denen der Benutzer die PIN
eingeben muss. Abbildung A.3 im Anhang A zeigt das PersonaliseCardPanel.
• DeleteCardPanel: wird angezeigt, wenn eine Karte gelöscht werden soll.
Das Löschen der Karte erfolgt nach einer PIN-Eingabe. Genauso wie beim
PersonaliseCardPanel variiert der Panelinhalt in Abhängigkeit von der Art der
PIN-Eingabe. Wenn die PIN-Eingabe über den Kartenleser gemacht wird, erscheint
im Panel einen Text, der den Benutzer darauf hinweist, die PIN am Kartenleser
einzugeben. Wenn die PIN-Eingabe über die Benutzeroberfläche realisiert werden
soll, erscheint ein Eingabefeld, in dem die PIN eingegeben werden muss. Abbildung
A.4 im Anhang A zeigt das DeleteCardPanel.
• ChangePINPanel: wird angezeigt, wenn der Benutzer die PIN seiner Smartcard
ändern möchte. Das Panel enthält Felder zur Eingabe der bisherigen und der neuen PIN oder Text mit Instruktionen, wenn die PIN-Eingabe über den Kartenleser
erfolgt. Abbildung A.6 im Anhang A zeigt das ChangePINPanel.
46
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
• ResetPINPanel: wird angezeigt, wenn die PIN der Karte entsperrt werden soll.
Der Benutzer wird aufgefordert die neue PIN der Karte anzugeben (entweder am
Kartenleser oder auf der Benutzeroberfläche). Abbildung A.5 im Anhang A zeigt
das ResetPINPanel.
5.2.3 WizardPanelDescriptor
Jedes WizardPanel besitzt einen Identifikator, der eine Unterklasse von
WizardPanelDescriptor ist und dazu dient, das Panel identifizieren und referenzieren zu können. Wenn man durch die Panels im Wizard blättert und die Weiter“”
oder Zurück“-Taste drückt, kann das aktuelle Panel seinen Nachfolger oder Vorgänger
”
anhand des Identifikators referenzieren und im Wizard anzeigen lassen. Jedes konkrete
WizardPanelDescriptor spezifiziert außerdem das Verhalten kurz bevor, während und
nachdem ein Panel im Wizard angezeigt wird. Somit können die Benutzereingaben
von der Benutzeroberfläche an den Controller geschickt und dort im Hintergrund
die gewünschte Operation ausgeführt werden. Ein WizardPanelDescripor hat die
Aufgabe, die Benutzereingaben an den Controller weiterzuleiten. Abbildung 5.4 gibt
eine Übersicht der vorhandenen Identifikatoren. Wie man sieht, ist die Hierarchie der
WizardPanelDescriptors parallel zur Hierarchie der WizardPanels.
Abbildung 5.4: Übersicht der WizardPanelDescriptors
Die wichtigsten Methoden von WizardPanelDescriptor sind (siehe auch Abbildung
5.5):
• getPanelDescriptorIdentifier(): liefert die Kennung des Panels, das mit diesem
WizardPanelDescriptor identifiziert wird, in Form von einem String.
47
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
• setPanelDescriptorIdentifier(Object id): setzt die Kennung des Panels.
• getPanelComponent(): liefert das Panel, das mit diesem WizardPanelDescriptor
identifiziert wird.
• setPanelComponent(WizardPanel panel): setzt das Panel, das mit diesem
WizardPanelDescriptor identifiziert werden soll.
• getNextPanelDescriptor(): liefert die Kennung des nächsten Panels, das beim
Klicken auf Weiter“ angezeigt werden soll. Diese Methode wird jedes Mal beim
”
Drücken des Weiter“-Buttons aufgerufen. Sie muss von jeder Unterklasse über”
schrieben werden.
• getBackPanelDescriptor(): liefert die Kennung des vorherigen Panels, das beim
Klicken auf Zurück“ angezeigt werden soll. Diese Methode wird jedes Mal beim
”
Drücken der Zurück“-Taste aufgerufen. Sie muss von jeder Unterklasse überschrie”
ben werden.
• aboutToHidePanel(): hier soll jede Unterklasse definieren, welche Aktionen ausgeführt werden sollen, bevor das Panel aus dem Wizard entfernt wird.
• displayingPanel(): hier soll jede Unterklasse definieren, welche Aktionen ausgeführt werden sollen, während das Panel angezeigt wird.
• aboutToDisplayPanel(): hier soll jede Unterklasse definieren, welche Aktionen ausgeführt werden sollen, bevor das Panel angezeigt wird.
Abbildung 5.5: Die Klasse WizardPanelDescriptor mit ihren Methoden
48
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
5.3 Das Model
Die Model-Klassen befinden sich im Paket de.flexsecure.flexiTrust.flexcardadmin.
model und seine Unterpakete. Diese halten alle Informationen bezüglich der verwendeten
Kartenschnittstelle, Kartenleser und Smartcard und haben die Aufgabe, die Verbindung
zum Kartenleser und Smartcard über die gewählte Kartenschnittstelle aufzubauen. Das
Model kann erst dann initialisiert werden, wenn es klar ist, welche Kartenschnittstelle, Kartenleser und Smartcard verwendet werden. Da dies im ersten Panel des Applets
(ConfigurationPanel) vom Benutzer festgelegt wird, wird das Model erst dann initialisiert, wenn der Benutzer seine Angaben gemacht hat und auf Weiter“ klickt. Im Fall,
”
dass die Angaben vom Administrator in der Konfigurationsdatei gemacht werden, wird
beim Klicken auf Weiter“ die Konfigurationsdatei ausgelesen. Die Benutzer- bzw. Admi”
nistratoreingaben werden an den Controller weitergeleitet, der diese verwendet, um das
Model zu instanziieren. Abbildung 5.6 zeigt die Klasse Model und ihre Methoden.
Wie im Abschnitt 4.2.1 schon angesprochen, werden drei Arten von Daten benötigt, um
die verwendete Kartenschnittstelle zu initialisieren und die Verbindung zur Smartcard
aufzubauen:
• kartenschnittstellenspezifische Daten
• kartenleserspezifische Daten
• smartcardspezifische Daten
Dementsprechend sind die Model-Klassen in drei Gruppen aufgeteilt:
• Die Klassen, die die kartenleserspezifischen Daten verwalten, werden im Paket
de.flexsecure.flexiTrust.flexcardadmin.model.reader gekapselt.
• Die Klassen, die die kartenspezifischen Daten verwalten, werden im Paket
de.flexsecure.flexiTrust.flexcardadmin.model.card gruppiert.
• Die Klassen, die eine bestimmte Kartenschnittstelle verwalten, werden in einem Unterpaket vom de.flexsecure.flexiTrust.flexcardadmin.model untergebracht. Zum Beispiel befinden sich im Paket de.flexsecure.flexiTrust.
flexcardadmin.model.pcsc die Klassen, die die Schnittstelle PC/SC verwalten.
Abbildung 5.9 gibt eine Übersicht aller Model-Klassen, die in den nächsten Abschnitten
beschrieben werden.
5.3.1 Verwaltung der Kartenschnittstellendaten
Für jede Kartenschnittstelle, die unterstützt werden soll, muss eine Klasse erzeugt werden,
die von Model erbt. Der Name jeder Unterklasse ist eine Konkatenation des Kartenschnittstellennamens, geschrieben in Großbuchstaben und ohne Sonderzeichen, und des Strings
Model“. Z.B. heißt die Klasse zur Verwaltung der PKCS#11-Schnittstelle PKCS11Model.
”
Bei der Instanziierung eines Models, werden die verwendeten Smartcard und Kartenleser
dem Model-Konstruktor übergeben. Anhand dieser Information wird die Verbindung zur
Smartcard aufgebaut.
49
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Abbildung 5.6: Die Klasse Model
Jedes Model besitzt drei Hilfsobjekte:
• Loader
• ReaderDriver
• ObjectIdentifier
Loader
Um die Daten zu laden, die von einer bestimmten Kartenschnittstelle benötigt werden,
besitzt jedes Model einen Loader und delegiert alle Ladeaufgaben an ihn. Dieser Loader
wird mit der Methode createLoader() erzeugt, die von jeder Unterklasse vom Model
implementiert werden muss und einen Loader vom gewünschten Typ erzeugt. Pro
Kartenschnittstelle existiert eine Unterklasse von Loader. Der Name jeder Unterklasse
ist, ähnlich wie bei den Model-Unterklassen, eine Konkatenation des Kartenschnittstellennamens, geschrieben in Großbuchstaben und ohne Sonderzeichen, und des Strings
Loader“. Die Methode createLoader() sowie die Beziehung zwischen den Model- und
”
Loader-Klassen ist nach dem Design-Pattern Factory Method [GHJV95] aufgebaut. Mit
Hilfe dieses Design-Patterns werden die zwei parallele Klassenhierarchien aller Models
und Loaders miteinander verbunden. Ein PCSCModel besitzt einen PCSCLoader, ein
PKCS11Model besitzt einen PKCS11Loader und so weiter.
Die wichtigsten Methoden eines Loaders, die von den konkreten Unterklassen implementiert werden und die in den gleichnamigen Model-Methoden aufgerufen werden, sind
(siehe auch Abbildung 5.7):
50
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
• loadLibraries(): lädt die von der konkreten Kartenschnittstelle benötigten nativen Bibliotheken, in Abhängigkeit des verwendeten Betriebssystems.
• loadReaderDrivers(): lädt alle Kartenlesertreiber, die in der Konfigurationsdatei
für die konkrete Kartenschnittstelle und für das verwendete Betriebssystem aufgelistet sind.
• loadProperties(): lädt smartcard-, kartenleser- sowie schnittstellenspezifische
Properties. Um die kartenleser- bzw. smartcardspezifische Properties zu laden, benutzt der Loader zwei Hilfsklassen CardPropLoader und CardReaderPropLoader,
auf die weiter unten näher eingegangen wird.
Abbildung 5.7: Die Klasse Loader mit den wichtigsten Methoden
ReaderDriver
Diese Klasse wird vom Framework SmartcardServices zur Verfügung gestellt und
dient dazu, die Verbindung zum Kartenleser aufzubauen. Bei der Instanziierung
eines ReaderDrivers müssen die Properties der verwendeten Smartcard, Kartenleser und Kartenschnittstelle dem Konstruktor übergeben werden. Hier wird die
Methode loadProperties() vom Loader benutzt, die diese Properties zurückgibt. Nachdem ein ReaderDriver instanziiert wurde, wird dieser mit der Methode
loadReaderDriver(ReaderDriver driver) der Klasse CardManager, die auch vom Framework SmartcardServices zur Verfügung gestellt wird, geladen. Nach dem Laden ist die
Verbindung zum Kartenleser aufgebaut und dieser kann angesrpochen werden.
Pro Kartenschnittstelle existiert eine Unterklasse von ReaderDriver. Der Name jeder
Unterklasse ist eine Konkatenation des Kartenschnittstellennamens, geschrieben in Großbuchstaben ohne Sonderzeichen, und des Strings ReaderDriver“. Ein ReaderDriver wird
”
mit der Methode createReaderDriver() der Klasse Model erzeugt, die von jeder Unter-
51
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
klasse von Model implementiert werden muss und einen ReaderDriver vom gewünschten
Typ zurückgibt.
Die Methode createReaderDriver() sowie die Beziehung zwischen den Model- und
ReaderDriver-Klassen ist nach dem Design-Pattern Factory Method aufgebaut. Mit Hilfe dieses Design-Patterns werden die zwei parallelen Klassenhierarchien aller Models und
ReaderDrivers miteinander verbunden. Ein PCSCModel besitzt einen PCSCReaderDriver,
ein PKCS11Model besitzt einen PKCS11ReaderDriver und so weiter.
ObjectIdentifier
Wie im Abschnitt 4.1.3 schon angesprochen, besitzen Objekte auf der Karte IDs
(CardObjectID), damit sie referenziert werden können. Diese IDs unterscheiden sich
in Abhängigkeit von der verwendeten Kartenschnittstelle und Smartcard. Mit dem
ObjectIdentifier lassen sich diese IDs konstruieren. Dieser verwendet dabei die Angaben in der Konfigurationsdatei vom FlexCardAdmin. Dort werden die IDs pro Applikation, Kartenschnittstelle und Kartentyp für die drei Arten von Objekten definiert:
öffentliche Schlüssel, private Schlüssel und Zertifikate. Die IDs werden in der Konfigurationsdatei als Strings angegeben. ObjectIdentifier wandelt diese in Objekte vom Typ
CardObjectID um. Außerdem liefert ObjectIdentifier Referenzen auf die einzelnen Objekte auf der Karte (CardObjectRef).
Pro Kartenschnittstelle muss eine Unterklasse von ObjectIdentifier definiert werden.
Der Name jeder Unterklasse ist eine Konkatenation des Kartenschnittstellennamens, geschrieben in Großbuchstaben ohne jegliche Sonderzeichen, und des Strings ObjectIden”
tifier“. Bei der Instanziierung eines ObjectIdentifiers wird der Typ der verwendeten
Smartcard dem Konstruktor übergeben. Somit ist klar für welche Smartcard die IDs konstruiert werden müssen.
Ein ObjectIdentifier wird mit der Methode createObjectIdentifier() der Klasse Model erzeugt, die von jeder Unterklasse von Model implementiert werden
muss und einen ObjectIdentifier vom gewünschten Typ zurückgibt. Die Methode createObjectIdentifier() sowie die Beziehung zwischen den Model- und
ObjectIdentifier-Klassen ist nach dem Design-Pattern Factory Method aufgebaut.
Mit Hilfe dieses Design-Patterns werden die zwei parallelen Klassenhierarchien aller
Models und ObjectIdentifiers miteinander verbunden. Ein PCSCModel besitzt einen
PCSCObjectIdentifier, ein PKCS11Model besitzt einen PKCS11ObjectIdentifier und
so weiter.
Jeder ObjectIdentifier besitzt einen CardObjectIdentifier, der die Konstruktion
der kartenspezifischen IDs übernimmt. Für jeden Kartentyp muss eine Unterklasse von
CardObjectIdentifier definiert werden. ObjectIdentifier bestimmt zur Laufzeit den
konkreten Typ des CardObjectIdentifiers, der instanziiert werden muss, in Abhängigkeit vom Kartentyp, der dem ObjectIdentifier-Konstruktor übergeben wird.
Abblidung 5.8 zeigt die wichtigsten Methoden von ObjectIdentifier.
52
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Abbildung 5.8: Die Klasse ObjectIdentifier mit den wichtigsten Methoden
5.3.2 Verwaltung der Kartenleserdaten
Um kartenleserspezifische Properties sowie andere Daten zu laden, gibt es die
Klasse CardReaderPropLoader. Für jeden Kartenleser muss eine Unterklasse von
CardReaderPropLoader definiert werden. Der Name jeder Unterklasse ist eine Konkatenation des Kartenlesernamens, geschrieben in Großbuchstaben ohne Sonderzeichen,
und des Strings CardReaderPropLoader“. Für die KOBIL-Kartenleser heißt die Klasse
”
KOBILCardReaderPropLoader. Diese stellt sicher, dass alle Voraussetzungen zur Einsatzbereitschaft der KOBIL-Kartenleser erfüllt sind:
• Die Konfigurationsdatei smartkey.inf muss sich im Homeverzeichnis des Benutzers
befinden.
• Die Bibliothek ct32br.dll bzw. libct.so muss sich im Homeverzeichnis des Benutzers befinden.
• In der Datei smartkey.inf soll das Attribut CT-Api mit dem Pfad zur Bibliothek
ct32br.dll bzw. libct.so initialisiert werden.
CardReaderPropLoaders werden vom Loader instanziiert. Der Loader bestimmt zur Laufzeit den konkreten Typ des CardReaderPropLoaders, in Abhängigkeit vom Kartenlesertyp, der dem Loader-Konstruktor übergeben wird. Die Instanz wird mit der LoaderMethode createCardReaderPropLoader() erzeugt.
5.3.3 Verwaltung der Smartcard-Daten
Um smartcardspezifische Properties sowie andere Daten zu laden, gibt es die Klasse
CardPropLoader. Für jeden Kartentyp muss eine Unterklasse von CardPropLoader definiert werden. Der Name jeder Unterklasse ist eine Konkatenation des Kartentyps, geschrieben in Großbuchstaben ohne Sonderzeichen, und des Strings CardPropLoader“.
”
Für die TCOS-2.0-Smartcards heißt die Klasse TCOS20CardPropLoader.
53
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
CardPropLoaders werden vom Loader instanziiert. Der Loader bestimmt zur Laufzeit den konkreten Typ des CardPropLoaders, in Abhängigkeit vom Kartentyp, der
dem Loader-Konstruktor übergeben wird. Die Instanz wird mit der Loader-Methode
createCardPropLoader() erzeugt.
5.4 Der Controller
Der Controller wird von der Controller-Klasse sowie eine Gruppe von
Action-Klassen repräsentiert. Die Controller-Klasse befindet sich im Paket
de.flexsecure.flexiTrust.flexcardadmin. Zu ihren wichtigsten Aufgaben gehören:
• das Erzeugen der View und des Models
• das Auslesen der Konfigurationsdatei
• das Setzen des Arbeitsverzeichnisses vom FlexCardAdmin
• die Spezifikation der vom FlexCardAdmin unterstützten Kartenleser, Smartcards,
Kartenschnittstellen und Sprachen
Die Hauptaufgabe des Controllers bleibt allerdings die Verarbeitung der Benutzereingaben auf der Benutzeroberfläche und die Ausführung der Smartcardoperationen. Die
WizardPanelDescriptor-Klassen dienen als Vermittler, die die Benutzereingaben dem
Controller zur Verfügung stellen. Nachdem der Benutzer seine Eingaben auf der graphischen Oberfläche gemacht hat, leitet der konkrete WizardPanelDescriptor die Benutzereingaben an den Controller weiter, der in Abhängigkeit davon, welche Operation
ausgeführt werden soll, die entsprechende Action-Unterklasse instanziiert, die sich um die
Ausführung der Smartcardoperation kümmert. Die Realisierung jeder primitiven Smartcardoperation ist in einer Action-Unterklasse ausgelagert. Alle Actions befinden sich im
Paket de.flexsecure.flexiTrust.flexcardadmin.action. Jede Action muss die Methode perform() implementieren und dort die Schritte zur Ausführung der Operation
spezifizieren. Abbildung 5.10 gibt eine Übersicht der vorhandenen Action-Unterklassen.
In den folgenden Abschnitten wird beschrieben wie die einzelnen Action-Klassen eingesetzt werden, um die Smartcardoperationen auszuführen.
5.4.1 Personalisieren einer Smartcard
Die Kartenpersonalisierung besteht aus folgenden Schritten, die nacheinander durchgeführt werden:
1. PIN und PUK zusammen mit Fehlbedienungszähler auf die Karte schreiben
2. zwei Schlüsselpaare auf der Karte erzeugen (für Signatur und Windows-Logon)
3. zwei PKCS#10-Zertifikatsanträge erstellen
4. die zwei fertigen Zertifikate (für Signatur und Windows-Logon) auf die Karte schreiben
5. den Inhalt einer PKCS#12-Datei (Verschlüsselungszertifikat und das zugehörige
Schlüsselpaar) auf die Karte schreiben
54
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Abbildung 5.9: Die Klassen von Model
55
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Abbildung 5.10: Die Action-Klassen
56
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
CreatePasswordsAction übernimmt die Aufgabe, die PIN und PUK auf die Karte zu
schreiben. Die PIN und PUK werden von der FlexiTrust-CA generiert und als Appletparameter dem Applet übergeben. Beide sind 3DES-verschlüsselt. Der Verschlüsselungsschlüssel ist im Applet einkompiliert und wird von FlexCardAdmin benutzt, um beide
Passwörter zu entschlüsseln. Die PIN wird dem Benutzer auf der Webseite mit dem Applet angezeigt. Anschließend kann der Benutzer die PIN selbst eingeben. Die eingegebene
PIN wird mit der automatisch generierten PIN verglichen und es wird überprüft, ob beide
übereinstimmen. Wenn dies der Fall ist, werden die PIN und die PUK zuerst entschlüsselt
und danach auf die Karte geschrieben.
GenerateKeyPairAction ist für das Erzeugen von Schlüsselpaaren auf der Karte
zuständig. Jedes Schlüsselpaar wird für eine konkrete Applikation generiert und muss
an der Stelle auf der Karte geschrieben werden, die für diese Applikation vorgesehen ist.
Die Applikation, für die das neue Schlüsselpaar generiert wird, wird als Appletparameter
übergeben. Dieser Parameter wird bei der Instanziierung von GenerateKeyPairAction
benutzt. Mit der angegebenen Applikation wird vor der Schlüsselgenerierung die Konfigurationsdatei ausgelesen, in der spezifiziert ist, an welcher Stelle auf der Karte das
Schlüsselpaar für diese Applikation (und die verwendete Kartenschnittstelle) zu speichern
ist, sowie die Schlüssellänge. Anschließend wird das Schlüsselpaar erzeugt und nach eine
PIN-Eingabe auf die Karte geschrieben.
CreateCertRequestAction erstellt einen PKCS#10-Zertifikatsantrag. Bei dieser Operation ist die Angabe der Applikation, für die das Zertifikat erstellt werden soll, erforderlich.
Die Applikation wird als Appletparameter übergeben. Mit ihrer Hilfe wird die Konfigurationsdatei ausgelesen, um die Stelle auf der Karte zu finden, an der das Schlüsselpaar für
diese Applikation gespeichert ist. Mit der Kenntnis der Schlüssel kann der Zertifikatsantrag erstellt werden. Der fertige Antrag wird an den Browser geschickt, indem der Wert
eines HTML-Formularfeldes in der aktuellen HTML-Seite mit dem Base64-kodierten Zertifikatsantrag gesetzt wird. Hier kommt die Technologie LiveConnect zum Einsatz, die
im Abschnitt 2.2.2 beschrieben wurde. Der Name des HTML-Feldes, das der fertige Zertifikatsantrag hält und das HTML-Formular, in dem sich das Feld befindet, werden als
Appletparameter spezifiziert und vor der Ausführung der Operation ausgelesen.
Die Zertifikatsanträge werden vom Browser an die FlexiTrust-CA geschickt, die die Zertifikate erstellt. Die fertigen Zertifikate werden in Base64-kodierter Form an das Applet
als Parameter zurückgegeben. WriteCertificateAction liest diese Parameter aus und
schreibt die Zertifikate auf die Karte.
FlexiTrust-CA erzeugt zusätzlich das Verschlüsselungsschlüsselpaar sowie das zugehörige Zertifikat. Diese werden im PKCS#12-Format Base64-kodiert an das Applet als
Parameter übergeben. Das PKCS#12-Passwort wird auch als Appletparameter 3DESverschlüsselt übergeben. WriteP12Action liest diese Parameter aus und schreibt die
Schlüssel und das Zertifikat auf die Karte.
Die Aufteilung der Kartenpersonalisierung in mehreren Actions bietet mehr Flexibilität.
Auf diese Weise können die einzelnen Operationen beliebig kombiniert und in beliebiger
Reihenfolge ausgeführt werden. Die Anzahl der Schlüsselpaare, Zertifikatsanträge oder
57
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Zertifikate, die erzeugt werden, ist nicht festgelegt und kann je nach Anwendungsfall über
die Appletparameter spezifiziert werden.
5.4.2 Entsperren der Smartcard
Das Entperren der Smartcard wird von ResetPINAction realisiert. Diese Action benötigt
die PUK der Karte und die neue PIN. Da der Benutzer die PUK nicht kennt, wird diese
als Appletparameter in 3DES-verschlüsselter Form übergeben. Eine neue PIN wird von
der FlexiTrust-CA generiert, dem Benutzer auf der Seite mit dem Applet angezeigt und
auch als Appletparameter übergeben. Es wird zuerst überprüft, ob die Karte tatsächlich
gesperrt ist. Danach wird die vom Benutzer eingegebenen PIN mit der automatisch generierten verglichen. Wenn beide übereinstimmen, wird die PUK entschlüsselt, die Karte
entsperrt und die neue PIN auf die Karte geschrieben.
5.4.3 Löschen der Karteninhalte
Die Karteninhalte werden mittels DeleteCardAction gelöscht. Diese Action benötigt die
PIN der Karte, damit sie sich auf der Karte einloggen kann, und die PUK, um die Karte zu
löschen. Die zwei Passwörter werden hier genauso wie beim Entsperren der Smartcard als
Appletparameter übergeben. Nachdem die PIN-Eingabe vom Benutzer überprüft wurde,
wird die PUK entschlüsselt und die Karte gelöscht.
5.4.4 PIN ändern
Die PIN wird mittels ChangePINAction geändert. Die neue PIN wird von der FlexiTrustCA generiert, dem Benutzer auf der Seite mit dem Applet angezeigt und als Appletparameter übergeben. Der Benutzer gibt die bisherige und die neue PIN ein. Die zwei
PIN-Eingaben werden überprüft. Wenn die bisherige PIN korrekt ist und die neue PIN
mit der automatisch generierten übereinstimmt, wird die PIN der Karte geändert.
5.5 Schnittstelle zum Enrollment-Server
FlexCardAdmin wird in den HTML-Seiten des Enrollment-Servers integriert. Beide befinden sich in ständiger Kommunikation: bei der Ausführung jeder Smartcardoperation
werden bestimmte Daten vom Enrollment-Server an das Applet übergeben und umgekehrt. Das Applet bekommt Daten vom Enrollment-Server über seine Parameter und
schickt Daten nach außen mithilfe der LiveConnect-Technologie (siehe Abschnitt 2.2.2).
Bestimmte Daten werden bei jeder Smartcardoperation zwischen FlexCardAdmin und
dem Enrollment-Server ausgetauscht. Deswegen werden für diese Daten, unabhängig von
der Smartcardoperation, dieselben Appletparameter verwendet. Nur bei der Kartenpersonalisierung werden zusätzliche Parameter benötigt, die für diese konkrete Operation
spezifisch sind.
58
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
5.5.1 Allgemeine Applet-Parameter
Folgende Parameter werden bei jeder Smartcardoperation vom Enrollment-Server an das
Applet übergeben:
• TANFOR: dieser Parameter besagt, welche Smartcardoperation von FlexCardAdmin ausgeführt werden soll. Der Parameter wird in Abhängigkeit davon gesetzt,
welche TAN der Benutzer auf der Enrollment-Seite eingegeben hat und für welche
Operation diese generiert wurde. Die erlaubten Parameterwerte sind:
– NEWCARD: das Applet soll in diesem Fall eine Kartenpersonalisierung
durchführen
– DELETE: bezeichnet, dass das Applet die Smartcard löschen soll
– PINRESET: gibt an, dass die Smartcard entsperrt werden soll
– PINCHANGE: bezeichnet, dass die PIN geändert werden soll
– REPLACEMENT: eine Ersatzkarte soll vom Applet erstellt werden
– EMERGENCY: eine Notfallkarte soll erstellt werden
• TANFORCARDID: dieser Parameter hält die Nummer der Karte, für die die TAN
generiert wurde und für die die Smartcardoperation erlaubt ist.
• ENCCARDPIN: hält die automatisch generierte 3DES-verschlüsselte SmartcardPIN. Der Verschlüsselungschlüssel ist im Applet einkompiliert und wird von FlexCardAdmin benutzt, um die PIN zu entschlüsseln.
• ENCCARDPUK: hält die automatisch generierte 3DES-verschlüsselte SmartcardPUK. Die PUK wird mit demselben Schlüssel wie die PIN entschlüsselt.
• ENCCARDPUKOLD: hält die PUK, die schon auf der Karte gespeichert ist, verschlüsselt mit 3DES. Wenn eine Karte zum ersten Mal personalisiert wird, wird
dieser Parameter nicht benutzt.
Im Folgenden sieht man ein Beispiel davon, wie die Parameterwerte aussehen können.
Der Wert von ENCARDPIN repräsentiert die 3DES-verschlüsselte Base64-kodierte PIN
123456, ENCARDPUK enthält die 3DES-verschlüsselte Base64-kodierte PUK 123456 und
ENCARDPUKOLD ist die 3DES-verschlüsselte Base64-kodierte PUK 654321.
<APPLET ...>
<PARAM
<PARAM
<PARAM
<PARAM
<PARAM
</APPLET>
name=TANFOR value="’NEWCARD">
name=TANFORCARDID value="8949017200001762803">
name=ENCCARDPIN value="cPnR/ibd7yZHWsY5jmiGSg==">
name=ENCCARDPUK value="cPnR/ibd7yZHWsY5jmiGSg==">
name=ENCCARDPUKOLD value="cPnR/ibd7yZC3Q6yErPS7g==">
5.5.2 Datenaustausch bei der Smartcard-Personalisierung
Die Kartenpersonalisierung ist die komplizierteste Smartcardoperation von allen. Diese
ist eine Aneinanderreihung verschiedener einfachen Operationen. Um ihre Ausführung
59
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
möglichst flexibel zu halten, wurden einzelne Kommandos für jede einzelne Operation definiert, so dass diese in beliebiger Reihenfolge und auch mehrfach nacheinander ausgeführt
werden können. Diese Kommandos werden dem Applet als Parameter mit dem Namen
CMDX übergeben (wobei X die Kommandonummer ist, beginnend mit 0) und nacheinander abgearbeitet. Bei jedem Kommando werden Daten auf der Karte entweder gelesen
oder aktualisiert. Jede Operation bearbeitet die Daten einer konkreten Applikation. D.h.,
es werden immer die Daten gelesen oder aktualisiert, die für eine spezifische Applikation
verwendet werden. Damit das Applet weiß, an welcher Stelle auf der Karte die benötigten
Daten zu finden sind oder geschrieben werden sollen, muss es die Applikation kennen. Deswegen gibt es neben jedem Kommando einen zusätzlichen Applet-Patameter APPLX (X
steht für die Nummer des Kommandos, bei dessen Ausführung diese Applikationsangabe
benutzt wird), der die Applikation angibt. Folgende Kommandos werden unterstützt, die
man als Wert des Parameters CMDX übergeben kann:
• CREATE PWD: dieses Kommando bedeutet, dass die PIN und die PUK auf der
Karte geschrieben werden sollen. Die PIN und PUK, die mit den Parametern ENCARDPIN und ENCARDPUK dem Applet übergeben werden, werden auf der Karte geschrieben.
• GENKEY: mit diesem Kommando wird ein Schlüsselpaar auf der Karte generiert.
Der APPLX-Parameter muss immer mitgegeben werden, damit es klar ist, für welche Applikation das neue Schlüsselpaar angelegt wird. Die Schlüssel werden an der
Stelle auf der Karte geschrieben, die für diese Applikation vordefiniert wurde. Dieses Kommando kann mehrfach an das Applet übergeben werden, wenn mehrere
Schlüsselpaare auf der Karte erzeugt werden sollen.
• PKCS10: mit diesem Kommando kann ein PKCS#10-Zertifikatsantrag erstellt und
an den Enrollment-Server geschickt werden. Der Antrag wird für das Schlüsselpaar einer bestimmten Applikation erstellt. Damit das richtige Schlüsselpaar aus
der Karte ausgelesen wird, wird die Applikation in dem Parameter APPLX spezifiziert. Nachdem der PKCS#10-Antrag von FlexCardAdmin erstellt wurde, wird
dieser in Base64-kodierter Form an die HTML-Seite übergeben, indem er als Wert
eines Input-Feldes in einem HTML-Formular gesetzt wird. Der Name des HTMLFormulars und des Input-Feldes werden dem Applet in den Parametern FORMX
und ELEMENTX mitgeteilt. X steht hier wieder für die Kommandonummer.
Der PKCS#10-Antrag wird an den Server geschickt, indem das Applet eine
JavaScript-Funktion aufruft, die die Formulareingaben losschickt. Der Name dieser
JavaScript-Funktion wird in dem Appletparameter SUBMIT METHOD angegeben.
Das HTML-Formular sowie die JavaScript-Funktion sieht man in der Abbildung
5.12.
• WRITE P12: dieses Kommando schreibt den Inhalt einer PKCS#12-Datei (ein
Schlüsselpaar und das zugehörige Zertifikat) auf die Karte. Der Base64-kodierte
Inhalt der PKCS#12-Datei wird über den Parameter P12 dem Applet übergeben. Das Passwort, mit dem die PKCS#12-Datei geschützt ist, ist mit dem 3DESAlgorithmus verschlüsselt und wird im Parameter ENCP12PW gehalten. Für dieses
60
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Kommando wird auch zusätzlich der Parameter APPLX benötigt, der die Applikation angibt, für die die Schlüssel und das Zertifikat verwendet werden. Somit kann
das Applet die richtige Stelle auf der Karte ermitteln, auf der die Daten gespeichert
werden sollen.
• WRITE CERT: mit diesem Kommando wird ein Zertifikat auf der Karte geschrieben. Das Zertifikat wird in Base64-kodierter Form im Parameter DATAX gehalten,
wobei X die Nummer des WRITE CERT-Kommandos ist. Der Parameter APPLX
gibt die Applikation an, für die das Zertifikat erstellt wurde und hilft die Position
des Zertifikats auf der Karte zu lokalisieren.
Abbildung 5.11 zeigt eine schematische Darstellung des Datenaustausches zwischen dem
Enrollment-Server, FlexCardAdmin und der Smartcard während der Kartenpersonalisierung. Dort sieht man auch die einzelnen Applet-Kommandos und die Reihenfolge, in der
diese ausgeführt werden.
Nachdem die PKCS#10-Anträge vom Applet erzeugt werden und an den EnrollmentServer geschickt werden, wird eine neue HTML-Seite geladen, in der die fertigen Zertifikate dem Applet übergeben werden. FlexCardAdmin wird beim Laden dieser Seite neu
gestartet. Normalerweise wird nach dem Start des Applets zuerst das Panel gezeigt, auf
dem man festlegen kann, welche Kartenschnittstelle, Smartcard und Kartenleser während
der Ausführung der Smartcardoperationen benutzt werden soll. Dieses Panel ist hier nicht
nötig, da diese Angaben schon beim ersten Start des Applets gemacht wurden. Damit das
erste Panel des Applets übersprungen werden kann, das Applet aber trotzdem die Information hat, welche Kartenschnittstelle, Smartcard und Kartenleser benutzt werden soll,
werden diese drei Angaben vom ersten“ Applet an den Enrollment-Server und von dort an
”
das zweite“ Applet weitergereicht. Das erste Applet setzt drei Input-Felder eines HTML”
Formulars mit diesen Daten, bevor das Formular an den Server geschickt wird. Beim zweiten Start des Applets werden diese drei Angaben als Parameter dem Applet übergeben.
Diese sind die Parameter CARD OS, CARD INTERFACE und CARD READER. Die
Namen des HTML-Formulars und der drei Input-Felder, in denen das erste“ Applet die
”
verwendete Kartenschnittstelle, Smartcard und Kartenleser angeben muss, werden ihm
mithilfe folgender Parameter mitgeteilt:
• FORM CARD OS: der Name des HTML-Formulars, in dem das Applet der Typ
der verwendeten Smartcard festlegt
• ELEMENT CARD OS: das Input-Feld im obigen HTML-Formular, das der Smartcardtyp hält
• FORM CARD INTERFACE: der Name des HTML-Formulars, in dem das Applet
die verwendete Kartenschnittstelle festlegt
• ELEMENT CARD INTERFACE: das Input-Feld im obigen HTML-Formular, das
die Kartenschnittstelle hält
• FORM CARD READER: der Name des HTML-Formulars, in dem das Applet der
Typ des verwendeten Kartenlesers festlegt
• ELEMENT CARD READER: das Input-Feld in dem obigen HTML-Formular, dass
61
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
den Kartenlesernamen hält
Abbildungen 5.13 und 5.14 zeigen wie FlexCardAdmin in den HTML-Seiten des
Enrollment-Servers eingebunden wird. Die erste Abbildung zeigt das Applet, das den ersten Teil der Kartenpersonalisierung durchführt, und die zweite Abbildung - das Applet,
das die Kartenpersonalisierung zu Ende bringt.
5.5.3 Zertifikat auslesen
FlexCardAdmin unterstützt ein zusätzliches Kommando READ CERT, mit dem ein Zertifikat, das sich auf der Karte befindet, ausgelesen werden kann. Mit dem Patameter
APPLx sollte die Applikation spezifiziert werden, für die das Zertifikat verwendet wird,
damit das Applet das Zertifikat auf der Karte erkennen kann. Das ausgelesene Zertifikat
wird einem HTML-Formular übergeben. Mit den Parametern FORMx und ELEMENTx
kann der Formularname und der Input-Feldname spezifiziert werden:
<PARAM
<PARAM
<PARAM
<PARAM
name=CMD0 value="READ_CERT">
name=APPL0 value="APPL1">
name=FORM0 value="ReadCertForm">
name=ELEMENT0 value="CERT-PEM0">
5.6 Konfiguration
Das Verhalten von FlexCardAdmin kann über seine XML-Konfigurationsdatei
flexCardAdmin.xml gesteuert werden. Dort sind verschiedene Parameter enthalten, die
in den folgenden Abschnitten beschrieben werden. Das Wurzelelement in der Datei ist
<flexcardadmin>. Dieses hat Kinder-Elemente, in denen die Parameter gruppiert sind.
Jeder Parameter ist mittels des <param>-Tag definiert und besitzt zwei Attribute: key
und value. Key ist der Name des Parameters und value - sein Wert. Das value-Attribut
ist anpassbar, das key-Attribut darf nicht verändert werden.
5.6.1 Allgemeine Parameter
Folgende allgemeine Parameter sind vorhanden:
• choose operation: Im Normalfall wird die Smartcardoperation, die vom Applet
ausgeführt werden soll, via einem Appletparameter festgelegt, der vom EnrollmentServer gesetzt wird, in Abhängigkeit davon für welche Operation die Benutzer-TAN
generiert wurde. Das Applet sieht zusätzlich eine zweite Möglichkeit vor, die Operation auszuwählen, indem der Benutzer selbst die Operation auf der Benutzeroberfläche angibt. Dies erfordert allerdings einige Änderungen in der Benutzeroberfläche
und der Logik des Applets, sowie in dem Ablauf der ausgeführten Operationen. In
62
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
Abbildung 5.11: Datenaustausch zwischen dem Enrollment-Server, FlexCardAdmin und
der Smartcard
63
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
<script language=JavaScript type="text/javascript">
function submitForm() {
document.CertRequestForm.submit();
}
</script>
<form name="CertRequestForm" action="${SUBMIT-URL}" method="POST">
<table>
<tr>
<td align="right">
<input type="hidden" name="GenRequest0">
<input type="hidden" name="GenRequest1">
<input type="hidden" name="GenRequest2">
<input type="hidden" name="CardOS" value="${CARD_OS}"/>
<input type="hidden" name="CardInterface" value="${CARD_INTERFACE}"/>
<input type="hidden" name="CardReader" value="${CARD_READER}"/>
....
</td>
</tr>
</table>
</form>
Abbildung 5.12: Das HTML-Formular CertRequestForm und die JavaScript-Funktion
submitForm()
64
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
<APPLET codebase="${SERVERNAME}/xenroll"
code="de.flexsecure.flexiTrust.flexcardadmin.FlexCardApplet.class"
name="FlexCardApplet" WIDTH="640" HEIGHT="370"
align="BOTTOM"
archive="flexCardAdmin_signed.jar,cardservices.jar,fs_util.jar,
nativelibs_signed.jar,p11.jar,jpcsc.jar,base-opt.jar,
base-core.jar,pcsc-wrapper-2.0.jar,codec.jar,
FlexiCoreProvider-1.1.5p7.signed.jar"
MAYSCRIPT>
<PARAM
<PARAM
<PARAM
<PARAM
<PARAM
name=TANFOR value="${TANFOR}">
name=TANFORCARDID value="${CARDID}">
name=ENCCARDPIN value="${ENCCARDPIN}">
name=ENCCARDPUK value="${ENCCARDPUK}">
name=ENCCARDPUKOLD value="${ENCCARDPUKOLD}">
<PARAM name=CMD0 value="CREATE_PWD">
<PARAM name=CMD1 value="GENKEY">
<PARAM name=APPL1 value="APPL1">
<PARAM name=CMD2 value="GENKEY">
<PARAM name=APPL2 value="APPL2">
<PARAM
<PARAM
<PARAM
<PARAM
name=CMD3 value="PKCS10">
name=APPL3 value="APPL1">
name=FORM3 value="CertRequestForm">
name=ELEMENT3 value="GenRequest0">
<PARAM
<PARAM
<PARAM
<PARAM
name=CMD4 value="PKCS10">
name=APPL4 value="APPL2">
name=FORM4 value="CertRequestForm">
name=ELEMENT4 value="GenRequest1">
<PARAM name=FORM_CARD_OS value="CertRequestForm">
<PARAM name=ELEMENT_CARD_OS value="CardOS">
<PARAM name=FORM_CARD_INTERFACE value="CertRequestForm">
<PARAM name=ELEMENT_CARD_INTERFACE value="CardInterface">
<PARAM name=FORM_CARD_READER value="CertRequestForm">
<PARAM name=ELEMENT_CARD_READER value="CardReader">
<PARAM name=SUBMIT_METHOD value="submitForm">
</APPLET>
Abbildung 5.13: Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenpersonalisierung (Teil 1)
65
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
<APPLET codebase="${SERVERNAME}/xenroll"
code="de.flexsecure.flexiTrust.flexcardadmin.FlexCardApplet.class"
name="FlexCardApplet" WIDTH="640" HEIGHT="370"
align="BOTTOM"
archive="flexCardAdmin_signed.jar,cardservices.jar,fs_util.jar,
nativelibs_signed.jar,p11.jar,jpcsc.jar,base-opt.jar,
base-core.jar,pcsc-wrapper-2.0.jar,codec.jar,
FlexiCoreProvider-1.1.5p7.signed.jar"
MAYSCRIPT>
<PARAM
<PARAM
<PARAM
<PARAM
<PARAM
name=TANFOR value="${TANFOR}">
name=TANFORCARDID value="${CARDID}">
name=ENCCARDPIN value="${ENCCARDPIN}">
name=ENCCARDPUK value="${ENCCARDPUK}">
name=ENCCARDPUKOLD value="${ENCCARDPUKOLD}">
<PARAM
<PARAM
<PARAM
<PARAM
name=CMD0 value="WRITE_P12">
name=APPL0 value="APPL0">
name=P12 value="${P12}">
name=ENCP12PW value="${P12PW}">
<PARAM name=CMD1 value="WRITE_CERT">
<PARAM name=APPL1 value="APPL1">
<PARAM name=DATA1 value="${CERT-PEM0}">
<PARAM name=CMD2 value="WRITE_CERT">
<PARAM name=APPL2 value="APPL2">
<PARAM name=DATA2 value="${CERT-PEM1}">
<PARAM name=CARD_OS value="${CARD_OS}">
<PARAM name=CARD_INTERFACE value="${CARD_INTERFACE}">
<PARAM name=CARD_READER value="${CARD_READER}">
</APPLET>
Abbildung 5.14: Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenpersonalisierung (Teil 2)
66
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
<APPLET codebase="${SERVERNAME}/xenroll"
code="de.flexsecure.flexiTrust.flexcardadmin.FlexCardApplet.class"
name="FlexCardApplet" WIDTH="640" HEIGHT="370"
align="BOTTOM"
archive="flexCardAdmin_signed.jar,cardservices.jar,fs_util.jar,
nativelibs_signed.jar,p11.jar,jpcsc.jar,base-opt.jar,
base-core.jar,pcsc-wrapper-2.0.jar,codec.jar,
FlexiCoreProvider-1.1.5p7.signed.jar"
MAYSCRIPT>
<PARAM
<PARAM
<PARAM
<PARAM
<PARAM
</APPLET>
name=TANFOR value="${TANFOR}">
name=TANFORCARDID value="${TANFORCARDID}">
name=ENCCARDPIN value="${ENCCARDPIN}">
name=ENCCARDPUK value="${ENCCARDPUK}">
name=ENCCARDPUKOLD value="${ENCCARDPUKOLD}">
Abbildung 5.15: Integration von FlexCardAdmin in der ES-Seite beim Löschen oder Entsperren einer Smartcard
dieser Version des Applets wird nur ein Prototyp dieser Lösung vorgestellt, der weiteretwickelt werden muss, um einsatzbereit zu sein. Der Parameter choose operation
wurde definiert, um zwischen den zwei Möglichkeiten umzuschalten. Wenn der Parameter auf no gesetzt ist, wird die Smartcardoperation via einem Appletparameter
festgelegt, wenn der Parameterwert yes ist, wird die Operation vom Benutzer gesetzt.
• use default interface: mit diesem Parameter wird festgelegt, ob eine Defaultkartenschnittstelle benutzt werden soll in den Fällen, in welchen eine Smartcardoperation nicht über die aktuelle Katenschnittstelle ausführbar ist. Wenn der Wert
des Parameters true ist, wird die aktuell verwendete Kartenschnittstelle mit der
Defaultkartenschnittstelle, die in der Controller-Klasse definiert ist, ausgetauscht,
so dass die Smartcardoperation ausgeführt werden kann. Wenn der Parameter auf
false gesetzt ist, wird die verwendete Kartenschnittstelle nie ausgetauscht und die
Ausführung der Operation, die von dieser Kartenschnittstelle nicht unterstützt ist,
wird mit einer Fehlermeldung abgebrochen.
• card os: hier kann die Smartcard definiert werden, die mit FlexCardAdmin verwendet werden soll. Mögliche Werte in dieser Version von FlexCardAdmin sind TCSO20
für TCOS-2.0-Smartcards oder der leere String. Die erlaubten Werte dieses Parameters (bis auf dem leeren String) sollen als Konstanten in der Controller-Klasse
definiert werden. Der leere String bedeutet, dass der Benutzer selbst den Typ seiner
Smartcard auf der Benutzeroberfläche spezifizieren muss. Er bekommt eine Liste
von Smartcards zur Auswahl angezeigt.
• card interface: hier kann die Kartenschnittstelle angegeben werden, die verwen-
67
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
det werden soll. Mögliche Werte in dieser Version von FlexCardAdmin sind PKCS11,
PCSC, OCF oder der leere String. Diese sind die Namen der einzelnen Kartenschnittstellen ohne jegliche Sonderzeichen. Dies ist wichtig, weil die angegebenen Strings
zum Erzeugen von Klassennamen zur Laufzeit benutzt werden und Klassennamen
dürfen keine Sonderzeichen wie # enthalten. Die erlaubten Werte dieses Parameters
(bis auf dem leeren String) sollen als Konstanten in der Controller-Klasse definiert
werden. Der leere String bedeutet, dass der Benutzer selbst die zu verwendende
Kartenschnittstelle auf der Benutzeroberfläche spezifizieren muss. Er bekommt eine
Liste von Kartenschnittstellen zur Auswahl angezeigt.
• card reader: hier kann der Kartenleser angegeben werden, der mit FlexCardAdmin
verwendet wird. Mögliche Werte in dieser Version von FlexCardAdmin sind KOBIL
oder der leere String. Die erlaubten Werte dieses Parameters (bis auf dem leeren
String) sollen als Konstanten in der Controller-Klasse definiert werden. Der leere
String bedeutet, dass der Benutzer selbst den zu verwendenden Kartenleser auf der
Benutzeroberfläche spezifizieren muss. Er bekommt eine Liste von Kartenlesern zur
Auswahl angezeigt.
5.6.2 Kartenlesertreiber
In der Konfigurationsdatei werden die Treiber der Kartenleser aufgelistet, die FlexCardAdmin unterstützen soll und die beim Aufbau der Verbindung zum Kartenleser geladen
werden müssen. Pro Kartenschnittstelle und Betriebssystem wird jeweils ein Parameter
definiert, dessen Wert den Namen der Kartenlesertreiberdatei für diese Kombination spezifiziert. Der Parametername ist eine Konkatenation des Kartenschnittstellennamen, des
Betriebssystems und der Nummer des Treibers. Bei jedem neuen Treiber, der in der Konfigurationsdatei hinzugefügt wird, wird die Treibernummer um eins inkrementiert. Die
Treiber sind zwecks besserer Übersicht folgendermaßen gruppiert:
• <pkcs11 driver>: hier werden die Kartenlesertreiber für die PKCS#11Schnittstelle spezifiziert. Folgende Parameter sind vorhanden:
– pkcs11 driver win 0: der Treiber mit der Nummer 0 für die PKCS#11Schnittstelle unter Windows
– pkcs11 driver linux 0: der Treiber mit der Nummer 0 für die PKCS#11Schnittstelle unter Linux
• <pcsc driver>: hier werden die Kartenlesertreiber für die PC/SC-Schnittstelle spezifiziert. Folgende Parameter sind vorhanden:
– pcsc driver win 0: der Treiber mit der Nummer 0 für die PC/SC-Schnittstelle
unter Windows
– pcsc driver linux 0: der Treiber mit der Nummer 0 für die PC/SCSchnittstelle unter Linux
• <ocf driver>: hier werden die Kartenlesertreiber für die OCF-Schnittstelle spezifiziert. Folgende Parameter sind vorhanden:
68
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
– ocf driver win 0: der Treiber mit der Nummer 0 für die OCF-Schnittstelle
unter Windows
– ocf driver linux 0: der Treiber mit der Nummer 0 für die OCF-Schnittstelle
unter Linux
• <manufacturer specific pkcs11 driver>: hier werden die PKCS#11-Treiber pro
Hersteller spezifiziert. Der Name jedes Parameters ist eine Konkatenation des Kartenschnittstellennamen, des Betriebssystems und des Namen des Kartenleserherstellers. Folgende Parameter sind vorhanden:
– pkcs11 driver win kobil: der PKCS#11-Treiber für KOBIL-Kartenleser unter Windows
– pkcs11 driver linux kobil: der PKCS#11-Treiber für KOBIL-Kartenleser
unter Linux
5.6.3 Referenzen auf Kartenobjekten
Für jedes Objekt, das von einer bestimmten Applikation genutzt wird, ist eine bestimmte
Stelle auf der Karte vorgesehen. In Abhängigkeit von der verwendeten Kartenschnittstelle
und des Smartcardtyps sieht die Kennzeichnung dieser Stelle unterschiedlich aus. In der
Konfigurationsdatei wird die Position jedes Objekts auf der Karte für jede Kombination
aus Kartenschnittstelle und Smartcardtyp vorgegeben. Die Parameter zum Referenzieren
der Kartenobjekte sind in Gruppen aufgeteilt. Jede Gruppe definiert die Objektreferenzen
für eine bestimmte Applikation:
• <card object ids appl0>: hier werden die Referenzen auf Objekte, die von Applikation 0 benutzt werden, spezifiziert.
• <card object ids appl1>: hier werden die Referenzen auf Objekte, die von Applikation 1 benutzt werden, spezifiziert.
• <card object ids appl2>: hier werden die Referenzen auf Objekte, die von Applikation 2 benutzt werden, spezifiziert.
Folgende Parameter sind für Applikation 0 vorhanden (die Parameter für die restlichen
Applikationen sind diesen analog):
• Objektreferenzen für den Fall, dass die PKCS#11-Schnittstelle und TCOS-2.0Smartcards verwendet werden:
– appl0 pkcs11 tcos20 pubkey: die Referenz auf dem öffentlichen Schlüssel
– appl0 pkcs11 tcos20 privkey: die Referenz auf dem privaten Schlüssel
– appl0 pkcs11 tcos20 cert: die Referenz auf dem Zertifikat
• Objektreferenzen für den Fall, dass die PC/SC-Schnittstelle und TCOS-2.0Smartcards verwendet werden:
– appl0 pcsc tcos20 pubkey: die Referenz auf dem öffentlichen Schlüssel
– appl0 pcsc tcos20 privkey: die Referenz auf dem privaten Schlüssel
– appl0 pcsc tcos20 cert: die Referenz auf dem Zertifikat
69
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
• Objektreferenzen für den Fall, dass die OCF-Schnittstelle und TCOS-2.0Smartcards verwendet werden:
– appl0 ocf tcos20 pubkey: die Referenz auf dem öffentlichen Schlüssel
– appl0 ocf tcos20 privkey: die Referenz auf dem privaten Schlüssel
– appl0 ocf tcos20 cert: die Referenz auf dem Zertifikat
Speziell für die Referenzierung von Objekten auf TCOS-2.0-Karten sind zusätzliche
Informationen nötig, um die CardObjectIDs erzeugen zu können. Diese Informationen
werden mit folgenden Parametern spezifiziert (hier wieder am Beispiel der Applikation 0
vorgestellt):
• appl0 pcsc tcos20 keynr: die Nummer des Schlüssels auf der Karte (wenn PC/SC
die verwendete Kartenschnittstelle ist)
• appl0 ocf tcos20 keynr: die Nummer des Schlüssels auf der Karte (wenn OCF die
verwendete Kartenschnittstelle ist)
• appl0 keyusage enc: spezifiziert, ob der Schlüssel ein Verschlüsselungsschlüssel ist;
mögliche Werte sind true und false;
• appl0 keyusage sign: spezifiziert, ob der Schlüssel ein Signaturschlüssel ist; mögliche Werte sind true und false;
• appl0 keyusage auth: spezifiziert, ob der Schlüssel ein Schlüssel zur Authentifikation ist; mögliche Werte sind true und false;
• appl0 keylength: die Schlüssellänge in Bit, z.B. 1024
Abbildung 5.16 zeigt ein Beispiel, wie die Parameter zur Objektreferenzierung gesetzt
werden können.
70
KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG
<card_object_ids_appl0>
<param key="appl0_pkcs11_tcos20_pubkey" value="TCOS1-00"/>
<param key="appl0_pkcs11_tcos20_privkey" value="TCOS1-00"/>
<param key="appl0_pkcs11_tcos20_cert" value="TCOS1-00"/>
<param
<param
<param
<param
key="appl0_pcsc_tcos20_pubkey" value=":3f00:4101:4e03"/>
key="appl0_pcsc_tcos20_privkey" value=":3f00:4101:5103"/>
key="appl0_pcsc_tcos20_cert" value=":3f00:4101:4352"/>
key="appl0_pcsc_tcos20_keynr" value="3"/>
<param
<param
<param
<param
key="appl0_ocf_tcos20_pubkey" value=":3f00:4101:4e03"/>
key="appl0_ocf_tcos20_privkey" value=":3f00:4101:5103"/>
key="appl0_ocf_tcos20_cert" value=":3f00:4101:4352"/>
key="appl0_ocf_tcos20_keynr" value="3"/>
<param key="appl0_keyusage_enc" value="true"/>
<param key="appl0_keyusage_sign" value="false"/>
<param key="appl0_keyusage_auth" value="false"/>
<param key="appl0_keylength" value="1024"/>
</card_object_ids_appl0>
<card_object_ids_appl1>
<param key="appl1_pkcs11_tcos20_pubkey" value="TCOS1-01"/>
<param key="appl1_pkcs11_tcos20_privkey" value="TCOS1-01"/>
<param key="appl1_pkcs11_tcos20_cert" value="TCOS1-01"/>
<param
<param
<param
<param
key="appl1_pcsc_tcos20_pubkey" value=":3f00:4101:4e04"/>
key="appl1_pcsc_tcos20_privkey" value=":3f00:4101:5104"/>
key="appl1_pcsc_tcos20_cert" value=":3f00:4101:4353"/>
key="appl1_pcsc_tcos20_keynr" value="4"/>
<param
<param
<param
<param
key="appl1_ocf_tcos20_pubkey" value=":3f00:4101:4e04"/>
key="appl1_ocf_tcos20_privkey" value=":3f00:4101:5104"/>
key="appl1_ocf_tcos20_cert" value=":3f00:4101:4353"/>
key="appl1_ocf_tcos20_keynr" value="4"/>
<param key="appl1_keyusage_enc" value="true"/>
<param key="appl1_keyusage_sign" value="true"/>
<param key="appl1_keyusage_auth" value="false"/>
<param key="appl1_keylength" value="1024"/>
</card_object_ids_appl1>
Abbildung 5.16: Konfigurationsparameter zum Referenzieren der Objekte auf der Karte
71
Kapitel 6
Zusammenfassung
Die Firma FlexSecure bietet die Softwarelösung FlexiTrust zur Verwaltung der PKI innerhalb eines Unternehmens. Als Erweiterung wurde FlexiTrust Identity Management
entwickelt, das sämtliche Aufgaben, die mit der Personalisierung und Verwaltung von
Smartcards verbunden sind, übernimmt. Eine der Komponenten von FlexiTrust Identity Management, die für die Realisierung der Smartcardoperationen zuständig ist, weist
gewisse Nachteile auf. Sie ist nicht plattformunabhängig, nicht flexibel genug und nicht
erweiterbar. Dies hat dazu geführt, dass Verbesserungen notwendig waren. Die vorliegende
Arbeit ist in Folge dessen entstanden mit dem Ziel, eine neue Lösung (FlexCardAdmin) zu
entwickeln, die die Probleme und Einschränkungen der bestehenden Applikation auflöst.
Am Anfang dieser Arbeit wurde zuerst die Funktionalität der bestehenden Lösung und die
Technologien, auf die sie basiert, vorgestellt. Auf die Nachteile wurde auch eingegangen,
damit nachvollziehbar wird, warum die Notwendigkeit besteht, nach eine neue Lösung zu
suchen. Die meisten Nachteile kamen von der verwendeten Technologie, die ausgetauscht
werden musste. Ein Teil der Arbeit bestand also darin, eine neue passende Technologie
auszusuchen und diese zu analysieren.
Eine der wichtigsten Anforderungen an FlexCardAdmin war, möglichst hohe Flexibilität zu bieten. Demzufolge musste ein Konzept entwickelt werden, wie man am besten
die Software gestaltet, so dass die Anwendung in beliebigen Umgebungen lauffähig ist:
unabhängig vom verwendeten Kartenlesertyp, Smartcard oder Kartenschnittstelle. Als
Grundlage bei der Implementierung wurde das Framework SmartcardServices benutzt,
das vor dem Einsatz analysiert werden musste, um sicherzustellen, dass dieses die notwendige Funktionalität bietet.
Als Ergebnis dieser Arbeit ist ein Applet entstanden, das im Gegensatz zu seinem
Vorgänger viele Vorteile bietet:
• FlexCardAdmin ist plattformunabhängig. Sein Vorgänger dagegen konnte nur unter
Windows ausgeführt werden.
• Es bietet hohe Flexibilität. Die OCX-Komponente von FlexiTrust Identity Management unterstützt nur zwei Kartentypen. FlexCardAdmin dagegen kann mit beliebigen Smartcards eingesetzt werden. Außerdem funktioniert das Applet unabhängig
vom Kartenleser.
• Dadurch dass das Design der Software an das Model-View-Controller-Pattern angelehnt ist, ist das Applet modular und einzelne Elemente sind leicht austauschbar
72
KAPITEL 6. ZUSAMMENFASSUNG
oder anpassbar.
• Das Applet ist leicht erweiterbar. Es ist einfach neue Komponenten, wie Kartentypen, Kartenschnittstellen, Kartenleser oder Sprachen in die Software hinzuzufügen.
• Einzelne primitive Smartcardoperationen sind beliebig kombinierbar und können
in beliebiger Reihenfolge ausgeführt werden. Die Anzahl der Schlüsselpaare, Zertifikatsanträge oder Zertifikate, die erzeugt werden, ist nicht festgelegt und kann je
nach Anwendungsfall spezifiziert werden.
Wie jede andere Software ist auch FlexCardAdmin verbesserungsfähig und gibt Raum
zur Weiterentwicklung. Im nächsten Kapitel wird ein Blick in die Zukunft geworfen und
angesprochen, was im Applet noch verbessert werden kann.
73
Kapitel 7
Ausblick
In diesem Kapitel wird beschrieben, wie FlexCardAdmin weiterentwickelt werden kann
und an welchen Stellen die Software noch verbesserungsfähig ist.
7.1 Weiterentwicklung der Software
FlexCardAdmin ist in seiner jetzigen Version in einer beschränkten Umgebung lauffähig,
aber wurde so kozipiert, dass diese Umgebung leicht erweitert werden kann und neue Komponenten leicht in die Software hinzugefügt werden können. Somit erfüllt FlexCardAdmin die Anforderungen an Flexibilität und Erweiterbarkeit. Folgende Elemente können
nachträglich in die Software aufgenommen werden:
• neue Kartentypen
• neue Kartenleser
• neue Kartenschnittstellen
• neue Sprachen
• neue Betriebssysteme
Um solche zusätzliche Elemente in die Software einzubauen, müssen einige Stellen in der
Software erweitert werden. Die einzelnen Schritte der Integration neuer Komponenten
werden in den nächsten Abschnitten beschrieben.
7.1.1 Hinzufügen neuer Karten
Damit FlexCardAdmin mit neuen Kartentypen verwendet werden kann, muss die
Software folgendermaßen erweitert werden:
• Das Framework SmartcardServices soll wie in [Dra06] beschrieben, erweitert werden.
• Der neue Kartentyp muss der Applikation bekannt gemacht werden. Dazu muss der
Controller folgendermaßen erweitert werden:
– Eine neue Konstante für die neue Smartcard muss definiert werden.
– Die Methode initializeSupportedEnvironment() muss erweitert werden.
– Der neue Kartentyp muss in der Liste der unterstützten Smartcards (HashMap
supportedSmartcards) hinzugefügt werden.
74
KAPITEL 7. AUSBLICK
– Die
Methode
checkCombination(String card os, String
card interface) muss erweitert werden. Dort wird spezifiziert mit welchen Kartenschnittstellen der neue Kartentyp kompatibel ist. Dies hängt von
den angebotenen Implementierungen im Framework SmartcardServices ab.
• Eine
neue
Unterklasse
von
CardPropLoader
muss
im
Paket
de.flexsecure.flexiTrust.flexcardadmin.model.card
angelegt
werden,
die die Properties des neuen Kartentyps verwaltet. Der Klassenname muss eine
Konkatenation des Namen der Controller-Konstante für den Kartentyp und des
Strings CardPropLoader“ sein.
”
• Eine neue Unterklasse von CardObjectIdentifier muss im Paket
de.flexsecure.flexiTrust.flexcardadmin.model.card
angelegt
werden.
Dort soll die kartenspezifische Referenzierung von Objekten auf der Karte spezifiziert werden. Der Klassenname muss eine Konkatenation des Namen der
Controller-Konstante für den Kartentyp und des Strings CardObjectIdentifier“
”
sein.
• Falls irgendwelche Properties des Kartentyps in einer Konfigurationsdatei angegeben
werden müssen, muss diese Datei im Verzeichnis conf abgelegt werden.
7.1.2 Hinzufügen neuer Kartenschnittstellen
Um neue Kartenschnittstellen mit FlexCardAdmin verwenden zu können, muss die
Software folgendermaßen erweitert werden:
• Das Framework SmartcardServices soll wie in [Dra06] beschrieben, erweitert werden.
• Die neue Kartenschnittstelle muss der Applikation bekannt gemacht werden. Dazu
muss der Controller folgendermaßen erweitert werden:
– Eine neue Konstante für die neue Kartenschnittstelle muss definiert werden.
– Die Methode initializeSupportedEnvironment() muss erweitert werden.
– Die neue Kartenschnittstelle muss in der Liste der unterstützten Kartenschnittstellen (HashMap supportedCardInterfaces) hinzugefügt werden.
– Die
Methode
checkCombination(String card os, String
card interface) muss erweitert werden. Dort wird spezifiziert mit welchen
Smartcards die neue Kartenschnittstelle verwendet werden kann. Dies hängt
von den angebotenen Implementierungen im Framework SmartcardServices
ab.
• Das Model muss um die neue Kartenschnittstelle erweitert werden. Ein neues Unterpaket von de.flexsecure.flexiTrust.flexcardadmin.model mit dem Namen
der Kartenschnittstelle muss angelegt werden. Dort werden die schnittstellenspezifischen Model-Klassen erzeugt:
– Eine Unterklasse von Model muss angelegt werden. Der Klassenname ist eine
Konkatenation des Schnittstellennamen und des String Model“.
”
75
KAPITEL 7. AUSBLICK
– Eine Unterklasse von Loader muss angelegt werden. Der Klassenname ist eine
Konkatenation des Schnittstellennamen und des Strings Loader“.
”
– Eine Unterklasse von ObjectIdentifier muss angelegt werden. Der Klassenname ist eine Konkatenation des Schnittstellennamen und des Strings Objec”
tIdentifier“.
• Externe und native Bibliotheken, die zur Initialisierung der Kartenschnittstelle
benötigt werden, müssen ins Verzeichnis lib kopiert werden. Die nativen Bibliotheken müssen zusätzlich im Verzeichnis nativelib abgelegt werden.
• Falls irgendwelche Properties der Kartenschnittstelle in einer Konfigurationsdatei
angegeben werden müssen, muss diese Datei im Verzeichnis conf abgelegt werden.
7.1.3 Hinzufügen neuer Kartenleser
Um FlexCardAdmin mit neuen Kartenlesern verwenden zu können, müssen folgende
Änderungen vorgenommen werden:
• Der neue Kartenleser muss der Applikation bekannt gemacht werden. Dazu muss
der Controller folgendermaßen erweitert werden:
– Eine neue Konstante für den neuen Kartenleser muss definiert werden.
– Die Methode initializeSupportedEnvironment() muss erweitert werden.
– Der neue Kartenleser muss in der Liste der unterstützten Kartenleser (HashMap
supportedCardReaders) hinzugefügt werden.
• Die Treiberdateien (pro Kartenschnittstelle und Betriebssystem) müssen in den Verzeichnissen lib und nativelib kopiert werden
• Die Konfigurationsdatei flexCardAdmin.xml muss um die Kartenlesertreiber (pro
Betriebssystem und pro Kartenschnittstelle) erweitert werden
• Eine neue Unterklasse von CardReaderPropLoader muss im Paket
de.flexsecure.flexiTrust.flexcardadmin.model.reader angelegt werden.
Der Klassenname muss eine Konkatenation des Namen der Controller-Konstante
für den Kartenleser und des Strings CardReaderPropLoader“ sein.
”
7.1.4 Hinzufügen neuer Sprachen
FlexCardAdmin wird in seiner jetzigen Version in zwei Sprachen ausgeliefert: Deutsch
und Englisch. Beliebige Sprachen können zum Sprachpaket der Software hinzugefügt
werden. Folgende Änderungen sind notwendig, um dies zu realisieren:
• Die neue Sprache muss der Applikation bekannt gemacht werden. Dazu muss der
Controller folgendermaßen erweitert werden:
– Eine neue Konstante für die neue Sprache muss definiert werden.
– Die Methode initializeSupportedEnvironment() muss erweitert werden.
76
KAPITEL 7. AUSBLICK
– Die neue Sprache muss in der Liste der unterstützten Sprachen (HashMap
supportedLanguages) hinzugefügt werden.
• Die Methode setLanguage(String language) der Klasse Lang muss erweitert werden.
• Die Übersetzung der GUI-Texte in der neuen Sprache müssen in einer Properties-Datei zusammengefasst werden (analog der schon vorhandenen Properties-Dateien für die anderen Sprachen) und im Paket
de.flexsecure.flexiTrust.flexcardadmin.util.language abgelegt werden.
7.1.5 Hinzufügen neuer Betriebssysteme
Das verwendete Betriebssystem beeinflüßt das Laden von nativen Bibliotheken. In
Abhängigkeit des Betriebssystems werden unterschiedliche Bibliotheken geladen. Man
kann diese leicht an der Dateiendung unterscheiden. Windows-Bibliotheken haben die
Endung .dll und Linux-Bibliotheken - die Endung .so. Wenn ein neues Betriebssystem
unterstützt werden muss, müssen die benötigten nativen Bibliotheken zur Verfügung gestellt werden und der Teil der Software, der das Laden der nativen Bibliotheken realisiert,
entsprechend erweitert werden:
• In der Klasse Loader muss eine neue Methode definiert werden, die analog
zu loadWinLibrary(String libName) und loadLinuxLibrary(String libName)
das Laden von Bibliotheken des neuen Betriebssystems ermöglicht.
• Die nativen Bibliotheken für das neue Betriebssystem (pro Kartenschnittstelle)
müssen bereitgestellt werden und in den Verzeichnissen lib und nativelib kopiert
werden.
• Die Kartenlesertreiber für das neue Betriebssystem (pro Kartenschnittstelle) müssen
ebenso bereitgestellt werden und in den Verzeichnissen lib und nativelib kopiert
werden.
• Die Kartenlesertreiber für das neue Betriebssystem müssen in der Konfigurationsdatei aufgelistet werden.
• Die Unterklassen von Loader (OCFLoader, PCSCLoader und PKCS11Loader) müssen
folgendermaßen erweitert werden:
– eine neue Konstante für die native Bibliothek des neuen Betriebssystems muss
in jeder der Unterklassen definiert werden.
– die Methoden loadLibraries() und loadReaderDrivers() müssen angepasst
werden.
• Die Methode loadData() der Klasse KOBILCardReaderPropLoader muss angepasst
werden.
77
KAPITEL 7. AUSBLICK
7.1.6 Das Applet als eigenständige Webanwendung
Das Applet ist in seiner jetzigen Version ein Teil der Enrollment-Seite und bekommt alle
benötigten Daten wie Zertifikate, Schlüssel, PUK der Karte als Appletparameter übegeben. Für die Zukunft könnte man sich überlegen, das Applet auch als eigenständige
Webanwendung bereitzustellen. Das würde bedeuten, dass die Kommunikation mit dem
Enrollment-Server, die momentan über die Enrollment-Seite abgewickelt wird, von dieser
Seite entkoppelt und im Applet realisiert werden soll. Das Applet wird direkt eine Verbindung mit dem Enrollment-Server aufbauen müssen, um relevante Daten auszutauschen.
Um diese Änderung zu realisieren, müsste man nicht nur das Applet entsprechend anpassen, sondern auch die Logik im FlexiTrust Identity Management. Dies erfordert einen
höheren Aufwand, den sich FlexSecure zu diesem Zeitpunkt nicht leisten konnte. Deswegen bleibt diese Änderung eine Aufgabe für die Zukunft.
Dessen ungeachtet wurden schon einige Klassen erzeugt, die in der jetzigen Version des
Applets nicht verwendet werden und für den späteren Einsatz im eigenständigen Applet
gedacht sind. Die ersten zwei repräsentieren einen Teil der Benutzeroberfläche und die
letzten zwei enthalten die Logik:
• ChooseOperationPanel: dient zur Auswahl der gewünschten Smartcardoperation
• LoginPanel: dient zum Einloggen auf dem Enrollment-Server
• LoginAction: hier soll der Aufbau der Verbindung zum Enrollment-Server implementiert werden
• SetOperationAction: hier wird dem Applet mitgeteilt, welche Operation vom Benutzer ausgewählt wurde
7.2 Verbesserungen
Mit dieser Version von FlexCardAdmin ist es, wie schon in den Abschnitten 4.2.3 und
4.2.4 beschrieben, nicht möglich die Smartcard oder den Kartenleser des Benutzers automatisch zu erkennen. Diese müssen entweder vom Administrator oder vom Benutzer
angegeben werden. Der Grund liegt im Konzept der Frameworks, auf die FlexCardAdmin
aufbaut: der PKCS#11-Provider und SmartcardServices. Um die automatische Erkennung
der Karte / des Kartenlesers zu ermöglichen, muss erforscht werden, ob die Konzepte so
angepasst werden können, dass die Initialisierung der Kartenschnittstellen ohne Kenntniss
der Karte oder des Kartenlesers möglich ist.
Die Smartcard-Administration ist bei FlexiTrust Identity Management so konzipiert, dass
die PUK der Smartcard dem Benutzer unbekannt bleibt. Aus diesem Grund wurde im
FlexCardAdmin die Eingabe der PUK (über die Benutzeroberfläche oder am Kartenleser) nicht vorgesehen. Das Applet könnte so erweitert werden, dass das Vorhandensein der Funktionalität zur PUK-Eingabe konfigurierbar ist. Der Benutzer könnte über
einen Konfigurationsparameter steuern, ob die PUK eingegeben werden muss oder nicht.
Dementsprechend müsste die Benutzeroberfläche aufgebaut werden und in Abhängigkeit
des Parameterwertes, Eingabefelder für die PUK ein- oder ausblenden.
78
Anhang A
Benutzeroberfläche
Abbildung A.1: Zwei der möglichen Varianten des ConfigurationPanels(1)
79
ANHANG A. BENUTZEROBERFLÄCHE
Abbildung A.2: Zwei der möglichen Varianten des ConfigurationPanels(2)
80
ANHANG A. BENUTZEROBERFLÄCHE
Abbildung A.3: Die zwei Varianten des PersonaliseCardPanels
81
ANHANG A. BENUTZEROBERFLÄCHE
Abbildung A.4: Die zwei Varianten vom DeleteCardPanel
82
ANHANG A. BENUTZEROBERFLÄCHE
Abbildung A.5: Die zwei Varianten vom ResetPINPanel
83
ANHANG A. BENUTZEROBERFLÄCHE
Abbildung A.6: Die zwei Varianten vom ChangePINPanel
84
Literaturverzeichnis
[acta]
ActiveX.
http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/
definitionen/activexcontrols.htm
[actb]
ActiveX.
http://www.softwareacademy.de/webscripting/referenz/
Default.aspx?opera=073.html
[actc]
Aktive
Inhalte.
http://www.bsi.de/fachthem/sinet/gefahr/
aktiveinhalte/index.htm
[app]
Applet. http://java.sun.com/docs/books/tutorial/deployment/applet/
index.html
[Buc03] Buchmann, Johannes: Einführung in die Kryptographie. Springer, Berlin, 2003
[Cor00] Coroama, Vlad:
Flexible Anbindung von SmartCards an eine JavaSicherheitsinfrastruktur. Entwurf und Implementierung eines HardwareProviders für die Java Cryptography Architecture, TU Darmstadt, Diplomarbeit,
März 2000
[Dra06] Drahavets, Maryia:
Flexible Anbindung von Smartcards an eine
Sicherheitsinfrastruktur, TU Darmstadt, Diplomarbeit, August 2006.
http://www.cdc.informatik.tu-darmstadt.de/reports/reports/Maryia_
Drahavets.diplom.pdf
[fle]
FlexSecure GmbH. http://www.flexsecure.de/
[GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph E. ; Vlissides, John: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley,
1995. – ISBN-10: 0201633612 ISBN-13: 978-0201633610
[Gmb] GmbH, FlexSecure: Trustcenter Software FlexiTrust. http://www.flexsecure.
de/ojava/flexitrust.html
[Gmb05] GmbH, KOBIL S.: Lösungskonzept ZDF Smartcard Enrollment. Juni 2005
[Gmb06a] GmbH, FlexSecure: FlexiTrust Identity Management: Produktbeschreibung.
Juni 2006
[Gmb06b] GmbH, KOBIL S.: mIDentity Manager Professional Manual. Oktober 2006
[JP]
Java-Wrapper für PC/SC: JPC/SC. http://www.musclecard.com/middle.
html
[jpc]
JPC/SC Java API. http://www.musclecard.com/middle.html/
[kob]
KOBIL Systems GmbH. http://www.kobil.de/
[liv]
LiveConnect. http://java.sun.com/products/plugin/1.3/docs/jsobject.
html
85
Literaturverzeichnis
[Lud07] Ludwig-Maximilians-Universität München:
Web-Programmierung
mit Java. www.medien.ifi.lmu.de/fileadmin/mimuc/mt_ss05/mtB7a.pdf.
Version: 2007
[Mor97] Morrison, Michael: Java 1.1 Unleashed. Sams.Net Publishing, 1997. – ISBN
1575212986
[mus]
MUSCLE - Movement for the Use of Smart Cards in a Linux Environment.
http://www.linuxtnet.com
[OC]
Open Card Framework. http://www.opencard.org
[ocf]
PC/SC CardTerminal für OCF. http://www.gemplus.com/techno/opencard/
cardterminals/pcsc/download.html
[OP]
Open Card Properties.
http://www.opencard.org/docs/pguide/PGuide.
html#HDROCPROPERTYFILELOADER
[PTT01] Produktbereich T-TeleSec, Deutschen Telekom A.: Telesec Chipcard Operating System: Betriebssystem für Chipkarten TCOS V2.0 Release 3. Januar
2001
[RSA99] RSA Laboratories:
PKCS#12 v1.0: Personal Information Exchange
Syntax.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf.
Version: Juni 1999
[RSA00] RSA Laboratories: PKCS#10 v1.7: Certification Request Syntax Standard.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf.
Version: Mai 2000
[RSA04] RSA Laboratories:
PKCS#11 v2.20: Cryptographic Token Interface Standard.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/
pkcs-11v2-20.pdf. Version: Juni 2004
[Sie]
Siemens:
CardOS: Betriebssystem für Chipkarten.
http://www.
medical.siemens.com/webapp/wcs/stores/servlet/ProductDisplay~q_
catalogId~e_-11~a_catTree~e_100010,1008631,1009807,1009806,
1009810~a_langId~e_-11~a_productId~e_173293~a_storeId~e_10001.htm
[wiz]
Swing-Wizard. http://java.sun.com/developer/technicalArticles/GUI/
swing/wizard/
86