Implementierung eines Selbstbedienungsclients fur eine ... · Kryptographie, die Chipkartentechnologie und die Public-Key-Infrastrukturen (PKI). Die digitale Identit at besteht aus

Technische Universitat Darmstadt

Fachbereich Informatik

Fachgebiet Theoretische Informatik - Kryptographie und Computeralgebra

Prof. Dr. Johannes Buchmann

Implementierung eines Selbstbedienungsclients fur

eine dezentral administrierbare Trustcenter-Losung

Diplomarbeit

von

Iskra Tomova

Studiengang: Informatik (Diplom)

Betreuer: Marcus Lippert (FlexSecure GmbH)

Dezember 2007

Hiermit versichere ich, die vorliegende Diplomarbeit selbststandig 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 ahnlicher Form noch keiner Prufungsbehorde vorgelegen.

Darmstadt, den 21. Dezember 2007

Iskra Tomova

ii

Inhaltsverzeichnis

1 Einleitung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 42.1 ActiveX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Einbindung in Webseiten . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Zugriff auf ActiveX-Objekte . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 Unterstutzte Plattformen . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Einbindung in Webseiten . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Kommunikation zwischen dem Applet und der Webseite . . . . . . 9

2.2.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.4 Unterstutzte Plattformen . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 ActiveX versus Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Standardisierte Kartenschnittstellen . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.2 PC/SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.3 OCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Ist- und Soll-Analyse 183.1 FlexiTrust Identity Management . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Komponentenuberblick . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2 Smartcardoperationen . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3 Die OCX-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 FlexCardAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2 Qualitatsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.3 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Designentstehung 314.1 Analyse des Frameworks SmartcardServices . . . . . . . . . . . . . . . . . 31

4.1.1 Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.2 Kartenoperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

iii

Inhaltsverzeichnis

4.1.3 Referenzieren von Objekten auf der Karte . . . . . . . . . . . . . . 33

4.2 Analyse der Kartenschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Anforderungen an die Umgebung . . . . . . . . . . . . . . . . . . . 35

4.2.2 Auswahl der Kartenschnittstelle . . . . . . . . . . . . . . . . . . . . 37

4.2.3 Auswahl des Kartenlesers . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.4 Auswahl der Chipkarte . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.5 Die Verknupfung Kartenschnittstelle - Kartenoperation . . . . . . . 40

4.3 Kommunikation mit dem Enrollment-Server . . . . . . . . . . . . . . . . . 40

5 Technisches Konzept und Implementierung 435.1 Aufbau der Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Die Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.1 Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.2 WizardPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.3 WizardPanelDescriptor . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Das Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.1 Verwaltung der Kartenschnittstellendaten . . . . . . . . . . . . . . 49

5.3.2 Verwaltung der Kartenleserdaten . . . . . . . . . . . . . . . . . . . 53

5.3.3 Verwaltung der Smartcard-Daten . . . . . . . . . . . . . . . . . . . 53

5.4 Der Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.1 Personalisieren einer Smartcard . . . . . . . . . . . . . . . . . . . . 54

5.4.2 Entsperren der Smartcard . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.3 Loschen der Karteninhalte . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.4 PIN andern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Schnittstelle zum Enrollment-Server . . . . . . . . . . . . . . . . . . . . . . 58

5.5.1 Allgemeine Applet-Parameter . . . . . . . . . . . . . . . . . . . . . 59

5.5.2 Datenaustausch bei der Smartcard-Personalisierung . . . . . . . . . 59

5.5.3 Zertifikat auslesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6.1 Allgemeine Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6.2 Kartenlesertreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.6.3 Referenzen auf Kartenobjekten . . . . . . . . . . . . . . . . . . . . 69

6 Zusammenfassung 72

7 Ausblick 747.1 Weiterentwicklung der Software . . . . . . . . . . . . . . . . . . . . . . . . 74

7.1.1 Hinzufugen neuer Karten . . . . . . . . . . . . . . . . . . . . . . . . 74

7.1.2 Hinzufugen neuer Kartenschnittstellen . . . . . . . . . . . . . . . . 75

7.1.3 Hinzufugen neuer Kartenleser . . . . . . . . . . . . . . . . . . . . . 76

7.1.4 Hinzufugen neuer Sprachen . . . . . . . . . . . . . . . . . . . . . . 76

7.1.5 Hinzufugen neuer Betriebssysteme . . . . . . . . . . . . . . . . . . . 77

7.1.6 Das Applet als eigenstandige Webanwendung . . . . . . . . . . . . 78

iv

Inhaltsverzeichnis

7.2 Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A Benutzeroberflache 79

Literaturverzeichnis 85

v

Abbildungsverzeichnis

2.1 Einbinden von ActiveX-Controls in Webseiten . . . . . . . . . . . . . . . . 5

2.2 Appletlebenszyklus (entnommen aus [Lud07]) . . . . . . . . . . . . . . . . 8

2.3 Der HTML-Tag <APPLET> zum Einbinden von Applets . . . . . . . . . 9

2.4 Zugriffsrechte von Applets auf Systemeigenschaften . . . . . . . . . . . . . 13

3.1 Komponenten von FlexiTrust und FlexiTrust Identity Management . . . . 21

4.1 Smartcardoperationen und die Kartenschnittstellenunterstutzung . . . . . . 34

5.1 Model-View-Controller-Pattern . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Der Aufbau des Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Ubersicht der WizardPanels . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4 Ubersicht der WizardPanelDescriptors . . . . . . . . . . . . . . . . . . . 47

5.5 Die Klasse WizardPanelDescriptor mit ihren Methoden . . . . . . . . . . 48

5.6 Die Klasse Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.7 Die Klasse Loader mit den wichtigsten Methoden . . . . . . . . . . . . . . 51

5.8 Die Klasse ObjectIdentifier mit den wichtigsten Methoden . . . . . . . 53

5.9 Die Klassen von Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.10 Die Action-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.11 Datenaustausch zwischen dem Enrollment-Server, FlexCardAdmin und der

Smartcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.12 Das HTML-Formular CertRequestForm und die JavaScript-Funktion

submitForm() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.13 Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenper-

sonalisierung (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.14 Integration von FlexCardAdmin in der ES-Seite im Fall einer Kartenper-

sonalisierung (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.15 Integration von FlexCardAdmin in der ES-Seite beim Loschen oder Ent-

sperren einer Smartcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.16 Konfigurationsparameter zum Referenzieren der Objekte auf der Karte . . 71

A.1 Zwei der moglichen Varianten des ConfigurationPanels(1) . . . . . . . . 79

A.2 Zwei der moglichen Varianten des ConfigurationPanels(2) . . . . . . . . 80

A.3 Die zwei Varianten des PersonaliseCardPanels . . . . . . . . . . . . . . . 81

A.4 Die zwei Varianten vom DeleteCardPanel . . . . . . . . . . . . . . . . . . 82

A.5 Die zwei Varianten vom ResetPINPanel . . . . . . . . . . . . . . . . . . . 83

vi

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 Willenserklarung haben sich auch

dementsprechend geandert. Normalerweise gilt der Personalausweis als Mittel der Identi-

fizierung und die Unterschrift ist ein anerkannter Vorgang zur Willensbekundung. Wenn

aber eine Person uber ein elektronisches Kommunikationsnetz wie das Internet identifi-

ziert werden soll oder eine unverwechselbare Willenserklarung abgeben mochte, sind diese

Mittel nicht anwendbar. Heute werden andere Losungen notig, die auch von Maschinen

interpretiert werden konnen. Man spricht von der digitalen Identitat. Drei Technologien

haben bei der Entstehung der digitalen Identitat eine entscheidende Rolle gespielt: die

Kryptographie, die Chipkartentechnologie und die Public-Key-Infrastrukturen (PKI).

Die digitale Identitat besteht aus Daten, welche die Nutzung von verschiedenen PKI-

Diensten wie Authentifikation, vertrauliche Kommunikation oder die digitale Unter-

zeichnung elektronischer Dokumente ermoglichen. Diese Daten konnen Zertifikate oder

Schlussel sein, die zur Authentifikation, zur Erstellung und Verifikation digitaler Signatu-

ren oder zur Ver- und Entschlusselung von Daten dienen. Da es sich um sensible Daten

handelt, die nicht jedem zuganglich sein durfen, mussen diese in einer sicheren Umge-

bung aufbewahrt werden. Chipkarten bieten das benotigte Sicherheitsniveau und werden

deswegen als Trager geheimer Informationen benutzt.

Die Chipkartentechnologie hat sich parallel zur Ausweitung der elektronischen Daten-

verarbeitung entwickelt und verspricht hohe Manipulationssicherheit und Zuverlassigkeit

sowie große Flexibilitat. Mit dem eingebauten Speicher ermoglicht die Chipkarte die

Aufbewahrung von Informationen, die maschinenlesbar sind. Sie bietet eine sichere

Umgebung fur 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 taglichen Leben eingesetzt werden konnen.

Immer mehr Unternehmen setzen Chipkarten im Rahmen der Unternehmens-PKI ein. Die

Einfuhrung 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, ware es nicht akzeptabel,

dass er deswegen nicht weiter arbeiten kann. Es soll moglich sein, eine Ersatzkarte

einfach und schnell auszustellen. Ansonsten werden die Geschaftsprozesse verlangsamt.

All dies spricht dafur, dass nicht nur die Nutzung der Chipkarten und der durch ihnen

ermoglichten PKI-Dienste dezentral und selbstbedient erfolgen soll, sondern auch ihre

Administration. Dies umfasst:

• den Roll-out (Personalisierung und Verteilung) der Chipkarten

• die Verlangerung der Schlussel- und somit der Kartengultigkeit

• das Handling von Notfall- und Ersatzkarten

• die Verwendung von Vertreterkarten

• das Loschen der Karteninhalte

• das Key-Backup von Verschlusselungsschlusseln

Um diese Anforderungen zu erfullen werden Anwendungen benotigt, die die Administra-

tion der Chipkarten ermoglichen und von den PKI-Teilnehmern bedient werden konnen.

1.1 Aufgabenstellung

Im Rahmen dieser Diplomarbeit soll eine Client-Anwendung implementiert werden, im fol-

genden FlexCardAdmin genannt, die die oben beschriebenen Anforderungen erfullt. 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. Die-

ses ist derzeit auf TCOS-2.0-Karten [PTT01] und CardOS-4.1-Karten [Sie] eingeschrankt

und verwendet eine OCX-Komponente, die in den Internet-Explorer installiert wird. Die

Losung ist also an Windows gebunden. Das Ziel ist, die bestehende OCX-Losung durch

eine neue zu ersetzen, die viel mehr Flexibilitat 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 Losung basieren. Durch den direkten Vergleich konnen die Nachteile der

bestehenden Losung besser hervorgehoben werden und die Notwendigkeit fur eine neue

Anwendung begrundet werden.

Im Kapitel 3, Ist- und Sollanalyse, wird die Funktionalitat von FlexiTrust Identity Mana-

2

KAPITEL 1. EINLEITUNG

gement beschrieben. Diese dient als Basis zur Spezifikation der Funktionalitat von Flex-

CardAdmin, die als Nachstes 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 Grunde

dafur gewesen sind.

Im Kapitel 5, Technisches Konzept und Implementierung, wird auf die technische Umset-

zung der Anforderungen eingegangen.

Das Kapitel 6, Zusammenfassung, beschreibt abschließend was durch diese Arbeit erreicht

wurde und gibt einen Uberblick uber das Endergebnis.

Im Kapitel 7, Ausblick, wird ein Blick in die Zukunft geworfen und erklart, wie die Soft-

ware 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 Flex-

CardAdmin verwendet werden und auch diejenigen, auf die die bestehende Losung Fle-

xiTrust Idenitity Management basiert. Diese Grundlagen sollen zum besseren Verstandnis

der Arbeit dienen. Zuerst wird eine kurze Einfuhrung in der ActiveX-Technologie darge-

boten, die in FlexiTrust Identity Management eingesetzt wurde. Es werden die Nachteile

vorgestellt und die Grunde erlautert, warum die Notwendigkeit besteht, diese Losung

durch eine neue zu ersetzen. Anschließend werden Applets eingefuhrt. Am Ende des Ka-

pitels wird noch auf die standardisierten Kartenschnittstellen eingegangen, da die Imple-

mentierung 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 ausfuhr-

barem Programmcode in Internet-Anwendungen, Webseiten oder generell in Microsoft-

orientierten Anwendungen beschreibt. Mit Hilfe von ActiveX werden die Anwendungen

in aktive Anwendugen verwandelt. ActiveX ist ein Uberbegriff fur verschiedene Software-

Komponenten. Alle diese Komponenten basieren auf dem sogenannten Component Object

Model (COM). Die ActiveX-Steuerelemente (oder ActiveX-Controls) sind vorkompilierte

wiederverwendbare Komponenten, die ahnlich wie Java-Applets, in Webseiten integriert

werden konnen. Somit werden die Webseiten dynamisch, was bei den statischen HTML-

Seiten nicht der Fall ist. Wenn die Webseite mit dem ActiveX-Control aufgerufen wird,

wird der ActiveX-Control aus dem Internet geladen (nachdem der Anwender bestatigt

hat, dass er das mochte) und auf dem Clientrechner installiert. Der Programmcode wird

clientseitig ausgefuhrt.

Da ActiveX-Controls nicht eigenstandig lauffahig sind, benotigen sie einen so genannten

ActiveX-Container, in den sie geladen und wo ihre Funktionen ausgefuhrt werden konnen.

Ein ActiveX-Container nimmt ActiveX-Objekte, wie beispielsweise ActiveX-Controls, auf

und kann ihre offentliche Eigenschaften (Objektvariablen) und Methoden (Objektfunktio-

nen) 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ß fruher OLE-Control (OLE steht fur Object Linking

and Embedding). OLE-Controls wurden umstrukturiert und umbenannt und in ActiveX-

Controls umgewandelt. Die OLE-Controls mußten eine Vielzahl von Methoden implemen-

tieren. Dadurch wurden sie in der Regel sehr groß. Solange sie nur von Containern wie

Visual Basic geladen wurden, war dies nicht wichtig. Seitdem die Moglichkeit besteht, sie

uber das Internet in einen Browser zu laden, hat ihre Große enorm an Bedeutung gewon-

nen. Deswegen hat Microsoft den Namen geandert und ActiveX-Controls so konzipiert,

daß diese nur die Methoden zu implementieren brauchen, die sie auch tatsachlich benoti-

gen. Somit sind ActiveX-Controls auf das Wesentliche reduziert und verglichen mit ihren

Vorgangern 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 Java-

Script) mit Bedienungslogik versorgt. Der Anwender benotigt allerdings einen ActiveX-

fahigen 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 fur 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 norma-

lerweise die Klassen-ID spezifizieren, denn beim Laden des Controls vom Server wird die

Klassen-ID verwendet, um das Control zu authentifizieren. Es wird uberpruft, ob das

Control zertifiziert wurde und ob das Zertifikat noch gultig 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, uber die von einer Skriptsprache aus

auf das Objekt zugegriffen werden kann. Ublicher ist jedoch der Zugriff uber die Namens-

ID.

Das codebase-Attribut wird dafur verwendet, das Control aus dem Netz zu laden, wenn

es auf dem lokalen System fehlt.

5


Fur jedes ActiveX-Control konnen beliebige zusatzliche Attribute mittels <PARAM>-

Tags definiert werden. Jedes Attribut besitzt einen Namen und einen Wert.

2.1.2 Zugriff auf ActiveX-Objekte

Grundsatzlich hat man aus einer Webseite heraus zwei Moglichkeiten fur den Zugriff auf

ein ActiveX-Control:

• mittels der Objektattribute definiert innerhalb der <PARAM>-Tags, deren genaue

Auspragung der Dokumentation jedes einzelnen ActiveX-Controls zu entnehmen ist.

• mittels Skript-Routinen, welche uber die ubliche Punktnotation ([Objekt ].[Eigen-

schaft/Methode]) auf die vom Control nach aussen dokumentierten Schnittstellen-

elemente zugreifen.

Der einfachste Zugriff auf ein Objekt funktioniert uber eine VBScript-Procedure mit dem

Namen <Objekt-ID> Click. Diese wird automatisch bei jedem Mausklick auf das Control

aufgerufen. Die flexiblere Zugriffsmoglichkeit 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 Eigen-

schaften identisch zu den Angaben im <PARAM>-Bereich des <OBJECT>-Containers

sind.

2.1.3 Sicherheit

Wenn man ein ActiveX-Control auf seinem Rechner erlauben mochte, 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 Con-

trol tatsachlich von dem angegebenen Entwickler stammt und daß es nachtraglich nicht

verandert wurde. Es gibt keine Garantie, dass die Ausfuhrung des Controls trotz Signatur

nicht schadlich fur 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 fuhren die Lizensierungsorganisationen mit hoher Wahrscheinlich-

keit verschiedene Uberprufungen durch, bevor eine Signatur ausgestellt wird. Somit wird

die signierte Software viel vertrauenswurdiger als diejenige, die nicht signiert ist.

Die tiefgreifenden Manipulationsmoglichkeiten auf fremden Rechnern uber ActiveX-

Controls aus einer Webseite heraus sind insbesondere aus Grunden der Sicherheit sehr

bedenklich. Viele Anwender lassen deswegen uberhaupt 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 uberhaupt 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 ausfuhren, die auch schadlich

6


sein konnten. Die Rechte des Controls auf dem Clientrechner sind uneingeschrankt.

Es besteht keine Moglichkeit festzulegen, dass das Control nur bestimmte Operationen

ausfuhren darf und andere nicht. Das Control bekommt entweder alle Rechte oder keine.

Lauft das ActiveX-Programm erst einmal, dann ist sein Funktionsumfang in keiner Weise

eingeschrankt oder kontrollierbar. Es lauft mit allen Rechten des angemeldeten Benutzers

- ohne jede Einschrankung. Es ist demnach leicht, private oder sicherheitsrelevante Daten

auszulesen, zu loschen, zu manipulieren, den Rechner umzukonfigurieren, einen Virus

oder ein Trojanisches Pferd zu installieren.

2.1.4 Unterstutzte Plattformen

ActiveX-Controls wurden fur die Windows-Welt konzipiert. Im Laufe der Zeit wurden

einige Versuche gemacht, ActiveX-Controls auch in anderen Betriebssystemen ausfuhrbar

zu machen.

• ActiveX unter Macintosh: Ende 1996 veroffentlichte Microsoft ein Software Deve-

lopment Kit (SDK) fur die Erstellung von ActiveX-Controls auf Apple Macintosh-

Plattformen. Diese ActiveX-Controls liefen im Internet Explorer fur Macintosh-

Plattformen ab Version 2. Die Macintosh ActiveX-Implementierung beruht auf einer

vereinfachten COM-Bibliothek. ActiveX-Controls werden hier nicht als eigenstandi-

ger Prozess außerhalb des Web-Browsers ausgefuhrt, sondern verbleiben in der Web-

Browser-Umgebung. Der Einsatz von ActiveX-Controls ist hier demnach nicht so

gefahrlich wie unter Windows. Jedoch wird von Microsoft nur noch die Version 5

des Internet Explorers fur den Macintosh unterstutzt, eine Weiterentwicklung des

Web-Browsers fur Macintosh-Umgebungen ist nicht geplant.

• ActiveX unter Linux: Auch fur UNIX-Plattformen arbeitet Microsoft zusammen mit

mehreren anderen Herstellern an einer ActiveX-Unterstutzung. Unabhangig hiervon

bestehen auch Implementierungen unter dem UNIX-Derivat Linux, um ActiveX-

Controls ausfuhren zu konnen. Fur den unter Linux lauffahigen Web-Browser Kon-

queror gibt es Bibliotheken, mit denen ActiveX-Controls ausgefuhrt werden konnen.

Da durch diese der Zugriff auf die lokalen Daten moglich 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 oh-

ne Zusatz als ActiveX-Container eingesetzt werden kann. Der Netscape Navigator, Mozilla

und der Konqueror konnen durch ein entsprechendes ActiveX-Plug-In erweitert werden,

damit auch hier ActiveX-Controls genutzt werden konnen.

2.2 Applet

Die folgende Beschreibung von Applets wurde aus [app] und [Lud07] entnommen und

hier zusammengefasst. Applets sind ausfuhrbare Java-Programme, die in eine Webseite

7


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 ausgefuhrt.

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 Oberflache, die die Interaktion mit dem Benutzer ermoglicht. Fur die Applets,

die diese GUI mit Swing-Komponenten aufbauen, bietet das Swing-Framework eine

spezielle Unterklasse von java.applet.Applet, namlich 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 Appletausfuhrung 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 verlasst, um eine andere Webseite aufzumachen, oder wenn der Browser ge-

schlossen wird. stop() halt die Appletausfuhrung 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 wahrend des Lebenszyklus

des Applets aufgerufen; die anderen zwei Methoden konnen mehrfach aufgerufen werden.

Alle vier Methoden konnen von den Unterklassen von Applet uberschrieben werden, um

das Appletverhalten zu spezifizieren.

8


2.2.1 Einbindung in Webseiten

Applets lassen sich mit dem <APPLET>-HTML-Tag in Webseiten einbinden (siehe Ab-

bildung 2.3). Dieser Tag hat folgende Attribute, die spezifiziert werden mussen:

• 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 mussen 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 Hohe der Applet-GUI in der Webseite festgelegt.

Fur jedes Applet konnen zusatzliche Attribute mittels des <PARAM>-Tag definiert wer-

den. 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 Moglichkeiten an. Skriptsprachen

wie JavaScript dagegen wurden dafur entwickelt, auf die einzelnen HTML-Elemente einer

Webseite zuzugreifen und verschiedene Operationen darauf auszufuhren. Wenn man Java

und JavaScript kombiniert wird die Interaktion zwischen dem Applet und der Websei-

te moglich und die Appletfahigkeiten werden erweitert [Mor97]. Um die Kommunikation

zwischen Java und JavaScript zu ermoglichen, hat Netscape die LiveConnect-Technologie

[liv] entwickelt. Mit LiveConnect wird es moglich, uber JavaScript auf Java-Objekte, -

Methoden und -Variablen zuzugreifen und umgekehrt konnen JavaScript-Funktionen von

einer Java-Anwendung aufgerufen werden.

Mit JavaScript kann das Appletverhalten beeinflusst werden. Das Applet kann dazu ge-

bracht werden, auf verschiedene Ereignisse in der HTML-Seite zu reagieren, indem die

9


Appletmethoden aufgerufen werden. JavaScript kann auf alle offentlichen Methoden oder

Attribute des Applets zugreifen. Dafur mussen diese offentlichen Methoden und Attribute

des Applets dem Entwickler bekannt sein. Im <APPLET>-Tag muss außerdem der Ap-

pletname spezifiziert werden, weil das Applet uber seinen Namen angesprochen wird. Die

Funktionen oder Attribute des Applets konnen ebenso uber den Appletnamen aufgerufen

bzw. abgefragt werden. Um eine Applet-Methode aufzurufen wird folgende Syntax ver-

wendet: document.appletName.methodName(arg1,..., argx). Im Folgenden wird ge-

zeigt 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>

Fur die Kommunikation von Java zu JavaScript stellt Netscape drei Java-Klassen zur

Verfugung:

• netscape.javascript.JSObject

• netscape.javascript.JSException

• netscape.plugin.Plugin

Will man von Java aus auf ein Objekt einer JavaScript-Anwendung zugreifen, so verhullt

JavaScript dieses Objekt in einer Instanz der Klasse netscape.javascript.JSObject.

Jede Instanz von JSObject reprasentiert eine DOM-Entitat 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, verhullt in einer JSObject-Instanz. Nachdem man diese Referenz bekom-

men hat, kann das Applet in die Webseite navigieren und mit der Methode getMember()

auf einzelne Elemente zugreifen. getMember() liefert das nachste Element in der Hier-

archie der HTML-Elemente. Das oberste Element in dieser Hierarchie ist das window-

Objekt. 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


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 andern, gibt es die Methode setMember(String elementName,

String value). Die Methode bekommt den Namen des Elements, dessen Wert geandert

werden soll, und den neuen Wert ubergeben.

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 auf-

gerufen werden konnen. Bei der ersten Methode werden der JavaScript-Methodenname

und ihre Argumente separat ubergeben. Die zweite Methode bekommt den Methodenauf-

ruf als String ubergeben. Dies kann z.B. so aussehen:

eval("document.writeln(\"Hier wird ein Text angezeigt.\");")

Aus Sicherheitsgrunden ist die Benutzung von JSObject standardmaßig nicht zugelassen.

Um JSObject verwenden zu konnen, muss das Applet mit dem zusatzlichen Attribut

MAYSCRIPT versehen werden. Wenn dieses Attribut im Applet fehlt, ist die Benutzung

von JSObject nicht moglich.

<APPLET code="MyApplet.class" width=50 height=50 NAME="Preview" MAYSCRIPT>

2.2.3 Sicherheit

Ahnlich wie die ActiveX-Controls, konnten Applets auf dem Clientrechner Schaden an-

richten. Sie werden uber das Internet geladen und gestartet und konnten verwendet wer-

den, um Daten auf dem lokalen Rechner zu verandern, loschen oder zu lesen, ohne dass

11


der Betrachter der Webseite, die das Applet enthalt, dies merkt. Um das zu verhindern

und die sichere Ausfuhrung von Applets zu ermoglichen, werden die Rechte des Applets

beschrankt. Dazu wird das Applet in einem speziellen Bereich ausgefuhrt, in dem nur

bestimmte Operationen zugelassen sind. Dieser Bereich wird als Sandkasten oder Sand-

box bezeichnet. Versucht das Applet Operationen außerhalb der Sandbox auszufuhren,

wird dies erkannt und unterbunden. Normalerweise gelten folgende Einschrankungen fur

Applets:

• Es durfen keine Operationen auf Dateien wie Lesen, Schreiben oder Umbenennen

durchgefuhrt werden. Außerdem durfen keine neuen Dateien angelegt werden und

auch nicht gepruft werden, ob eine bestimmte Datei existiert.

• Es durfen 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 zu-

greifen. Abbildung 2.4 gibt eine Ubersicht.

• 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 konnen von Applets weder gestartet, gestoppt, unterbrochen, noch

kann ihre Prioritat geandert werden. Manipulationen an den Threads in der eigenen

virtuellen Maschine, in der das Applet lauft, sind jedoch moglich.

• Der Aufruf nativer Methoden ist verboten. Eine Ausnahme stellen einige Methoden

des JDK dar.

• Applets durfen keine Bibliotheken, beispielsweise mittels System.loadLibrary(),

laden.

Durch diese restriktive Politik wird auch gutartigen Applets die Moglichkeit genommen,

ausgefuhrt zu werden. Deswegen wurden die Sicherheitsmaßnahmen bei Applets so an-

gepasst, dass bestimmte Applets mehr Rechte bekommen, wenn sie entweder digital si-

gniert sind und vom Benutzer als vertrauenswurdig eingestuft wurden, oder lokal auf dem

Rechner in einem CLASSPATH-Verzeichnis installiert sind. Fur solche Applets sind die

Einschrankungen aufgehoben.

Damit ein Java-Applet digital signiert werden kann, benotigt der Entwickler ein Zer-

tifikat. Das Zertifikat kann bei einem Zertifikatsaussteller erworben werden. Es enthalt

Signaturprufdaten, die Aufschluss uber 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 re-

ferenziert. Fordert der Web-Browser des Anwenders eine solche HTML-Seite an, so wird

zunachst die digitale Signatur des Archivs gepruft. Anschließend erscheint eine Meldung

im Web-Browser, die die Signaturprufdaten des Zertifikats anzeigt und erfragt, ob der

Anwender dem Applet mehr Rechte erteilen will. Bestatigt der Anwender diese Meldung

12


Systemeigenschaft Beschreibung Kann von Ap-plets ausgele-sen werden?

file.separator Dateienseparator (z.B.”/“) ja

java.class.version Version der Java-Klasse jajava.vendor Java-Vendor-spezifischer String jajava.vendor.url URL des Java-Vendors jajava.version Java-Version jaline.separator Zeilenseparator jaos.arch Architektur des Betriebssystems jaos.name Name des Betriebssystems japath.separator Pfadseparator (z.B.

”:“) ja

java.class.path Java-Classpath neinjava.home Verzeichnis mit der Java-

Installationnein

user.dir Arbeitsverzeichnis des Benutzers neinuser.home Home-Verzeichnis des Benutzers neinuser.name Loginname das Benutzers nein

Abbildung 2.4: Zugriffsrechte von Applets auf Systemeigenschaften

positiv, wird das digital signierte Java-Applet mit den entsprechend eingeforderten Rech-

ten im Web-Browser ausgefuhrt.

2.2.4 Unterstutzte Plattformen

Webseiten mit Applets konnen mit einem Java-fahigen Browser betrachtet werden. Alle

aktuellen Browser verfugen uber eine Java-Virtual-Machine, sind Java-fahig und somit in

der Lage, Java-Applets auszufuhren.

2.3 ActiveX versus Applets

Wenn man sich zwischen ActiveX und Applets entscheiden soll, spricht einiges fur die

Applets. Ihre Hauptvorteile sind:

• Applets sind plattformunabhangig. Da sie in Java geschrieben werden, sind sie in

jedem Betriebssystem ausfuhrbar. ActiveX-Controls dagegen laufen nur unter Win-

dows.

• Applets werden von mehreren Browsern unterstutzt. Der einzige Browser dagegen,

der ohne Zusatz als ActiveX-Container eingesetzt werden kann, ist Internet Ex-

plorer. Die restlichen Browser mussen zuerst durch einen ActiveX-Plugin erweitert

werden.

13


• Die Sicherheitsmaßnahmen bei Applets sind viel besser. Applets werden in einer

Sandbox ausgefuhrt, in der nur bestimmte Operationen zugelassen sind. Mochte

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 uber die zulassigen Operationen

nicht. Das Control bekommt entweder alle Rechte oder keine, unabhangig davon ob

es signiert ist oder nicht. Damit erweist sich die Systemsicherheit als großes ActiveX-

Problem. ActiveX-Komponenten haben vollen Zugriff auf das System und empfindli-

che Speicherbereiche. So bietet sich eine Angriffsflache fur Viren und Online-Spione.

Der einzige Schutzmechanismus ist eine Herkunftskennung. Anhand eines Zertifikats

sollen sich Programmierer von ActiveX-Controls ausweisen und erklaren, dass ihr

Code bedenkenlos laufen kann.

Sicherlich hat auch ActiveX gewisse Vorteile:

• In Sachen Geschwindigkeit haben ActiveX-Controls ihren Java-Konkurrenten eini-

ges voraus. Die Unabhangigkeit vom Betriebssystem und Prozessor erkauft sich Java

mit Geschwindigkeitsverlusten. Die Ubersetzung des Java-Zwischencodes in der Vir-

tual Machine kostet Zeit. Zudem kann Java wegen der Sicherheitsbeschrankungen

nicht alle Raffinessen eines Betriebssystems oder Prozessors ausnutzen. Bei ActiveX

verzichtete man auf den Zwischencode, da es ActiveX nur fur Windows gibt. Die

Controls sind bereits in Maschinensprache fur Intel und Windows ubersetzt 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 Anwen-

dungsfall analysieren. In bestimmten Fallen wird es besser sein, ActiveX zu verwenden,

in anderen werden Applets die geeignetere Wahl sein. Wenn man aber auf die Sicherheit

und die Plattformunabhangigkeit Wert legt, sind Applets zu bevorzugen.

2.4 Standardisierte Kartenschnittstellen

Wenn Smartcards als Trager der digitalen Identitat im Rahmen von Public-Key-

Infrastrukturen eingesetzt werden, werden sie im Normalfall uber 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

ermoglichen 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


2.4.1 PKCS#11

Der Public Key Cryptography Standard 11 (PKCS#11) [RSA04] ist eine der Spezifikatio-

nen von der Familie von Spezifikationen Public Key Cryptography Standards (PKCS), die

von RSA Laboratories spezifiziert wurde, um die Kompatibilitat und Interoperabilitat

zwischen verschiedenen kryptographischen Anwendungen zu erreichen. PKCS#11,

auch”Cryptoki“ (Abkurzung fur cryptographic token interface) genannt, stellt eine

C-Schnittstelle zu Geraten zur Verfugung, die kryptographische Daten aufbewahren

oder kryptographische Funktionen ausfuhren. Diese konnen zum Beispiel Smartcards,

USB-Tokens oder Handheld-PCs sein. Alle solche kryptographische Gerate werden als

ein sogenanntes kryptographisches Token betrachtet. Kartenleser dagegen werden als

sogenannte Slots aufgefasst. Das Ziel von PKCS#11 ist, die Unabhangigkeit der Anwen-

dungen von der verwendeten Hardware zu erreichen. Durch das Token-Konzept werden

alle Gerate 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 Unabhangigkeit auch als Nachteil interpetiert

werden, weil fur den Benutzer viele Aspekte transparent und unbeeinflussbar bleiben.

Man wird mit den Einschrankungen 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 benotigten PIN-/PUK-Operationen in den bekannten

PKCS#11-Implementierungen verfugbar sind. Es ist zum Beispiel nicht moglich, die

PIN und die PUK der Karte zu loschen. Dadurch kann eine Smartcard nicht vollstandig

geloscht und nicht erneut personalisiert werden.

Um die C-Funktionen der PKCS#11-Schnittstelle aus einer Java-Umgebung aufru-

fen zu konnen, 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

Verfugung.

15


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 Computersyste-

men und Chipkarten. Bei PC/SC handelt es sich um eine Low-Level-Schnittstelle, wel-

che die Ubermittlung von APDUs zur Smartcard ubernimmt. Einerseits bedeutet dies,

dass man jeweils eine Implementierung pro Kartentyp benotigt; der Entwickler muss al-

so alle Details des Kartenbetriebssystems verstehen und die Entwicklungszeiten sind im

Vergleich zu PKCS#11 wesentlich langer. Außerdem besteht die Gefahr, dass mit jedem

Kartenbetriebssystemupdate die Applikation angepasst werden muss, weil benutzte Funk-

tionen nicht mehr verfugbar sind. Andererseits eroffnet die APDU-Welt die Moglichkeit,

die Smartcard-Funktionalitat in vollem Umfang auszunutzen und Funktionen zu imple-

mentieren, die der eigenen Bedurfnissen und Anforderungen genau entsprechen. Um die

PC/SC-Schnittstelle zu benutzen, muss ein PC/SC-Treiber fur den Kartenleser installiert

werden. Da der Standard weltweit hohe Verbreitung kennt, sind PC/SC-Treiber fur die

meisten Lesegerate verfugbar.

Um die PC/SC-Bibliothek aus einer Java-Umgebung anzusprechen, kann ein Java-

Wrapper fur PC/SC von IBM (JPC/SC) [jpc] verwendet werden.

PC/SC wurde ursprunglich fur Windows konzipiert, kann aber auf verschiedenen Platt-

formen eingesetzt werden. Von JPC/SC werden Windows- und Linux-Umgebungen un-

terstutzt. Das Projekt MUSCLE [mus] bietet PC/SC-Kartenlesertreiber fur 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 Smartcard-

Anwendungen. Das Framework ist auf jeder Java-fahigen Plattform einsetzbar

und ist damit als solches unabhangig 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 CardSer-

vices und CardTerminals bezeichnet). Die Installation ist aber im Gegensatz

zu PC/SC nicht trivial, weil zusatzlich zu den Bibliotheken noch das Frame-

work selbst installiert werden muss.

OCF bietet eine objekt-orientierte Smartcard-Schnittstelle, die Veranderungen

in Hardware oder im Smartcard-Betriebssystem vor der Anwendung verbirgt.

Das Framework definiert die Schnittstelle fur die Anwendung als sogenannte

CardServices. Die Implementierung eines CardService ist fur die Anwendung

transparent und kann jeder Zeit ausgetauscht werden.

OCF hat sich zum Standard im Java-Umfeld etabliert, es ist gut dokumen-

tiert und von umfangreichen Tutorials begleitet. OCF-Treiber existieren al-

16


lerdings nur fur wenige Kartenleser. Aus diesem Grund wurde ein OCF-

Wrapper fur 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 OCF-

Framework als Java-Wrapper fur die PC/SC-Schnittstelle, d.h. man kann aus

einer Java-Umgebung APDUs an die Smartcard senden. Durch die zusatzli-

chen Komponenten wird die Installation noch aufwandiger und benutzerun-

freundlicher, unter anderem weil der Wrapper sich auf die Java Comm API

stutzt.

17

Kapitel 3

Ist- und Soll-Analyse

In diesem Kapitel wird die bestehende Losung FlexiTrust Identity Management vorge-

stellt. 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. An-

schließend werden die Anforderungen an die neue Komponente FlexCardAdmin spezifi-

ziert.

3.1 FlexiTrust Identity Management

FlexiTrust Identity Management [Gmb06a] ist eine Webapplikation, welche die

Trustcenter-Software FlexiTrust [Gmb] erweitert und im Rahmen einer PKI samtliche

Aufgaben ubernimmt, die mit der dezentralen Personalisierung und Verwaltung von

Smartcards verbunden sind. Das System ermoglicht die selbstbediente Administration der

Smartcards. In jedem Unternehmen, das Chipkarten im Rahmen der Unternehmens-PKI

einsetzt, sind diese notwendige Operationen. Mit FlexiTrust Identity Management lasst

sich eine dezentrale und flexible Smartcard-Rollout-Infrastruktur aufbauen, die selbst-

bediente Verfahren unterstutzt und den eigenen Bedurfnissen und Anforderungen genau

entspricht.

Folgende Operationen lassen sich mit FlexiTrust Identity Management ausfuhren:

• Selbstbediente Personalisierung von Smartcards: Nachdem ein neuer Mitarbeiter in

einem Unternehmen eingestellt wird, wird ein neues Benutzerkonto fur ihn angelegt

und er muss seine Mitarbeiterkarte personalisieren. Er erhalt eine leere, unperso-

nalisierte Smartcard und seine Authentifizierungsdaten. Nach einer erfolgreichen

Authentifikation dem System gegenuber 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 fur

sich ausstellen. Dafur erhalt er eine leere Smartcard oder loscht vollstandig seine

Vorgangerkarte. Nach einer erfolgreichen Benutzerauthentifikation wird die Karte

neu personalisiert, wobei ein Key-Recovery fur gesicherte Schlusselpaare und ent-

sprechende Zertifikate stattfindet. Alle anderen Daten (Schlusselpaare, 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 ver-

legt, kann vom PKI-Administrator eine Notfallkarte mit einer kurzen Gultigkeits-

dauer erstellt werden. Gesicherte Schlusselpaare und entsprechende Zertifikate wer-

den ubernommen, alle anderen Daten werden neu generiert. Nach dem Ablauf der

Gultigkeit mussen Notfallkarten zuruckgegeben werden. Sie werden dann vom PKI-

Administrator vollstandig geloscht.

• Selbstbedientes Entsperren der Karte und Neusetzen der Geheimzahl (PIN): Eine

Karte wird gesperrt, wenn die PIN mehrmals falsch eingegeben wird. Die Anzahl der

moglichen Fehlversuche bei der PIN-Eingabe ist konfigurierbar und wird beim Per-

sonalisieren der Smartcard gesetzt. Nach einer erfolgreichen Authentifikation dem

System gegenuber kann der Kartenbesitzer die Karte entsperren und seine PIN neu

setzen.

• Selbstbedientes Loschen der Karteninhalte: Wenn ein Mitarbeiter das Unternehmen

verlasst, gibt er seine Smartcard zuruck und diese wird vollstandig geloscht. Nach

dem Loschen ist die Karte leer und kann neu personalisiert werden.

Fur alle oben beschriebenen selbstbedienten Smartcard-Operationen ist eine Benutzerau-

thentifikation mit Benutzernamen, Passwort und Einmalpasswort (TAN) erforderlich. Die-

se findet uber ein Webinterface statt. Die Benutzer bekommen Zugriff auf das System uber

eine Webseite (die Enrollment-Seite), auf der sie sich mit ihrem Benutzernamen, Passwort

und der TAN authentifizieren mussen. Von dort aus konnen die Smartcardoperationen

ausgefuhrt werden.

Das TAN-Konzept tragt dafur Sorge, dass die ausgefuhrten Smartcardoperationen kon-

trolliert und verwaltet werden konnen. Mit der TAN kann eine Operation nur einmal und

nur von dem TAN-Besitzer ausgefuhrt werden. Das Einmalpasswort wird automatisch

generiert, nachdem der Benutzer einen Request fur eine bestimmte Smartcardoperation

gestellt hat. Die TAN kann nur fur 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 gewunschte Operation ausfuhren. Um die

Sicherheit zu erhohen, ist die TAN zusatzlich an die Smartcard-Seriennummer gebunden

und hat eine begrenzte Gultigkeitsdauer. Fur einen Benutzer darf immer hochstens 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 ermoglicht die Kenntnis

der PUK die zentrale Ausfuhrung wichtiger Administrationsaufgaben. Jede zuruckgegene

Karte (z.B. die Karte eines Mitarbeiters, der das Unternehmen verlasst, oder eine Notfall-

karte) kann vom PKI-Administrator problemlos mit Hilfe der PUK vollstandig geloscht

werden.

19


3.1.1 Komponentenuberblick

Abbildung 3.1 gibt eine Ubersicht der Komponenten der Trustcenter-Software FlexiTrust.

Die Komponenten, die zu FlexiTrust Identity Management gehoren, sind rot markiert.

Diese sind:

• Anmeldeserver mit Benutzerschnittstelle (im Folgenden Enrollment-Server oder ES

genannt): Das Eingangsportal fur die PKI-Teilnehmer. Es bietet eine HTML-Seite

an, auf der sich die PKI-Teilnehmer mit Benutzernamen, Passwort und TAN an-

melden und selbstbediente Smartcardoperationen ausfuhren konnen.

• Datentransport (im Folgenden Enrollment Server Importer oder ESI genannt):

zustandig fur den Datentransport zwischen dem Enrollment-Server und der

FlexiTrust-Zertifizierungsstelle, wie man in der Abbildung 3.1 sehen kann. Da die

Funktionen dieser Komponente fur diese Arbeit nicht relevant sind, werden sie nicht

naher beschrieben.

• OCX-Komponente: zustandig fur 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

ubernimmt folgende Aufgaben:

– Personalisierung der Karte

∗ PIN/PUK mit Fehlbedienungszahler (FBZ) auf die Karte schreiben

∗ Verschlusselungszertifikat bzw. Schlusselbackup einspielen

– PIN der Chipkarte unter Benutzung der PUK zurucksetzen. Der FBZ der PIN

wird dabei zuruckgesetzt.

– Komplette Karte mit Hilfe der PUK loschen. Dabei werden PIN, PUK und alle

Zertifikate geloscht. Die Karte kann dann wieder neu personalisiert werden, wie

im Urzustand.

– Sonstige Hilfsoperationen

∗ PIN verifizieren

∗ Kartenseriennummer auslesen

∗ Personalisierungsstatus der eingelegten Chipkarte feststellen (leer oder in-

itialisiert)

• Verwaltungskonsole (auch Management Console oder MC genannt): ermoglicht die

Verwaltung der:

– Benutzerkonten

– Administratorenkonten

– Chipkarten

– Zertifikaten

– Sperrlisten

Die Verwaltungskonsole wird hier nicht naher beschrieben, weil sie fur diese Arbeit

irrelevant ist.

20


Abbildung 3.1: Komponenten von FlexiTrust und FlexiTrust Identity Management

21


3.1.2 Smartcardoperationen

Wie schon am Anfang dieses Kapitels erwahnt, sind folgende Operationen mit FlexiTrust

Identity Management moglich:

• 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 Loschen der Karteninhalte (Prozess”Karte loschen“)

Im Folgenden werden sie detaillierter beschrieben.

Personalisierung einer Smartcard

Eine Karte muss in folgenden Fallen personalisiert werden:

• Ein neues Benutzerkonto wurde angelegt (z.B. nachdem ein neuer Mitarbeiter ein-

gestellt wurde)

• Das Verschlusselungszertifikat/Signaturzertifikat ist abgelaufen

• Alle Inhalte der alten Karte wurden gesperrt

• Der Benutzername des Karteninhabers hat sich geandert (z.B. durch Namensande-

rung)

Aus den oberen Anwendungsfallen wird klar, dass die Notwendigkeit besteht, eine Kar-

te mehrmals personalisieren zu konnen. Dies wird von FlexiTrust Identity Management

sichergestellt.

Nachdem der Benutzer eine leere Smartcard und seine Authentifikationsdaten (Benut-

zername, Passwort und eine TAN fur 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. Datenprufung: ESI uberpruft die Benutzerdaten mittels Datenbankabfragen sowie

Abfragen am LDAP-Server; ESI generiert zufallige PIN und PUK und schickt diese

zuruck an den Enrollment-Server.

3. Kartenpersonalisierung Teil 1: Nach einer erfolgreichen Benutzeranmeldung er-

scheint eine Seite mit dem integrierten ActiveX-Control. Diese Seite zeigt die auto-

matisch generierte PIN der Karte. Die PUK wird wie schon am Anfang des Kapitels

erwahnt, nicht angezeigt. Auf der Seite kann der Benutzer außerdem seine Antwor-

ten auf verschiedene vordefinierte Sicherheitsfragen eingeben. Durch das Betatigen

einer Taste auf der Seite wird die Smartcard uber 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


vollstandig geloscht.

b) PIN und PUK werden zusammen mit dem Fehlbedienungszahler (FBZ) auf die

Karte geschrieben.

c) Die Schlusselpaare fur die elektronische Signatur und Windows-Smartcard-

Logon werden in der Karte erzeugt und damit PKCS#10-Zertifikatsantrage

[RSA00] erstellt.

d) Die Zertifikatsantrage werden an ESI geschickt.

e) Weitere Geheimnisse und Daten, die fur verschiedene Anwendungen erforder-

lich sind (z.B. Kobil SecOVID OTP Generator), werden auf die Karte geschrie-

ben.

4. Zertifikatserstellung: ESI leitet die Zertifikatantrage an die FlexiTrust-CA wei-

ter. Da fur das Verschlusselungsschlusselpaar ein Key-Recovery erwunscht ist, wird

es in der FlexiTrust-CA und nicht in der Karte erzeugt. FlexiTrust-CA erstellt das

zugehorige Verschlusselungszertifikat, sowie die zwei beantragten Zertifikate (fur Si-

gnatur und Windows-Smartcard-Logon). Das Verschlusselungsszertifikat und das

zugehorige Schlusselpaar werden als PKCS#12-Datei [RSA99] gesichert hinterlegt

(Key Backup). Außerdem loscht ESI die TAN und wartet anschließend bis die be-

antragten Zertifikate in die Datenbank geschrieben wurden, um diese zuruck 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 ActiveX-

Control schreibt die Zertifikate und das Verschlusselungsschlusselpaar auf die Karte.

Erneuern einer Smartcard

Eine Karte muss in folgenden Fallen erneuert werden:

• Das Signatur- oder Windows-Logon-Zertifikat lauft ab.

• Die Karte ist defekt oder verloren gegangen.

• Die Position des Benutzers im Unternehmen hat sich geandert.

Der Benutzer kann seine Karte erneuern, wenn er seine alte oder eine leere Smart-

card und eine TAN fur den Prozess”Ersatzkarte“ erhalten hat. Der Prozess, der bei der

Kartenpersonalisierung beschrieben wurde, wird hier wiederholt. Der Unterschied besteht

darin, dass das Verschlusselungsschlusselpaar und das Verschlusselungszertifikat nicht neu

erzeugt werden. Fur den Verschlusselungsschlussel findet ein Key-Recovery statt und das

zugehorige Zertifikat wird aus dem Archiv ausgelesen. Dadurch ist sichergestellt, dass der

Benutzer weiterhin auf seine verschlusselten Daten zugreifen kann.

Erstellung einer Notfallkarte

Eine Notfallkarte wird dann erstellt, wenn der Benutzer seine Karte verlegt oder verges-

sen hat. Diese Karten werden vom Administrator erstellt und haben eine kurze Gultig-

23


keitsdauer (z.B. einen Tag). Die Karte wird personalisiert wie eine Ersatzkarte, d.h. das

Verschlusselungsschlusselpaar und das zugehorige Zertifikat werden nicht neu erzeugt.

Entsperren der Smartcard

Die Karteninhalte sind durch die PIN geschutzt. 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 fur 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 (uber das bereitge-

stellte Webinterface) mit seinem Benutzernamen, Passwort und der TAN an.

2. Datenprufung: ESI uberpruft die Benutzerdaten. Es wird außerdem uberpruft,

ob die an die TAN gebundene Smartcard-Seriennummer mit der Seriennummer der

Chipkarte ubereinstimmt.

3. Karte entsperren: Durch das Betatigen einer Taste auf der angezeigten Webseite

wird die Karte uber die OCX-Komponente mit Hilfe der PUK entsperrt. Eine neue

PIN wird generiert und im Browser angezeigt. Der Fehlbedienungszahler der PIN

wird dabei zuruckgesetzt. Die neue PIN wird auf die Karte geschrieben.

Loschen der Karteninhalte

Karten mussen in folgenden Fallen geloscht werden:

• Eine zuruckgegeben Notfallkarte, um sie wieder zu verwenden

• Die zuruckgegebene Karte eines Mitarbeiters, der das Unternehmen verlassen hat

Nachdem der Benutzer die TAN fur den Prozess”Karte loschen“ erhalten hat, kann er

die Karte loschen. Dazu sind folgende Schritte notwendig:






3. Karte loschen: Durch das Betatigen einer Taste auf der angezeigten Webseite wird

die Karte uber die OCX-Komponente mit Hilfe der PUK komplett geloscht.

3.1.3 Die OCX-Komponente

Die OCX-Komponente ist zustandig fur die Realisierung der oben beschriebenen Smart-

cardoperationen. Sie wird auf dem Clientrechner installiert und ubernimmt alle Aufgaben,

24


die mit der Kommunikation und Datenubertragung zur Smartcard verbunden sind. Leider

weist diese Komponente gewisse Nachteile auf:

• Sie wurde speziell fur nur zwei Kartentypen (TCOS2.0 und CardOS) entwickelt. Alle

anderen Kartentypen werden nicht unterstutzt. Diese fehlende Flexibilitat schrankt

automatisch die Anzahl der potenziellen Anwender und Kunden ein. Die Hinzunah-

me neuer Kartentypen ist nicht trivial und nur mit hohem Aufwand realisierbar.

• Dadurch, dass die ActiveX-Technologie zu Grunde dieser Komponente liegt, ist

die Plattformunabhangigkeit nicht gewahrleistet (siehe auch Kapitel 2). ActiveX-

Controls sind nur unter Windows ausfuhrbar und ihr Einsatz auf verschiedenen

Plattformen ist somit beschrankt. Die Hinzunahme neuer Betriebssysteme ist also

auch nicht moglich.

• ActiveX wird nicht von vielen Browsern unterstutzt. Der einzige Browser, der ohne

Zusatz als ActiveX-Container eingesetzt werden kann, ist Internet Explorer. Die

restlichen Browser mussen zuerst durch einen ActiveX-Plugin erweitert werden.

Die OCX-Komponente ist also nicht flexibel genug und nicht erweiterbar. Es ist nicht

moglich, neue Komponenten in die Software hinzuzufugen. Es stellt sich die Frage welche

Technologie als Ersatz genommen werden kann, so dass alle diese Nachteile eliminiert

werden konnen. Im nachsten Kapitel wird diese Frage beantwortet.

3.2 FlexCardAdmin

Die neue Losung, die die bestehende OCX-Komponente ersetzen soll und die im Folgenden

FlexCardAdmin genannt wird, soll alle vorhandene Probleme eliminieren und folgende

Bedingungen erfullen:

• Die Plattormunabhangigkeit ist gewahrleistet

• Die Software ist im Browser ausfuhrbar und kann uber das Internet geladen werden.

• Alle gangige Browser werden unterstutzt.

• 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,

mussen zwei Voraussetzungen gegeben sein. Erstens muss auf den zu installieren-

den Rechner Java und WebStart installiert sein und zweitens muss im Browser als

Hilfsanwendung fur Dateien mit der Endung .jnlp das aufuhrbare 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 ladt nun anhand der Eintrage in der

JNLP-Datei die zur Anwendung gehorenden JAR-Archive herunter, erzeugt, wenn

gewunscht einen Desktopshortcut und startet dann die Anwendung. Fur weitere

25


Starts der heruntergeladenen Anwendung ist dann meist keine Netzwerkverbindung

mehr notig. WebStart-Anwendungen werden nicht im Browser ausgefuhrt. Da ei-

ne der Anforderungen an FlexCardAdmin ist, dass dieser im Browser lauft, ist die

WebStart-Technologie zur Realisierung der neuen Losung nicht geeignet.

• Java Servlets: Servlets sind serverseitige Anwendungen, die nach einem vom Client

ausgelosten HTTP-Request dynamisch HTML-Seiten erzeugen und im Browser des

Clients anzeigen. Servlets bestehen aus Java-Klassen, die uber einen Webserver mit-

tels einer URL angesprochen werden. Servlets werden auf dem Server ausgefuhrt.

FlexCardAdmin soll aber eine clientseitige Anwendung sein, die auf dem Client-

rechner installiert und dort ausgefuhrt wird. Somit konnen auch Servlets fur die

Realisierung von FlexCardAdmin nicht verwendet werden.

• Java Server Pages (JSP): Eine Java Server Page is eine um Java-Code angerei-

cherte HTML-Seite. Java Server Pages erlauben die Vermischung von regularem,

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 eingefugt. Jede JSP wird automatisch zu einem

Servlet kompiliert und ausgefuhrt.

• Java Applets: ein Applet ist ein Java-Programm, das in einer HTML-Seite einge-

bettet ist und in einem Browser ausgefuhrt wird. Applets wurden schon ausfuhrlich

im Kapitel 2 eingefuhrt. Nach Berucksichtigung der gestellten Anforderungen und

dem Vergleich mit den anderen Webtechnologien, haben sich Applets als die geeig-

nete Technologie zur Erstellung von FlexCardAdmin erwiesen. Wie im Abschnitt

2.2 dargestellt, erfullt die Java-Applet-Technologie die ersten drei der oben genann-

ten Bedingungen. Daruber hinaus unterstutzen 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 vervollstandigt die

benotigten Sicherheitsmerkmale und garantiert daruber hinaus die Flexibilitat und

Erweiterbarkeit.

3.2.1 Funktionale Anforderungen

FlexCardAdmin soll alle Smartcardoperationen, die FlexiTrust Identity Management

ermoglicht und die im Abschnitt 3.1.2 vorgestellt wurden, unterstutzen. Die Smart-

cardfunktionen der OCX-Komponente werden durch das Betatigen einer Taste auf der

Enrollment-Webseite aufgerufen und anschließend ausgefuhrt. In der neuen Losung wird

diese Taste entfernt und stattdessen das Applet in der Webseite eingebettet. Beim Offnen

der Webseite wird das Applet automatisch geladen und ist einsatzbereit. FlexCardAdmin

soll eine passende Benutzeroberflache anbieten, um z.B. die Smartcard-PIN eingeben zu

konnen. Durch die Interaktion mit der Benutzeroberflache der Applets, kann ein Benutzer

eine bestimmte Smartcardoperation starten. Da Daten mit dem Enrollment-Server aus-

getauscht werden mussen, soll außerdem eine Schnittstelle zur Kommunikation mit dem

26


Enrollment-Server vorhanden sein.

Im Folgenden wird jede Smartcardoperation genauer analysiert und die Funktionalitat

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

unverandert. Trotzdem werden sie hier der Vollstandigkeit 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. Datenprufung: ESI uberpruft die Benutzerdaten mittels Datenbankabfragen sowie

Abfragen am LDAP-Server; ESI generiert zufallige PIN und PUK und schickt diese

zuruck an den Enrollment-Server.

3. Kartenpersonalisierung Teil 1: Nach einer erfolgreichen Benutzeranmeldung er-

scheint 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 Personalisierungs-

prozess. Folgende Schritte werden durchlaufen:

a) Zuerst werden die PUK und die PIN zusammen mit Fehlbedienungszahler auf

die Karte geschrieben. Der Startwert des Fehlbedienungszahlers soll konfigu-

rierbar sein.

b) Die Schlusselpaare fur die elektronische Signatur und Windows-Smartcard-

Logon werden in der Karte erzeugt.

c) Mit den neuen Schlusseln werden PKCS#10-Zertifikatsantrage erstellt und an

das ESI geschickt.

4. Zertifikatserstellung: Die beantragten Zertifikate, sowie ein Verschlusselungszer-

tifikat, 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 Verschlusselungszertifikat und das zugehorige

Schlusselpaar enthalt, 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 ausgefuhrt werden, sind identisch

zu den oben aufgelisteten.

27


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:






3. Karte entsperren: Nach einer erfolgreichen Benutzeranmeldung erscheint eine Sei-

te 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 Fehlbedienungszahler der PIN wird zuruckgesetzt

und die neue PIN wird auf die Karte geschrieben.

Loschen der Karteninhalte

Mit FlexCardAdmin soll durch die Ausfuhrung folgender Schritte moglich sein, eine Karte

zu loschen:






3. Karte loschen: 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 geloscht.

PIN andern

Eine neue Funktion, die zur Zeit nicht von der OCX-Komponente angeboten wird,

soll mit FlexCardAdmin moglich sein, namlich das Andern der PIN. Ein neuer TAN-

Verwendungszweck”PIN andern“ soll eingefuhrt werden. Nachdem der Benutzer die TAN

fur den Prozess”PIN andern“ erhalten hat, kann er die PIN seiner Smartcard andern.

Dazu sind folgende Arbeitsschritte notwendig:

1. Login: Der Benutzer meldet sich auf dem Enrollment-Server mit seinem Benutzer-

namen, Passwort und der TAN an.




3. PIN andern: Nach erfolgreicher Anmeldung wird eine Seite mit dem integrierten

28


Applet angezeigt. Mit dem Applet kann der Benutzer die PIN andern, indem er die

bisherige und die neue PIN eingibt.

3.2.2 Qualitatsanforderungen

Die Software soll folgende Eigenschaften haben:

• Flexibilitat

– moglichst viele verschiedene Kartentypen sollen unterstutzt werden

– moglichst viele verschiedene Kartenleser sollen unterstutzt werden; die Anwen-

dung soll mit gangigen Kartenlesern funktionieren, im Idealfall unabhangig

davon sein

– die Anwendung soll auf verschiedenen Plattformen laufen (mindestens Linux,

Windows 2000 und Windows XP)

• leichtes Deployment

– die Anwendung soll mit moglichst wenig Installationsaufwand (am besten mit

keinem) zur Verfugung stehen

– die Anwendung auf der Clientseite soll immer up-to-date sein

• Modularitat

– die Benutzeroberflache soll leicht austauschbar und anpassbar sein

• Benutzerfreundlichkeit

• Erweiterbarkeit: es soll moglichst einfach sein neue Komponenten in die Software

hinzuzufugen, 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 Identitat um sensible Daten handelt, muss sichergestellt

werden, dass diese Daten geschutzt vor unauthorisiertem Zugriff bleiben.

Sichere PIN-Eingabe

Die Daten auf der Karte werden durch die PIN vor unberechtigtem Zugriff geschutzt.

Es gibt Kartenleser mit integrierter Tastatur, die eine sichere PIN-Eingabe (Secure PIN

Entry - SPE) ermoglichen, d.h. die PIN wird uber die Kartenlesertastatur eingegeben.

Diese Art der PIN-Eingabe ist sicherer als die Eingabe uber eine graphische Benutzero-

berflache, da die sensiblen Daten weder auf dem PC gespeichert, noch uber die unsichere

PC/Kartenleser-Verbindung ubertragen werden. Sie befinden sich ausschließlich innerhalb

29


der Karten/Leser-Umgebung. Die PIN wird direkt zu der Karte geschickt und somit ist

diese von Viren und Trojanern geschutzt.

Wenn ein Kartenleser, der eine Tastatur besitzt, mit der Anwendung benutzt wird, sollte

es moglich sein, die PIN-Eingaben uber die Kartenlesertastatur zu machen, um somit

hochste Sicherheit zu bieten. Fur die sonstigen Kartenleser erfolgt die Eingabe uber die

graphische Benutzeroberflache.

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 Erstel-

lung der Arbeit getroffen wurden und warum.

4.1 Analyse des Frameworks SmartcardServices

Fur 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 Funktionalitat angeboten wird

und ob es irgendwelche Besonderheiten gibt, die berucksichtigt werden sollen.

4.1.1 Implementierungen

Das Framework SmartcardServices ist so konzipiert, dass es Interfaces zu den einzel-

nen Kartenoperationen definiert und fur jede Kartenschnittstelle oder Kartentyp, die

unterstutzt werden sollen, Implementierungen geliefert werden mussen. Einige Implemen-

tierungen existieren schon in der vorhandenen Frameworkversion.

Unterstutzte Kartenschnittstellen Das Framework unterstutzt in seiner jetzigen Ver-

sion folgende Kartenschnittstellen:

• PC/SC

• OCF

• PKCS#11

Unterstutzte Chipkarten Da die PKCS#11-Schnittstelle unabhangig von der verwen-

deten Chipkarte ist, konnen im Prinzip beliebige Kartentypen uber diese Kartenschnitt-

stelle angesprochen werden. Die anderen zwei Schnittstellen sind wiederum abhangig

vom Betriebssystem der Chipkarte und konnen nur dann benutzt werden, wenn eine

ApduChannelCard-Implementierung fur diesen Kartentyp bereitgestellt wird. Die jetzige

Version des Frameworks bietet eine solche Implementierung fur TCOS-2.0-Chipkarten.

31

KAPITEL 4. DESIGNENTSTEHUNG

4.1.2 Kartenoperationen

Es ist wichtig, dass das Framework alle Kartenoperationen unterstutzt, die benotigt wer-

den, um die gestellten Anforderungen zu erfullen. Deswegen ist eine der Aufgaben dieser

Arbeit gewesen, eine Analyse durchzufuhren und festzustellen, ob alle notwendigen Kar-

tenoperationen vom Framework angeboten werden.

Kartenpersonalisierung Chipkarten konnen personalisiert werden, indem personliche

Daten auf der Karte gespeichert werden. Voraussetzung fur die Personalisierung ist, dass

die Karte leer ist. Prinzipiell ist es moglich und sinnvoll eine Karte mehrmals zu persona-

lisieren. Das ware notwendig, wenn z.B. ein Mitarbeiter das Unternehmen verlasst. Seine

Karte kann von einem anderen Mitarbeiter benutzt werden, nachdem sie erneut persona-

lisiert wurde. Die PKCS#11-Implementierung, auf der das Framework SmartcardServices

aufbaut, unterstutzt 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 vollstandig loscht, wird die Karte als personalisiert

erkannt. Da die mehrfache Personalisierung eine Anforderung an den FlexCardAdmin

ist, bedeutet das, dass die Kartenpersonalisierung entweder uber PC/SC oder uber OCF

durchgefuhrt werden muss.

Die Kartenpersonalisierung umfasst mehrere Schritte:

• PIN und PUK der Karte setzen

• Schlusselpaare auf der Karte generieren

• Zertifikatsantrage erstellen

• Schlusselpaare und die zugehorigen Zertifikate auf die Karte schreiben

Das Setzen der PIN und PUK wird von allen Kartenschnittstellen unterstutzt. Die Gene-

rierung von Schlusselpaaren auf der Karte wird von TCOS-2.0-Karten nicht unterstutzt.

Das Framework bietet aber trotzdem die Moglichkeit, Schlusselpaare fur TCOS-2.0-

Karten zu generieren, indem diese in einer sicheren Umgebung erzeugt und anschließend

auf die Karte geschrieben werden. Bei der Schlusselgenerierung ist es außerdem wichtig,

anzugeben, wo genau auf der Karte die neuen Schlussel geschrieben werden sollen. Wenn

mehrere Schlusselpaare auf der Karte erzeugt werden sollen, mussen sie referenziert wer-

den konnen. Diese Funktionalitat fehlt in der PKCS#11-Schnittstelle. Man kann zwar

Schlusselpaare erzeugen, aber man kann nicht angeben, wo die Schlussel auf der Karte

zu speichern sind. Demzufolge werden generierte Schlussel auf der Karte uberschrieben,

wenn die Schlusselgenerierung mehrmals durchgefuhrt wird, da die Schlussel 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 Zertifikatsantragen sowie das Schreiben von Schlusselpaaren und Zerti-

fikaten auf der Karte ist mit allen Kartenschnittstellen moglich. Um ein Zertifikat auf die

Karte zu schreiben, muss das zugehorige Schlusselpaar auf der Karte vorhanden sein.

32


Loschen der Karteninhalte Bevor eine Karte erneut personalisiert werden kann, mussen

die vorhandenen Karteninhalte zuerst geloscht werden. Die PKCS#11-Implementierung

unterstutzt nicht das vollstandige Loschen der Karte, weil die PIN und PUK nicht

geloscht werden konnen. Die Konsequenz ist, dass man Karten uber die PC/SC oder

OCF-Schnittstelle loschen muss.

Andern und Entsperren der PIN Beide Operationen werden vom Framework un-

terstutzt und konnen mit jeder Kartenschnittstellenimplementierung durchgefuhrt wer-

den.

Abbildung 4.1 zeigt alle Kartenoperationen im Uberblick und die Schnittstellen, die

diese Operationen unterstutzen.

4.1.3 Referenzieren von Objekten auf der Karte

Die Daten auf der Karte mussen referenziert werden konnen. Wenn sich z.B. mehrere

Schlussel auf der Karte befinden, muss es moglich sein, zu erkennen, welcher Schlussel zur

Verschlusselung und welcher zum Signieren benutzt wird, damit der richtige Schlussel fur

die entsprechende Operation verwendet werden kann.

Das Framework bietet Methoden an, um alle Zertifikate, alle Schlussel (privat oder offent-

lich) 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 fur den Anwender. Die ID ist aber mit keiner

semantischen Bedeutung verknupft; sie gibt keine Information uber das Anwendungs-

gebiet des Objekts. Es besteht keine Moglichkeit zu erfahren, welches Objekt in einem

bestimmten Anwendungsfall benutzt werden soll. Wenn sich z.B. auf der Karte zwei Signa-

turschlussel befinden, ist es unmoglich den richtigen Schlussel zu erkennen. Man braucht

also eine zusatzliche Abstraktionsebene, die vom FlexCardAdmin angeboten werden soll

und die das Referenzieren von Objekten auf der Karte ermoglicht. Es muss eine Zuordnung

zwischen jedem Objekt auf der Karte und der Applikation, die dieses Objekt benutzt, her-

gestellt werden. Wird ein Objekt fur 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 moglich sein, dieses bestimmte Zertifikat eindeutig zu identifizieren. Es ist offen-

sichtlich, dass wenn man eine Verknupfung zwischen der Objekt-ID und der Applikation

herstellt, immer bekannt sein wird, welches Objekt fur diese Applikation benutzt werden

soll.

Die Objekt-ID wird von den verschiedenen Kartenschnittstellen unterschiedlich darge-

stellt. 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 zusammengehorige Objekte, wie

ein Schlusselpaar und das zugehorige Zertifikat, haben identische Kennung, konnen aber

33


Smartcardoperation KartenschnittstelleSmartcard personalisieren PC/SC, OCF- Mehfache Personalisierung PC/SC, OCF- PIN initialisieren PC/SC, OCF, PKCS#11- PUK initialisieren PC/SC, OCF, PKCS#11- Schlusselpaar schreiben PC/SC, OCF, PKCS#11- Zertifikat schreiben PC/SC, OCF, PKCS#11- Zertifikatsantrag erstellen PC/SC, OCF, PKCS#11- Schlusselpaar generieren PC/SC, OCF, PKCS#11Smartcard loschen PC/SC, OCF- PIN loschen PC/SC, OCF- PUK loschen PC/SC, OCF- Schlusselpaare loschen PC/SC, OCF, PKCS#11- Zertifikate loschen PC/SC, OCF, PKCS#11- Sonstige Daten loschen PC/SC, OCF, PKCS#11PIN andern PC/SC, OCF, PKCS#11PIN entsperren PC/SC, OCF, PKCS#11

Abbildung 4.1: Smartcardoperationen und die Kartenschnittstellenunterstutzung

anhand des Objekttyps (privater Schlussel, offentlicher Schlussel, Zertifikat etc.) eindeu-

tig 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 Kartenbe-

triebssystemebene gemacht. Objekte werden mit einem eindeutigen Pfad im Dateisystem

identifiziert, der gemaß dem Standard ISO 7816 gebildet wird und fur TCOS-2.0-Karten

beispielsweise wie folgt aussieht: :3f00:4101:4e03.

Da sich die Objekt-IDs in Abhangigkeit von der Kartenschnittstelle und dem Karten-

typ unterscheiden, muss FlexCardAdmin die Moglichkeit bieten, jeder Kombination aus

Applikation, Kartenschnittstelle, Kartentyp und Objekttyp eine spezifische Objekt-ID zu-

zuordnen, 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 uber verschiedene standardisierte Smartcard-

Schnittstellen realisiert werden. Damit die Flexibilitat vom FlexCardAdmin gewahrleistet

wird, sollte dieser in der Lage sein alle Kartenschnittstellen zu unterstutzen. Das Frame-

work SmartcardServices, das als Basis der Implementierung benutzt wird, hilft diese Auf-

gabe zu erfullen, da sie eine Abstraktionsebene darstellt und die Chipkartenfunktionen

unabhanging von der verwendeten Kartenschnittstelle zur Verfugung stellt. Die eigentliche

Implementierung, die benutzt wird, bleibt fur die Anwender transparent.

34


4.2.1 Anforderungen an die Umgebung

Obwohl das Framework eine gewisse Flexibilitat mit sich bringt, bietet es keine Funk-

tionalitat zur Vorbereitung der Umgebung (in diesem Fall der Clientrechner) an, damit

die Kartenschnittstellen benutzbar sind. Die Kartenschnittstellen mussen namlich zuerst

installiert und initialisiert werden, bevor sie einsatzbereit sind; sie stellen gewisse Anfor-

derungen an die Umgebung. D.h. jede Anwendung, die das Framework SmartcardServices

benutzt, muss selbst sicherstellen, dass alle Vorbereitungen zur Kartenschnittstellenini-

tialisierung getroffen wurden. Um das zu vermeiden, muss ein ubergreifendes Konzept

zur Kartenschnittstelleninitialisierung entwickelt und vom FlexCardAdmin realisiert wer-

den, so dass kein zusatzlicher Aufwand von Benutzerseite verursacht wird. Dafur muss

analysiert werden, wie jede Kartenschnittstelle initialisiert wird, um Gemeinsamkeiten zu

finden, die fur die Spezifizerung des Konzeptes wichtig sind.

Initialisierung der Framework-Schnittstelle zu PC/SC Um die Framework-

Schnittstelle zu PC/SC zu benutzen, ist folgendes notwendig:

• Java-Wrapper JPC/SC jpcsc.jar [7] im Java-Classpath und die dazugehorige

native Bibliothek fur das verwendete Betriebssystem (jpcsc.dll, jpcsc.so) in

java.library.path.

• FlexiCoreProvider-1-1-5p3.signed.jar (oder eine andere Version des FlexiPro-

viders) und codec.jar im Java-Classpath, um PKCS#10-Zertifikatsantrage zu er-

stellen

• eine native PC/SC-Bibliothek (Treiber) in java.library.path in Abhangigkeit

vom Betriebssystem fur jeden Kartenleser, der unterstutzt werden soll. Die mei-

sten Kartenleser unterstutzen PC/SC und keine zusatzliche Treiber mussen geladen

werden.

• Konfigurationsdateien und sonstige Daten, die vom Kartenleser benotigt 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 mussen geladen werden, z.B. tcos20.properties

fur TCOS-2.0-Chipkarten.

Initialisierung der Framework-Schnittstelle zu PKCS#11 Um die Framework-

Schnittstelle zu PKCS#11 zu benutzen ist folgendes notwendig:

• der Java-PKCS#11-Provider p11.jar [1] im Java-Classpath und die zugehori-

ge native Bibliothek fur das verwendete Betriebssystem (nativepkcs11.dll,

libnativepkcs11.so) in java.library.path



stellen

35


• eine native PKCS#11-Bibliothek (Treiber) in java.library.path in Abhangigkeit

vom Betriebssystem fur jeden Kartenleser, der unterstutzt werden soll. (z.B. die

Bibliothek fur Kobil-Kartenleser kpkcs11hash.dll oder libkpkcs11hash.so)


z.B. smartkey.inf und ct32br.dll beim Kobil Kaan Advanced Kartenleser.

• Die Chipkarte muss nicht spezifiziert werden, da PKCS#11 eine High-Level-

Kartenschnittstelle ist, die vom Betriebssystem der Smartcard abstrahiert. Dies be-

deutet, dass die PKCS#11-Implementierung prinzipiell mit allen Smartcards funk-

tionsfahig ist.



Initialisierung der Framework-Schnittstelle zu OCF Um die Frameworkschnittstelle

zu OCF (uber 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

zugehorige native Bibliothek fur das verwendete Betriebssystem (ocfpcsc1.dll) in

java.library.path



stellen

• eine native PC/SC-Bibliothek (Treiber) in java.library.path in Abhangigkheit

vom Betriebssystem fur jeden Kartenleser, der unterstutzt werden soll. Wie schon

erwahnt, unterstutzen die meisten Kartenleser PC/SC und keine zusatzliche Treiber

mussen geladen werden.


z.B. smartkey.inf und ct32br.dll beim Kobil Kaan Advanced Kartenleser

• Die ApduChannelCard-Implementierung, die verwendet werden soll, muss angege-

ben werden, z.B. de.tud.cdc.cardservices.tcos20.TCOS20Card fur 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 konnen die Daten, die benotigt werden, um

die Schnittstellen zu initialisieren, in folgende Kategorien aufgeteilt werden:

36


• Externe Bibliotheken

• Kartenschnittstellenspezifische Daten

– native Bibliotheken

– Konfigurationsdateien

– Kartenlesertreiber fur die konkrete Kartenschnittstelle

• Kartenleserspezifische Daten

– native Bibliotheken (Kartenlesertreiber)

– Konfigurationsdateien

• Chipkartenspezifische Daten

– Konfigurationsdateien (Java-Property-Format)

Die externen Bibliotheken werden als zusatzliche Archive in der Applikation eingebun-

den, d.h. ihr Deployment verursacht keinen zusatzlichen Implementierungsaufwand. Beim

Starten des Applets werden sie vom Server auf den Clientrechner heruntergeladen und ste-

hen dem Applet zur Verfugung. Die nativen Bibliotheken und die Konfigurationsdateien

der Kartenschnittstellen mussen 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 konnen auch nur zur Laufzeit geladen werden, nachdem die Applikation er-

mittelt 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 SmartcardService-

Implementierung zu verwenden ist. Zwei Moglichkeiten sind hier vorgesehen: der Benutzer

kann die Kartenschnittstelle auf der Benutzeroberflache auswahlen oder die Kartenschnitt-

stelle wird vom Administrator als Konfigurationsparameter in der Konfigurationsdatei des

Applets angegeben. Die zweite Losung ist besser aus der Sicht der Benutzer, weil die Be-

nutzer die verschiedenen Kartenschnittstellen nicht kennen mussen und die Auswahl der

richtigen Kartenschnittstelle ist schwierig oder unmoglich. Diese Losung hat aber auch

einen Nachteil. Wenn die Kartenschnittstelle einmal konfiguriert ist, wird diese fur jede

Operation verwendet, die die Benutzer ausfuhren mochten. Es gibt allerdings Karten-

schnittstellen, die nicht alle Operationen unterstutzen, die mit dem Applet ausgefuhrt

werden sollen; z.B. eine Chipkarte kann uber die PKCS#11-Schnittstelle nicht geloscht

werden. Wenn ein Benutzer versucht, seine Karte zu loschen und die Applikation fur

die PKCS#11-Kartenschnittstelle konfiguriert ist, wurde die Operation fehlschlagen. Das

bedeutet, dass die angegebene Kartenschnittstelle nur als Defaultschnittstelle betrachtet

werden muss. Sobald eine Operation ausgefuhrt werden soll, die von dieser Kartenschnitt-

stelle nicht unterstutzt wird, muss das Applet im Hintergrund die Kartenschnittstelle mit

37


einer anderen austauschen, mit der die Operation ausfuhrbar ist.

Sowohl die Angabe der Kartenschnittstelle als Konfigurationsparameter, als auch die

Angabe uber die Benutzeroberflache, soll mit dem Applet moglich sein, damit die Flexi-

bilitat erhalten bleibt. Die Angabe uber die Benutzeroberflache kann außerdem zu Test-

zwecken sehr praktisch sein. Wenn keine Kartenschnittstelle in der Konfigurationsdatei

des Applets angegeben wurde, soll auf der ersten Seite des Applets eine Liste mit den

unterstutzten Kartenschnittstellen erscheinen. Der Benutzer kann die gewunschte Kar-

tenschnittstelle auswahlen. Falls die Kartenschnittstelle vorkonfiguriert wurde, wird die

Auswahlmoglichkeit auf der Benutzeroberflache entfernt.

4.2.3 Auswahl des Kartenlesers

Die meisten Kartenschnittstellen konnen ohne Kenntnis des Kartenlesers, der verwendet

wird, initialisiert werden. Dies ist nur bei der PKCS#11-Kartenschnittstelle nicht der

Fall. Fur 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 fur alle Kartenleser benutzt werden kann. Man muss genau den

Treiber des Kartenlesers angeben, der gerade verwendet wird. Der verwendete Kartenle-

ser muss also bekannt sein, bevor die Kartenschnittstelle initialisiert ist. Die automatische

Erkennung des Kartenlesers ist aber zu diesem Zeitpunkt nicht moglich, weil ohne initia-

lisierte Kartenschnittstelle keine Vebindung zum Kartenleser aufgebaut werden kann und

somit keine Information uber den Kartenleser verfugbar ist. Die einzige Moglichkeit, die

ubrig bleibt, ist die Angabe des verwendeten Kartenlesers uber die Benutzeroberflache

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 gewahlt wurde, muss das Applet den entsprechenden Trei-

ber finden und diesen dem Java-PKCS#11-Provider ubergeben. Das bedeutet auch, dass

die (betriebssystemspezifischen) Treiber aller Kartenleser, die unterstutzt werden sollen,

der Applikation bekannt und in dem Lieferpaket enthalten sein mussen.

Auf den ersten Blick konnte man sagen, dass die Kartenleserangabe fur die anderen Kar-

tenschnittstellen nicht notwendig ist und die Auswahl des Kartenlesers (uber die Benut-

zeroberflache oder in der Konfigurationsdatei) nur fur die PKCS#11-Schnittstelle imple-

mentiert werden muss. Die restlichen Schnittstellen konnen ohne die Kartenleserangabe

bzw. ohne die Angabe eines konkreten Kartenlesertreibers initialisiert werden. Es kann

aber passieren, dass fur den Kartenleser, der gerade verwendet wird, doch ein Treiber fur

die Schnittstelle geladen werden muss, damit die Kommunikation mit dem Kartenleser

uber diese Schnittstelle moglich ist.Dieses Problem kann folgendermaßen gelost werden:

alle der Applikation bekannten Kartenlesertreiber werden bei der Initialisierung der Kar-

tenschnittstelle geladen, ohne den konkreten Treiber zu kennen, der tatsachlich benotigt

wird. Der Kartenleser erkennt spater den richtigen Treiber und verwendet ihn.

Bis jetzt spricht also alles dafur, die Kartenleserangabe nur fur die PKCS#11-Schnittstelle

38


zu ermoglichen. Allerdings gibt es Falle, in denen die Kartenschnittstelle mitten in der

Ausfuhrung des Applets ausgetauscht werden muss. Dies ist notwendig, wenn die gewahl-

te Kartenschnittstelle die auszufuhrende Smartcardoperation nicht unterstutzt. In diesem

Fall wird die Kartenschnittstelle im Hintergrund gegen die Defaultschnittstelle ausge-

tauscht. Wenn die Default-Kartenschnittstelle beispielsweise PKCS#11 ist und die Anga-

be des verwendeten Kartenlesers verlangt, stoßt man auf das Problem, dass das Applet den

richtigen Kartenlesertreiber nicht kennt, weil die urspunglich gewahlte Kartenschnittstelle

diesen nicht kennt. Somit kann die Default-Kartenschnittstelle nicht initialisiert werden.

Um dieses Problem zu umgehen ist die Entscheidung gefallen, die Moglichkeit zur Auswahl

des Kartenlesers (auf der Benutzeroberflache oder in der Konfigurationsdatei) fur jede

Kartenschnittstelle anzubieten und nicht nur speziell fur die PKCS#11-Schnittstelle.

Es bleibt nur noch zu klaren, wie der richtige Treiber erkannt wird, nachdem ein Karten-

leser ausgewahlt wurde. Es muss eine Zuordnung zwischen dem Kartenleser und seinem

Treiber geben. Diese kann in der Konfigurationsdatei des Applets abgebildet werden.

Fur 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 An-

gabe der verwendeten Chipkarte. Die ApduChannelCard-Implementierung, die verwen-

det 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-Level-

Kartenschnittstelle ist, die vom Betriebssystem der Smartcard abstrahiert und prinzi-

piell mit allen Smartcards funktionsfahig ist. Trotzdem muss die verwendete Chipkarte

bekannt sein, damit die kartenspezifischen Properties geladen werden konnen. Genau-

so wie bei den Kartenlesern ist die automatische Erkennung der Karte nicht moglich,

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

Moglichkeiten: Die Chipkarte wird entweder auf der Benutzeroberflache ausgewahlt oder

als Konfigurationsparameter in der Konfigurationsdatei angegeben. Falls kein Konfigura-

tionsparameter angegeben wurde, erscheint auf der ersten Seite des Applets eine Liste der

unterstutzten Smartcards und der Benutzer muss diejenige auswahlen, die zu seiner Karte

passt. Falls eine Smartcard in der Konfigurationsdatei angegeben wird, verschwindet die

Auswahlmoglichkeit aus der Benutzerobrflache.

39


4.2.5 Die Verknupfung Kartenschnittstelle - Kartenoperation

Es gibt Operationen, die nicht uber jede beliebige Kartenschnittstelle realisierbar sind.

Das Applet muss flexibel genug sein, um zu erkennen, ob eine Operation mit der gewahl-

ten Kartenschnittstelle ausfuhrbar ist und entsprechend reagieren. Die Operation muss

uber die Kartenschnittstelle realisiert werden, uber die dies moglich ist. D.h es muss ei-

ne Default-Kartenschnittstelle fur jede Operation definiert werden. Abbildung 4.1 zeigt

welche Operation von welcher Kartenschnittstelle unterstutzt wird.

4.3 Kommunikation mit dem Enrollment-Server

FlexCardAdmin soll mit der vorhandenen Losung von FlexSecure interagieren, insbeson-

dere mit dem Enrollment-Server. Um dies zu realisieren, mussen die moglichen Formen

der Appletintegration analysiert werden und die Schnittstellen, uber die die Interaktion

stattfinden soll, definiert werden.

Das erste Szenario ware, dass das Grundgerust der bestehenden FlexSecure-Losung

unverandert bleibt und lediglich der Teil, der die Kommunikation mit der Chipkarte

ubernimmt, durch das neue Applet ersetzt wird. D.h. Benutzer loggen sich weiterhin uber

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 uber die Enrollment-Seite

Der Benutzer mochte eine bestimmte Operation mit seiner Chipkarte ausfuhren.

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 auszufuhren. Der Enrollment-Server leitet die Daten weiter an

ESI.

• Schritt 2: Datenprufung (ESI)

ESI uberpruft 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 aus-

gefuhrt wird, werden Daten auf die Karte geschrieben, aktualisiert oder geloscht.

Daten, die das Applet eventuell benotigt, werden von der Enrollment-Webseite uber-

geben. Und umgekehrt alle Daten, die sich aus der Appletausfuhrung ergeben, wer-

den an die Enrollment-Seite weitergeleitet.

• Schritt 4: Datenubertragung (ESI)

Die Enrollment-Seite kummert sich darum, dass die richtigen Empfanger (z.B. die

CA) diese Daten bekommen.

40


Die Schnittstelle zwischen dem Applet und der Enrollment-Seite muss spezifiziert

werden. Es muss festgelegt werden, wie das Applet Daten von der Seite ubergeben

bekommt und umgekehrt wie das Applet Daten an die Seite schickt.

Jedes Mal, wenn eine Chipkartenoperation ausgefuhrt werden soll, muss sich der Benutzer

neu auf der Enrollment-Seite anmelden und das Applet wird neu gestartet. Beim Initia-

lisieren des Applets werden alle benotigten Bibliotheken neu geladen. Dies kann einige

Sekunden dauern. Nachdem das Applet gestartet ist und auf der Benutzeroberflache des

Applets die gewunschte Kombination aus Karte, Kartenleser und Kartenschnittstelle

gewahlt wurde (falls dies nicht schon vorkonfiguriert war), werden zusatzlich die Kar-

tenlesertreiber sowie alle Bibliotheken, die die Kartenschnittstellen benotigen, geladen.

D.h., die Wartezeiten zum Starten des Applets konnten steigen, wenn man mehrere

Operationen nacheinander ausfuhren mochte und das Applet mehrfach gestartet wird.

Um dieses Problem zu umgehen, konnte 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 wurden 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 uber das Applet

Der Benutzer meldet sich uber die Benutzeroberflache des Applets am Enrollment-

Server mit seinem Benutzernamen, Passwort und TAN an. Hier muss die Logik

zum Aufbau der Verbindung zum Enrollment-Server aus der Login-Seite im Applet

ubernommen werden.

• Schritt 3: Datenprufung (ESI)

ESI uberpruft 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 fuhrt die gewunschte

Operation aus.

• Schritt 5: Datenubertragung (ESI)

Das Applet wird nur einmal gestartet, auch wenn man mehrere Operationen nacheinan-

der ausfuhren mochte. Nach dem Initialisieren des Applets, wahrend dessen alle benotig-

ten Bibliotheken geladen werden, erscheint eine Benutzeroberflache zum Einloggen, uber

den der Benutzer sich am Enrollment-Server anmelden kann, bevor er eine Operation

ausfuhrt. Um eine neue Operation auszufuhren, muss man nur zu diese Login-Seite des

Applets zuruckspringen und sich mit einer anderen TAN einloggen. Das Laden der Bi-

bliotheken 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


Applets selbst, muss die Schnittstelle zwischen dem Applet und der Enrollment-Seite de-

finiert werden. Das Applet muss zusatzlich in der Seite integriert werden. Um das zweite

Szenario zu realisieren ist der Aufwand großer, weil man zusatzlich den kompletten In-

halt der Enrollment-Seite in das Applet ubertragen muss. Wenn es oft vorkommt, dass

mehrere Chipkartenoperationen direkt nacheinander ausgefuhrt werden und wenn es vor-

gesehen ist, dass ein Benutzer mehr als eine TAN gleichzeitig besitzen darf, ware die zweite

Losung die bessere, ansonsten ist die erste Losung akzeptabel. In dieser Arbeit wird das

erste Szenario umgesetzt.

42

Kapitel 5

Technisches Konzept undImplementierung

Der Fokus dieses Kapitels ist auf die technische Umsetzung der Anforderungen gerichtet.

Die Software-Komponenten und deren Zusammenspiel werden dargestellt. Der Leser soll

somit befahigt werden, das verwendete Designprinzip zu verstehen und einen leichten

Einstieg zu finden, wenn Anderungen am System vorgenommen werden sollen.

5.1 Aufbau der Software

FlexCardAdmin ist ein Java-Applet, das in den HTML-Seiten des Enrollment-Servers in-

tegriert wird. Jedes Mal wenn die Webseite aufgerufen wird, wird der Appletcode auf

dem Clientrechner heruntergeladen und von der Java-Virtual-Machine des Browsers aus-

gefuhrt. Der Browser muss dafur Java-fahig sein. Neben der Anwendungslogik stellt das

Applet eine Benutzeroberflache zur Verfugung. Der Aufbau und das Zusammenspiel dieser

Komponenten ist an das”Model-View-Controller“-Pattern (MVC) angelehnt. Das MVC-

Pattern ist das Standardpattern fur Anwendungen, die Benutzerinteraktion voraussetzen

und eine Schnittstelle zum Benutzer anbieten. MVC ermoglicht die klare Trennung der

Benutzeroberflache von der Programmlogik. Durch diese Modularisierung lassen sich die

einzelnen Komponenten leicht austauschen, die Anwendung gewinnt an Flexibilitat und

Wiederverwendbarkeit und kann leichter gewartet werden. MVC besteht aus den drei

Komponenten Model, View und Controller. Das Model enthalt die Anwendungslogik, die

View reprasentiert die Benutzeroberflache und der Controller definiert wie die Anwendung

auf Benutzereingaben reagieren soll (siehe Abbildung 5.1). In FlexCardAdmin uberneh-

men diese Komponenten folgende Aufgaben:

• Die View reprasentiert die Benutzeroberflache des Applets, die in Form eines Wi-

zards aufgebaut ist. Die wichtigsten Klassen der View sind Wizard, WizardPanel

und WizardPanelDescriptor.

• Das Model ist fur die Initialisierung der Kartenschnittstellen zustandig und baut die

Verbindung zum Kartenleser und Smartcard uber die gewahlte Kartenschnittstelle

auf. Es ermoglicht das Laden verschiedener Bibliotheken und Properties, die von

den Kartenschnittstellen, Kartenlesern und Smartcards benotigt werden. Außerdem

43

KAPITEL 5. TECHNISCHES KONZEPT UND IMPLEMENTIERUNG

lassen sich durch das Model die IDs der Kartenobjekte konstruieren, damit sie re-

ferenziert werden konnen. Die wichtigsten Klassen des Models sind Model, Loader,

CardPropLoader, CardReaderPropLoader und ObjectIdentifier.

• Die Hauptaufgabe des Controllers ist die Verarbeitung der Benutzereingaben

auf der Benutzeroberflache und die Ausfuhrung 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 fur jede primitive Smartcardoperation eine Action-Klasse zur Verfugung. In

Abhangigkeit davon, welche Smartcardoperation ausgefuhrt werden muss, instanzi-

iert der Controller eine der Action-Klassen, die fur die Ausfuhrung der Smartcard-

operation zustandig ist.

In den folgenden Abschnitten werden diese drei Komponenten naher beschrieben.

Abbildung 5.1: Model-View-Controller-Pattern

5.2 Die Benutzeroberflache

Die Klassen der Benutzeroberflache befinden sich im Paket

de.flexsecure.flexiTrust.flexcardadmin.view und seinen Unterpakete. Die

Benutzeroberfache 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 fur verschie-

dene JPanels, die eingebunden werden konnen und die den Wizard mit Inhalt fullen. Die

zwei Tasten”Weiter“ und

”Zuruck“ dienen zur Navigation und zum Blattern durch die

Panels. Jedes Panel soll seinen Vorganger und seinen Nachfolger spezifizieren. Unter be-

stimmten Bedingungen konnen sich der Nachfolger und der Vorganger eines bestimmten

Panels andern. Wenn das aktuelle Panel keinen Vorganger hat, wird die Taste”Zuruck“

deaktiviert, und wenn kein Nachfolger vorhanden ist, ist die”Weiter“-Taste inaktiv. Der

44


Wizard enthalt zusatzlich eine Dropdown-Liste zur Auswahl der gewunschten Sprache.

Der Wizard besitzt ein Model und einen Controller. WizardModel halt die Wizarddaten

und den Wizardzustand, z.B. kennt WizardModel das aktuell im Wizard angezeigte Pa-

nel. WizardController bearbeitet die Events, die vom Wizard kommen, wenn die Tasten

gedruckt werden.

5.2.2 WizardPanel

Die Panels, die in den Wizard hinzugefugt werden konnen, sind Unterklassen von

WizardPanel. WizardPanel definiert die einheitliche Struktur seiner Unterklassen. Je-

des Panel besitzt einen Titel, der im oberen Teil angezeigt wird. Im unteren Teil ist

Platz fur Fehlermeldungen vorgesehen. Am linken Rand befindet sich eine Leiste, die

die gerade ausgefuhrte 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 zusatzlich 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 Uberblick. Wenn das Applet gestar-

tet wird, wird zuerst das ConfigurationPanel im Wizard angezeigt. Dieses bietet die

Moglichkeit, die verwendete Kartenschnittstelle, den Kartenleser und die Smartcard aus-

zuwahlen. Da diese Angaben auch vom Administrator vorkonfiguriert werden konnen,

mussen sie nicht immer uber die Benutzeroberflache gemacht werden. Deshalb hat das

ConfigurationPanel unterschiedliche Versionen, je nachdem was konfiguriert wurde und

45


was uber die Benutzeroberflache angegeben werden muss. Einige dieser Versionen sieht

man in Abbildungen A.1 und A.2 im Anhang A.

Abbildung 5.3: Ubersicht der WizardPanels

Je nachdem welche Smartcardoperation ausgefuhrt werden soll, wird als nachstes das

Panel fur diese Operation angezeigt. Fur 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 hangt davon ab, ob die PIN-Eingabe uber den Kartenleser oder uber die

Benutzeroberflache 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 geloscht werden soll.

Das Loschen der Karte erfolgt nach einer PIN-Eingabe. Genauso wie beim

PersonaliseCardPanel variiert der Panelinhalt in Abhangigkeit von der Art der

PIN-Eingabe. Wenn die PIN-Eingabe uber den Kartenleser gemacht wird, erscheint

im Panel einen Text, der den Benutzer darauf hinweist, die PIN am Kartenleser

einzugeben. Wenn die PIN-Eingabe uber die Benutzeroberflache 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

andern mochte. Das Panel enthalt Felder zur Eingabe der bisherigen und der neu-

en PIN oder Text mit Instruktionen, wenn die PIN-Eingabe uber den Kartenleser

erfolgt. Abbildung A.6 im Anhang A zeigt das ChangePINPanel.

46


• 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 Benutzeroberflache). 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 referen-

zieren zu konnen. Wenn man durch die Panels im Wizard blattert und die”Weiter“-

oder”Zuruck“-Taste druckt, kann das aktuelle Panel seinen Nachfolger oder Vorganger

anhand des Identifikators referenzieren und im Wizard anzeigen lassen. Jedes konkrete

WizardPanelDescriptor spezifiziert außerdem das Verhalten kurz bevor, wahrend und

nachdem ein Panel im Wizard angezeigt wird. Somit konnen die Benutzereingaben

von der Benutzeroberflache an den Controller geschickt und dort im Hintergrund

die gewunschte Operation ausgefuhrt werden. Ein WizardPanelDescripor hat die

Aufgabe, die Benutzereingaben an den Controller weiterzuleiten. Abbildung 5.4 gibt

eine Ubersicht der vorhandenen Identifikatoren. Wie man sieht, ist die Hierarchie der

WizardPanelDescriptors parallel zur Hierarchie der WizardPanels.

Abbildung 5.4: Ubersicht 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


• 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 nachsten Panels, das beim

Klicken auf”Weiter“ angezeigt werden soll. Diese Methode wird jedes Mal beim

Drucken des”Weiter“-Buttons aufgerufen. Sie muss von jeder Unterklasse uber-

schrieben werden.

• getBackPanelDescriptor(): liefert die Kennung des vorherigen Panels, das beim

Klicken auf”Zuruck“ angezeigt werden soll. Diese Methode wird jedes Mal beim

Drucken der”Zuruck“-Taste aufgerufen. Sie muss von jeder Unterklasse uberschrie-

ben werden.

• aboutToHidePanel(): hier soll jede Unterklasse definieren, welche Aktionen aus-

gefuhrt werden sollen, bevor das Panel aus dem Wizard entfernt wird.

• displayingPanel(): hier soll jede Unterklasse definieren, welche Aktionen aus-

gefuhrt werden sollen, wahrend das Panel angezeigt wird.

• aboutToDisplayPanel(): hier soll jede Unterklasse definieren, welche Aktionen aus-

gefuhrt werden sollen, bevor das Panel angezeigt wird.

Abbildung 5.5: Die Klasse WizardPanelDescriptor mit ihren Methoden

48


5.3 Das Model

Die Model-Klassen befinden sich im Paket de.flexsecure.flexiTrust.flexcardadmin.

model und seine Unterpakete. Diese halten alle Informationen bezuglich der verwendeten

Kartenschnittstelle, Kartenleser und Smartcard und haben die Aufgabe, die Verbindung

zum Kartenleser und Smartcard uber die gewahlte Kartenschnittstelle aufzubauen. Das

Model kann erst dann initialisiert werden, wenn es klar ist, welche Kartenschnittstel-

le, Kartenleser und Smartcard verwendet werden. Da dies im ersten Panel des Applets

(ConfigurationPanel) vom Benutzer festgelegt wird, wird das Model erst dann initia-

lisiert, 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 benotigt, 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 ei-

nem Unterpaket vom de.flexsecure.flexiTrust.flexcardadmin.model unter-

gebracht. 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 Ubersicht aller Model-Klassen, die in den nachsten Abschnitten

beschrieben werden.

5.3.1 Verwaltung der Kartenschnittstellendaten

Fur jede Kartenschnittstelle, die unterstutzt werden soll, muss eine Klasse erzeugt werden,

die von Model erbt. Der Name jeder Unterklasse ist eine Konkatenation des Kartenschnitt-

stellennamens, 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 ubergeben. Anhand dieser Information wird die Verbindung zur

Smartcard aufgebaut.

49


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 benotigt 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 gewunschten Typ erzeugt. Pro

Kartenschnittstelle existiert eine Unterklasse von Loader. Der Name jeder Unterklasse

ist, ahnlich wie bei den Model-Unterklassen, eine Konkatenation des Kartenschnittstel-

lennamens, 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 imple-

mentiert werden und die in den gleichnamigen Model-Methoden aufgerufen werden, sind

(siehe auch Abbildung 5.7):

50


• loadLibraries(): ladt die von der konkreten Kartenschnittstelle benotigten nati-

ven Bibliotheken, in Abhangigkeit des verwendeten Betriebssystems.

• loadReaderDrivers(): ladt alle Kartenlesertreiber, die in der Konfigurationsdatei

fur die konkrete Kartenschnittstelle und fur das verwendete Betriebssystem aufge-

listet sind.

• loadProperties(): ladt smartcard-, kartenleser- sowie schnittstellenspezifische

Properties. Um die kartenleser- bzw. smartcardspezifische Properties zu laden, be-

nutzt der Loader zwei Hilfsklassen CardPropLoader und CardReaderPropLoader,

auf die weiter unten naher eingegangen wird.

Abbildung 5.7: Die Klasse Loader mit den wichtigsten Methoden

ReaderDriver

Diese Klasse wird vom Framework SmartcardServices zur Verfugung gestellt und

dient dazu, die Verbindung zum Kartenleser aufzubauen. Bei der Instanziierung

eines ReaderDrivers mussen die Properties der verwendeten Smartcard, Karten-

leser und Kartenschnittstelle dem Konstruktor ubergeben werden. Hier wird die

Methode loadProperties() vom Loader benutzt, die diese Properties zuruck-

gibt. Nachdem ein ReaderDriver instanziiert wurde, wird dieser mit der Methode

loadReaderDriver(ReaderDriver driver) der Klasse CardManager, die auch vom Fra-

mework SmartcardServices zur Verfugung 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


klasse von Model implementiert werden muss und einen ReaderDriver vom gewunschten

Typ zuruckgibt.

Die Methode createReaderDriver() sowie die Beziehung zwischen den Model- und

ReaderDriver-Klassen ist nach dem Design-Pattern Factory Method aufgebaut. Mit Hil-

fe 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 konnen. Diese IDs unterscheiden sich

in Abhangigkeit von der verwendeten Kartenschnittstelle und Smartcard. Mit dem

ObjectIdentifier lassen sich diese IDs konstruieren. Dieser verwendet dabei die An-

gaben in der Konfigurationsdatei vom FlexCardAdmin. Dort werden die IDs pro Ap-

plikation, Kartenschnittstelle und Kartentyp fur die drei Arten von Objekten definiert:

offentliche Schlussel, private Schlussel und Zertifikate. Die IDs werden in der Konfigura-

tionsdatei als Strings angegeben. ObjectIdentifier wandelt diese in Objekte vom Typ

CardObjectID um. Außerdem liefert ObjectIdentifier Referenzen auf die einzelnen Ob-

jekte auf der Karte (CardObjectRef).

Pro Kartenschnittstelle muss eine Unterklasse von ObjectIdentifier definiert werden.

Der Name jeder Unterklasse ist eine Konkatenation des Kartenschnittstellennamens, ge-

schrieben in Großbuchstaben ohne jegliche Sonderzeichen, und des Strings”ObjectIden-

tifier“. Bei der Instanziierung eines ObjectIdentifiers wird der Typ der verwendeten

Smartcard dem Konstruktor ubergeben. Somit ist klar fur welche Smartcard die IDs kon-

struiert werden mussen.

Ein ObjectIdentifier wird mit der Methode createObjectIdentifier() der Klas-

se Model erzeugt, die von jeder Unterklasse von Model implementiert werden

muss und einen ObjectIdentifier vom gewunschten Typ zuruckgibt. Die Me-

thode 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 ubernimmt. Fur jeden Kartentyp muss eine Unterklasse von

CardObjectIdentifier definiert werden. ObjectIdentifier bestimmt zur Laufzeit den

konkreten Typ des CardObjectIdentifiers, der instanziiert werden muss, in Abhangig-

keit vom Kartentyp, der dem ObjectIdentifier-Konstruktor ubergeben wird.

Abblidung 5.8 zeigt die wichtigsten Methoden von ObjectIdentifier.

52


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. Fur jeden Kartenleser muss eine Unterklasse von

CardReaderPropLoader definiert werden. Der Name jeder Unterklasse ist eine Konka-

tenation des Kartenlesernamens, geschrieben in Großbuchstaben ohne Sonderzeichen,

und des Strings”CardReaderPropLoader“. Fur die KOBIL-Kartenleser heißt die Klasse

KOBILCardReaderPropLoader. Diese stellt sicher, dass alle Voraussetzungen zur Einsatz-

bereitschaft der KOBIL-Kartenleser erfullt sind:

• Die Konfigurationsdatei smartkey.inf muss sich im Homeverzeichnis des Benutzers

befinden.

• Die Bibliothek ct32br.dll bzw. libct.so muss sich im Homeverzeichnis des Be-

nutzers 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 Lauf-

zeit den konkreten Typ des CardReaderPropLoaders, in Abhangigkeit vom Kartenleser-

typ, der dem Loader-Konstruktor ubergeben wird. Die Instanz wird mit der Loader-

Methode createCardReaderPropLoader() erzeugt.

5.3.3 Verwaltung der Smartcard-Daten

Um smartcardspezifische Properties sowie andere Daten zu laden, gibt es die Klasse

CardPropLoader. Fur jeden Kartentyp muss eine Unterklasse von CardPropLoader de-

finiert werden. Der Name jeder Unterklasse ist eine Konkatenation des Kartentyps, ge-

schrieben in Großbuchstaben ohne Sonderzeichen, und des Strings”CardPropLoader“.

Fur die TCOS-2.0-Smartcards heißt die Klasse TCOS20CardPropLoader.

53


CardPropLoaders werden vom Loader instanziiert. Der Loader bestimmt zur Lauf-

zeit den konkreten Typ des CardPropLoaders, in Abhangigkeit vom Kartentyp, der

dem Loader-Konstruktor ubergeben 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 reprasentiert. Die Controller-Klasse befindet sich im Paket

de.flexsecure.flexiTrust.flexcardadmin. Zu ihren wichtigsten Aufgaben gehoren:

• das Erzeugen der View und des Models

• das Auslesen der Konfigurationsdatei

• das Setzen des Arbeitsverzeichnisses vom FlexCardAdmin

• die Spezifikation der vom FlexCardAdmin unterstutzten Kartenleser, Smartcards,

Kartenschnittstellen und Sprachen

Die Hauptaufgabe des Controllers bleibt allerdings die Verarbeitung der Benutzerein-

gaben auf der Benutzeroberflache und die Ausfuhrung der Smartcardoperationen. Die

WizardPanelDescriptor-Klassen dienen als Vermittler, die die Benutzereingaben dem

Controller zur Verfugung stellen. Nachdem der Benutzer seine Eingaben auf der gra-

phischen Oberflache gemacht hat, leitet der konkrete WizardPanelDescriptor die Be-

nutzereingaben an den Controller weiter, der in Abhangigkeit davon, welche Operation

ausgefuhrt werden soll, die entsprechende Action-Unterklasse instanziiert, die sich um die

Ausfuhrung der Smartcardoperation kummert. Die Realisierung jeder primitiven Smart-

cardoperation ist in einer Action-Unterklasse ausgelagert. Alle Actions befinden sich im

Paket de.flexsecure.flexiTrust.flexcardadmin.action. Jede Action muss die Me-

thode perform() implementieren und dort die Schritte zur Ausfuhrung der Operation

spezifizieren. Abbildung 5.10 gibt eine Ubersicht der vorhandenen Action-Unterklassen.

In den folgenden Abschnitten wird beschrieben wie die einzelnen Action-Klassen einge-

setzt werden, um die Smartcardoperationen auszufuhren.

5.4.1 Personalisieren einer Smartcard

Die Kartenpersonalisierung besteht aus folgenden Schritten, die nacheinander durch-

gefuhrt werden:

1. PIN und PUK zusammen mit Fehlbedienungszahler auf die Karte schreiben

2. zwei Schlusselpaare auf der Karte erzeugen (fur Signatur und Windows-Logon)

3. zwei PKCS#10-Zertifikatsantrage erstellen

4. die zwei fertigen Zertifikate (fur Signatur und Windows-Logon) auf die Karte schrei-

ben

5. den Inhalt einer PKCS#12-Datei (Verschlusselungszertifikat und das zugehorige

Schlusselpaar) auf die Karte schreiben

54


Abbildung 5.9: Die Klassen von Model

55


Abbildung 5.10: Die Action-Klassen

56


CreatePasswordsAction ubernimmt die Aufgabe, die PIN und PUK auf die Karte zu

schreiben. Die PIN und PUK werden von der FlexiTrust-CA generiert und als Applet-

parameter dem Applet ubergeben. Beide sind 3DES-verschlusselt. Der Verschlusselungs-

schlussel ist im Applet einkompiliert und wird von FlexCardAdmin benutzt, um beide

Passworter zu entschlusseln. Die PIN wird dem Benutzer auf der Webseite mit dem App-

let angezeigt. Anschließend kann der Benutzer die PIN selbst eingeben. Die eingegebene

PIN wird mit der automatisch generierten PIN verglichen und es wird uberpruft, ob beide

ubereinstimmen. Wenn dies der Fall ist, werden die PIN und die PUK zuerst entschlusselt

und danach auf die Karte geschrieben.

GenerateKeyPairAction ist fur das Erzeugen von Schlusselpaaren auf der Karte

zustandig. Jedes Schlusselpaar wird fur eine konkrete Applikation generiert und muss

an der Stelle auf der Karte geschrieben werden, die fur diese Applikation vorgesehen ist.

Die Applikation, fur die das neue Schlusselpaar generiert wird, wird als Appletparameter

ubergeben. Dieser Parameter wird bei der Instanziierung von GenerateKeyPairAction

benutzt. Mit der angegebenen Applikation wird vor der Schlusselgenerierung die Kon-

figurationsdatei ausgelesen, in der spezifiziert ist, an welcher Stelle auf der Karte das

Schlusselpaar fur diese Applikation (und die verwendete Kartenschnittstelle) zu speichern

ist, sowie die Schlussellange. Anschließend wird das Schlusselpaar erzeugt und nach eine

PIN-Eingabe auf die Karte geschrieben.

CreateCertRequestAction erstellt einen PKCS#10-Zertifikatsantrag. Bei dieser Opera-

tion ist die Angabe der Applikation, fur die das Zertifikat erstellt werden soll, erforderlich.

Die Applikation wird als Appletparameter ubergeben. Mit ihrer Hilfe wird die Konfigura-

tionsdatei ausgelesen, um die Stelle auf der Karte zu finden, an der das Schlusselpaar fur

diese Applikation gespeichert ist. Mit der Kenntnis der Schlussel kann der Zertifikatsan-

trag 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 Zer-

tifikatsantrag 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 Zer-

tifikatsantrag halt und das HTML-Formular, in dem sich das Feld befindet, werden als

Appletparameter spezifiziert und vor der Ausfuhrung der Operation ausgelesen.

Die Zertifikatsantrage werden vom Browser an die FlexiTrust-CA geschickt, die die Zer-

tifikate erstellt. Die fertigen Zertifikate werden in Base64-kodierter Form an das Applet

als Parameter zuruckgegeben. WriteCertificateAction liest diese Parameter aus und

schreibt die Zertifikate auf die Karte.

FlexiTrust-CA erzeugt zusatzlich das Verschlusselungsschlusselpaar sowie das zugehori-

ge Zertifikat. Diese werden im PKCS#12-Format Base64-kodiert an das Applet als

Parameter ubergeben. Das PKCS#12-Passwort wird auch als Appletparameter 3DES-

verschlusselt ubergeben. WriteP12Action liest diese Parameter aus und schreibt die

Schlussel und das Zertifikat auf die Karte.

Die Aufteilung der Kartenpersonalisierung in mehreren Actions bietet mehr Flexibilitat.

Auf diese Weise konnen die einzelnen Operationen beliebig kombiniert und in beliebiger

Reihenfolge ausgefuhrt werden. Die Anzahl der Schlusselpaare, Zertifikatsantrage oder

57


Zertifikate, die erzeugt werden, ist nicht festgelegt und kann je nach Anwendungsfall uber

die Appletparameter spezifiziert werden.

5.4.2 Entsperren der Smartcard

Das Entperren der Smartcard wird von ResetPINAction realisiert. Diese Action benotigt

die PUK der Karte und die neue PIN. Da der Benutzer die PUK nicht kennt, wird diese

als Appletparameter in 3DES-verschlusselter Form ubergeben. Eine neue PIN wird von

der FlexiTrust-CA generiert, dem Benutzer auf der Seite mit dem Applet angezeigt und

auch als Appletparameter ubergeben. Es wird zuerst uberpruft, ob die Karte tatsachlich

gesperrt ist. Danach wird die vom Benutzer eingegebenen PIN mit der automatisch ge-

nerierten verglichen. Wenn beide ubereinstimmen, wird die PUK entschlusselt, die Karte

entsperrt und die neue PIN auf die Karte geschrieben.

5.4.3 Loschen der Karteninhalte

Die Karteninhalte werden mittels DeleteCardAction geloscht. Diese Action benotigt die

PIN der Karte, damit sie sich auf der Karte einloggen kann, und die PUK, um die Karte zu

loschen. Die zwei Passworter werden hier genauso wie beim Entsperren der Smartcard als

Appletparameter ubergeben. Nachdem die PIN-Eingabe vom Benutzer uberpruft wurde,

wird die PUK entschlusselt und die Karte geloscht.

5.4.4 PIN andern

Die PIN wird mittels ChangePINAction geandert. Die neue PIN wird von der FlexiTrust-

CA generiert, dem Benutzer auf der Seite mit dem Applet angezeigt und als Applet-

parameter ubergeben. Der Benutzer gibt die bisherige und die neue PIN ein. Die zwei

PIN-Eingaben werden uberpruft. Wenn die bisherige PIN korrekt ist und die neue PIN

mit der automatisch generierten ubereinstimmt, wird die PIN der Karte geandert.

5.5 Schnittstelle zum Enrollment-Server

FlexCardAdmin wird in den HTML-Seiten des Enrollment-Servers integriert. Beide be-

finden sich in standiger Kommunikation: bei der Ausfuhrung jeder Smartcardoperation

werden bestimmte Daten vom Enrollment-Server an das Applet ubergeben und umge-

kehrt. Das Applet bekommt Daten vom Enrollment-Server uber 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 fur diese Daten, unabhangig von

der Smartcardoperation, dieselben Appletparameter verwendet. Nur bei der Kartenper-

sonalisierung werden zusatzliche Parameter benotigt, die fur diese konkrete Operation

spezifisch sind.

58


5.5.1 Allgemeine Applet-Parameter

Folgende Parameter werden bei jeder Smartcardoperation vom Enrollment-Server an das

Applet ubergeben:

• TANFOR: dieser Parameter besagt, welche Smartcardoperation von FlexCardAd-

min ausgefuhrt werden soll. Der Parameter wird in Abhangigkeit davon gesetzt,

welche TAN der Benutzer auf der Enrollment-Seite eingegeben hat und fur welche

Operation diese generiert wurde. Die erlaubten Parameterwerte sind:

– NEWCARD: das Applet soll in diesem Fall eine Kartenpersonalisierung

durchfuhren

– DELETE: bezeichnet, dass das Applet die Smartcard loschen soll

– PINRESET: gibt an, dass die Smartcard entsperrt werden soll

– PINCHANGE: bezeichnet, dass die PIN geandert werden soll

– REPLACEMENT: eine Ersatzkarte soll vom Applet erstellt werden

– EMERGENCY: eine Notfallkarte soll erstellt werden

• TANFORCARDID: dieser Parameter halt die Nummer der Karte, fur die die TAN

generiert wurde und fur die die Smartcardoperation erlaubt ist.

• ENCCARDPIN: halt die automatisch generierte 3DES-verschlusselte Smartcard-

PIN. Der Verschlusselungschlussel ist im Applet einkompiliert und wird von Flex-

CardAdmin benutzt, um die PIN zu entschlusseln.

• ENCCARDPUK: halt die automatisch generierte 3DES-verschlusselte Smartcard-

PUK. Die PUK wird mit demselben Schlussel wie die PIN entschlusselt.

• ENCCARDPUKOLD: halt die PUK, die schon auf der Karte gespeichert ist, ver-

schlusselt 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 konnen.

Der Wert von ENCARDPIN reprasentiert die 3DES-verschlusselte Base64-kodierte PIN

123456, ENCARDPUK enthalt die 3DES-verschlusselte Base64-kodierte PUK 123456 und

ENCARDPUKOLD ist die 3DES-verschlusselte Base64-kodierte PUK 654321.

<APPLET ...><PARAM name=TANFOR value="’NEWCARD"><PARAM name=TANFORCARDID value="8949017200001762803"><PARAM name=ENCCARDPIN value="cPnR/ibd7yZHWsY5jmiGSg=="><PARAM name=ENCCARDPUK value="cPnR/ibd7yZHWsY5jmiGSg=="><PARAM name=ENCCARDPUKOLD value="cPnR/ibd7yZC3Q6yErPS7g==">

</APPLET>

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 Ausfuhrung

59


moglichst flexibel zu halten, wurden einzelne Kommandos fur jede einzelne Operation de-

finiert, so dass diese in beliebiger Reihenfolge und auch mehrfach nacheinander ausgefuhrt

werden konnen. Diese Kommandos werden dem Applet als Parameter mit dem Namen

CMDX ubergeben (wobei X die Kommandonummer ist, beginnend mit 0) und nachein-

ander 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 fur eine spezifische Applikation

verwendet werden. Damit das Applet weiß, an welcher Stelle auf der Karte die benotigten

Daten zu finden sind oder geschrieben werden sollen, muss es die Applikation kennen. Des-

wegen gibt es neben jedem Kommando einen zusatzlichen Applet-Patameter APPLX (X

steht fur die Nummer des Kommandos, bei dessen Ausfuhrung diese Applikationsangabe

benutzt wird), der die Applikation angibt. Folgende Kommandos werden unterstutzt, die

man als Wert des Parameters CMDX ubergeben 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 EN-

CARDPIN und ENCARDPUK dem Applet ubergeben werden, werden auf der Kar-

te geschrieben.

• GENKEY: mit diesem Kommando wird ein Schlusselpaar auf der Karte generiert.

Der APPLX-Parameter muss immer mitgegeben werden, damit es klar ist, fur wel-

che Applikation das neue Schlusselpaar angelegt wird. Die Schlussel werden an der

Stelle auf der Karte geschrieben, die fur diese Applikation vordefiniert wurde. Die-

ses Kommando kann mehrfach an das Applet ubergeben werden, wenn mehrere

Schlusselpaare 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 fur das Schlussel-

paar einer bestimmten Applikation erstellt. Damit das richtige Schlusselpaar aus

der Karte ausgelesen wird, wird die Applikation in dem Parameter APPLX spe-

zifiziert. Nachdem der PKCS#10-Antrag von FlexCardAdmin erstellt wurde, wird

dieser in Base64-kodierter Form an die HTML-Seite ubergeben, indem er als Wert

eines Input-Feldes in einem HTML-Formular gesetzt wird. Der Name des HTML-

Formulars und des Input-Feldes werden dem Applet in den Parametern FORMX

und ELEMENTX mitgeteilt. X steht hier wieder fur 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

Schlusselpaar und das zugehorige Zertifikat) auf die Karte. Der Base64-kodierte

Inhalt der PKCS#12-Datei wird uber den Parameter P12 dem Applet uberge-

ben. Das Passwort, mit dem die PKCS#12-Datei geschutzt ist, ist mit dem 3DES-

Algorithmus verschlusselt und wird im Parameter ENCP12PW gehalten. Fur dieses

60


Kommando wird auch zusatzlich der Parameter APPLX benotigt, der die Applika-

tion angibt, fur die die Schlussel 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 geschrie-

ben. 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, fur 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 wahrend der Kartenpersonalisie-

rung. Dort sieht man auch die einzelnen Applet-Kommandos und die Reihenfolge, in der

diese ausgefuhrt werden.

Nachdem die PKCS#10-Antrage vom Applet erzeugt werden und an den Enrollment-

Server geschickt werden, wird eine neue HTML-Seite geladen, in der die fertigen Zertifi-

kate dem Applet ubergeben 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 wahrend

der Ausfuhrung der Smartcardoperationen benutzt werden soll. Dieses Panel ist hier nicht

notig, da diese Angaben schon beim ersten Start des Applets gemacht wurden. Damit das

erste Panel des Applets ubersprungen werden kann, das Applet aber trotzdem die Infor-

mation 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 zwei-

ten Start des Applets werden diese drei Angaben als Parameter dem Applet ubergeben.

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 Smart-

cardtyp halt

• 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 halt

• 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


den Kartenlesernamen halt

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 er-

sten Teil der Kartenpersonalisierung durchfuhrt, und die zweite Abbildung - das Applet,

das die Kartenpersonalisierung zu Ende bringt.

5.5.3 Zertifikat auslesen

FlexCardAdmin unterstutzt ein zusatzliches Kommando READ CERT, mit dem ein Zer-

tifikat, das sich auf der Karte befindet, ausgelesen werden kann. Mit dem Patameter

APPLx sollte die Applikation spezifiziert werden, fur die das Zertifikat verwendet wird,

damit das Applet das Zertifikat auf der Karte erkennen kann. Das ausgelesene Zertifikat

wird einem HTML-Formular ubergeben. Mit den Parametern FORMx und ELEMENTx

kann der Formularname und der Input-Feldname spezifiziert werden:

<PARAM name=CMD0 value="READ_CERT"><PARAM name=APPL0 value="APPL1"><PARAM name=FORM0 value="ReadCertForm"><PARAM name=ELEMENT0 value="CERT-PEM0">

5.6 Konfiguration

Das Verhalten von FlexCardAdmin kann uber 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 verandert werden.

5.6.1 Allgemeine Parameter

Folgende allgemeine Parameter sind vorhanden:

• choose operation: Im Normalfall wird die Smartcardoperation, die vom Applet

ausgefuhrt werden soll, via einem Appletparameter festgelegt, der vom Enrollment-

Server gesetzt wird, in Abhangigkeit davon fur welche Operation die Benutzer-TAN

generiert wurde. Das Applet sieht zusatzlich eine zweite Moglichkeit vor, die Ope-

ration auszuwahlen, indem der Benutzer selbst die Operation auf der Benutzerober-

flache angibt. Dies erfordert allerdings einige Anderungen in der Benutzeroberflache

und der Logik des Applets, sowie in dem Ablauf der ausgefuhrten Operationen. In

62


Abbildung 5.11: Datenaustausch zwischen dem Enrollment-Server, FlexCardAdmin undder Smartcard

63


<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-FunktionsubmitForm()

64


<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 name=TANFOR value="${TANFOR}"><PARAM name=TANFORCARDID value="${CARDID}"><PARAM name=ENCCARDPIN value="${ENCCARDPIN}"><PARAM name=ENCCARDPUK value="${ENCCARDPUK}"><PARAM 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 name=CMD3 value="PKCS10"><PARAM name=APPL3 value="APPL1"><PARAM name=FORM3 value="CertRequestForm"><PARAM name=ELEMENT3 value="GenRequest0">

<PARAM name=CMD4 value="PKCS10"><PARAM name=APPL4 value="APPL2"><PARAM name=FORM4 value="CertRequestForm"><PARAM 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 Kartenper-sonalisierung (Teil 1)

65




MAYSCRIPT>

<PARAM name=TANFOR value="${TANFOR}"><PARAM name=TANFORCARDID value="${CARDID}"><PARAM name=ENCCARDPIN value="${ENCCARDPIN}"><PARAM name=ENCCARDPUK value="${ENCCARDPUK}"><PARAM name=ENCCARDPUKOLD value="${ENCCARDPUKOLD}">

<PARAM name=CMD0 value="WRITE_P12"><PARAM name=APPL0 value="APPL0"><PARAM name=P12 value="${P12}"><PARAM 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 Kartenper-sonalisierung (Teil 2)

66




MAYSCRIPT>

<PARAM name=TANFOR value="${TANFOR}"><PARAM name=TANFORCARDID value="${TANFORCARDID}"><PARAM name=ENCCARDPIN value="${ENCCARDPIN}"><PARAM name=ENCCARDPUK value="${ENCCARDPUK}"><PARAM name=ENCCARDPUKOLD value="${ENCCARDPUKOLD}">

</APPLET>

Abbildung 5.15: Integration von FlexCardAdmin in der ES-Seite beim Loschen oder Ent-sperren einer Smartcard

dieser Version des Applets wird nur ein Prototyp dieser Losung vorgestellt, der weite-

retwickelt werden muss, um einsatzbereit zu sein. Der Parameter choose operation

wurde definiert, um zwischen den zwei Moglichkeiten umzuschalten. Wenn der Pa-

rameter auf no gesetzt ist, wird die Smartcardoperation via einem Appletparameter

festgelegt, wenn der Parameterwert yes ist, wird die Operation vom Benutzer ge-

setzt.

• use default interface: mit diesem Parameter wird festgelegt, ob eine Default-

kartenschnittstelle benutzt werden soll in den Fallen, in welchen eine Smartcard-

operation nicht uber die aktuelle Katenschnittstelle ausfuhrbar 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 ausgefuhrt werden kann. Wenn der Parameter auf

false gesetzt ist, wird die verwendete Kartenschnittstelle nie ausgetauscht und die

Ausfuhrung der Operation, die von dieser Kartenschnittstelle nicht unterstutzt ist,

wird mit einer Fehlermeldung abgebrochen.

• card os: hier kann die Smartcard definiert werden, die mit FlexCardAdmin verwen-

det werden soll. Mogliche Werte in dieser Version von FlexCardAdmin sind TCSO20

fur TCOS-2.0-Smartcards oder der leere String. Die erlaubten Werte dieses Para-

meters (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 Benutzeroberflache spezifizieren muss. Er bekommt eine Liste

von Smartcards zur Auswahl angezeigt.

• card interface: hier kann die Kartenschnittstelle angegeben werden, die verwen-

67


det werden soll. Mogliche Werte in dieser Version von FlexCardAdmin sind PKCS11,

PCSC, OCF oder der leere String. Diese sind die Namen der einzelnen Kartenschnitt-

stellen ohne jegliche Sonderzeichen. Dies ist wichtig, weil die angegebenen Strings

zum Erzeugen von Klassennamen zur Laufzeit benutzt werden und Klassennamen

durfen 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 Benutzeroberflache spezifizieren muss. Er bekommt eine

Liste von Kartenschnittstellen zur Auswahl angezeigt.

• card reader: hier kann der Kartenleser angegeben werden, der mit FlexCardAdmin

verwendet wird. Mogliche 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

Benutzeroberflache 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 FlexCard-

Admin unterstutzen soll und die beim Aufbau der Verbindung zum Kartenleser geladen

werden mussen. Pro Kartenschnittstelle und Betriebssystem wird jeweils ein Parameter

definiert, dessen Wert den Namen der Kartenlesertreiberdatei fur diese Kombination spe-

zifiziert. Der Parametername ist eine Konkatenation des Kartenschnittstellennamen, des

Betriebssystems und der Nummer des Treibers. Bei jedem neuen Treiber, der in der Kon-

figurationsdatei hinzugefugt wird, wird die Treibernummer um eins inkrementiert. Die

Treiber sind zwecks besserer Ubersicht folgendermaßen gruppiert:

• <pkcs11 driver>: hier werden die Kartenlesertreiber fur die PKCS#11-

Schnittstelle spezifiziert. Folgende Parameter sind vorhanden:

– pkcs11 driver win 0: der Treiber mit der Nummer 0 fur die PKCS#11-

Schnittstelle unter Windows

– pkcs11 driver linux 0: der Treiber mit der Nummer 0 fur die PKCS#11-

Schnittstelle unter Linux

• <pcsc driver>: hier werden die Kartenlesertreiber fur die PC/SC-Schnittstelle spe-

zifiziert. Folgende Parameter sind vorhanden:

– pcsc driver win 0: der Treiber mit der Nummer 0 fur die PC/SC-Schnittstelle

unter Windows

– pcsc driver linux 0: der Treiber mit der Nummer 0 fur die PC/SC-

Schnittstelle unter Linux

• <ocf driver>: hier werden die Kartenlesertreiber fur die OCF-Schnittstelle spezifi-

ziert. Folgende Parameter sind vorhanden:

68


– ocf driver win 0: der Treiber mit der Nummer 0 fur die OCF-Schnittstelle

unter Windows

– ocf driver linux 0: der Treiber mit der Nummer 0 fur 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 Kar-

tenschnittstellennamen, des Betriebssystems und des Namen des Kartenleserherstel-

lers. Folgende Parameter sind vorhanden:

– pkcs11 driver win kobil: der PKCS#11-Treiber fur KOBIL-Kartenleser un-

ter Windows

– pkcs11 driver linux kobil: der PKCS#11-Treiber fur KOBIL-Kartenleser

unter Linux

5.6.3 Referenzen auf Kartenobjekten

Fur jedes Objekt, das von einer bestimmten Applikation genutzt wird, ist eine bestimmte

Stelle auf der Karte vorgesehen. In Abhangigkeit 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 fur jede Kombination

aus Kartenschnittstelle und Smartcardtyp vorgegeben. Die Parameter zum Referenzieren

der Kartenobjekte sind in Gruppen aufgeteilt. Jede Gruppe definiert die Objektreferenzen

fur eine bestimmte Applikation:

• <card object ids appl0>: hier werden die Referenzen auf Objekte, die von Appli-

kation 0 benutzt werden, spezifiziert.





Folgende Parameter sind fur Applikation 0 vorhanden (die Parameter fur die restlichen

Applikationen sind diesen analog):

• Objektreferenzen fur den Fall, dass die PKCS#11-Schnittstelle und TCOS-2.0-

Smartcards verwendet werden:

– appl0 pkcs11 tcos20 pubkey: die Referenz auf dem offentlichen Schlussel

– appl0 pkcs11 tcos20 privkey: die Referenz auf dem privaten Schlussel

– appl0 pkcs11 tcos20 cert: die Referenz auf dem Zertifikat

• Objektreferenzen fur den Fall, dass die PC/SC-Schnittstelle und TCOS-2.0-


– appl0 pcsc tcos20 pubkey: die Referenz auf dem offentlichen Schlussel

– appl0 pcsc tcos20 privkey: die Referenz auf dem privaten Schlussel

– appl0 pcsc tcos20 cert: die Referenz auf dem Zertifikat

69


• Objektreferenzen fur den Fall, dass die OCF-Schnittstelle und TCOS-2.0-


– appl0 ocf tcos20 pubkey: die Referenz auf dem offentlichen Schlussel

– appl0 ocf tcos20 privkey: die Referenz auf dem privaten Schlussel

– appl0 ocf tcos20 cert: die Referenz auf dem Zertifikat

Speziell fur die Referenzierung von Objekten auf TCOS-2.0-Karten sind zusatzliche

Informationen notig, um die CardObjectIDs erzeugen zu konnen. Diese Informationen

werden mit folgenden Parametern spezifiziert (hier wieder am Beispiel der Applikation 0

vorgestellt):

• appl0 pcsc tcos20 keynr: die Nummer des Schlussels auf der Karte (wenn PC/SC

die verwendete Kartenschnittstelle ist)

• appl0 ocf tcos20 keynr: die Nummer des Schlussels auf der Karte (wenn OCF die

verwendete Kartenschnittstelle ist)

• appl0 keyusage enc: spezifiziert, ob der Schlussel ein Verschlusselungsschlussel ist;

mogliche Werte sind true und false;

• appl0 keyusage sign: spezifiziert, ob der Schlussel ein Signaturschlussel ist; mogli-

che Werte sind true und false;

• appl0 keyusage auth: spezifiziert, ob der Schlussel ein Schlussel zur Authentifika-

tion ist; mogliche Werte sind true und false;

• appl0 keylength: die Schlussellange in Bit, z.B. 1024

Abbildung 5.16 zeigt ein Beispiel, wie die Parameter zur Objektreferenzierung gesetzt

werden konnen.

70


<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 key="appl0_pcsc_tcos20_pubkey" value=":3f00:4101:4e03"/><param key="appl0_pcsc_tcos20_privkey" value=":3f00:4101:5103"/><param key="appl0_pcsc_tcos20_cert" value=":3f00:4101:4352"/><param key="appl0_pcsc_tcos20_keynr" value="3"/>

<param key="appl0_ocf_tcos20_pubkey" value=":3f00:4101:4e03"/><param key="appl0_ocf_tcos20_privkey" value=":3f00:4101:5103"/><param key="appl0_ocf_tcos20_cert" value=":3f00:4101:4352"/><param 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 key="appl1_pcsc_tcos20_pubkey" value=":3f00:4101:4e04"/><param key="appl1_pcsc_tcos20_privkey" value=":3f00:4101:5104"/><param key="appl1_pcsc_tcos20_cert" value=":3f00:4101:4353"/><param key="appl1_pcsc_tcos20_keynr" value="4"/>

<param key="appl1_ocf_tcos20_pubkey" value=":3f00:4101:4e04"/><param key="appl1_ocf_tcos20_privkey" value=":3f00:4101:5104"/><param key="appl1_ocf_tcos20_cert" value=":3f00:4101:4353"/><param 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 Softwarelosung FlexiTrust zur Verwaltung der PKI in-

nerhalb eines Unternehmens. Als Erweiterung wurde FlexiTrust Identity Management

entwickelt, das samtliche Aufgaben, die mit der Personalisierung und Verwaltung von

Smartcards verbunden sind, ubernimmt. Eine der Komponenten von FlexiTrust Identi-

ty Management, die fur die Realisierung der Smartcardoperationen zustandig ist, weist

gewisse Nachteile auf. Sie ist nicht plattformunabhangig, nicht flexibel genug und nicht

erweiterbar. Dies hat dazu gefuhrt, dass Verbesserungen notwendig waren. Die vorliegende

Arbeit ist in Folge dessen entstanden mit dem Ziel, eine neue Losung (FlexCardAdmin) zu

entwickeln, die die Probleme und Einschrankungen der bestehenden Applikation auflost.

Am Anfang dieser Arbeit wurde zuerst die Funktionalitat der bestehenden Losung und die

Technologien, auf die sie basiert, vorgestellt. Auf die Nachteile wurde auch eingegangen,

damit nachvollziehbar wird, warum die Notwendigkeit besteht, nach eine neue Losung 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, moglichst hohe Flexibi-

litat zu bieten. Demzufolge musste ein Konzept entwickelt werden, wie man am besten

die Software gestaltet, so dass die Anwendung in beliebigen Umgebungen lauffahig ist:

unabhangig 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 not-

wendige Funktionalitat bietet.

Als Ergebnis dieser Arbeit ist ein Applet entstanden, das im Gegensatz zu seinem

Vorganger viele Vorteile bietet:

• FlexCardAdmin ist plattformunabhangig. Sein Vorganger dagegen konnte nur unter

Windows ausgefuhrt werden.

• Es bietet hohe Flexibilitat. Die OCX-Komponente von FlexiTrust Identity Manage-

ment unterstutzt nur zwei Kartentypen. FlexCardAdmin dagegen kann mit beliebi-

gen Smartcards eingesetzt werden. Außerdem funktioniert das Applet unabhangig

vom Kartenleser.

• Dadurch dass das Design der Software an das Model-View-Controller-Pattern an-

gelehnt 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 Kartenty-

pen, Kartenschnittstellen, Kartenleser oder Sprachen in die Software hinzuzufugen.

• Einzelne primitive Smartcardoperationen sind beliebig kombinierbar und konnen

in beliebiger Reihenfolge ausgefuhrt werden. Die Anzahl der Schlusselpaare, Zerti-

fikatsantrage oder Zertifikate, die erzeugt werden, ist nicht festgelegt und kann je

nach Anwendungsfall spezifiziert werden.

Wie jede andere Software ist auch FlexCardAdmin verbesserungsfahig und gibt Raum

zur Weiterentwicklung. Im nachsten 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 verbesserungsfahig ist.

7.1 Weiterentwicklung der Software

FlexCardAdmin ist in seiner jetzigen Version in einer beschrankten Umgebung lauffahig,

aber wurde so kozipiert, dass diese Umgebung leicht erweitert werden kann und neue Kom-

ponenten leicht in die Software hinzugefugt werden konnen. Somit erfullt FlexCardAd-

min die Anforderungen an Flexibilitat und Erweiterbarkeit. Folgende Elemente konnen

nachtraglich in die Software aufgenommen werden:

• neue Kartentypen

• neue Kartenleser

• neue Kartenschnittstellen

• neue Sprachen

• neue Betriebssysteme

Um solche zusatzliche Elemente in die Software einzubauen, mussen einige Stellen in der

Software erweitert werden. Die einzelnen Schritte der Integration neuer Komponenten

werden in den nachsten Abschnitten beschrieben.

7.1.1 Hinzufugen 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 fur die neue Smartcard muss definiert werden.

– Die Methode initializeSupportedEnvironment() muss erweitert werden.

– Der neue Kartentyp muss in der Liste der unterstutzten Smartcards (HashMap

supportedSmartcards) hinzugefugt werden.

74

KAPITEL 7. AUSBLICK

– Die Methode checkCombination(String card os, String

card interface) muss erweitert werden. Dort wird spezifiziert mit wel-

chen Kartenschnittstellen der neue Kartentyp kompatibel ist. Dies hangt 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 fur 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 spe-

zifiziert werden. Der Klassenname muss eine Konkatenation des Namen der

Controller-Konstante fur den Kartentyp und des Strings”CardObjectIdentifier“

sein.

• Falls irgendwelche Properties des Kartentyps in einer Konfigurationsdatei angegeben

werden mussen, muss diese Datei im Verzeichnis conf abgelegt werden.

7.1.2 Hinzufugen neuer Kartenschnittstellen

Um neue Kartenschnittstellen mit FlexCardAdmin verwenden zu konnen, 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 fur die neue Kartenschnittstelle muss definiert werden.


– Die neue Kartenschnittstelle muss in der Liste der unterstutzten Kartenschnitt-

stellen (HashMap supportedCardInterfaces) hinzugefugt 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 hangt

von den angebotenen Implementierungen im Framework SmartcardServices

ab.

• Das Model muss um die neue Kartenschnittstelle erweitert werden. Ein neues Un-

terpaket von de.flexsecure.flexiTrust.flexcardadmin.model mit dem Namen

der Kartenschnittstelle muss angelegt werden. Dort werden die schnittstellenspezi-

fischen 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 Klassen-

name ist eine Konkatenation des Schnittstellennamen und des Strings”Objec-

tIdentifier“.

• Externe und native Bibliotheken, die zur Initialisierung der Kartenschnittstelle

benotigt werden, mussen ins Verzeichnis lib kopiert werden. Die nativen Biblio-

theken mussen zusatzlich im Verzeichnis nativelib abgelegt werden.

• Falls irgendwelche Properties der Kartenschnittstelle in einer Konfigurationsdatei

angegeben werden mussen, muss diese Datei im Verzeichnis conf abgelegt werden.

7.1.3 Hinzufugen neuer Kartenleser

Um FlexCardAdmin mit neuen Kartenlesern verwenden zu konnen, mussen folgende

Anderungen vorgenommen werden:

• Der neue Kartenleser muss der Applikation bekannt gemacht werden. Dazu muss

der Controller folgendermaßen erweitert werden:

– Eine neue Konstante fur den neuen Kartenleser muss definiert werden.


– Der neue Kartenleser muss in der Liste der unterstutzten Kartenleser (HashMap

supportedCardReaders) hinzugefugt werden.

• Die Treiberdateien (pro Kartenschnittstelle und Betriebssystem) mussen in den Ver-

zeichnissen 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

fur den Kartenleser und des Strings”CardReaderPropLoader“ sein.

7.1.4 Hinzufugen neuer Sprachen

FlexCardAdmin wird in seiner jetzigen Version in zwei Sprachen ausgeliefert: Deutsch

und Englisch. Beliebige Sprachen konnen zum Sprachpaket der Software hinzugefugt

werden. Folgende Anderungen 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 fur die neue Sprache muss definiert werden.


76

KAPITEL 7. AUSBLICK

– Die neue Sprache muss in der Liste der unterstutzten Sprachen (HashMap

supportedLanguages) hinzugefugt werden.

• Die Methode setLanguage(String language) der Klasse Lang muss erweitert wer-

den.

• Die Ubersetzung der GUI-Texte in der neuen Sprache mussen in ei-

ner Properties-Datei zusammengefasst werden (analog der schon vor-

handenen Properties-Dateien fur die anderen Sprachen) und im Paket

de.flexsecure.flexiTrust.flexcardadmin.util.language abgelegt werden.

7.1.5 Hinzufugen neuer Betriebssysteme

Das verwendete Betriebssystem beeinflußt das Laden von nativen Bibliotheken. In

Abhangigkeit 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

unterstutzt werden muss, mussen die benotigten nativen Bibliotheken zur Verfugung ge-

stellt 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 ermoglicht.

• Die nativen Bibliotheken fur das neue Betriebssystem (pro Kartenschnittstelle)

mussen bereitgestellt werden und in den Verzeichnissen lib und nativelib kopiert

werden.

• Die Kartenlesertreiber fur das neue Betriebssystem (pro Kartenschnittstelle) mussen

ebenso bereitgestellt werden und in den Verzeichnissen lib und nativelib kopiert

werden.

• Die Kartenlesertreiber fur das neue Betriebssystem mussen in der Konfigurations-

datei aufgelistet werden.

• Die Unterklassen von Loader (OCFLoader, PCSCLoader und PKCS11Loader) mussen

folgendermaßen erweitert werden:

– eine neue Konstante fur die native Bibliothek des neuen Betriebssystems muss

in jeder der Unterklassen definiert werden.

– die Methoden loadLibraries() und loadReaderDrivers() mussen angepasst

werden.

• Die Methode loadData() der Klasse KOBILCardReaderPropLoader muss angepasst

werden.

77

KAPITEL 7. AUSBLICK

7.1.6 Das Applet als eigenstandige Webanwendung

Das Applet ist in seiner jetzigen Version ein Teil der Enrollment-Seite und bekommt alle

benotigten Daten wie Zertifikate, Schlussel, PUK der Karte als Appletparameter ube-

geben. Fur die Zukunft konnte man sich uberlegen, das Applet auch als eigenstandige

Webanwendung bereitzustellen. Das wurde bedeuten, dass die Kommunikation mit dem

Enrollment-Server, die momentan uber die Enrollment-Seite abgewickelt wird, von dieser

Seite entkoppelt und im Applet realisiert werden soll. Das Applet wird direkt eine Verbin-

dung mit dem Enrollment-Server aufbauen mussen, um relevante Daten auszutauschen.

Um diese Anderung zu realisieren, musste man nicht nur das Applet entsprechend an-

passen, sondern auch die Logik im FlexiTrust Identity Management. Dies erfordert einen

hoheren Aufwand, den sich FlexSecure zu diesem Zeitpunkt nicht leisten konnte. Deswe-

gen bleibt diese Anderung eine Aufgabe fur die Zukunft.

Dessen ungeachtet wurden schon einige Klassen erzeugt, die in der jetzigen Version des

Applets nicht verwendet werden und fur den spateren Einsatz im eigenstandigen Applet

gedacht sind. Die ersten zwei reprasentieren einen Teil der Benutzeroberflache und die

letzten zwei enthalten die Logik:

• ChooseOperationPanel: dient zur Auswahl der gewunschten Smartcardoperation

• LoginPanel: dient zum Einloggen auf dem Enrollment-Server

• LoginAction: hier soll der Aufbau der Verbindung zum Enrollment-Server imple-

mentiert werden

• SetOperationAction: hier wird dem Applet mitgeteilt, welche Operation vom Be-

nutzer ausgewahlt 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 moglich die Smartcard oder den Kartenleser des Benutzers au-

tomatisch zu erkennen. Diese mussen 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 ermoglichen, muss erforscht werden, ob die Konzepte so

angepasst werden konnen, dass die Initialisierung der Kartenschnittstellen ohne Kenntniss

der Karte oder des Kartenlesers moglich 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 (uber die Benutzeroberflache oder am Karten-

leser) nicht vorgesehen. Das Applet konnte so erweitert werden, dass das Vorhanden-

sein der Funktionalitat zur PUK-Eingabe konfigurierbar ist. Der Benutzer konnte uber

einen Konfigurationsparameter steuern, ob die PUK eingegeben werden muss oder nicht.

Dementsprechend musste die Benutzeroberflache aufgebaut werden und in Abhangigkeit

des Parameterwertes, Eingabefelder fur die PUK ein- oder ausblenden.

78

Anhang A

Benutzeroberflache

Abbildung A.1: Zwei der moglichen Varianten des ConfigurationPanels(1)

79

ANHANG A. BENUTZEROBERFLACHE

Abbildung A.2: Zwei der moglichen Varianten des ConfigurationPanels(2)

80


Abbildung A.3: Die zwei Varianten des PersonaliseCardPanels

81


Abbildung A.4: Die zwei Varianten vom DeleteCardPanel

82


Abbildung A.5: Die zwei Varianten vom ResetPINPanel

83


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: Einfuhrung in die Kryptographie. Springer, Berlin, 2003

[Cor00] Coroama, Vlad: Flexible Anbindung von SmartCards an eine Java-

Sicherheitsinfrastruktur. Entwurf und Implementierung eines Hardware-

Providers fur die Java Cryptography Architecture, TU Darmstadt, Diplomarbeit,

Marz 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: De-

sign 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.: Losungskonzept 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 fur 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

http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/definitionen/activexcontrols.htm

http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/definitionen/activexcontrols.htm

http://www.softwareacademy.de/webscripting/referenz/Default.aspx?opera=073.html

http://www.softwareacademy.de/webscripting/referenz/Default.aspx?opera=073.html

http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm

http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm

http://java.sun.com/docs/books/tutorial/deployment/applet/index.html

http://java.sun.com/docs/books/tutorial/deployment/applet/index.html

http://www.cdc.informatik.tu-darmstadt.de/reports/reports/Maryia_Drahavets.diplom.pdf

http://www.cdc.informatik.tu-darmstadt.de/reports/reports/Maryia_Drahavets.diplom.pdf

http://www.flexsecure.de/

http://www.flexsecure.de/ojava/flexitrust.html

http://www.flexsecure.de/ojava/flexitrust.html

http://www.musclecard.com/middle.html

http://www.musclecard.com/middle.html

http://www.musclecard.com/middle.html/

http://www.kobil.de/

http://java.sun.com/products/plugin/1.3/docs/jsobject.html

http://java.sun.com/products/plugin/1.3/docs/jsobject.html

Literaturverzeichnis

[Lud07] Ludwig-Maximilians-Universitat Munchen: 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 fur 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 Ope-

rating System: Betriebssystem fur 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 Stan-

dard. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf.

Version: Mai 2000

[RSA04] RSA Laboratories: PKCS#11 v2.20: Cryptographic Token Inter-

face Standard. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/

pkcs-11v2-20.pdf. Version: Juni 2004

[Sie] Siemens: CardOS: Betriebssystem fur 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

www.medien.ifi.lmu.de/fileadmin/mimuc/mt_ss05/mtB7a.pdf

http://www.linuxtnet.com

http://www.opencard.org

http://www.gemplus.com/techno/opencard/cardterminals/pcsc/download.html

http://www.gemplus.com/techno/opencard/cardterminals/pcsc/download.html

http://www.opencard.org/docs/pguide/PGuide.html#HDROCPROPERTYFILELOADER

http://www.opencard.org/docs/pguide/PGuide.html#HDROCPROPERTYFILELOADER

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

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




http://java.sun.com/developer/technicalArticles/GUI/swing/wizard/

http://java.sun.com/developer/technicalArticles/GUI/swing/wizard/

Documents

Implementierung eines Selbstbedienungsclients fur eine ... · Kryptographie, die Chipkartentechnologie und die Public-Key-Infrastrukturen (PKI). Die digitale Identit at besteht aus