Flexibles Datenbankmodell für TrustCenter - CDC

DIPLOMARBEIT
Flexibles Datenbankmodell
”
für TrustCenter“
von
Frank Homann
am
Fachgebiet für Theoretische Informatik
von Prof. Dr. rer. nat. Johannes Buchmann
Betreuer: Dipl. Inform. Marcus Lippert
Technische Universität Darmstadt (TUD)
– Fachbereich Informatik –
Vorwort
Zu Beginn dieser Arbeit möchte ich meiner Familie danken,
insbesondere meiner Mutter,
die mich im Laufe meines Studiums stets unterstützte.
Des weiteren danke ich meinem Betreuer und Ansprechpartner
für diese interessante Arbeit – Marcus Lippert.
Formaler Hinweis
Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig, ohne Hilfe Dritter und nur
mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den
Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in
gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Frank Homann, Oktober 2004
Kontaktadresse
Annastr. 48
64673 Zwingenberg
eMail: [email protected]
–2–
Inhaltsverzeichnis
Vorwort
2
Inhaltsverzeichnis
3
Einleitung
6
1 Einführung in Kryptographie und Computer-Sicherheit
1.1 Wozu Kryptographie? . . . . . . . . . . . . . . . . . . . .
1.1.1 Schutzziele . . . . . . . . . . . . . . . . . . . . . . .
1.2 Kryptographische Verfahren . . . . . . . . . . . . . . . . .
1.2.1 Symmetrische Verschlüsselung . . . . . . . . . . . .
1.2.2 Asymmetrische Verschlüsselung . . . . . . . . . . .
1.2.3 Verschlüsselung in der Praxis . . . . . . . . . . . .
1.2.4 Hybridverfahren . . . . . . . . . . . . . . . . . . . .
1.2.5 Hash und MAC . . . . . . . . . . . . . . . . . . . .
1.2.6 Signatur . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7 Kryptosysteme und Schutzziele . . . . . . . . . . .
1.3 Angriffsformen, Abwehrmaßnahmen und Anwendungen . .
1.3.1 Angriffsziele . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Grundlagen von Angriffen . . . . . . . . . . . . . .
1.3.3 Angriffe auf die Mathematik . . . . . . . . . . . . .
1.3.4 Angriffe auf Protokoll-Strukturen . . . . . . . . . .
1.3.5 Seitenkanal-Angriffe ( Side Channel Attacks“) . . .
”
1.3.6 Brechen von Schlüsseln oder Kryptoverfahren . . .
1.3.7 Anwendungen und Protokolle . . . . . . . . . . . .
1.4 Public Key-Infrastrukturen (PKI) . . . . . . . . . . . . . .
2 TrustCenter FlexiTrust
2.1 Ziele und Aufgaben von PKIs und TrustCentern . . .
2.2 Zertifikate und ihre Bedeutung . . . . . . . . . . . . .
2.2.1 Kommunikation mit Zertifikaten . . . . . . . .
2.2.2 Schutzziele und Zertifikate . . . . . . . . . . .
2.3 TrustCenter-Struktur auf Basis von FlexiTrust . . . .
2.3.1 Komponentenmodell auf Basis von FlexiTrust
2.4 Registration Authority . . . . . . . . . . . . . . . . .
2.5 Key Authority . . . . . . . . . . . . . . . . . . . . . .
2.6 Certificate Management Authority . . . . . . . . . .
2.7 Directory Service . . . . . . . . . . . . . . . . . . . .
2.7.1 Aufgabe von Verzeichnisdiensten . . . . . . .
2.7.2 DAP und X.500 . . . . . . . . . . . . . . . . .
2.7.3 LDAP und X.509 . . . . . . . . . . . . . . . .
2.7.4 LDAP Lösungen . . . . . . . . . . . . . . . .
2.7.5 Multiple Zertifikate . . . . . . . . . . . . . . .
2.7.6 Distinguished Names . . . . . . . . . . . . . .
2.8 Time Stamp Service . . . . . . . . . . . . . . . . . .
–3–
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
10
10
11
13
14
14
15
15
16
16
17
17
18
19
20
20
21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
25
25
25
26
27
28
29
29
30
30
31
33
35
35
36
INHALTSVERZEICHNIS
3 Einführung in Datenbanksysteme
3.1 Grundlagen Datenbanksysteme . . . . . . .
3.2 Datenbank Management-System (DBMS) . .
3.2.1 Datenunabhängigkeit . . . . . . . . .
3.3 Transaktionen . . . . . . . . . . . . . . . . .
3.3.1 Trigger und Coupling Modes . . . . .
3.3.2 Concurrency Control . . . . . . . . .
3.3.3 Recovery und Backup . . . . . . . . .
3.4 Datenmodelle . . . . . . . . . . . . . . . . .
3.4.1 Grundlagen von Datenmodellen . . .
3.4.2 Objekte und Konstruktoren . . . . .
3.4.3 Beziehungen . . . . . . . . . . . . . .
3.4.4 Relationale Datenbanken . . . . . . .
3.4.5 Schlüssel . . . . . . . . . . . . . . . .
3.5 Script Query Language (SQL) . . . . . . . .
3.5.1 Datenzugriff und Datenmanipulation
3.5.2 Strukturmanipulation . . . . . . . . .
3.6 Applikationsentwicklung . . . . . . . . . . .
3.7 Hardware- und Softwareauswahl . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Datenbankapplikationen für TrustCenter
4.1 Datenbanken und Datenhaltung in TrustCentern . . . . . . . . . . . . .
4.1.1 Registrierungsdaten und Zertifikate . . . . . . . . . . . . . . . .
4.1.2 Import und Export von Daten . . . . . . . . . . . . . . . . . . .
4.2 Praktische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 TrustCenter an einer Universität . . . . . . . . . . . . . . . . .
4.3 TrustCenter-Implementierung mit Java . . . . . . . . . . . . . . . . . .
4.3.1 Datenbankzugriffe unter Java mittels JDBC . . . . . . . . . . .
4.4 Konzept der FlexiTrust-OpenRA . . . . . . . . . . . . . . . . . . . . .
4.4.1 Datenbank-Abläufe rund um die OpenRA . . . . . . . . . . . .
4.4.2 Erweiterungsmöglichkeiten für das OpenRA-Konzept . . . . . .
4.5 Persistierung von Daten . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Datengattungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.2 Entwickeln von Datenbankapplikationen für TrustCenter . . . .
4.5.3 Einrichten von Datenbanken und logischen Strukturen . . . . .
4.5.4 Ziele der Persistierung allgemein und in einem TrustCenter . . .
4.6 Möglichkeiten zur Persistierung und Repräsentation . . . . . . . . . . .
4.6.1 Persistierungsmöglichkeiten im Überblick . . . . . . . . . . . . .
4.6.2 Repräsentationsschichten für einstufige und mehrstufige Objekte
4.7 Objekt-basierte Java-Lösungen . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 Manuelle Persistierung mit reinem JDBC . . . . . . . . . . . . .
4.7.2
Serialization“ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
”
4.7.3 JDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Datenbank-basierte Lösungen . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 Datenzugriffe über Cursor . . . . . . . . . . . . . . . . . . . . .
4.8.2 Steuer- bzw. Hilfstabellen . . . . . . . . . . . . . . . . . . . . .
4.8.3 Dynamische Strukturen bzw. Tabellendefinitionen . . . . . . . .
4.9 Bewertung der Persistierungslösungen . . . . . . . . . . . . . . . . . . .
–4–
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
39
39
40
40
40
41
41
42
43
43
45
46
49
50
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
54
55
55
57
57
59
61
62
68
69
69
70
70
71
73
74
75
82
84
87
89
95
95
97
99
104
INHALTSVERZEICHNIS
4.10 Weiterführende Überlegungen . . . . . . . . . . . . . . . . . . . . . .
4.10.1 Administration und Absicherung von Datenbanken . . . . . .
4.10.2 Vergabe von Distinguished Names . . . . . . . . . . . . . . . .
4.10.3 Multiple Zertifikate und multiple Distinguished Names . . . .
4.10.4 Multiple TrustCenter . . . . . . . . . . . . . . . . . . . . . . .
4.10.5 Unterstützen des Verzeichnisdienstes . . . . . . . . . . . . . .
4.10.6 Erstellen von Datenbank-Berichten bzw. Datenbank-Auszügen
4.10.7 Wahl des Datenbanksystems und Spezialisierungsbeispiel . . .
4.10.8 Bedeutung von Transaktionen . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
106
106
108
110
111
112
112
113
114
A Anhang
117
A.1 Beigefügte Software bzw. Dateien . . . . . . . . . . . . . . . . . . . . . . . 117
A.1.1 Beispiel-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.2 Technische Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Literaturverzeichnis
119
Abbildungsverzeichnis
122
Index
123
–5–
Einleitung
Diese Arbeit ist in den Kontext des bereits vorhandenen OpenRA- bzw. TrustCenter-Projektes
(FlexiTrust), entstanden in der Arbeitsgruppe von Prof. J. Buchmann1 , einzuordnen.
Allgemein formuliert handelt die vorliegende Arbeit zum Teil von der Persistierung von
Daten innerhalb eines TrustCenters, genauer von der Analyse sowie den Zielen und Aufgaben
des hinter einem TrustCenter liegenden Datenbankmodells. Daher spielen neben den Konzepten
der TrustCenter-Datenbank und der Datenbankapplikation an sich auch Sicherheitsaspekte eine
essentielle Rolle.
Die Daten, welche bei einem TrustCenter-Produkt, das für verschiedene Anwendungskontexte geeignet sein soll, verarbeitet werden müssen, können in der Praxis stark variieren. Die
Art der Persistierung dieser Daten, betrifft daher einerseits die Flexibilität und Effizienz in der
Anwendungsentwicklung für einen bestimmten individuellen Anforderungsbereich und andererseits die Effizienz im laufenden Betrieb des TrustCenters. Des weiteren müssen beispielsweise
Änderungen und Wartung möglich und auf flexible Weise durchführbar sein.
All diese Aspekte werden gleichermaßen bezogen auf TrustCenter im Allgemeinen sowie auf
FlexiTrust diskutiert. Im letztgenannten Falle werden an entsprechender Stelle ebenfalls einige
Erweiterungs- und Verbesserungsmöglichkeiten aufgezeigt, welche nicht nur eine Verfeinerung
sondern ebenso eine Weiterentwicklung von FlexiTrust im Sinne praktischer TrustCenter- und
PKI-Aspekte darstellen.
Zum Verständnis der vorliegenden Arbeit wird lediglich Grundwissen im Bereich der Informatik vorausgesetzt. Infolgedessen beginnt diese Arbeit mit Einführungen zu den Themen
Kryptographie und TrustCenter und enthält des weiteren eine Einführung in das Gebiet der
Datenbanksysteme. Anschließend folgt mit der Diskussion verschiedener Datenbankkonzepte
und Persistierungsmöglichkeiten in Kapitel 4 der eigentliche Kern der Arbeit.
Für weitere und ergänzende Details zu den im Folgenden beschriebenen Verfahren und
Systemen sei u.a. auf das Literaturverzeichnis (ab Seite 119) verwiesen.
1 Für weitere Details sei auf das Fachgebiet von Prof. J. Buchmann an der TU Darmstadt bzw. auf folgende Arbeiten verwiesen:
Vor allem [Dam01], [Sch01], [Kan04] sowie [Zoe02], [Zoe03].
–6–
1
Einführung in Kryptographie und Computer-Sicherheit
1.1
Wozu Kryptographie?
Unter dem Begriff Kryptographie findet man im Duden (1993) zwei Erläuterungen: Kryptographie zum einen als die aus der Psychologie stammende Bezeichnung für eine absichtslos
”
entstandene Kritzelzeichnung bei Erwachsenen“ und zum anderen als ein veraltetes Wort für
”
Geheimschrift“. In der Tat umfaßt der Begriff Kryptographie heutzutage wesentlich mehr als
lediglich den geheimen Austausch von Nachrichten. Jedoch hat er historische Wurzeln und ist
keineswegs eine Erfindung der jüngsten Phase der Neuzeit.
So wurde beispielsweise schon zu den Zeiten Cäsars ein Buchstaben-Tauschsystem verwendet, um streng geheime Botschaften (etwa über Kriegsstrategien) über große Strecken zu
transportieren. Diese Methode ist natürlich sehr einfach und dem heutigen Technologie- und
Bildungsstand weit unterlegen.
Abbildung 1: Einfache Verschlüsselung mit Buchstaben-Tauschsystem
Abbildung 1 zeigt ein Beispiel für ein mögliches Tauschsystem: Ein a“ in der zu übertra”
genden Nachricht (Klartext) wird in der verschlüsselten Nachricht (Verschlüsselungstext) zu
einem c“ usw. So wird also eine Mitteilung wie HALLO AXEL“ zu JCNNQ CZGN“.
”
”
”
Anwendungen von Verschlüsselungstechniken liegen jedoch nicht nur in militärischen Bereichen. Wenngleich der Austausch von Nachrichten bei Militärs, Staatsmännern, Geheimdiensten
etc. meist äußerst sicherheitskritisch ist2 . Aber in vielen Fällen besteht auch in der Industrie
oder bei Privatleuten die Notwendigkeit bzw. der Wunsch, daß Mitteilungen von einer Partei
A zu einer anderen Partei B nicht mitgelesen, belauscht oder ausspioniert werden können.
Die Kryptographie hat heute allerdings weit mehr Aufgaben als die Verschlüsselung an sich.
Denn viele andere Sicherheitsaspekte spielen mittlerweile eine wichtige Rolle. Man spricht hier
allgemein von Schutzzielen, auf welche im nächsten Abschnitt 1.1.1 eingegangen wird.
Es gibt dazu zahlreiche Anwendungsgebiete, wie z.B. die elektronische Kommunikation, der
elektronische Geldverkehr oder die elektronische Unterschrift als Ersatz für das analoge“ also
”
handschriftliche Signum. Dabei handelt es sich nicht ausschließlich um Anwendungen die mit
einem Personal Computer in Verbindung stehen. Längst haben eingebettete Systeme Einzug
in unser tägliches Leben gehalten. Das sind Computersysteme, die in ein technisches System
eingebettet sind, welches nach außen hin aber nicht wie ein Computer in Erscheinung tritt.
Beispiele hierfür sind das Handy oder die Wegfahrsperre, aber auch Kredit- oder EC-Karte
fallen in das Anwendungsgebiet der Kryptographie.
Selbstverständlich ist sie teilweise mehr, teilweise weniger auch Teil der allgemeinen Computer-Sicherheit. Darunter fallen zahlreiche Themenbereiche wie Schutz vor Computerviren und
Trojanern3 , sichere Netzwerkkonfigurationen, Digitale Wasserzeichen4 oder Sicherheitspoliti2 Als
historisches Beispiel sei hier die Nachrichtenübermittlung im Zweiten Weltkrieg erwähnt. Die Deutschen benutzen zur
Verschlüsselung von geheimen Nachrichten die kryptographische Maschine“ Enigma. Diese wurde von den Alliierten sozusagen
”
egalisiert (mit Hilfe der Kryptoanalyse) und der Nachrichtenverkehr konnte somit mitgelesen bzw. mitgehört werden. Ähnliches
gelang den USA mit japanischen Verschlüsselungsmethoden, was insgesamt sicher zur Verkürzung des Krieges beitrug.
3 Dabei finden verschiedenste Sicherheitsaspekte Bedeutung, wie z.B. vollständige Systemausfälle oder Ausspähen von
Paßwörtern mittels sogenannter Keylogger .
4 Digitale Wasserzeichen werden u.a. dazu eingesetzt das Urheberrecht verschiedener digitaler Medien zu wahren bzw. nachzuweisen, wie z.B. bei Musik, Bildern oder Videos.
–7–
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
ken etc., auf welche hier aber nicht weiter eingegangen werden soll.5
In der heutigen Zeit sind also die Kryptographie und ihre verwandten Gebiete nicht alleine in die wissenschaftlichen Bereiche der Informatik und Mathematik einzuordnen, sondern
beispielsweise auch in die Elektrotechnik oder Physik6 .
1.1.1
Schutzziele
Im vorherigen Abschnitt wurde geschildert, welche Anwendungsgebiete in den Bereich der
Kryptographie fallen. Für solche Anwendungen kann man allgemein folgende sieben Schutzziele
definieren:
• Authentizität: Durch Authentizität wird eine Identität bestätigt bzw. deren Echtheit
gewährleistet. Dazu muß natürlich der Nachweis einer bestimmten Identität, z.B. von
einer Person oder auch eines Rechners, erbracht werden. Dies wird etwa bei Rechnernetzen benötigt, um Unbefugten den Zugang vom Internet aus zu verwehren7 . Weitere
Anwendungen sind z.B. Home-Banking oder Bestimmen des Urhebers einer eMail.
Eine Nachricht läßt sich also als authentisch bezeichnen, wenn die Authentifikation erfolgreich war. Allgemeine Hilfsmittel für das Nachweisen einer Identität (authentisieren),
um Bestätigung dieser vom Kommunikationspartner zu erhalten (authentifizieren), sind:
– Biometrische Merkmale (z.B. Fingerabdruck),
– Spezielle Fähigkeiten (z.B. die eigenhändige Unterschrift oder der Tastaturanschlag),
– Wissen (z.B. Paßwort),
– Besitz (z.B. persönlicher Schlüssel, Codekarte),
– Kombinationen aus den vorherigen Punkten je nach Anwendungsfall.
• Integrität/Unveränderlichkeit: Oftmals ist es nicht nur wünschenswert, den Urheber einer Übermittlung bestimmen zu können, sondern man möchte auch sicher stellen, daß
die betreffende Übermittlung auf dem Übertragungsweg nicht verändert wurde. Denn es
kann gefährlich sein, wenn man dem eigentlichen Urheber vertraut, sich aber ein Angreifer unbemerkt in die Kommunikation mit diesem eingeschaltet hat. Dies gilt z.B. beim
Herunterladen von Computer-Software aus dem Internet, beim Lesen von eMails oder
dem Absenden einer Bestellung beim Online-Einkauf.
• Datiertheit/Datierung : Der Nachweis, daß eine bestimmte Aktion zu einem bestimmten
Zeitpunkt stattgefunden hat oder daß ein gewisser Zustand zu einem gewissen Zeitpunkt
vorgelegen hat, kann in einigen Fällen notwendig sein. Dieser Nachweis geschieht normalerweise durch eine dritte Instanz. Ein Beispiel hierfür ist das Eintreffen des Angebots
einer Firma zu einer öffentlichen Ausschreibung, was meist zu einer festgelegten Frist
geschehen muß. In Streitfällen muß die betreffende Firma nachweisen können, daß ihr
Angebot rechtzeitig eingereicht wurde oder auch daß es dabei und zu diesem Augenblick
vollständig war.
5 Etwas weiter weg von diesen Bereichen und dennoch mit einigen Überschneidungen zur Kryptographie ist die Steganographie
angesiedelt. Diese handelt von den Methoden zum Verbergen der Existenz einer Nachricht, also etwa dem Verstecken einer
Textnachricht in einem Bild. Bei digitalen Wasserzeichen macht man sich auch solche Methoden zunutze.
6 Das Standhalten bestimmter kryptographischer Verfahren kann z.B. mit der Entwicklung von speziellen Hochleistungscomputern (etwa Quantencomputer ) stark gefährdet werden. Gleiches kann durch die Entwicklung oder Entdeckung effizienter Algorithmen geschehen, die schwere mathematische Probleme lösen, welche die Grundlage mancher Kryptosysteme bilden.
7 In einem weiteren Schritt wird die Autorisierung vorgenommen. D.h., Rechte, wie etwa das Lesen einer Datei, werden vom
Computer-System aufgrund des Nachweises einer Identität, etwa durch Einloggen mittels Benutzernamen und Paßwort, vergeben.
–8–
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
• Privatheit/Anonymität: Im Zuge der Technisierung des Alltags ist eine damit verbundene mögliche Überwachung des Menschen beachtenswert. Z.B. ist das Bezahlen von
Rechnungen mittels EC- oder Kreditkarte nicht anonym, da immer eine Verbindung zu
einer bestimmten Karten- oder gar Kontonummer und vielleicht der zugehörigen dahinterstehenden Identität besteht. Dasselbe gilt für Bestellungen, welche über das Internet
getätigt werden. Theoretisch ist es also möglich, sich einen Überblick über das Kaufverhalten einer bestimmten Person zu verschaffen.
Durch dieses Beispiel8 sollte die fallweise Notwendigkeit zur Wahrung der Privatsphäre
mit kryptographischen Mitteln deutlich geworden sein. Ein konkretes Anwendungsbeispiel
ist (politische) Wahlen auf elektronischem Wege umzusetzen. Ein solches Vorhaben muß
bestimmte Vorgaben einer nicht-elektronischen Wahl wahren, wie etwa daß die Wahl
geheim stattfindet, also daß keine Zuordnung von abgegebener Stimme und Identität
möglich ist.
• Verbindlichkeit/Nicht-Abstreitbarkeit: Die Verbindlichkeit geht etwas weiter als die Authentizität. Bei der Verbindlichkeit geht es nicht nur darum sich selbst der Identität seines
Kommunikationspartners sicher zu sein, sondern dies auch Dritten gegenüber beweisen zu
können. Wenn man beispielsweise ein Auto bei einem Händler kauft und dort den Kaufvertrag unterschreibt, kann der Händler dies durch die handschriftlich erfolgte Unterschrift
z.B. vor einem Gericht beweisen. Es geht hier also um den digitalen Ersatz“ der eigenen
”
Unterschrift für elektronische Kommunikation. Im Falle des Kaufvertrages möchte man
eine auch rechtlich anerkannte elektronische Unterschrift, auch digitale Signatur genannt.
Dabei sind für deren Gültigkeit Regelungen des Gesetzgebers zu beachten, z.B. Signaturgesetz9 , wozu man meist eine weitere Vertrauensinstanz benötigt. Darauf wird aber in
Kapitel 2 über TrustCenter ab Seite 22 noch näher eingegangen.
• Verfügbarkeit: In der Vergangenheit zielten einige aufsehenerregende Angriffe auf prominente Internet-Server oder gar Rechnernetze auf deren Verfügbarkeit ab. Dies geschieht
folgendermaßen: Ein Server, welcher einen bestimmen Dienst zur Verfügung stellt, wird
mit unberechtigten Anfragen überflutet. D.h., er besitzt nicht genügend Kapazität diese Flut von Anfragen abzuweisen, womit der auf dem Server bereitgestellte Dienst zum
Erliegen kommt. Folglich können auch die berechtigten Nutzer nicht mehr erfolgreich
auf den Server bzw. dessen Dienst zugreifen. Im Zuge der wirtschaftlichen Nutzung des
Internets ist die Verfügbarkeit von Diensten, z.B. Online-Shops, ein wichtiges Schutzziel
geworden.
• Vertraulichkeit: Vertraulichkeit bezeichnet allgemein ausgedrückt den schon geschilderten
klassischen Hintergrund der Kryptographie, nämlich schlicht Daten geheimzuhalten. Dies
kann etwa bedeuten, Dritte oder Unbefugte vom Mitlesen der Kommunikation zweier
Parteien auszuschließen, z.B. bei eMails. Oder man möchte Firmen- bzw. Personendaten
oder persönliche Dateien, etwa ein Tagebuch, auf einem Computer nur für sich bzw.
entsprechend berechtigte Personen lesbar machen. Ebenfalls kann es wünschenswert sein,
daß – auch über Funkverbindungen ins Internet – abgesendete Online-Bestellungen oder
heruntergeladene Internet-Inhalte nicht von anderen eingesehen werden können.
8 Dies kann man vielleicht als unbedeutend ansehen. Jedoch sind hiervon auch andere Bereiche außerhalb von eCommerce und
elektronischem Geldverkehr betroffen. Etwa bei der Datensicherheit in medizinischen Bereichen spricht man von dem gläsernen
”
Menschen“ und bezieht sich hierbei auf die evt. Einführung von Krankenversicherungskarten für Versicherungsnehmer, welche nicht
nur Stammdaten (z.B. Adressen oder Versicherungsnummer) sondern auch medizinische Daten oder Akten enthalten könnten.
Auch elektronische Fahrausweise birgen eine Art potentieller Kontrollmöglichkeiten in sich, und zwar sobald mit einem solchen
Fahrausweis auch eine Verbindung zur Identität des Fahrgastes hergestellt werden kann. So wäre es möglich beispielsweise ein
Profil über Teile des Tagesablaufs von Personen zu erstellen. Auf dessen Nutzen soll hier jedoch nicht weiter eingegangen werden.
9 Hierbei existieren mittlerweile z.B. deutsche aber auch EU-Richtlinien.
–9–
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Zwischen den beschriebenen Schutzzielen bestehen verschiedene und unterschiedlich starke
Abhängigkeiten. So ist es beispielsweise nicht sinnvoll, die Authentizität einer Nachricht zu
gewährleisten ohne deren Integrität.
Um diese Schutzziele zu gewährleisten benötigt man natürlich weitere Mittel als die reine Verschlüsselung. Die grundlegenden Techniken dafür, die im nächsten Abschnitt genauer
erläutert werden, sind (siehe [Buc04], [Men96]):
• Verschlüsselung,
• Authentifikation,
• Digitale Signatur.
1.2
Kryptographische Verfahren
Die Grundlagen fast aller Methoden und Verfahren der Kryptographie (Kryptosysteme) beruhen
auf Verschlüsselungstechniken. Allgemein werden bei der Verschlüsselung Klartexte auf sogenannte Schlüsseltexte abgebildet und zwar in Abhängigkeit von dem verwendeten Schlüssel. Um
Texte auf andere Texte mathematisch abbilden zu können benötigt man – neben der Umwandlung der Texte in ein Zahlensystem – Verschlüsselungsfunktionen. Damit der verschlüsselte Text
wieder lesbar wird, benutzt man die entsprechende Umkehr- oder Entschlüsselungsfunktion.
1.2.1
Symmetrische Verschlüsselung
Ein Beispiel für dieses allgemein geschilderte Vorgehen findet sich in Abschnitt 1.1 in Form des
Buchstaben-Tauschsystems. Die Verschlüsselungsfunktion ordnet jedem Zeichen des Eingabetextes genau ein anderes Zeichen zu, was nach dieser mathematischen Vorschrift geschieht:
e(m) = (m + 2) mod 26.
Der Name der Funktion lautet e, die Eingabe m entspricht der Position eines Buchstabens
im Alphabet (mit Startposition 0) und das Ergebnis von e angewendet auf jedes Zeichen der
Eingabe ist c, der Schlüsseltext.
Dies ist nur ein triviales Beispiel und zwar für eine sogenannte symmetrische Verschlüsselung. Die Entschlüsselung erfolgt auf dieselbe bzw. analoge Art wie die Verschlüsselung:
d(c) = (c − 2) mod 26.
Wobei d hier die Entschlüsselungsfunktion ist und das Ergebnis von d angewendet auf jedes
Zeichen der Eingabe ist wiederum m. Das wichtigste für die Ver- und Entschlüsselung allerdings ist der Schlüssel, der in diesem Beispiel bisher außer Acht gelassen wurde. Es handelt
sich um die 2“, sie stellt den eigentlichen Schlüssel dieses Verfahrens dar. Er muß beiden
”
Kommunikationspartnern genauso bekannt sein wie die verwendeten Funktionen.
Man kann in diesem konkreten Falle die Funktionen e und d jedoch auch als identisch
betrachten. Daraus resultiert eine einzige Funktion für Ver- und Entschlüsselung:
f (m, k) = (m + k) mod 26.
Nun ist der Schlüssel k allerdings nicht mehr für beide Seiten gleich, d.h. bei der Verschlüsselung
ist k = 2, hingegen ist bei der Entschlüsselung k = −2. Dennoch bezeichnet man dies als
symmetrisches Verfahren, weil die Schlüssel quasi gleich, nämlich voneinander leicht oder direkt
ableitbar sind. Diese Ableitung wird meist innerhalb der Entschlüsselungsfunktion vollzogen
– 10 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
bzw. in dieser integriert. Bei symmetrischen Verfahren spricht man daher von dem geheimen
Schlüssel.
Abbildung 2 faßt den eben erläuterten Weg z.B. einer verschlüsselten Nachricht von A nach
B noch einmal zusammen.
Abbildung 2: Symmetrische Verschlüsselung
Beispiele für aktuelle symmetrische Verfahren sind: AES, RC4, IDEA, DES, 3-DES. Teil
eines solchen kann heutzutage z.B. die Matrizenmultiplikation sein, wobei Matrix und Inverse
dann die bzw. den Schlüssel bilden (siehe [Buc04], [Men96]).
1.2.2
Asymmetrische Verschlüsselung
Aus vielerlei Gründen, die im nächsten Abschnitt 1.2.3 genauer erläutert werden, bringen
symmetrische Verfahren in der Praxis gewisse Probleme mit sich aber auch Vorteile. Ein wesentlicher Nachteil ist es jedoch oftmals, daß auf beiden Seiten der Kommunikation der selbe
Schlüssel vorhanden sein muß.
Bei asymmetrischer Verschlüsselung hingegen hat jeder Kommunikationspartner ein Schlüsselpaar, welches jeweils aus einem sogenannte privaten und einem öffentlichen Schlüssel besteht. Der Unterschied zu dem geheimen Schlüssel bei der symmetrischen Variante ist die
Unabhängigkeit der Schlüssel voneinander. Diese sind zwar ein Paar, denn Ver- und Entschlüsselung muß weiterhin funktionieren, allerdings läßt sich aus dem öffentlichen nicht der
– 11 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
private Schlüssel berechnen. Die mathematischen Grundlagen bzw. die Algorithmen der asymmetrischen Verfahren beruhen im Allgemeinen auf schwer lösbaren mathematischen Problemen, z.B. der Primfaktorzerlegung großer Zahlen oder diskreten Logarithmen. Es war bisher
noch nicht beweisbar, daß ein solches Verfahren sicher ist. Allenfalls läßt sich zeigen, daß ein
bestimmtes Verfahren genauso schwer zu brechen, wie das zugrundeliegende Problem lösbar
ist.
Im Grunde funktioniert die asymmetrische Verschlüsselung ähnlich der symmetrischen. Der
Unterschied liegt in der Verwendung der Schlüssel. Möchte man jemandem z.B. eine vertrauliche Nachricht zukommen lassen, so verschlüsselt man diese mit dem öffentlichen Schlüssel des
Kommunikationspartners. Dies kann jeder tun, da der Schlüssel wie schon erwähnt öffentlich
ist. Aber nur mit dem passenden privaten Schlüssel läßt sich die Nachricht wieder entschlüsseln.
Dies kann folglich nur der alleinige Besitzer des privaten Schlüssels. Mit dem öffentlichen
Schlüssel alleine kann also niemand etwas anfangen.
Auch hier faßt die Abbildung 3 den eben erläuterten Weg z.B. einer verschlüsselten Nachricht von A nach B noch einmal zusammen.
Abbildung 3: Asymmetrische Verschlüsselung
Beispiele für aktuelle asymmetrische Verfahren sind RSA oder ElGamal. Ein Schlüsselaustauschverfahren ist Diffie-Hellman, welches eng mit ElGamal zusammenhängt. Grundlage dieser sind, wie schon beschrieben, ineffizient10 lösbare mathematische Probleme (Details siehe
10 Eine
genauere Betrachtung bzw. Einordnung eines Problems in eine solche Kategorie, wie etwa polynomielle oder exponentielle
– 12 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
[Buc04], [Men96]).
Ein weiteres im Moment sehr aktuelles Verfahren ist das Elliptic Curve Cryptosystem (ECC).
Dessen Vorteil ist, daß es auf einem schwereren mathematischem Problem basiert. Dadurch
sind kleinere Schlüssel notwendig als z.B. in RSA, wird die Ausführung von Operationen effizienter und ist das ECC für Hardware-Implementierungen besonders attraktiv.
1.2.3
Verschlüsselung in der Praxis
In den vorherigen Abschnitten 1.2.1 und 1.2.2 wurden zwei grundlegende Verschlüsselungsmethoden vorgestellt, die hier nun ein wenig verglichen werden sollen.
Ein wesentlicher Unterschied ist die Art der verwendeten Schlüssel. Ein symmetrischer
Schlüssel muß immer beiden Kommunikationspartnern bekannt sein. D.h., bevor man z.B. die
erste verschlüsselte Nachricht austauschen kann, muß man sich auf einen gemeinsamen geheimen Schlüssel einigen bzw. diesen auf irgendeine Weise austauschen. Da man verschlüsselt,
wenn man mittels eines unsicheren Übertragungsweges kommunizieren möchte, macht das
Verschicken des geheimen Schlüssels über einen solchen Kanal wenig Sinn.
Des weiteren muß man mit jedem Partner einen Schlüssel austauschen, was zum sogenannten Schlüsselaustauschproblem führt: Bei n Nutzern, von denen jeder mit jedem anderen
vertraulich kommunizieren will, benötigt man insgesamt
n ∗ (n − 1)
2
Schlüssel, welche natürlich auch gegenseitig ausgetauscht werden müssen11 . Außerdem muß
jeder dieser Schlüssel sorgfältig aufgehoben werden, da es sich ja um geheime Schlüssel handelt.
Bei der asymmetrischen Variante bestehen diese Probleme nicht, dafür andere. Im Folgenden sind die Vor- und Nachteile symmetrischer und asymmetrischer Verschlüsselungstechniken
zusammengefaßt.
Vorteile asymmetrischer gegenüber symmetrischen Verfahren
• Kein Austausch geheimzuhaltender Schlüssel notwendig,
• öffentliche Schlüssel nur bedingt sicherheitskritisch,
• nur ein Schlüsselpaar pro Person.
Probleme bzw. Nachteile asymmetrischer Verfahren
• Langsame Berechnungen (im Verhältnis zu symmetrischen Verfahren ca. 1:70),
• Nachweisen der Identität zu einem öffentlichen Schlüssel,
• große Schlüssellängen (typisch sind z.B. AES mit 128Bit ggü. RSA mit 1024Bit),
• keine Gruppenschlüssel (geheime symmetrische Schlüssel können einfach an mehrere Personen verteilt werden).
Vorteile symmetrischer gegenüber asymmetrischen Verfahren
• Schnelle Berechnungen/sehr effizient.
Laufzeit, sei z.B. der theoretischen Informatik vorbehalten.
11 Auch dafür gibt es Lösungen, z.B. ein Key Distribution-Server als zentrale Stelle für die Schlüsselverteilung.
– 13 –
1
1.2.4
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Hybridverfahren
Nicht zuletzt aufgrund der bekannten Vor- und Nachteile jeder Verfahrensweise kommen in
der Praxis oftmals keine reinen symmetrischen oder asymmetrischen Verfahren zum Einsatz,
sondern Hybridverfahren. Auf diese Weise will man die Vorteile beider Möglichkeiten kombinieren.
Bei der hybriden Verschlüsselung wird zunächst wie in Abbildung 2 gezeigt vorgegangen:
Eine Nachricht wird symmetrisch verschlüsselt. Der benutzte Schlüssel ist allerdings meist ein
Einmal-Schlüssel, ein sogenannter Sitzungsschlüssel oder Session-Key. Dieser wird anschließend
wie in Abbildung 3 gezeigt asymmetrisch verschlüsselt, z.B. mit einem öffentlichen Schlüssel
oder auch mit mehreren.
Der asymmetrisch verschlüsselte Sitzungsschlüssel wird zusammen mit der verschlüsselten
Nachricht übertragen. Geht die Nachricht an mehrere Empfänger, wird mit jedem öffentlichen
Empfänger-Schlüssel der Sitzungsschlüssel verschlüsselt und alle werden an die Übertragung
angehängt.
Die Entschlüsselung funktioniert dann natürlich auf dem genau umgekehrten Wege, beginnend mit dem Entschlüsseln des Sitzungsschlüssel mittels des eigenen privaten Schlüssels usw.
entsprechend der Abbildungen 3 und 2.
1.2.5
Hash und MAC
Oftmals ist es nötig Nachrichten verkleinern zu können und zwar auf effiziente und sichere Art
und Weise. Dazu benutzt man kryptographische Hash-Funktionen. Dies sind mathematische
Abbildungen die Bitfolgen oder Bitstrings beliebiger Länge auf eine feste Länge n abbilden12 .
Dadurch entstehen natürlich Kollisionen, d.h. es existieren Paare (x, x0 ) mit x 6= x0 und
h(x) = h(x0 ). Eine Hash-Funktion h ist allerdings wie folgt definiert:
h : {0, 1}∗ → {0, 1}n , x 7→ h(x) und
(1) h ist eine Einwegfunktion, d.h. schwach kollisionsresistent:
Zu einem gegebenem Wert h0 ist es praktisch unmöglich bzw. nicht effizient möglich, ein
x zu finden, so daß h0 = h(x).
(2) h ist (stark) kollisionsresistent:
Es ist praktisch unmöglich bzw. nicht effizient möglich, irgendein Paar (x, x0 ) zu finden
mit h(x) = h(x0 ).
Beispiele für solche Hash-Verfahren, die eben diesen Anforderungen genügen, sind: DES-CBC,
SHA-1 (Secure Hash Algorithmus) und RIPEMD-160. Bei den beiden letztgenannten handelt
es sich z.B. um 160-Bit Hashes.
Hash-Funktionen werden vor allem bei Signaturen (siehe Abschnitt 1.2.6) eingesetzt. Da
die Berechnung eines Ursprungswertes durch Hash-Funktionen gerade verhindert wird, lassen
sich Hash-Funktionen nicht für die direkte Ver- bzw. Entschlüsselung nutzen. Dennoch können
Hash-Funktionen aufgrund ihrer gezeigten Eigenschaften die Sicherheit mancher Kryptosysteme erhöhen.
Eine Erweiterung der Hash-Funktionen ist der Message Authentication Code (MAC). Für
die Berechnung des korrekten sogenannten MAC-Tags – ähnlich dem Hash-Wert – ist dabei
ein geheimer symmetrischer Schlüssel notwendig. Hiermit ist z.B. Authentifikation möglich, da
nur die Kommunikationspartner, welche Inhaber des Schlüssels sind, den entsprechenden Tag
erstellen sowie verifizieren, also überprüfen und sich somit authentifizieren können.
12 In
diesem Zusammenhang wird auch der Begriff Message Digest verwendet.
– 14 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Gängige MAC-Verfahren sind HMAC – wie z.B. HMAC-MD5 und HMAC-SHA-1 mit Basis
MD5 bzw. SHA-1, UMAC, DES-CBC mit DES-Schlüssel, keyed MD5 (siehe [Men96]).
1.2.6
Signatur
Eine weitere Möglichkeit, um u.a. ebenfalls Authentifikation zu betreiben, leitet sich aus den
asymmetrischen Verschlüsselungsverfahren ab. Man kann nämlich die Benutzung der Schlüssel
(siehe Abbildung 3) umkehren, womit sich digitale Signaturen erzeugen lassen. Beispielsweise
kann man so eine eMail signieren, womit deren Urheber sicher feststeht. Des weiteren existieren
reine Signaturverfahren, die sich nicht aus einem asymmetrischen Verschlüsselungsverfahren
ableiten, aber daran angelehnte Konzepte verwenden, wie z.B. öffentliche und private Schlüssel.
Das Signieren geschieht dadurch, daß man auf eine Nachricht den eigenen privaten Schlüssel
anwendet und dementsprechend kann jeder, der den passenden öffentlichen Schlüssel kennt, die
so entstandene Signatur verifizieren, also ihre Gültigkeit überprüfen (siehe [Buc04], [Men96]).
Ist sie gültig, läßt sich die Nachricht als authentisch bezeichnen.
Dies ist also eine Art von Umkehrung des asymmetrischen Verschlüsselungsvorgangs: Nur
der Besitzer des privaten Schlüssels kann eine Nachricht signieren, also mit seiner eigenen digitalen Unterschrift versehen. Hingegen kann jeder mit dem öffentlichen Schlüssel diese Signatur
überprüfen. Demgegenüber wird bei der Verschlüsselung der öffentliche Schlüssel benutzt, was
jeder tun kann. Entschlüsseln kann nur der Inhaber des privaten Schlüssels.
Da asymmetrische Verfahren viel langsamer sind als symmetrische, besteht beim Signieren
von z.B. großen Dokumenten ein Effizienzproblem. Deswegen macht man sich beim Signieren
in der Praxis meist Hash-Funktionen zunutze13 , welche man zuerst, also vor dem Signieren
auf das entsprechende Dokument anwendet. Die Signatur wird also indirekt, d.h. über den
Hash-Wert, verifiziert. Dies ist sicher, u.a. aufgrund der Eigenschaften der Hash-Funktionen.
Abbildung 4 zeigt den gesamten Vorgang beim Erstellen und Verifizieren einer Signatur.
Ein Beispiel für ein eingesetztes Verfahren ist der Digital Signature Algorithm (DSA).
Es ist selbstverständlich möglich ein Dokument zu Signieren und auch verschlüsselt zu
übertragen. Aus verschiedenen Sicherheitsgründen, die hier nicht näher erläutert werden sollen,
kommen in der Praxis dann meist verschiedene Schlüssel für Verschlüsselung und Signatur zum
Einsatz. Denn beide Vorgänge hängen eng zusammen und um es klar herauszustellen, anders
als bei der handschriftlichen Unterschrift ist die digitale Signatur für jedes signierte Dokument
unterschiedlich und dennoch exakt zu zuordnen.
Dies bringt natürlich einige Vorteile mit sich, z.B. kann der Empfänger einer Signatur diese
nicht für Fälschungen bei anderen Dokumenten benutzen, und es läßt sich beim Signieren ein
sogenannter Zeitstempel (Time Stamp, siehe Abschnitt 2.8) einfügen.
1.2.7
Kryptosysteme und Schutzziele
In Abschnitt 1.1.1 wurden sieben Schutzziele aufgeführt und erläutert. Mit den gezeigten Verfahren auch in Kombination sind diese erfüllbar, was teilweise offensichtlich ist. So ist natürlich
mit der digitalen Signatur das Schutzziel der Authentizität, aber auch das der Integrität sicher
gestellt. Letzteres bedeutet, bei gültiger Signatur ist das signierte Dokument auch unverändert.
Kommt eine dritte Vertrauensinstanz hinzu, z.B. ein TrustCenter, ist mit ihr ebenso die Verbindlichkeit gesichert (siehe Abschnitt 2.2.2). Der MAC hingegen kann nur Authentizität und
Integrität bieten. Durch Verschlüsselung erfolgt Vertraulichkeit, wie auch zum Teil die Anonymität in Kombination mit z.B. blinden Signaturen (siehe [Buc04], [Men96]).
13 Bei entsprechend kleinen Dokumenten kann man u.U. auf den Einsatz von Hash-Funktionen verzichten, etwa beim Signieren
von IP-Paketen. Dies macht den gesamten Vorgang bzw. Abbildung 4 natürlich etwas weniger komplex.
– 15 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Abbildung 4: Erstellen und Verifizieren digitaler Signaturen
Anonymität, Verbindlichkeit und Verfügbarkeit sind allerdings schwieriger zu gewährleisten
und hängen stark von den jeweiligen Gegebenheiten sowie den darauf anzuwendenden Verfahren
ab (siehe u.a. [Eck02]). Die Datiertheit kann durch eine dritte Instanz in Kombination mit deren
digitaler Signatur erfüllt werden. Auch hier kann diese Instanz wieder ein TrustCenter sein.
1.3
Angriffsformen, Abwehrmaßnahmen und Anwendungen
Dieser Abschnitt ist bewußt kurzgefaßt, aber nach der bisherigen Einführung in kryptographische Methoden notwendig, um einen praktischen Einblick für die theoretisch erläuterten
Verfahren und deren Bedeutung für die heutigen Schutzziele zu bekommen.
Im Folgenden werden sodann einige Angriffsformen skizziert sowie kurz Implementierungen
und Protokolle der in den vorherigen Abschnitten vorgestellten Verfahrensweisen beschrieben,
welche erfolgreiche Abwehrmaßnahmen darstellen.
1.3.1
Angriffsziele
Ziele von Angriffen sind natürlich die Umgehung von Kryptoverfahren bzw. Kryptosystemen
und die damit abgesicherten Daten. In der einfachsten Form zielt ein Angriff also auf die
Verschlüsselungstexte bzw. den Klartext sowie die verwendeten Schlüssel ab.
– 16 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
In der heutigen Zeit geht dies natürlich einen Schritt weiter und ein Angriff richtet sich meist
gegen die aus Abschnitt 1.1.1 bekannten Schutzziele, wie etwa gegen die Authentizität, die
Vertraulichkeit oder die Verfügbarkeit, auf welche verschiedene konkrete Systeme und Dienste
angewiesen sind.
1.3.2
Grundlagen von Angriffen
Der Begriff der Kryptographie ist allgemein definiert als die Lehre von den Methoden zur
Ver- und Entschlüsselung, wobei man heutzutage sicher mehr darunter versteht, wie schon in
den vorherigen Abschnitten beschrieben. Selbstverständlich existieren aber auch Gegensätze
zur Kryptographie. Wichtig ist hierbei die Kryptoanalyse – die Wissenschaft von Methoden
zur Decodierung von Nachrichten. Denn natürlich muß man die Qualität kryptographischer
Verfahren bewerten und sogar nachweisen können. In der Kryptologie, die eine Verknüpfung
von Kryptographie und Kryptoanalyse darstellt, wird dies u.a. auch getan. Damit in Verbindung
steht, die Möglichkeiten abzutasten ein Kryptosystem zu brechen (siehe [Eck02]).
Nach der kurzen Begriffsklärung geht es im Folgenden um Angriffe auf Kryptosysteme. Ein
solcher Angriff kann grundsätzlich auf mindestens drei Arten geschehen:
• Auf die zugrundeliegende Mathematik,
• auf die Struktur eines Protokolls,
• auf die Implementierung14 in Soft- oder Hardware (Seitenkanal-Angriff ).
Hierbei kann man wiederum zwei Arten unterscheiden:
– Aktive Angriffe (z.B. Manipulation von Hardware),
– passive Angriffe (z.B. Aufzeichnen Ein-/Ausgaben, Messen, Abhören).
Für praktische Implementierungen gilt das Kerckhoff-Prinzip. Es besagt, daß die Sicherheit
eines kryptographischen Verfahrens nur auf der Geheimhaltung des Schlüssels beruhen darf
und nicht auf der Geheimhaltung des kryptographischen Algorithmus selbst. Verstöße gegen
dieses Prinzip haben in der Vergangenheit bereits zu spektakuläreren Angriffen geführt (siehe
z.B. [Nzz01]).
Kryptosysteme bzw. Kryptoverfahren müssen demnach nicht nur theoretisch sicher und
effizient sein, man benötigt ebenfalls eine sichere Implementierung. Hat man einen sicheren
kryptographischen Algorithmus (wie RSA) aber eine schlechte und unsichere Implementierung,
ist das resultierende Kryptosystem sinnlos. Theorie und Implementierung müssen also schon
recht früh aufeinander abgestimmt werden.
1.3.3
Angriffe auf die Mathematik
Die Kryptoanalyse folgt einem einfachen grundlegenden Prinzip: Ein Verschlüsselungstext bzw.
eine codierte Nachricht hängt von dem ursprünglichen Klartext ab. Der Klartext wiederum ist
nicht zufällig. Aus diesen Feststellungen resultieren einige Angriffsformen auf Kryptosysteme,
die durch die zugrundeliegenden mathematischen Verfahren abgewehrt werden müssen.
Eine offensichtliche Angriffsmöglichkeit auf ein Kryptosystem bzw. dessen gewährleistete
Vertraulichkeit ist das Durchprobieren aller möglichen Schlüsselkombinationen (Brute Force),
womit sich beispielsweise auch das Tauschverfahren aus Abschnitt 1.1 leicht brechen läßt.
14 Die Bedeutung von Attacken auf eine Implementierung sei durch folgendes Beispiel verdeutlicht: 1998 gab es eine erfolgreiche
Attacke auf DES. Die sogenannte Differential Error Analysis benötigte 20 bis 200 Blöcke codierten Textes, um den DES-Schlüssel
zu bestimmen. Hingegen benötigte die beste Nicht-Seitenkanal-Attacke gegen DES etwa 64 Terabytes an Blöcken von Klar- und
Verschlüsselungstext (siehe [Osw01]).
– 17 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Meist sind Attacken allerdings intelligenter. Es ist z.B. bekannt, daß in jeweiligen Sprachen
gewisse individuelle Buchstaben oder Wörter mit einer bestimmten Häufigkeit bzw. in Kombination auftreten. Dazu sind bereits etliche Sprachanalysen bekannt und frei verfügbar, womit
sich beispielsweise auch das Tauschverfahren aus Abschnitt 1.1 leicht brechen läßt, aber auch
kompliziertere Verfahren.
Ebenfalls gibt es eine Reihe von Angriffen, die abhängig von den Möglichkeiten des Angreifers sind, und z.B. auf den Schlüssel des Kryptosystems oder auf die Decodierung der übertragenen Verschlüsselungstexte abzielen. So z.B. die sogenannte Ciphertext-Only Attacke, bei
welcher der Angreifer nur den Verschlüsselungstext mitlesen kann. Ist es ihm möglich ohne
Kenntnis des Schlüssels den Klartext zu bestimmen, ist das benutzte Kryptosystem völlig unsicher. Ein anderes Beispiel ist die Known-Plaintext Attacke – hier kennt der Angreifer zu einem
Verschlüsselungstext aus gewissen Gründen den zugehörigen Klartext – und einige mehr. Ein
sicheres Kryptosystem muß all solchen Angriffsmöglichkeiten gewachsen sein.
Eine der mächtigsten theoretischen Angriffe, dessen Durchführbarkeit in der Praxis nicht
allzu leicht, dennoch alles andere als unmöglich ist, nennt man Man in the Middle. Dabei kann
der in der Mitte zweier Kommunikationspartner befindliche Angreifer alle von beiden Seiten
übertragenen Daten mitlesen und selbst in diese Kommunikation eingreifen. Die Abwehr eines
solchen Angriffs ist schwierig und z.B. das Verfahren von Diffie und Hellman (siehe auch
Abschnitt 1.2.2) in der einfachsten Form ist gegen diesen nicht sicher. Denn beim Austausch
auch von nur öffentlichen Schlüsseln asymmetrischer Verfahren könnte ein solcher Angreifer
seinen eigenen öffentlichen Schlüssel übertragen lassen unter der Vorgabe, dieser gehöre jemand
anderem. Auf diese Weise kann der Angreifer dann alle mit diesem seinem öffentlichen Schlüssel
verschlüsselten Daten mitlesen.
Es existieren natürlich weitaus mehr Angriffsmöglichkeiten, gerade auch in Details der mathematischen Grundlagen, auf denen Kryptosysteme beruhen. Dazu sei hier allerdings auf z.B.
[Buc04] oder [Men96] verwiesen.
1.3.4
Angriffe auf Protokoll-Strukturen
Bei Protokoll-Strukturen, welche einen anwendungsbezogenen Ablauf von z.B. kryptographischen Methoden festlegen (siehe auch Abschnitt 1.3.7), kann die zugrundeliegende Mathematik
genauso angegriffen werden wie im vorherigen Abschnitt geschildert. Denn natürlich kommen
in Sicherheitsprotokollen auch die hier gezeigten mathematischen Verfahren zum Einsatz.
Zusätzlich existieren Angriffe auf prinzipielle Annahmen sowie Protokollschritte, und auch
Attacken wie Man in the Middle lassen sich auf Protokollstrukturen anwenden. Bei Netzwerken
und einfachen Netzwerkprotokollen beispielsweise zielen Angriffe oftmals auf Authentizität und
Verfügbarkeit (siehe Abschnitt 1.1.1) der Kommunikation ab, z.B. durch:
• Spoofing (Vortäuschen einer Absenderadresse, also einer falschen Identität),
• Session-Hijacking (Übernehmen einer anderen evt. bereits nachgewiesenen Identität),
• Replays (Wiedereinspielen verschlüsselter und Klartext-Nachrichten, z.B. IP-Pakete),
• DoS-Attacken (Denial of Service; Überfluten und Ausschalten eines Rechners).
Diese Angriffsmöglichkeiten sollen hier nur kurz erwähnt werden. Für Details sei auf z.B.
[Boe02], [Bus02] und [Eck02] verwiesen.
– 18 –
1
1.3.5
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Seitenkanal-Angriffe ( Side Channel Attacks“)
”
Implementierungen in Hardware sind meist stark optimiert, daher sehr effizient und oft genutzt, womit sie natürlich ebenso beachtenswert für Sicherheitsaspekte sind. Dennoch sind
Seitenkanal-Angriffe nicht auf Hardware beschränkt, wenngleich sie eher selten auf Software
erfolgen.
Ein Seitenkanal entsteht im Allgemeinen aus unerwünschter Seiteninformation, welche unbeabsichtigt von der Hardware abgegeben wird. Analysiert wird z.B.:
• Stromverbrauch (z.B. von Mikrochips; bekannt als Simple Power Analysis (SPA) und
Differential Power Analysis (DPA)15 ),
• Zeitverhalten (z.B. Ausführungszeiten von Operationen),
• Temperatur (z.B. Veränderung, Anstiege),
• Verhalten nach gezielter Beschädigung,
• Elektromagnetische Strahlung von Hardware-Modulen (z.B. Tastatur, Kabel, Monitor,
Grafikkarte etc.), was hauptsächlich für das Auslesen und Ausspähen von Daten aus der
Ferne genutzt wird, wie etwa bei Bildschirmausgaben oder Paßworteingaben.
Natürlich existieren auch Attacken gegen Software-Implementierungen, wie z.B. gegen:
• Zeitverhalten (z.B. eines Servers),
• Löschen von Dateien ohne Überschreiben (verschlüsseltes Dateisystem),
• (Pseudo-)Zufallszahlengenerator.
Diese Art von Angriffen kann sehr mächtig16 sein und auch in Kombination, z.B. auf Stromverbrauch und Zeitverhalten, auftreten.
Schlüssel sind oftmals das Ziel solcher Attacken, deren Grundidee im Folgenden am Beispiel
der SPA verdeutlicht werden soll und leicht einzusehen ist: Der augenblickliche Stromverbrauch
der Hardware steht im direkten Zusammenhang zur ausgeführten Instruktion und den benutzten Daten17 . So können Operationen, z.B. die Addition, bzw. Schlüssel auf direktem oder
indirektem Wege erkannt und abgeleitet werden (siehe [Osw01]).
Besondere Maßnahmen gegen Seitenkanal-Angriffe
Für Gegenmaßnahmen kann man zum einen auch hier wieder mathematisch vorgehen, wie
in den vorherigen Abschnitten erläutert. D.h., man verändert vorhandene oder erstellt neue
Algorithmen, die praktische Anforderungen berücksichtigen und diesen genügen.
15 Der Aufwand für die SPA ist verhältnismäßig klein. Notwendig sind ein digitales Oszilloskop und ein Standard-PC, um die
gemessenen Daten zu verarbeiten. Ein tiefgehendes Verständnis über die Ausführung ist nicht nötig. Dies bedeutet also, daß
nicht nur wenige Fachleute“ einen solchen Angriff durchführen können. Die DPA hingegen erweitert die SPA mit Methoden der
”
Statistik und ist daher nicht so einfach anzuwenden. Dennoch ist sie die am häufigsten genutzte, weil erfolgreichste Vorgehensweise
gegen Kryptosysteme.
16 Ein gutes Beispiel, um dies zu verdeutlichen, ist das Lesen einer eMail, die verschlüsselt versendet und auf den eigenen Rechner
geholt wurde. Um diese eMail einmal lesen zu können, muß sie entschlüsselt und im Klartext am Bildschirm angezeigt werden. Ist
der Angreifer in der Lage, z.B. die Bildschirmanzeige in einigen Metern Entfernung zu rekonstruieren, hat er alle vorgenommenen
Verschlüsselungsmethoden umgangen.
17 Man betrachte z.B. das unterschiedliche elektrische Verhalten bei der CMOS-Technologie: n-MOS- und p-MOS-Transistoren
sind verschieden, aber jeweils verantwortlich für High- und Low-Werte (also logische 1 und 0 in z.B. den verwendeten Daten).
Dies läßt sich als Seiteninformation bezeichnen.
– 19 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
Die zweite Möglichkeit liegt im Bereich der Hardware selbst: So haben die Hersteller in der
Vergangenheit Verbesserung vorgenommen und Lücken auch in Form von Verwundbarkeiten
geschlossen. Die Abgabe von Seiteninformation wurde minimiert, womit heute z.B. Chipkarten
gegen viele Attacken, wie etwa auf die Temperatur, resistent sind (siehe [Osw01]).
1.3.6
Brechen von Schlüsseln oder Kryptoverfahren
Das Brechen von Kryptoverfahren hat nicht zwingend, kann jedoch katastrophale Auswirkungen haben. Dies hängt sehr stark von dem Bereich bzw. dem Anwendungsfall ab (siehe z.B.
Seite 7), in welchem sie eingesetzt werden. Es folgen ein paar kleinere Beispiele.
Bei der eigenen Signatur gibt es mehr oder weniger kritische Problemfälle. Hat man z.B.
ein Dokument digital signiert und verliert seinen privaten Schlüssel bzw. wird dieser oder das
benutzte Kryptoverfahren kompromittiert, kann das Dokument mit neuem Schlüssel und bzw.
oder neuem Verfahren einfach noch einmal signiert werden.
In Vertragsfällen kann das Verlieren eines Schlüssels problematischer sein. Unter Umständen
möchte ein Vertragspartner bewußt die Ungültigkeit eines signierten Vertrages herbeiführen.
Die Handhabung solcher Fälle hängt stark von den Gegebenheiten ab (siehe Abschnitt 2.2.2).
Schwieriger sieht es bei der Verschlüsselung aus, z.B.: Sind die Daten etwa auf dem eigenen
Laptop nur verschlüsselt abgelegt, z.B. mittels verschlüsseltem Dateisystem, und geht der
Entschlüsselungsschlüssel verloren, sind auch diese Daten vollständig verloren. Hier wird die
Beachtung für eine Sicherheitskopie des Schlüssels deutlich.
Beim Übertragen von verschlüsselten Nachrichten über einen öffentlichen Kanal, wie dem
Internet oder einer Funkverbindung, muß das benutzte Kryptoverfahren zeitlichen Bestand
haben. Denn die mitgelesene verschlüsselte Nachricht soll eventuell auch in mehreren Jahren
oder Jahrzehnten nicht für einen Angreifer entschlüsselbar sein. Neuerliches Verschlüsseln dieser bereits abgefangenen Nachricht, deren Kryptoverfahren vielleicht später gebrochen wurde,
mit einem anderen Kryptoverfahren ist offensichtlich sinnlos.
Es kommt auch vor, daß ein Kryptosystem in Laufe der Zeit zwar nicht gebrochen wird,
dennoch die benutzten Schlüssel für spätere Angriffe zu kurz geworden sind. Das bedeutet, um
das Verfahren (wieder) sicher benutzen zu können, muß die Länge der Schlüssel erhöht werden,
was sich natürlich wiederum nur auf die Sicherheit bei der zukünftigen Nutzung auswirkt. U.a.
daher muß ein sicheres Kryptosystem von Grund auf zeitlichen Bestand haben.
1.3.7
Anwendungen und Protokolle
In diesem Abschnitt sollen kurz einige aktuelle Anwendungen bzw. Clients, also Implementierungen und konkrete Protokolle für kryptographische Verfahren genannt werden. Diese können
meist mehrere Schutzziele gewährleisten, also die geschilderten Angriffe erfolgreich abwehren
und sind auch kombinierbar. Für weitere Details sei auf [Boe02], [Bus02], [Eck02] verwiesen.
Zu beachten ist hierbei, daß auf allen Schichten des OSI-Modelles18 solche Anwendungen
oder Protokolle zu finden sind, was natürlich verschiedene Konsequenzen in der Benutzbarkeit
und Automatisierung nach sich zieht.
PGP (Pretty Good Privacy) ist ein auch als Freeware“ weitverbreitetes Programm, welches
”
zum Verschlüsseln und Signieren geeignet ist und etliche genannte Verfahren aus den Abschnitten 1.2.1ff. implementiert hat. Im Gegensatz zu dieser Lösung für eher kleinere und mittlere
Anforderungen, ist Kerberos ein Protokoll für große sowie verteilte Dienste und Systeme.
18 Es handelt sich hierbei um das bekannte Modell für die Datenübertragung zwischen Computersystemen, bestehend aus
sieben übereinanderliegenden Abstraktionsschichten, welche individuelle Aufgaben und Schnittstellen besitzen. OSI steht für Open
Systems Interconnection und ist eine Sammlung von Standards der International Standardisation Organisation (ISO) (Details siehe
[Bus02], [Boe02]).
– 20 –
1
EINFÜHRUNG IN KRYPTOGRAPHIE UND COMPUTER-SICHERHEIT
SSL (bzw. TLS) ist ein Kommunikationsprotokoll, welches zwischen Anwendungs- und
Transportschicht angesiedelt ist und somit alle Anwendungen, die darauf zugreifen, absichert.
Auf Netzwerk- und Data Link-Schicht finden sich einige Protokolle, z.B. IPSec, u.a. für
Vertraulichkeit und Authentifikation, womit sich sogenannte Virtuelle Private Netze (VPN)
realisieren lassen. Dabei handelt es sich um die Realisierung von logischen Direktverbindungen
zum Datenverkehr über öffentliche Netze wie dem Internet oder Funkverbindungen.
1.4
Public Key-Infrastrukturen (PKI)
Dieses Kapitel diente als Einführung in die Kryptographie, wobei auch praktische Aspekte aufgezeigt wurden. Im nächsten Kapitel wird die schon genannte Vertrauensinstanz, das TrustCenter näher erläutert und die damit verbundenen Public Key-Infrastrukturen.
Denn damit können noch ausstehende Probleme gelöst werden: Die Schutzziele der Verbindlichkeit und der Datiertheit sowie die sichere Zuordnung von einer Identität zu einem
öffentlichen Schlüssel bzw. Public Key.
– 21 –
2
TrustCenter FlexiTrust
Dieses Kapitel beschreibt die Möglichkeiten zur Realisierung einer PKI mit einem TrustCenter
zum einen allgemein und zum anderen speziell bezogen auf das TrustCenter-Produkt Fle”
xiTrust“. Dabei ist zu beachten, daß die üblichen und allgemeinen Eigenschaften eines TrustCenters natürlich auch bei FlexiTrust umgesetzt sind. Doch zunächst werden die Ziele und
Aufgaben einer PKI im Allgemeinen etwas verdeutlicht.19
2.1
Ziele und Aufgaben von PKIs und TrustCentern
In Kapitel 1 wurden verschiedene Kryptoverfahren vorgestellt und deren Vor- und Nachteile
erläutert. Wie schon gesehen, kommen in der Praxis meist Hybridverfahren zum Einsatz, um
Vorteile aller Varianten zu kombinieren. Einer dieser Vorteile ist die Nutzung von Verfahren
mit öffentlichen Schlüsseln.
Die essentielle Aufgabe einer PKI ist es nun darauf aufbauend, die Verknüpfung von Personen bzw. Identitäten zu deren öffentlichen Schlüsseln, z.B. mittels Zertifikaten (siehe nächster
Abschnitt), sicherzustellen. Zertifikate stellen dabei heute das wichtigste Werkzeug dar.
Natürlich besteht die Möglichkeit in einem kleinen Kreis von Personen eine PKI durch
persönliche Kontakte“ aufzubauen und gegenseitig Zertifikate auszustellen bzw. Schlüssel
”
auszutauschen. Die verbreitete Sicherheitssoftware PGP (Pretty Good Privacy) beispielsweise
setzt genau an diesem Punkt an.20
Man spricht hier von Direct Trust. Dabei übernimmt jeder PKI-Teilnehmer selbst das
Schlüsselmanagement, womit die Generierung und Verteilung von Schlüsseln gemeint ist.
Bei großen Benutzermengen, die sich persönlich unbekannt sind, ist die Lösung des Direct
Trust jedoch nicht ausreichend. Denn Vertrauen ist in solchen Gruppen nicht übertragbar. In
diesem Falle wird eine unabhängige dritte Instanz benötigt oder eine kleine Menge der solchen,
wodurch eine Vertrauensbasis sowie eine Vertrauenshierarchie geschaffen wird.
Innerhalb einer solchen hierarchischen PKI gibt es dann nur eine oder wenige Instanzen,
welchen wirklich vertraut werden muß. Man spricht von der sogenannten Certification Authority (CA). Man kann sagen, die CA stellt die oberste PKI-Instanz dar, ihr müssen alle PKITeilnehmer vertrauen. Nur sie darf Zertifikate und CRLs (siehe auch Abschnitt 2.2) ausstellen,
signieren und veröffentlichen.
Ein TrustCenter beispielsweise stellt eine solche Instanz dar. Es registriert Personen, welche
an einer PKI teilnehmen bzw. PKI-Mitglieder werden wollen, z.B. auch durch persönliche Überprüfung und stellt diesen sodann ihr individuelles Zertifikat für diese PKI aus (siehe Abschnitte
2.4ff.).
Die PKI-Teilnehmer können nun mit Hilfe ihrer Zertifikate untereinander z.B. vertraulich
kommunizieren. Das TrustCenter legt dazu, z.B. durch die Schlüsselgenerierung, einige der
genutzten kryptographischen Verfahren fest. Dies gewährleistet beste Kontrolle für eingesetzte Algorithmen, Verfahren und deren Schlüssel. Denn Schlüssel beispielsweise sind nicht unabhängig von den zugrundeliegenden Verfahren. Ein bestimmtes Verfahren erzwingt meist
bestimmte Schlüsseleigenschaften, und so sind beispielsweise Schlüssel für symmetrische und
asymmetrische Verfahren völlig unterschiedlich.
19 Nicht immer sind PKIs vonnöten, also das Nutzen von Public Key-Verfahren. Dies hängt stark von der jeweiligen Anwendungsanforderung ab. Die Grundbuchgerichte Hessens beispielsweise setzen zum Bearbeiten ihrer elektronischen Akten, die auf
einem für ganz Hessen zentralen Server abgelegt sind, auf wechselnde Paßwörter zur Authentifikation bzw. Unterschrift.
20 Die Möglichkeiten von PGP gehen allerdings wesentlich weiter, so läßt sich beispielsweise ein Key-Server nutzen (siehe auch
Abschnitt 1.2.3).
– 22 –
2
TRUSTCENTER FLEXITRUST
PKIs, realisiert z.B. mit einem TrustCenter, sind oftmals sehr individuell aufgebaut. Daher
legt jede PKI ihre eigene sogenannte Policy oder Sicherheitspolitik öffentlich fest.21
Ein TrustCenter bietet u.a. den besten Schutz vor den Angriffsmöglichkeiten aus Abschnitt
1.3.2ff. Durch entsprechende Sicherheitspolitik beispielsweise ist ein Man in the Middle-Angriff
durch eine TrustCenter-PKI leicht abzuwehren. Denn ein zentrales TrustCenter hat es leicht
seinen öffentlichen Schlüssel bekanntzugeben und dessen Korrektheit von PKI-Teilnehmern
überprüfen zu lassen. So kann es beispielsweise den öffentlichen Schlüssel selbst oder zur
Überprüfung des Schlüssels einen Fingerprint 22 verschicken oder über das Internet bzw. in
Papierform veröffentlichen. Folglich kann also jeder Signaturen, welche vom TrustCenter, also
der Vertrauensinstanz selbst erstellt wurden, verifizieren.
Also stellt ein TrustCenter die besten Rahmenbedingungen für die Personalisierung von
Schlüsseln, z.B. auch nach gesetzlichen Maßstäben (siehe Abschnitt 1.1.1 über Verbindlichkeit), zur Verfügung. Dazu gehören ebenso nicht-technische Maßnahmen, wie z.B. geschützter
Unterbringungsort für TrustCenter-Server oder das Vieraugenprinzip usw.23
Neben den allgemeinen Schutzzielen aus Abschnitt 1.1.1, haben PKIs im speziellen folgende
Ziele:
• Verknüpfung von Personen zu öffentlichen Schlüsseln,
• Verteilung öffentlicher Schlüssel,
• Authentizität öffentlicher Schlüssel.
Für TrustCenter leitet sich daraus ab bzw. gilt zusätzlich:
• Verbindlichkeit,
• Datiertheit.
Aus diesen Zielen resultieren für das TrustCenter die folgenden Aufgaben:
• Veröffentlichung von Teilnehmer-Zertifikaten,
• Veröffentlichung von Revokations-/Sperrinformationen (z.B. Certificate Revocation Lists
(CRLs) bzw. Sperrlisten),
• Veröffentlichungen typischerweise über das Internet.
2.2
Zertifikate und ihre Bedeutung
Ein Zertifikat ist eine Art von digitalem Ausweis. Es enthält u.a. den Namen seines Besitzers,
den Namen der ausstellenden Behörde (Zertifizierungsstelle, also CA), einen Gültigkeitszeitraum, den öffentlichen Schlüssel des asymmetrischen Schlüsselpaares des Besitzers sowie weitere mögliche Daten. Über die digitale Signatur, welche die CA mit ihrem öffentlichen Schlüssel
21 Als Beispiel sei hier die über ein Java-Framework implementierte FlexiPKI“ aus der Arbeitsgruppe von Prof. Buchmann
”
an der TUD erwähnt, welche, wie schon am Namen zu erkennen, ein flexibles System zur Verfügung stellt, kryptographische
Verfahren zu benutzen, leicht auszutauschen und zu wählen. Auch eine Failsafe-PKI, also das sichere Ersetzen von gebrochenen
Verfahren und Aufrechterhalten der PKI, ist so möglich.
22 Ein Fingerabdruck ist ein eindeutiger und sicherer Hash-Wert (siehe Abschnitt 1.2.5) über ein Dokument, hier über den
öffentlichen Schlüssel.
23 Das Festlegen und Durchsetzen solcher Maßnahmen hängt natürlich stark von den jeweiligen Anforderungen ab. Außerdem
muß man hervorheben, daß außerhalb von kryptographischen Protokollen der Begriff der Sicherheit sehr stark von den Umgebungsbedingungen und vor allem den Verantwortlichen hinter dem TrustCenter abhängt. Dabei können bestimmte Regeln, z.B.
beim Austausch zwischen den TrustCenter-Komponenten und bei der jeweiligen Betreuung einer Komponente im Allgemeinen,
eine zentrale Rolle spielen.
Zum Vergleich kann man den Ablauf der Bundestagswahlen heranziehen. Betrug ist hier nur bei bewußtem oder unbewußtem
Fehlverhalten bzw. fehlerhaftem Kontrollverhalten einer großen Menge der Wahlbetreuer möglich.
– 23 –
2
TRUSTCENTER FLEXITRUST
über das gesamte Zertifikat bildet, wird der öffentliche Schlüssel eindeutig an seinen Benutzer
gebunden. Damit wird also das primäre Ziel von PKIs, die Personalisierung eines öffentlichen
Schlüssels erreicht.
Die Vorteile sind leicht zu erkennen, denn ein TrustCenter kann so die Vergabe und Nutzung
von öffentlichen Schlüsseln steuern. Durch Zertifikate ist es möglich, einen Kreis von Personen
für die Teilnahme an einer PKI festzulegen. Dies bedeutet auch, daß man spezielle Personen,
z.B. Angreifer, oder spezielle Schlüssel, z.B. gebrochene, von der Kommunikation innerhalb
der PKI ausschließen kann.
Ein Zertifikat kann beispielsweise Daten wie eine eindeutige Seriennummer oder einen
Gültigkeitszeitraum enthalten und den jeweiligen öffentlichen Schlüssel daran binden. Zertifikate lassen sich daher sperren, man spricht hier von Revokation. Der enthaltene öffentliche
Schlüssel ist auf diese Weise zwar ebenfalls gesperrt, aber eine Kontrolle, ob dieser z.B. erneut
verwendet oder innerhalb einer anderen PKI ebenfalls genutzt wird, ist impraktikabel.
Natürlich ist es äußerst sinnvoll, daß für Zertifikate ein einheitlicher Standard unabhängig
von der jeweiligen PKI verwendet wird. Dies wird mit dem X.509 -Standard, z.B. in der Version
3, daher auch getan.
Ein X.509v3-Zertifikat besteht zum einen aus Standard-Feldern bzw. Standard-Attributen
und ist im ASN.1-Format codiert. Des weiteren kann es Extensions enthalten, wobei es sich
um frei definierbare Felder handelt. Jeder Zertifikatsaussteller kann unter der Beachtung von
Formatregeln zusätzliche Felder und Informationen, eben sogenannte Extensions in ein Zertifikat einfügen. Extensions sind ab Version 3 in einem X.509-Zertifikat erlaubt. Auch hier gibt
es schon vordefinierte Standard-Extensions für PKIs.
Ein Beispiel für ein Zertifikat unter Verwendung des X.509-Standards findet sich in Abbildung 5. Somit ist eine Veröffentlichung von Zertifikaten im hierarchischen Modell (siehe
auch Abbildung 7) sehr einfach. Im Beispiel enthält das Zertifikat den Issuer , also den Aussteller bzw. die CA sowie den Inhaber des Zertifikats als Subject und beide sind über ihren
Distinguished Name (siehe Abschnitte 2.7 und 2.7.6) eindeutig identifiziert. Auf Distinguished
Names wird im Folgenden noch näher eingegangen, hierbei handelt es sich aber lediglich um
eine eindeutige Kennzeichnung.
Revokations- bzw. Sperrlisten, also Listen mit revozierten Zertifikaten lassen sich über den
Verzeichnisdienst (siehe Abschnitt 2.7) bzw. den Distinguished Name des Issuers ebenfalls
leicht erreichen und deren Download, z.B. von einer PKI-Clientsoftware aus, automatisieren.
Certificate
Data:
Version: 3 (0x2)
Serial Number: 44 (0x2c)
Signature Algorithm: sha1WithRSA
Issuer: C=DE, O=TUD, OU=FB20, OU=CDC, CN=FlexiTrustCA
Validity
Not Before: Nov 19 23:00:00 2002 GMT
Not After : Nov 19 23:00:00 2003 GMT
Subject: C=DE, O=TUD, OU=FB20, OU=CDC, CN=Juergen Jonny Steinmann
[...]
--- Öffentlicher Schlüssel als Binärwert --[...]
--- Signatur der entsprechenden CA über das gesamte Zertifikat --[...]
Abbildung 5: Beispiel für ein Zertifikat mit Distinguished Names
– 24 –
2
2.2.1
TRUSTCENTER FLEXITRUST
Kommunikation mit Zertifikaten
Zur Kommunikation (siehe Abschnitt 2.7) mit einem PKI-Teilnehmer wird nicht dessen öffentlicher Schlüssel sondern dessen Zertifikat gesucht. Benutzt wird natürlich jedoch der darin
enthaltene Schlüssel.
Ein TrustCenter nimmt die Veröffentlichung der Zertifikate vor (siehe Abschnitt 2.7) und
auch die Veröffentlichung von Sperrlisten, welche ungültige Zertifikate und somit ungültige
Schlüssel enthalten.
Auf diese Weise findet also der Schlüsselaustausch statt – unter Beachtung der jeweiligen
Policy. Natürlich werden so ebenfalls für Kryptoverfahren wichtige Schlüsseleigenschaften oder
-längen festgelegt.
2.2.2
Schutzziele und Zertifikate
Aufgrund der Personalisierung von Schlüsseln durch Zertifikate werden bestimmte Schutzziele
überhaupt erst realisierbar und zwar:
• Verbindlichkeit,
• Authentizität,
• Datiertheit (siehe Abschnitt 2.8).
Authentizität ist nur dadurch gewährleistet, daß der Absender innerhalb einer Kommunikation bekannt ist. Dies wird nur möglich, wenn der verwendete Schlüssel auch einer Person
zugeordnet werden kann (siehe Abschnitt 1.1.1).
Verbindlichkeit (siehe auch Abschnitt 1.1.1) beruht somit natürlich auf Authentizität. Doch
Verbindlichkeit geht darüber hinaus. Sie verlangt, daß man den Inhalt und Absender eines
Kommunikationsvorgangs, z.B. einer eMail, Dritten gegenüber beweisen kann. Dazu benötigt
man:
• Authentizität,
• Verwendung von Public Key-Verfahren bzw. digitalen Signaturen (siehe Abschnitt 1.2.6),
• eine Vertrauensinstanz bzw. ein TrustCenter.
Wie in Abschnitt 2.1 gezeigt, bietet das TrustCenter die Rahmenbedingung für die Personalisierung von Schlüsseln. Durch digitale Signaturen wird gewährleistet, daß digitale Unterschriften
ausschließlich vom Schlüsselinhaber selbst angefertigt werden können. Die Authentizität ist
durch die beiden vorherigen Punkte mit eingeschlossen.
2.3
TrustCenter-Struktur auf Basis von FlexiTrust
Die spezielle Struktur des TrustCenters FlexiTrust ist in Abbildung 6 zu sehen. Die einzelnen
Teile bzw. Komponenten des TrustCenters (bzw. Kürzel in der Abbildung) sind die folgenden:
• Registration Authority (RA),
• Key Authority (KA),
• Certificate Management Authority (CMA),
• Directory Service (DS),
– 25 –
2
TRUSTCENTER FLEXITRUST
• Time Stamp Service (TSS).
Wie in der Abbildung zu erkennen, bildet die CMA das Herzstück des TrustCenters, da hier
alle Bereiche zusammenfinden. Anlaufstellen zum Kontakt mit dem TrustCenter sind durch die
äußeren Pfeilen dargestellt, die inneren Pfeile stellen den internen Ablauf dar. Im Folgenden
werden nun die einzelnen fünf Bereiche näher beleuchtet sowie die Abläufe im und um das
TrustCenter genauer erläutert.
Abbildung 6: Struktur des TrustCenters FlexiTrust
2.3.1
Komponentenmodell auf Basis von FlexiTrust
Abbildung 6 zeigt nicht nur die Bestandteile von FlexiTrust sondern auch dessen externe und
interne Vorgänge. Das Diskettensymbol soll andeuten, daß Interaktion im betreffenden Falle
nicht unmittelbar möglich ist bzw. sein soll (siehe dazu die nächsten Abschnitte), z.B. wegen
Sicherheits- oder Korrektheitsprüfungen und Signierungsvorgängen.
Von außen hat man drei Zugangsmöglichkeiten zum TrustCenter und zwar über die Komponenten:
• Registration Authority,
• Directory Service bzw. Verzeichnisdienst,
• Time Stamp Service.
Die Registration Authority stellt also die Registrierungsautorität dar. Das bedeutet, ein potentieller PKI-Teilnehmer tritt an die RA heran, um die Mitgliedschaft in der PKI zu beantragen.
Für den internen Ablauf im TrustCenter FlexiTrust sind alleine die drei Komponenten RA,
KA und CMA zuständig, welche zusammen das eigentliche TrustCenter bilden. Natürlich ist es
– 26 –
2
TRUSTCENTER FLEXITRUST
wichtig, daß die meisten Abläufe zwischen den Komponenten sicher sowie automatisiert vonstatten gehen können. Wie in der Abbildung angedeutet, beginnt beispielsweise die KA ihre Arbeit erst auf Initiierung durch die RA, z.B. bei der Schlüssel-Erzeugung oder -Wiederherstellung,
und die RA kann nur indirekt über die KA mit der CMA interagieren.
Natürlich existieren verschiedene Möglichkeiten und Modelle für Realisierung eines TrustCenters (siehe auch [Ada02]).24 Im Folgenden wird nun ein konkretes Modell beschrieben und
definiert, basierend auf der gezeigten Struktur von FlexiTrust.
2.4
Registration Authority
Die RA stellt die zentrale Stelle zur Registrierung von PKI-Teilnehmern dar. Man kann die
RA also als Eintrittspforte“ zur PKI bezeichnen. Bei einem PKI-Teilnehmer, im Folgenden
”
auch bezeichnet als Entity, handelt es sich jedoch nicht ausschließlich um eine Person. Auch
Computer oder Computer-Dienste können Entities sein.25
Die RA initiiert ebenfalls andere TrustCenter-Vorgänge, wie z.B. die Schlüsselerzeugung in
der KA. Zur Registrierung an sich gehören, neben dem Erfassen der individuellen Registrierungsdaten bzw. des Registrierungsdatensatzes, viele Aufgaben und Ziele, um die Basis für
den TrustCenter-Betrieb zu gewährleisten, wie z.B.:
• Annahme von Zertifikatsanträgen,
• Annahme von Revokationsanträgen,
• Verknüpfen von Registrierungsdaten und Zertifikaten,
• Gewährleisten der Vollständigkeit der Registrierungsdaten,
• Gewährleisten der Korrektheit der Registrierungsdaten,
• Gewährleisten der Vertraulichkeit der Registrierungsdaten,
• Schutz vor Manipulation der Registrierungsdaten,
• Nachvollziehbarkeit und Nachweisbarkeit aller Abläufe.
Diese Aspekte sind nicht bei jeder konkreten RA-Realisierung vorhanden oder gleich und
können je nach Ablauf des Registrierungsvorgangs im entsprechenden Anwendungsszenario
optional sein.
Die Daten, welche von der RA erhoben und gespeichert werden müssen, stellen die erfaßte Identität einer Entity dar, und können verschiedene Sicherheitsanforderungen bzgl. ihrer
Herkunft besitzen:
• Registrierung ohne Überprüfung (z.B. online),
• Registrierung mit Überprüfung (z.B. persönlich durch Ausweis),
• Übernahme von vertrauenswürdigen Quellen (z.B. Firmendatenbank),
• Mischformen.
24 Die
Struktur von bzw. Gewaltenteilung bei FlexiTrust ist sicher nur eine von mehreren Möglichkeiten, auf welche hier allerdings
ausführlich eingegangen wird. Aber es wäre ebenfalls denkbar, daß z.B. RA und KA eine einzige Komponente bilden und nicht
getrennt werden.
25 In dieser Arbeit ist hauptsächlich die Rede von Personendaten, wenn Registrierungsdaten angesprochen werden. Jedoch ist es
auch denkbar, daß Rechner, wie z.B. Workstations in einem Computer-Netzwerk, registriert und für eine PKI zertifiziert werden.
Dies beeinflußt die vorgestellten Systeme und Ideen dieser Arbeit jedoch kaum.
– 27 –
2
TRUSTCENTER FLEXITRUST
Alle, auch nach anderen Modellen aufgebaute, TrustCenter haben gemeinsam, daß Anforderungen und Verfahrensweisen etc. dieser Art, über die jeweilige Sicherheitspolitik des TrustCenters,
auch Policy genannt, festgelegt werden. In diesem Modell müssen sie von der RA durchgesetzt
werden.
Die Erfassung von Daten kann grundsätzlich auf zwei verschiedene Arten durchgeführt
werden und zwar zentral oder verteilt, also dezentral. Dabei kann sowohl die Erfassung als auch
die Datenhaltung zentral oder dezentral sein – je nach individueller Anwendungsanforderung.
Nach der erfolgreichen Registrierung eines PKI-Mitglieds kann die RA sodann Vorgänge bei
der KA, wie z.B. Zertifikatserzeugung, initiieren. Durch das Binden der Registrierungsdaten an
ein Zertifikat und das Signieren von Zertifikaten durch die KA wird die Personalisierung von
Schlüsseln durch das TrustCenter vollzogen und abgeschlossen.
Weitere Aspekte und Details zum Registrierungsablauf sowie zu RA-Aufgaben im vorgestellten und definierten TrustCenter-Modell finden sich in Kapitel 4.
2.5
Key Authority
Die KA hat die Schlüsselerzeugung und das Schlüsselmanagement zur Aufgabe. Dabei geht es
nicht um die Veröffentlichung von Schlüsseln oder Zertifikaten. Die KA stellt eine reine OfflineKomponente dar – zum einen aus Sicherheitsgründen, da Schlüssel hoch sicherheitskritisch
sind, und zum anderen weil aufgrund der Struktur von FlexiTrust keine Notwendigkeit besteht,
die KA über eine Online-Schnittstelle über das Internet zugänglich zu machen.
Die KA hat als einzige Komponente des TrustCenters folgende Eigenschaften:
• Besitzer des privaten CA- bzw. Aussteller-Schlüssels,
• Möglichkeit zum Einsehen von fremden Privatschlüsseln.
Als zentrale Stelle für Schlüssel kommen der KA folgende essentielle Aufgaben zu:
• Unterschreiben/Signieren von Zertifikaten,
• Unterschreiben von Revokationslisten,
• Erzeugung und Auslieferung von Schlüsselpaaren.
D.h., die KA übernimmt Aufgaben, deren Ergebnisse nach außen hin sichtbar sind. Dennoch
erfolgt die Ausführung der Aufgaben wie schon beschrieben nicht online. Die Ergebnisse wiederum werden nur indirekt und zwar mittels der CMA (siehe nächster Abschnitt) weitergegeben,
z.B. per manueller Weitergabe.
Die Aufgaben der KA bzgl. Schlüsseln sind Erzeugung, Transport, Zerstörung, Hinterlegung,
Speicherung und Wiederherstellung. Dies bedeutet also z.B., daß durch die KA ein Key-Backup
möglich wird (vgl. Abschnitt 1.3.6) oder private Teilnehmerschlüssel generiert und verschickt
werden, sofern ein Teilnehmer keine eigenen Schlüssel besitzt. Besitzt ein Teilnehmer hingegen
schon ein Schlüsselpaar, welches er benutzen möchte, so muß er seinen öffentlichen Schlüssel
hinterlegen.
Zum Verschicken privater Schlüssel vom TrustCenter an den jeweiligen Teilnehmer bzw. zum
sicheren Lagern und Aufbewahren dieser werden Tokens bzw. Personal Security Environments
(PSEs) verwendet. Sie gewährleisten, daß ein privater Schlüssel nur vom späteren Besitzer
einsehbar wird und daß nur der Besitzer Zugriffs- und Benutzungsberechtigung auf seinen
privaten Schlüssel erhält.
– 28 –
2
2.6
TRUSTCENTER FLEXITRUST
Certificate Management Authority
Natürlich kommt der KA eine zentrale, weil sicherheitskritische Aufgabe zu. Da die KA jedoch
offline arbeitet, hat die CMA die wichtige Aufgabe die Erzeugnisse der KA zu veröffentlichen. Man kann also sagen, die CMA übernimmt die nach außen hin sichtbaren TrustCenterAufgaben, die schon in Abschnitt 2.1 aufgezeigt wurden.
Wie in Abbildung 6 erkennbar ist, ist die CMA also die Online-Schnittstelle nach außen und
zwar über die ihr direkt unterstehenden Dienste Directory Service und Time Stamp Service.
Über diese Dienste geschieht beispielsweise das Verschicken von Schlüsseln, Veröffentlichen
von Zertifikaten und Revokation von Zertifikaten. Hierbei muß erneut hervorgehoben werden,
daß diese Vorgänge automatisiert und sicher erfolgen sollen. Dabei ist selbstverständlich auch
eine Interaktion von CMA und KA notwendig, z.B. bei Problemen bzgl. eines bestimmten
Schlüsselpaares.
Des weiteren kommt der CMA eine wichtige Aufgabe während der Verteilung von privaten
Schlüsseln bzw. Aktivierung von Teilnehmerkonten der PKI zu. Da die Registrierung eines PKITeilnehmers meist in mehreren Schritten erfolgt, ist die Freischaltung eines Teilnehmerkontos,
was z.B. das PKI-Zertifikat oder den Teilnehmer-Entry (siehe Abschnitt 2.7) miteinschließt,
recht komplex. Denn dazu muß beispielsweise berücksichtigt werden, ob ein privater Schlüssel
erfolgreich und fehlerlos an die entsprechende Person ausgeliefert wurde (siehe z.B. [Kar04]
für weitere Details). Bei diesen Vorgängen ist eine Zusammenarbeit zwischen RA und CMA
unumgänglich, da der RA für ihre Aufgaben die Datenbank mit den Teilnehmerdaten untersteht. Zusammenarbeit ist allerdings nur indirekt über die KA, welche wiederum von der RA
initiiert wird, oder über die TrustCenter-Datenbank (siehe Kapitel 4) möglich.
2.7
Directory Service
Wie im vorherigen Abschnitt erläutert, hat die CMA die Aufgabe, TrustCenter-Leistungen nach
außen hin zugänglich zu machen. Dies geschieht allerdings nicht direkt, sondern über den der
CMA unterstehenden Verzeichnisdienst. TrustCenter-Aufgaben wie z.B. Verteilung öffentlicher Schlüssel und Veröffentlichung von Zertifikaten werden also durch den Verzeichnisdienst
ausgeführt.
Der Verzeichnisdienst bezieht seine Existenzberechtigung vor allem aus praktischen Gründen. Möchte man eine TrustCenter-PKI aktiv nutzen, also etwa eine eMail an einen anderen
PKI-Teilnehmer verschicken, benötigt man dessen öffentlichen Schlüssel bzw. dessen Zertifikat.
In manchen Fällen, z.B. wenn man die Person gut kennt, können direktere“ Wege zum
”
Austausch von Schlüsseln und Zertifikaten existieren, wie durch persönlichen Austausch, aber
oftmals ist dies nicht möglich und gerade bei großen sowie sich unbekannten Benutzergruppen
impraktikabel.
Daher benötigt man in der Praxis etwas zu einem Telefonbuch oder den Gelbe Seiten“
”
vergleichbares für PKIs, um seinen Kommunikationspartner bzw. dessen Zertifikat einfach
finden zu können: Den Verzeichnisdienst.
Bei PKIs muß man also auch vor Kommunikationsvorgängen eine Person bzw. deren Zertifikat mittels des Verzeichnisdienstes erst suchen und aufgrund von Revokationen auch stets
die weitere Gültigkeit von Zertifikaten, z.B. automatisiert, überprüfen, wobei Revokationslisten
ebenfalls über den Verzeichnisdienst bezogen werden.
– 29 –
2
2.7.1
TRUSTCENTER FLEXITRUST
Aufgabe von Verzeichnisdiensten
Die wesentliche Aufgabe eines Verzeichnisdienstes innerhalb einer Public Key Infrastruktur ist
es, z.B. über das Internet die Veröffentlichung von Teilnehmer-Zertifikaten vorzunehmen, und
damit einher geht selbstverständlich die Veröffentlichung von Revokations- bzw. Sperrlisten,
also von Certificate Revocation Lists (CRLs).
Allgemein haben Verzeichnisdienste folgende Eigenschaften26 :
• sie greifen auf Datenbanken zu und stellen selbst keine Datenbanken dar,
• ihre Struktur ist hierarchisch,
• Suchen und Lesen sind die am häufigsten benutzten Operationen.
Ein Verzeichnisdienst läßt sich also wie folgt charakterisieren: Er stellt eine Schnittstelle dar
zwischen Datenbank und Verzeichnis, er übernimmt die Aufbereitung und Bereitstellung der
Verzeichnisdaten, er stellt Zugriffs- und Suchmöglichkeiten von außen auf das Verzeichnis zur
Verfügung.
Es gibt einige Möglichkeiten einen Verzeichnisdienst für PKIs zu realisieren. Das hierfür
allerdings gängigste und dominanteste Protokoll für den Einsatz bei Verzeichnisdiensten ist
– trotz mancher praktischen Schwierigkeiten – das Lightweight Directory Access Protocol
(LDAP) bzw. der X.500 -Standard. Die Entwicklung und Eigenschaften dieses Protokolls, sollen
im Folgenden kurz erläutert werden.
2.7.2
DAP und X.500
Der Standard X.500 bezeichnet ein allgemeines Datenmodell, welches Informationen oder Daten in Form eines hierarchisch strukturierten Baumes anordnet. Hierbei handelt es sich um den
sogenannten Directory Information Tree (DIT), dessen Knoten als Entry bezeichnet werden.
Jeder Entry besteht aus einer Menge von Attributen und jedes Attribut wiederum besteht
aus dem Attribut-Typ und einem oder mehr Attributwerten. Des weiteren ist jeder Entry mit
einem eindeutigen Namen versehen, dem Distinguished Name (Details siehe Abschnitt 2.7.6),
welcher sich aus der hierarchischen Baumstruktur, nämlich aus allen Vorgängern eines Entrys
ableitet.
Dieser Baum aus dem X.500-Standard ist die allgemeine Definition eines Verzeichnisses
und ist folglich auch für die Nutzung außerhalb von PKIs geeignet. Ein gängiges Protokoll
zum Zugriff auf einen solchen DIT ist das Directory Access Protocol (DAP). In diesem auch
standardisierten Protokoll war bzw. ist die Unterstützung für PKIs bereits enthalten. Es definiert allgemein ausgedrückt die Kommunikation zwischen Directory User Agent (DUA) und
Directory System Agent (DSA), also z.B. Client und Server.
Das X.500-Modell hat eine Vielzahl von möglichen Anwendungen. Z.B. kann man damit ein
einfaches Benutzerverzeichnis realisieren mit Benutzerdaten wie etwa Adresse, Telefonnummer
und eMail-Adresse oder ein Druckerverzeichnis in einem Netzwerk mit Informationen über den
Standort, die Druckerart, den druckbaren Seiten pro Minute und Zugriffsrechten.
Auch ist es möglich den Directory Information Tree über mehrere Server zu verteilen, den
Verzeichnisdienst also als verteiltes System zu betreiben oder sinnvoll aufzuteilen. Dies ist vor
allem für TrustCenter und verteilte PKIs interessant.
26 Ein Beispiel für einen Verzeichnisdienst außerhalb von Kryptographie und PKIs ist das Domain Name System (DNS), welches
die Klartextnamen von Computern in IP-Adressen umsetzt etc.
– 30 –
2
2.7.3
TRUSTCENTER FLEXITRUST
LDAP und X.509
Da X.500 ein in der Praxis oft eingesetztes Datenmodell ist, sollten PKI-Verzeichnisdienste
auf dem X.500-Standard aufbauen. Dadurch entstehen jedoch einige praktische Probleme.
Man benötigt ein geeignetes Protokoll zur Kommunikation zwischen PKI-Client und Verzeichnisdienst bzw. -Server. DAP unterstützt zwar vollständig PKIs, ein Problem von DAP
allerdings ist dessen Inkompatibilität zum TCP/IP-Protokoll.
U.a. diese Probleme löst LDAP, welches sich aus DAP ableitet. Daher ist LDAP das in der
Praxis am meisten eingesetzte Protokoll für diese Art von PKI-Anwendung, was nicht zuletzt an
der vorhandenen und freien OpenSource-Implementierung des Standards liegt (siehe [Ope04]).
Durch den Zusammenhang zu DAP stellt der Zugriff auf X.500-Verzeichnisse kein Problem
dar.
Jedoch bestehen ebenfalls mit LDAP Probleme bei der Kommunikation innerhalb von PKIs,
welche die mittlerweile standardmäßig eingesetzten X.509v3-Zertifikate benutzen. Die Probleme rühren vom Vereinfachungsprozeß her, welcher von DAP zu LDAP stattfand, womit auch
die vollständige PKI-Unterstützung von DAP zu LDAP zunächst verloren ging. Dennoch sind
X.500 bzw. LDAP sehr stark verbreitete und genutzte Standards. Daher ist es natürlich sinnvoll, daß Verzeichnisdienste für PKIs auf diese zurückgreifen – was sie bereits auch tun, da
so keine grundlegende Erneuerung von Software-Infrastrukturen vonnöten ist. Systeme, welche
X.500 sowie LDAP auch außerhalb von PKI-Anwendungen nutzen und unterstützen, sind z.B.:
• IBM DB2 (Zugriff auf Verzeichnisdienste per LDAP),
• Microsoft Exchange (LDAP Directory Gateway),
• Microsoft Internet Explorer,
• Microsoft Windows 2000 Active Directory Service,
• Netscape Browser-Typen,
• Novell eDirectory (LDAPv3 in Netware 5 als Zugriffsprotokoll auf die NDS27 ),
• Siemens DirX.
Des weiteren läßt sich LDAP heute als Standard-Zugriffsmöglichkeit auf Verzeichnisdienste
auch über das Internet bezeichnen. Die Eigenschaften von LDAP in Kombination mit X.500
sind im Folgenden zusammengefaßt und überschneiden sich natürlich mit den bereits erläuterten Eigenschaften von DAP:
• LDAP setzt direkt auf TCP/IP auf,
• LDAP regelt die Kommunikation zwischen Client und X.500-Verzeichnisdienst (z.B. Suchfunktion),
• Daten sind als Entrys gespeichert,
• jeder Entry hat einen eindeutigen Distinguished Name,
• mit dem Distinguished Name ist der Entry im Verzeichnis eindeutig identifizierbar,
• X.509-Zertifikatsinhaber und -aussteller haben zusammenhängende Distinguished Names,
27 Die Netware Directory Services wurden für die Verwaltung eines Verzeichnisses für eMail-Adressen in Novell-Netzwerken
entworfen. Später entstand daraus eine dezentrale Datenbank für Benutzeraccounts, Zugriffsrechte etc.
– 31 –
2
TRUSTCENTER FLEXITRUST
• jeder Entry hat einen oder mehrere Attribute,
• jedes Attribut hat einen oder mehrere Werte (ungeordnete Menge),
• jeder Entry muß das Attribut objectClass besitzen,
• objectClass definiert sozusagen den Entry,
• Zertifikate sind über das Attribut userCertificate als Binärdaten zugänglich.
Abbildung 7: Auszug aus dem LDAP-Tree am Fachbereich Informatik der TUD
Abbildung 7 zeigt ein Beispiel für einen LDAP-Tree bzw. -DIT, wie er am Fachbereich 20 der
TUD vorkommt. Ein Beispiel für einen hieraus abgeleiteten Distinguished Name ist:
C=DE, O=TUD, OU=FB20, OU=cdc, CN=Vangelis Karatsiolis
Man beachte, daß ein Entry selbstverständlich aus vielen Attributen und nicht nur aus dem
Distinguished Name besteht. Ein Blatt-Entry, also ein Entry auf der CN-Ebene, könnte auch
Attribute bzw. Felder mit spezifischeren Informationen zum Zertifikat bzw. zur CRL enthalten,
z.B. eMail-Adresse“, Telefonnummer“, Gültigkeitszeitraum“ oder Issuer“. Denn wenn das
”
”
”
”
Verzeichnis beispielsweise mit Attribute Extraction erstellt wurde, sucht LDAP in den EntryAttributen. In jedem Falle beinhaltet der Entry das Attribut userCertificate mit einem Wert
bestehend aus Binärdaten, welche das Zertifikat des PKI-Benutzers darstellen. Dieses wiederum
enthält ebenfalls den Distinguished Name, wie z.B. in Abbildung 5 zu sehen.
Es ist überlegenswert, zusätzliche Daten wie Postadresse oder Telefonnummer in einen
Verzeichnis-Entry einzufügen. Dies obliegt natürlich der jeweiligen Certification Authority. Allerdings ist es nicht praktikabel solche Daten in ein Zertifikat zu integrieren, in ein VerzeichnisEntry könnte man diese jedoch durchaus einbetten.
– 32 –
2
TRUSTCENTER FLEXITRUST
An dem konkreten Beispiel eines LDAP-Trees aus Abbildung 7 erkennt man das modellierte hierarchische Vertrauen, z.B. könnte eine TUD-Certification Authority den Fachbereich
zertifizieren usw. Dennoch ist beispielsweise auch Cross-Zertifizierung 28 möglich, da die Verzeichnisstruktur bzw. der Verzeichnisdienst nur dafür sorgt, daß PKI-Teilnehmer schnell und
eindeutig gefunden werden können und dies unabhängig von der Policy der jeweiligen PKI.
Zu beachten ist, daß innerhalb der PKI der Verzeichnisdienst als unsicher bzw. als potentieller Angriffspunkt angesehen wird. Daher wird jede über ihn veröffentlichte Revokationsliste,
also CRL von der zuständigen CA signiert, um die Gültigkeit und Korrektheit der Liste zu
garantieren. Denn nur der CA wird vertraut – nicht etwa auch dem Verzeichnisdienst – und
die veröffentlichten Zertifikate sind ohnehin von der CA ausgestellt sowie signiert.
Der Vorgang des Findens eines richtigen und gesuchten Zertifikats ist unter PKI-Gesichtspunkten also nicht trivial. Denn es ist eher impraktikabel, etwa bei Attribute Extraction (siehe
Abschnitt 2.7.4) jeden Verzeichnis-Entry zu signieren. D.h., beim Auffinden eines Zertifikats
in einem Verzeichnis muß stets überprüft werden, ob es sich dabei auch um das gesuchte
Zertifikat handelt29 .
Leider hat jedoch LDAP das Problem, daß es grundsätzlich keine Zertifikat- bzw. CRLSuche unterstützt nach einem einfach Schema wie: Bitte das Zertifikat zu dem Teilnehmer mit
”
der eMail-Adresse [email protected]“ o.ä. Und dies obwohl X.509v3-Zertifikate eine
Komponente SubjectAltName enthalten, wo diese eMail-Adresse exakt vorkommen könnte.
Das Problem rührt daher, daß keine Unterstützung in LDAP existiert, um die Attribute eines
X.509v3-Zertifikats – und somit die darin enthaltenen Informationen – sozusagen als Attribute
des Verzeichniseintrages sichtbar bzw. zugreifbar zu machen.
2.7.4
LDAP Lösungen
In Folgenden werden Details zu LDAP, LDAP-Versionen sowie zu praktischen Problemen und
Lösungen erläutert, die immer zum Ziel haben, die Verwaltung von und vor allem die Suche
nach Zertifikaten mit LDAP zu realisieren.
Die Probleme mit LDAP und PKI-Zertifikaten beruhen hauptsächlich darauf, daß obwohl
X.509 und X.500 zur selben Familie von Standards gehören, grundlegende Probleme mit der
Codierung von LDAP und X.509-Zertifikaten bestehen.
Während Zertifikate ASN.1 codiert30 sind, werden bei LDAP einfache ASCII-Strings benutzt. Natürlich lassen sich diese Formate grundsätzlich in einander überführen. Dennoch
stellten sich in der Praxis einige schwerwiegende Probleme mit solchen Verfahrensweisen heraus (siehe z.B. [Cha03-1] und [Cha03-2]).
Die Probleme rührten u.a. daher, daß es an Unterstützung seitens vieler Firmen fehlte, einen
gemeinsamen Standard zu entwickeln. So wies beispielsweise der Browser Netscape Communicator massive Fehler im Umgang mit Zertifikaten auf oder Microsoft unterstützte Bestrebungen
der PKIX Working Group im RFC-Standardisierungsprozeß für die IETF nicht.
Unabhängig von Standardisierungsprozessen und Modifikationen am LDAP-Protokoll selbst
existieren Bemühungen, das OpenLDAP-Projekt (siehe [Ope04]) über LDAP hinaus so zu
erweitern, daß die Suche nach X.509v3-Zertifikaten erleichtert wird. Die hierbei auf diese
28 Ein
Beispiel für Cross-Zertifizierung wäre die gegenseitige Zertifizierung der TUD-CA und der CA der Universität von Hawaii.
mögliche Attacke wäre, daß sich ein Angreifer Schreib-Zugriff auf das Verzeichnis verschafft und es ihm auf diese Weise
gelingt, Entrys zu modifizieren. So ist es ihm zwar nicht möglich, Zertifikate zu fälschen, aber u.U. kann er z.B. sein Zertifikat
in den Entry eines anderen PKI-Teilnehmers einfügen oder eine Zertifikatssuche auf seinen Verzeichnis-Entry umleiten, indem er
falsche Werte in diesen einfügt. Für einen solchen Angriff müßte er natürlich selbst Teilnehmer der PKI sein und ein von der
passenden CA ausgestelltes Zertifikat besitzen.
30 Mit Codierung ist in diesem Falle selbstverständlich nicht Verschlüsselung im kryptographischen Sinne gemeint, sondern
schlicht das Format zur Datenübertragung.
29 Eine
– 33 –
2
TRUSTCENTER FLEXITRUST
Weise entstandenen Lösungsansätze wurden größtenteils auch in Standards gefaßt bzw. in den
LDAP-Standard integriert.
Es gibt also einige Lösungen, welche in verschiedenen Bereichen stattfinden (siehe u.a.
[Cha03-1] und [Cha03-2]): Spezifizierung von Standards und Quasi-Standards sowie Implementierungsalternativen in OpenLDAP. Auf diese Weise existieren zwar verschiedene Lösungsmöglichkeiten, andererseits besteht dadurch das Problem, daß sich diese inklusive ihrer Nachteile
auch durchsetzen und sich mindestens die wichtigen Hersteller von PKI- bzw. LDAP-Produkten
auf bestimmte gemeinsame Lösungen einigen müssen, um Kompatibilitätsprobleme zu vermeiden.
Das OpenLDAP-Projekt (siehe [Ope04]) bietet jedoch einen guten Ansatz für die Umsetzung von LDAP- bzw. X.500-Servern und bleibt auch weitestgehend kompatibel mit vorhandenen LDAP- bzw. PKI-Clients.
Daher entschied die IETF 2003, daß zwei aktuelle Lösungen, welche sich in OpenLDAP
etabliert haben, Standard-Lösungen sein sollen. Bei diesen gibt es vor allem große Unterschiede
in der Art der Datenhaltung (siehe auch Abschnitt 4.1).
Component Matching soll dabei der Standard-Weg überhaupt werden, um nach X.509v3Zertifikaten in einem Verzeichnis zu suchen. Denn dieser Ansatz ist sehr elegant, da keine
gesonderte Datenpflege für das Verzeichnis nötig und eine Zertifikatssuche direkt auf den
Zertifikatsattributen ausgeführt wird.
Bis sich allerdings Component Matching in den Implementierungen von vorhandenen Servern und Clients durchgesetzt hat – wenn überhaupt, ist Attribute Extraction in Kombination
mit dem X.509-attribute Parsing Server eine äußerst brauchbare, weil auch leicht umzusetzende Lösung, und für vorhandene Server und Clients werden damit keine Software-Updates
nötig.
Component Matching
Beim Component Matching werden Zertifikate direkt in dem Verzeichnis-Entry oder in unterschiedlichen Verzeichnis-Entrys des jeweiligen Teilnehmers abgelegt. Die Suche nach Zertifikaten erfolgt dann direkt auf dessen ASN.1-codierten Feldern bzw. Komponenten, also auf dem
Binärwert des LDAP-Verzeichnisses, welcher das Benutzer-Zertifikat darstellt.
Hier ist zu überlegen, ob es sinnvoll ist, daß man nur nach Attributen im Zertifikat und nicht
nach zusätzlichen Informationen, welche nicht im Zertifikat enthalten sind, suchen kann. Um
dies zu realisieren, müßte man auf dem Zertifikat und dem Verzeichnis-Entry suchen können.
Attribute Extraction
Bei der Attribute Extraction werden die Attribute eines Zertifikats extrahiert, also aus dem
Zertifikat ausgelesen und als zusätzliche Attribute in dem jeweiligen Verzeichnis-Entry abgelegt. Damit werden die Informationen aus den Attributen des Zertifikats für jeden LDAPClient lesbar, womit ebenfalls eine einfache LDAP-Suche und erfolgreiche Zertifikatsrückgabe
möglich wird. Unterstützt wird dieser Vorgang vom X.509-attribute Parsing Server (XPS),
der es möglich macht die Attributsextraktion und separate Speicherung automatisiert durchzuführen.
Der Nachteil ist offensichtlich die notwendige Aufbereitung der Daten, also die zusätzlich
nötige Datenpflege (Zertifikatsattribute und Entry-Attribute müssen übereinstimmen), wenngleich man durch den XPS dabei natürlich unterstützt wird.
Ein weiterer möglicher Nachteil ist allerdings die notwendige doppelte Datenhaltung. Da
es nicht möglich ist, über LDAP auf eine fremde relationale Datenbank (siehe Kapitel 3) zu
– 34 –
2
TRUSTCENTER FLEXITRUST
zugreifen, muß die Certification Authority die Daten bzw. Attribute und Attributswerte in ihrer
eigentlichen Datenbank und somit in den Zertifikaten sowie zusätzlich im Verzeichnis, welches
sie ebenfalls verwaltet, halten (siehe Abschnitt 4.1).
Außerdem ist die LDAP-Suche u.U. beschränkt, da diese nur nach den extrahierten und in
den Entrys eingefügten Attributen möglich ist.
2.7.5
Multiple Zertifikate
Bei PKIs in der heutigen Zeit kommt es sehr oft vor, daß ein PKI-Teilnehmer mehrere Zertifikate
besitzt. Die Gründe dafür sind verschieden, z.B.:
• Aus Sicherheitsgründen benötigt ein Teilnehmer für Verschlüsselung und Signatur verschiedene Schlüsselpaare und somit Zertifikate.
• Ein Teilnehmer ist in mehreren Organisationen tätig oder benutzt mehrere Applikationen.
Es gibt nun verschiedene Möglichkeiten, wie man in einem PKI-Verzeichnis mit mehreren
Zertifikaten pro Teilnehmer umgehen kann. Man beachte dabei, daß es immer noch einfach
möglich sein soll, für eine bestimmte Kommunikation das passende Zertifikat innerhalb des
Verzeichnisses zu finden.
Die erste Idee ist natürlich, alle Zertifikate eines Teilnehmers in dessen LDAP-Entry abzulegen. Denn das Attribut userCertificate kann offensichtlich in Übereinstimmung mit dem
LDAP-Standard mehrere Werte und somit Zertifikate enthalten. Das Problem hierbei ist, daß
den Werten bzw. Zertifikaten keine Eigenschaften zugeordnet werden können, da sie nur als
ungeordnete Menge angesehen werden. Damit sind sie für die Attribute Extraction nicht unterscheidbar.
Eine weitverbreitete Lösungsmöglichkeit ist, den LDAP-Entry zu erweitern und zwar um
das Attribut certificateType sowie in einem LDAP-Entry nur ein Zertifikat zu halten. Für den
X.500-Baum bzw. das X.500-Verzeichnis gibt es dann drei mögliche Arten des Aufbaus.
• Subeinträge: Ein PKI-Teilnehmer erhält ein Verzeichnis-Entry mit seinen Daten und die
verschiedenen Zertifikate befinden sich in Untereinträgen.
• Geschwistereinträge: PKI-Teilnehmer erhalten mehrere parallele Verzeichnis-Entrys, welche jeweils deren Daten und das jeweilige Zertifikat enthalten.
• Applikationsbasierte Einträge: Der Verzeichnisbaum wird nach Anwendungen organisiert.
Dabei erhält ein Teilnehmer ebenfalls mehrere Einträge je nach Anwendung.
Auch existieren viele Lösungsansätze für verteilte Systeme, und LDAP macht es sogar möglich,
mehrere PKIs bzw. PKI-Server mit einander zu verbinden.
2.7.6
Distinguished Names
Die DNs haben, wie im vorherigen Abschnitt gesehen, ihren Ursprung beim Aufbau eines
Verzeichnisdienstes. Bei TrustCentern kommt ihnen zusätzlich eine essentielle Aufgabe zu,
nämlich die Verknüpfung von PKI-Zertifikaten und den Registrierungsdaten bzw. TeilnehmerIdentitäten zu gewährleisten.
Daher finden Distinguished Names besondere Beachtung. Denn u.U. muß nicht nur die
Gültigkeit einer digitalen Signatur über ein bestimmtes Dokument sondern auch der Urheber
der Signatur gerichtlich nachweisbar sein. Daher ist die Eindeutigkeit der Suchkriterien und
der Distinguished Names essentiell. Wünschenswerte Eigenschaften von guten Distinguished
Names sind die Folgenden:
– 35 –
2
TRUSTCENTER FLEXITRUST
• Einzigartig bzw. einmalig,
• registriert (z.B. Internet-Domains),
• benutzerfreundlich31 .
Man beachte, daß Distinguished Names innerhalb von PKIs mittlerweile eine etwas andere
Bedeutung haben als bei reinen Verzeichnisdiensten. So kann es durchaus vorkommen, daß ein
PKI-Teilnehmer mehrere Distinguished Names innerhalb dieser PKI besitzt. Die Einzigartigkeit
bzw. Einmaligkeit eines Distinguished Names bedeutet hier jedoch die eindeutige Zugehörigkeit
zu einem Registrierungsdatensatz bzw. einer Identität.
Abbildung 8 zeigt ein übliches Beispiel für die Vergabe von Distinguished Names – in diesem
Falle bei der Rechnerbetriebsgruppe (RBG) des Fachbereich 20 an der TUD. Ein Zertifikat
mit Distinguished Names war bereits in Abbildung 5 zu sehen ebenso wie in Abbildung 7 ein
LDAP-Verzeichnisbaum mit Distinguished Names.
Name der Baumebene
Bedeutung, engl. Beschreibung
C
Country
DE
O
Organization
TU Darmstadt
OU
Organizational Unit
FB Informatik
OU
Organizational Unit
Kürzel des Fachgebiets
CN
Common Name
Titel, Vorname und Nachname
Abbildung 8: Namensgebung der PKI am Fachbereich Informatik der TUD
2.8
Time Stamp Service
Der TSS gewährleistet das Schutzziel der Datiertheit (siehe Abschnitt 1.1.1). Betroffen sind
hier beliebige Dokumente, die von einem PKI-Teilnehmer an das TrustCenter gesendet werden
können, welches wiederum das entsprechende Dokument signiert (siehe Abbildung 4) und dabei
zusätzlich eine Zeitangabe, z.B. 25.08.2004 20:14:56, einfügt.
Selbstverständlich läßt sich auch ein vom PKI-Teilnehmer signiertes Dokument mit einem
solchen Zeitstempel versehen. Aufgrund der Verwendung der digitalen Signatur ist somit durch
das TrustCenter als Vertrauensinstanz gewährleistet, daß zu einem bestimmten Zeitpunkt ein
bestimmtes Dokument vorlag evt. mit auch vorhandener Verfasser-Signatur.
31 In der Benutzerfreundlichkeit bei DNs findet sich sicher auch die Nachvollziehbarkeit von TrustCenter-Vorgängen wieder. Ein
lesbarer Name als Bestandteil in einem DN eines Zertifikats ist ein Beispiel für Benutzerfreundlichkeit im Gegensatz zu einem
bestimmten Nummerncode, da mit einem Namen für einen anderen PKI-Teilnehmer eine gewisse Bedeutung verbunden ist.
– 36 –
3
Einführung in Datenbanksysteme
Dieses Kapitel dient als Einführung in das Gebiet der Datenbanksysteme (DBS) und kann
es demnach nicht vollständig erfassen. Daher wird nur auf die für diese Arbeit notwendigen
Aspekte eingegangen, angefangen bei elementaren Sachverhalten.
3.1
Grundlagen Datenbanksysteme
Eine Datenbank ist folgendermaßen definiert als: Eine einheitlich beschriebene Darstellung
”
eines Weltausschnittes mittels diskreter Daten auf externen und persistenten Speichermedien.“
Dies mag eine recht abstrakte Definition sein, sie trifft allerdings den Kern.
Denn im wesentlichen geht es bei Datenbanksystemen um die Persistierung von Daten, d.h.
um deren Dauerhaftigkeit. In einem einfachen Falle wird diese durch das Abspeichern in einer
Datei auf der Festplatte, welche ein persistentes Speichermedium darstellt, gewährleistet. Im
Falle von Datenbanksystemen sind die Daten jedoch zu komplex, als daß man diese auf simple
Weise in Dateien speichern könnte. Daher erfolgt die Bearbeitung einer Datenbank nicht direkt
sondern ausschließlich über das Datenbank Management-System (DBMS).
Damit ist sichergestellt, daß mehrere Anwendungen bzw. Benutzer gleichzeitig auf eine
Datenbank, also gemeinsame Datenbestände zugreifen und diese verändern können, ohne daß
es zu Konflikten oder Kollisionen kommt. Datenbanken haben schließlich den Zweck für mehrere verschiedene Anwendungen und Benutzer auch bei verteilten Systemen, Daten und somit
Informationen zur Verfügung zu stellen.
Ein Datenbanksystem hat nach außen hin gesehen im Wesentlichen folgende Bestandteile:
• Datenbank Management-System,
• Query-Sprache (Daten-Zugriff, Daten- und Struktur-Bearbeitung),
• Datenmodell (Repräsentation der Daten).
3.2
Datenbank Management-System (DBMS)
In Abbildung 9 ist die Struktur eines DBMS zu sehen, hier nur aus Gründen der Vollständigkeit.
Die Eigenschaften eines DBMS lassen sich folgendermaßen zusammenfassen:
• Datenunabhängigkeit,
• Effizienter Zugriff,
• Mehrbenutzerbetrieb (Concurrency Control),
• Persistenz der Daten,
• Query-Sprache und Query-Optimierung (siehe Abschnitt 3.5),
• Sicherheit bei bzw. vor Fehlern und Abstürzen (Recovery/Backup),
• Umgang mit Transaktionen (siehe Abschnitt 3.3),
• Verwaltung der Daten,
• Verwendung von Konsistenzregeln (z.B. auch Redundanzvermeidung),
• Zugriffskontrolle.
– 37 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Abbildung 9: Struktur eines Datenbank Management-Systems
Für viele Anwendungen und Systeme sind diese Eigenschaften nicht zu ersetzen. Ein einfaches
Dateisystem beispielsweise kann die meisten dieser Merkmale nicht bereitstellen, wie etwa
Datenunabhängigkeit.
Natürlich hat die Verwendung von DBMSs auch Nachteile:
• Allgemeine DBMSs weniger effizient als spezialisierte Software,
• Optimierung nicht für alle konkurrierenden Anwendungen möglich,
• Overhead an Funktionen (u.U. nicht benötigte Funktionen),
• Personal mit speziellen Qualifikationen nötig.
3.2.1
Datenunabhängigkeit
Wenn verschiedene Anwendungen auf dieselbe Datenbank zugreifen, möchte man, daß diese
vollständig unabhängig von einander arbeiten können. Daher erhält jede eine individuelle Sicht
auf diese Datenbank. Auch sollen die Anwendungen nicht davon beeinflußt werden, wenn sich
– 38 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Strukturen an der bzw. um die Datenbank ändern. Jedes Datenbanksystem bietet dazu zwei
Formen von Datenunabhängigkeit.
• Physische Datenunabhängigkeit: Werden Zugriffswege und Speicherstrukturen der Datenbank modifiziert, sind Anwendungen davon unbeeinflußt.
• Logische Datenunabhängigkeit: Wird die logische Struktur (siehe Abschnitt 3.4.1) der
Datenbank modifiziert, sind auch davon Anwendungen unbeeinflußt.
3.3
Transaktionen
Als Transaktionen bezeichnet man minimale Prozeßeinheiten eines Datenbanksystems und
sie überführen dieses per Definition stets von einem konsistenten Zustand in einen anderen
konsistenten Zustand. Das bedeutet, eine Transaktion kann sozusagen eine Datenbank nicht
zerstören oder Daten ungültig machen und beeinflußt keine andere Transaktion. Folglich sieht“
”
eine Transaktion die Datenbank auch immer nur in einem konsistenten Zustand.
Eine Transaktion selbst besteht aus einer Abfolge von elementaren Befehlen bzw. Operationen. Dabei sind Transaktionen sehr gut steuerbar, der Anfang einer Transaktion ist stets
mit Begin Of Transaction (BOT) das Ende mit End Of Transaction (EOT) im System gekennzeichnet. Des weiteren werden Änderungen, die von Transaktionen an der Datenbank
vorgenommen werden, erst nach dem abschließenden Commit sichtbar bzw. dauerhaft (persistent). Das Commit ist immer der letzte Befehl in einer Transaktion mit einer Ausnahme,
dem Abort. Der Abbruch einer Transaktion kann viele Gründe haben, z.B. Konflikt mit einer
anderen Transaktion, und ist bis zum Commit möglich.
Datenbank Management-Systeme steuern und verwalten Transaktionen. Dabei gewährleisten sie, daß für jede Transaktion die ACID-Eigenschaften gelten. Dieses Akronym leitet sich
aus dem Englischen ab und wird im Folgenden erläutert.
• Atomarität: Eine Transaktion wird vollständig oder gar nicht ausgeführt.
• Konsistenz: Transaktionen erzeugen keine inkonsistenten Datenbankzustände.
• Isolation: Erst nach der Beendigung einer Transaktion wird dessen Änderung sichtbar.
• Dauerhaftigkeit: Änderungen, die von Transaktionen vorgenommen werden, sind permanent.
Bei teilweiser Umgehung des DBMS, also etwa beim direkten Zugriff auf die Datenbank selbst,
sind offensichtlich diese Eigenschaften nicht gewährleistet.
Der Vorteil bei Verwendung von Transaktionen ist zum einen aus den ACID-Eigenschaften
ersichtlich. Zum anderen kann ein DBMS viele Eigenschaften aus Abschnitt 3.2 nur unter der
Verwendung von Transaktionen gewährleisten, z.B. Concurrency Control oder Recovery.
3.3.1
Trigger und Coupling Modes
Trigger sind eine bei gewissen Anwendungen äußerst wichtige Möglichkeit, um Transaktionen
unter bestimmten Bedingungen auszulösen. Es ist z.B. bei Aktiven Datenbanken und Real-time
Datenbanken32 möglich, auf vorgegebene Datenbank-Zustände zu reagieren. Dabei kann genau
32 Oftmals wird der Begriff der Echtzeit mit Effizienz bzw. hocheffizienten Rechensystemen gleichgesetzt. Dies ist jedoch falsch,
wenngleich Echtzeit-Systeme meist hocheffizient arbeiten können müssen. Jedoch ist ein Echtzeit-System lediglich allgemein definiert als ein System, bei welchem die Korrektheit einer Berechnung nicht nur vom richtigen Ergebnis an sich abhängt sondern
ebenfalls von der Rückgabe des Ergebnisses in einer vorgegebenen Zeit bzw. Deadline. Eine Überschreitung dieser Deadline kann ne-
– 39 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
festgelegt werden, wie und wann diese Reaktion, also das Auslösen einer Transaktion erfolgen
soll. Durch Coupling Modes wiederum läßt sich festlegen, auf welche Weise Transaktionen
zueinander ausgeführt werden sollen, z.B. nacheinander oder parallel, aber auch Forderungen
wie gleichzeitige Beendigung o.ä. sind möglich.
Für weitere Details auch zu den Themen Aktive Datenbanken und Real-time Datenbanken
sei auf das Literaturverzeichnis (ab Seite 119) verwiesen.
3.3.2
Concurrency Control
Das Concurrency Control hat im DBMS eine essentielle Aufgabe und untersteht dem Scheduler (siehe Abbildung 9). Dieser übernimmt die Planung sowie Optimierung des Ablaufs von
anstehenden Transaktionen und sorgt vor allem für eine fehlerlose Ausführung.
Dabei werden Transaktionen oder Teile von Transaktionen häufig parallel ausgeführt – je
nach Correctness Criteria, wonach sich eine gültige Abfolge dieser richtet.
Um Konflikte bei der Transaktionsausführung zu vermeiden, zu erkennen sowie aufzulösen,
ist die Verwaltung, also Sperrung sowie Zuteilung von Systemressourcen, z.B. Datenbank- oder
Speicherbereichen, unumgänglich und ebenfalls Aufgabe des Schedulers.
Zu den Themen Concurrency Control und Correctness Criteria existieren reichlich Theorien
und Abhandlungen, da diese Themen äußerst komplex sind. Für weitere Details sei auf das
Literaturverzeichnis (ab Seite 119) verwiesen.
3.3.3
Recovery und Backup
Der Recovery Manager (siehe Abbildung 9) sorgt dafür, daß eine Datenbank immer in einem
konsistenten Zustand bleibt, auch bei schweren Fehlern wie z.B. einem Systemabsturz.
Dazu muß der Recovery Manager u.a. Logs führen, also Protokolldaten über jegliche Transaktionen festhalten, z.B. über die vorgenommenen Änderungen. Damit ist es möglich, Transaktionen rückgängig zu machen, welche abgebrochen wurden oder Transaktionen erneut auszuführen bzw. abzuschließen.
Bei Main Memory-Datenbanksystemen, also bei hocheffizienten Datenbanksystemen, welche auf speziellen Rechnern laufen und sich vollständig im Hauptspeicher befinden, läßt sich
der Recovery Manager mit seinen Aufgaben als Bottleneck, also als stark ineffizienter Systemteil bezeichnen. Denn auch oder gerade bei Main Memory-Datenbanken muß deren Konsistenz
sichergestellt sein, was natürlich nur durch das zusätzliche Absichern der Protokolldaten und
auch der Datenbank auf einen Festspeicher möglich ist.
Wie beim Concurrency Control existieren zum Thema Recovery reichlich Theorien und
Abhandlungen. Für weitere Details sei auf das Literaturverzeichnis (ab Seite 119) verwiesen.
3.4
Datenmodelle
Der Sinn und Zweck von Datenbanken ist es, Informationen (dauerhaft) zu speichern und
einen einfachen Zugriff auf diese zu gewährleisten. Nun ist der Begriff der Information nicht
weniger abstrakt als der Begriff der Daten, dennoch müssen Informationen oftmals auf eine
Datenbank abgebildet werden.
Um Informationen in einer Datenbank sinnvoll aufzubewahren, müssen zunächst die zu
speichernden Daten ausgewählt werden. Grob ausgedrückt müssen die für eine Datenbank
gative (Soft Real-time) oder verheerende (Hard Real-time) Folgen haben. Ein Echtzeit-System garantiert also die Ausführungszeit
bzw. Deadline für einen einzelnen Prozeß. Dem hingegen bietet ein hocheffizientes Rechensystem eine schnelle durchschnittliche
Ausführungszeit.
– 40 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
geeigneten Daten in tabellarischer Form darstellbar sein. Es macht z.B. wenig Sinn, einen
Brief in einer Datenbank zu speichern. Hingegen kann die Indexierung vieler Briefe auch von
einer Datenbank übernommen werden. Man beachte, daß z.B. auch Daten von Straßenkarten
oder ähnlich große Datenmengen in Datenbanken abgelegt werden können.
Daten sind also die essentiellen Teile einer Information und um sie in einer Datenbank entsprechend abbilden zu können, benutzt man ein passendes Datenmodell. Zusammenhängende
Daten werden als Datensatz oder auch Tupel bezeichnet.
3.4.1
Grundlagen von Datenmodellen
Ein Datenmodell entsteht allgemein aus drei Bestandteilen:
• Logische Struktur(en),
• Operatoren,
• Korrektheitsbedingungen.
Die logischen Strukturen fügen den Daten eine gewisse Semantik hinzu, wobei es sich hierbei
um eine statische Eigenschaft des Datenmodells handelt (als Beispiel siehe Abbildung 10).
Hingegen handelt es sich bei den Operatoren um sog. dynamische Eigenschaften, da sie Änderungen an den Daten ermöglichen.
Korrektheitsbedingungen oder Constraints sorgen für syntaktische sowie semantische Korrektheit der Operatoren und somit der Daten. Mit Hilfe von Korrektheitsbedingungen wird es
dem DBMS also möglich, Daten auf z.B. erlaubte Wertebereiche zu prüfen.
Für die Erstellung von Strukturen bzw. Strukturmanipulation wird eine Data Definition Language (DDL) verwendet. Die Datenmanipulation, also das Ausführen von Operatoren erfolgt
über eine Data Manipulation Language (DML). Zugriffe auf, also das Abfragen von Daten
erfolgt über eine Query Language (QL) bzw. eine Query.33 Die gängigste Sprache, welche
auch DDL, DML und QL in sich vereint, ist SQL (siehe Abschnitt 3.5).
Einnahmen EUR Ausgaben EUR Jahr
300000 400000 2001
280000 300000 2002
310000 300000 2003
ohne Struktur
300000
400000
2001
280000
300000
2002
310000
300000
2003
mit Struktur
Abbildung 10: Daten ohne und mit Struktur
3.4.2
Objekte und Konstruktoren
Der Begriff der Objekte ist vor allem bekannt aus der objektorientierten Programmierung.
Ebenso existiert bei Datenbanksystemen der Begriff des Objekts bzw. der Objektinstanz. Dabei
handelt es sich um einen einzelnen konkreten Datensatz, der aber auch verteilt sein kann.
Datensätze selbst bestehen aus Merkmalen bzw. Feldern bzw. Attributen. Ein Objekttyp
oder auch Klasse ist daher allgemein eine definierte Menge von Attributen.
33 Bei Query handelt es sich um einen üblichen Begriff. Eine mögliche deutsche Entsprechung ist Abfrage, welche auch z.B. von
Microsoft bei deutschen Softwareversionen, etwa von Microsoft Access, genutzt wird.
– 41 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Ein Beispiel für einen Objekttyp wäre Filme(Titel,Regisseur,Komponist)“, für ein Ob”
jekt hierfür ’Forrest Gump’;’Robert Zemeckis’;’Alan Silvestri’“ und wiederum für ein Attribut
”
hierfür Komponist“, wobei Alan Silvestri“ einen Attributswert darstellt.
”
”
Ähnlich wie bei der objektorientierten Programmierung erstellt man auch bei Datenmodellen
komplexe Objekttypen aus weniger komplexen. Dabei werden Attributen zunächst elementare
Datentypen zugewiesen, z.B. INTEGER oder CHARACTER.
Komplexere Objekttypen werden durch die Konstruktoren Aggregation und Assoziation gebildet. Aggregationen erfolgen durch die Gruppierung von verschiedenen Attributen oder bereits
erstellter Objekttypen, z.B. Name(CHARACTER)“ sowie Vorname(CHARACTER)“ zu Kompo”
”
”
nist(Name,Vorname)“ usw. wiederum zu Filme(Titel,Regisseur,Komponist)“. Assoziationen
”
hingegen sind Mengenaggregationen, werden also aus mehreren gleichartigen Objekten zusammengesetzt, z.B. Kameramann(Name,Vorname)“ zu Film Kamerateam(Kameramann)“.
”
”
Es gibt auch Typen bzw. Attribute, die aus vorhandenen abgeleitet und nicht explizit abgespeichert werden. So wird z.B. das Alter einer Person meist in einer Personendatenbank nicht
gespeichert sondern nur das entsprechende Geburtsdatum. Das aktuelle Alter errechnet sich
dann offensichtlich erst aus der Differenz zwischen aktuellem Datum und Geburtsdatum.
Weitere gängige Begriffe, die gerne an Stelle von Objekt und Objekttyp verwendet werden,
sind Entity und Entity-Typ, meinen aber dasselbe. Ein Objekttyp läßt sich allerdings auch
schlicht als Tabelle bezeichnen bzw. ansehen.
3.4.3
Beziehungen
Beziehungen sind ein zentraler Aspekt eines jeden Datenmodells. Selten ist es sinnvoll, alle Daten einer Datenbank in einer Tabelle zu speichern. In Abbildung 11 ist eine Tabelle zu sehen,
welche bei einer größeren Anzahl an Datensätzen bzw. Zeilen sowie Attributen bzw. Spalten verschiedene Nachteile durch Redundanz hat, wie Speicherverschwendung und schwierige
Datenpflege (z.B. bei Datenänderungen).
Daher ist es sinnvoll, die Tabelle T CDCollection“ in diesem Falle aufzubrechen bzw.
”
aufzuteilen und zwar in zwei Tabellen T Album(*AlbumID,Artist,Album,Label,Year,Genre)“
”
sowie T Song(AlbumID,Song,Time,No)“.
”
T CDCollection
Song
Artist
Time Album
No Label Year Genre
Theme from Goldfinger Cincin.Pops 02:32
Bond And Beyond
1 Telarc
1991
Orch.
James Bond Theme
Cincin.Pops 02:20
Bond And Beyond
2 Telarc
1991
Orch.
From Russia With Love Cincin.Pops 02:40
Bond And Beyond
3 Telarc
1991
Orch.
So excited
B.B.King
05:12
Completely Well
1 MCA
1982
Blues
No good
B.B.King
04:58
Completely Well
2 MCA
1982
Blues
You’re losin’ me
B.B.King
03:33
Completely Well
3 MCA
1982
Blues
Abbildung 11: Nicht-verteilte Tabelle
Zwischen den beiden neuen Tabellen besteht nun eine Beziehung durch das neu eingeführte Attribut AlbumID“, welches den Primärschlüssel (siehe Abschnitt 3.4.5) in der Relation
”
T Album“ darstellt und ebenso für T Song“ als Verweis auf bzw. Verknüpfung zu T Album“
”
”
”
dient, wobei hier offensichtlich auch die Umkehrung gilt. Auf diese Weise läßt sich ebenfalls
die alte Tabelle T CDCollection“ wiederherstellen (siehe auch Abschnitt 3.5.1).
”
– 42 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Bei einem solchen Vorgang des Aufteilens ist stets zu beachten, daß dabei Information
verloren geht, die im Beispiel durch die Einführung des neuen Attributs AlbumID“ kompen”
siert wurde. Derartige Neueinführungen sind nicht zwangsläufig, dennoch oftmals nötig. Des
weiteren existieren sogenannte Normalformen, die solche Aufteilungen in bestimmte Kategorien einordnen und klassifizieren. Für weitere Details zu Normalformen sei allerdings auf das
Literaturverzeichnis (ab Seite 119) verwiesen.
3.4.4
Relationale Datenbanken
Ein sehr einfaches, weil graphisches Datenmodell ist das Entity-Relationship Modell (ERM).
In Abbildung 12 ist ein konkretes, aber vereinfachtes Beispiel für ein ERM-Datenmodell einer
Banken-Datenbank zu sehen. Im Vergleich zum Beispiel aus Abbildung 11 (siehe auch Abschnitt 3.4.3) ist hier eine sinnvolle Verteilung der Daten über mehrere Entitys vorhanden. Die
Elemente dieses Datenmodells haben die folgende Bedeutung:
• Rechtecke sind Objekttypen,
• Quadrate sind Beziehungen bzw. Relationships,
• Ellipsen sind Attribute ( *“ kennzeichnet Primärschlüssel; siehe Abschnitt 3.4.5).
”
Nun ist das ERM sehr praktikabel, um Daten und ihre Beziehungen graphisch zu modellieren,
jedoch nicht, um ein solches Modell konkret umzusetzen.
Das gängigste und üblichste Modell für praktische Umsetzungen ist das relationale Datenmodell. Relationen und ihre Beziehungen bilden den Kern dieses Modells, wobei Relationen
schlicht als Tabellen angesehen werden können und jegliche Modellierung innerhalb dieser vollzogen wird. Die Tabellenköpfe stellen dabei die logische Struktur dar, wie schon gesehen bei
z.B. Filme(Titel,Regisseur,Komponist)“ oder T Song(AlbumID,Song,Time,No)“.
”
”
Das Relationenmodell ist einerseits sehr geeignet für praktische Umsetzungen, bietet andererseits einen mathematischen Formalismus an: Die Relationenalgebra. Diese soll hier jedoch
nur kurz erläutert werden (Details siehe u.a. [Ram00], [Heu00], [Hae99], [Dat03]).
Die fünf Basisfunktionen der Relationenalgebra sind Vereinigung, Differenz, Kartesisches
Produkt, Projektion und Selektion. Diese reichen aus, um auch die folgenden Funktionen
abzuleiten: Joins, Schnitt und Quotient.
Joins (siehe Abschnitt 3.5.1) sind äußerst wichtige Funktionen, weil mit ihrer Hilfe oftmals erst Beziehungen von Relationen bzw. Tabellen und die dahinterstehenden Informationen
effizient zusammengesetzt werden können.
Die beiden folgenden Beispiele besitzen keine logische Struktur, sollen jedoch nur die
Ausführung zweier Funktionen der Relationenalgebra verdeutlichen. Abbildung 13 zeigt ein
Beispiel für die Vereinigung von Relationen. Die minimale Voraussetzung hierbei ist allerdings,
daß die Basisrelationen gleichen Grad, d.h. dieselbe Anzahl an Attributen, besitzen. Eine weitere, vor allem praktische Voraussetzung ist die Verwendung von kompatiblen (Daten-)Typen.
Ein Beispiel für ein kartesisches Produkt findet sich in Abbildung 14. Dieses stellt auch eine
mögliche alternative Realisierung von Joins dar, u.U. allerdings nicht effizient.
3.4.5
Schlüssel
U.a. zum Verknüpfen von Datensätzen einzelner Relationen ist es wichtig, diese Datensätze
eindeutig identifizieren und referenzieren zu können, wozu Schlüssel34 benutzt werden.
34 Um jegliche Irritationen zu vermeiden, sei hier darauf hingewiesen, daß Schlüssel bei Datenbanken und Schlüssel in der
Kryptographie nicht viel gemeinsam haben. Es wird lediglich der gleiche Begriff verwendet.
– 43 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Abbildung 12: ERM-Beispiel
Es existieren fünf Typen von Schlüsseln, die im Folgenden näher beschrieben werden.
• Super-Schlüssel: Jede Menge von Attributen einer Relation, welche die Datensätze dieser Relation eindeutig identifiziert. Dies gilt z.B. bei jeder Relation für die Menge aller
Attribute.
• Schlüssel: Ein Super-Schlüssel welcher minimal ist. D.h., keine echte Teilmenge eines
Schlüssels ist auch ein Schlüssel.
• Schlüsselkandidaten: Alle Schlüssel einer Relation.
• Primärschlüssel (Primary Key): Ein beliebiger, jedoch ausgewählter und festgelegter
Super-Schlüssel. Hier wird oftmals auch der kleinste Schlüsselkandidat verwendet.
• Fremdschlüssel (Foreign Key): Eine Menge von Attributen, welche in einer anderen Relation Super-Schlüssel ist, z.B. der Primärschlüssel. Bindet man einen Fremdschlüssel in
eine Relation ein, wird damit meist ein Verweis auf eine andere Relation vollzogen, und
somit die Beziehung der zwei oder mehr Relationen modelliert.
Dabei ist zu beachten, daß ein Fremdschlüssel nicht die Datensätze der eigenen Relation
eindeutig identifiziert, er dient lediglich als Verweis.
– 44 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Relation A
Buttermilch
Apfel
Fisch
Relation A∪B
Cidre
Fisch
Buttermilch
Buttermilch
Apfel
Fisch
Ei
Dosenmilch Gummiadler
Cidre
Fisch
Buttermilch
Ei
Dosenmilch Gummiadler
Fisch
Apfel
Cidre
Dosenmilch Buttermilch
Relation B
Fisch
Apfel
Fisch
Cidre
Dosenmilch Buttermilch
Fisch
vereinigte Relationen
einzelne Relationen
Abbildung 13: Beispiel für eine Vereinigung in der Relationenalgebra
Man spricht von referentieller Integrität, wenn sichergestellt ist, daß zu jedem Fremdschlüssel auch ein Datensatz in der referenzierten Relation existiert.
Die Attribute von Relationen kann man in folgende Kategorien einteilen:
• Schlüsselattribut (im Primärschlüssel enthalten),
• Hauptattribut (in Schlüsselkandidaten enthalten),
• Nichtschlüsselattribut (nicht im Primärschlüssel enthalten),
• Nebenattribut (in keinem Schlüsselkandidaten enthalten).
Es fällt natürlich auf, daß bei Relationen, welche nur einen Schlüsselkandidaten besitzen,
Schlüsselattribut und Hauptattribut sowie Nichtschlüsselattribut und Nebenattribut identisch
sind.
3.5
Script Query Language (SQL)
SQL ist die gängigste Sprache, welche Datenzugriffe, Datenmanipulation, Strukturmanipulation und somit auch praktische Ausführung der Relationenalgebra in sich vereint. Mit SQL ist
es also möglich, die Datenbank einzusehen, Daten zu bearbeiten und logische Strukturen zu
verändern – alles mittels Queries.
Des weiteren bieten solche Query-Sprachen wie SQL Applikationen und Benutzern die
Möglichkeit, Zugriffe auf eine Datenbank zu filtern. Denn nicht immer möchte man für eine spezielle Aufgabe auf das gesamte Datenvolumen zugreifen.
Es existieren natürlich auch andere Sprachen, die derartige Möglichkeiten bieten. Im Folgenden werden Query-Aktionen aber anhand von SQL erläutert und die SQL-Syntax wird anhand
von Beispielen eingeführt. Queries sind dabei vergleichsweise kurze Code-Abschnitte.
Queries werden natürlich auf Relationen angewendet, wobei für alle gültigen Queries die
Abgeschlossenheit gilt. Das bedeutet, das Resultat einer Query ist erneut und stets wieder
eine Relation. Auch sind mehrere Queries unter bestimmten Voraussetzungen miteinander
kombinierbar.
Dabei ist zu beachten, daß Queries mit SQL einfach formuliert werden können, deren
Ausführung aber meist nicht auf effiziente Weise geschehen würde. In einem DBMS erfolgt
deswegen eine automatische Optimierung (siehe u.a. Abbildung 9) der jeweiligen Query nach
speziellen Regeln, woraus schließlich eine sehr effiziente Query resultiert.
– 45 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Relation A
Buttermilch
Apfel
Fisch
Cidre
Fisch
Buttermilch
Ei
Dosenmilch Gummiadler
Relation B
Fisch
Apfel
Cidre
Dosenmilch
einzelne Relationen
Relation A×B
Buttermilch
Apfel
Fisch
Fisch Apfel
Buttermilch
Apfel
Fisch
Cidre Dosenmilch
Cidre
Fisch
Buttermilch Fisch Apfel
Cidre
Fisch
Buttermilch Cidre Dosenmilch
Ei
Dosenmilch Gummiadler Fisch Apfel
Ei
Dosenmilch Gummiadler Cidre Dosenmilch
Kartesisches Produkt der beiden Relationen
Abbildung 14: Beispiel für ein Kartesisches Produkt in der Relationenalgebra
3.5.1
Datenzugriff und Datenmanipulation
Das erste SQL-Beispiel ist eine einfache Auswahl bzw. Selektion und typisch für SQL auch
weitestgehend selbsterklärend. Die Basis für diesen SQL-Code ist die Relation aus Abbildung
15 ( T CosbyShow-Episodes“), wobei auch hier das Sternsymbol ( *“) den Primärschlüssel
”
”
kennzeichnet.
SELECT
FROM
WHERE
ORDER BY
T_CosbyShow-Episodes.EpName
T_CosbyShow-Episodes
T_CosbyShow-Episodes.Year=1984
T_CosbyShow-Episodes.EpNo;
Auch das Ergebnis der Query ist in Abbildung 15 zu sehen. ORDER BY legt dabei fest, nach
welchen Attributen die Ausgabe – falls gewünscht – aufsteigend oder absteigend sortiert werden
soll. Hier erfolgt die Sortierung nach dem Attribut EpNo“, obwohl es für die Ausgabe gar
”
nicht ausgewählt wurde.
Die wichtigsten SQL-Anweisungen sind Joins. Sie dienen dem Darstellen von Relationsbeziehungen, indem sie z.B. zur Ansicht eine Gesamtrelation auf Basis der Beziehungen bzw.
Verknüpfungen erzeugen, wobei die Verknüpfungen nicht auf Schlüsseln basieren müssen. Dabei existieren verschiedene Arten von Joins, je nach Anforderung an die Darstellung der Daten.
• Inner-Join bzw. Equi-Join bzw. Natural-Inner-Join: In die Gesamtrelation werden ausschließlich Datensätze der Einzel- oder Ursprungsrelationen aufgenommen, bei welchen
gleiche Werte in verknüpften Attributen vorliegen.
• Left/Right-Outer-Join: Die Gesamtrelation besteht aus allen Datensätzen einer der verknüpften Relationen. Datensätze der anderen Relation kommen nur vor bei gleichen Werten in verknüpften Attributen.
– 46 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
T CosbyShow-Episodes
*EpNo EpName
Year
EpName
11 Bon Jour Sondra
1984
Bon Jour Sondra
13 Rudy’s Sick
1984
Rudy’s Sick
19 Clair’s Case
1984
Clair’s Case
23 Mr. Quiet
1984
Mr. Quiet
37 Vanessa’s Bad Grade
1985
Ergebnis-Relation der SQL-Query
(siehe Abschnitt 3.5.1)
41 Play It Again, Russell 1985
Ursprungsrelation
Abbildung 15: Einfache Selektion mit SQL
• Natural-Full-Outer-Join: In der Gesamtrelation kommen alle Datensätze der Ursprungsrelationen vor, aber nur bei gleichen Werten in verknüpften Attributen werden die Datensätze auch kombiniert.
• Cross-Join: Bildung des vollständigen kartesischen Produkts zweier Relationen.
• Union-Join: Die Gesamtrelation besteht aus allen Attributen der Relationen A und B,
stellt aber lediglich ein Untereinanderfügen von A und B dar.
Das folgende Beispiel zeigt einen einfachen Inner-Join, definiert als SQL-Query. Das Beispiel
bezieht sich auf die Relationen aus Abbildung 16, wo auch das Ergebnis der Query zu finden ist. Für den Join wird das Attribut EpNo“ ausgenutzt, welches der Primärschlüssel von
”
T CSEpisodes“ und der Fremdschlüssel in T CSStaff“ ist.
”
”
SELECT T_CSEpisodes.EpName, T_CSEpisodes.Year
FROM
T_CSEpisodes
INNER JOIN T_CSStaff ON T_CSEpisodes.EpNo=T_CSStaff.EpNo
WHERE
(T_CSStaff.Name=’Malcom-Jamal Warner’)
AND (T_CSStaff.Function=’Director’);
Für dieses Beispiel – sonst eher selten – existiert eine weitere, aber je nach Optimierung u.U.
ineffiziente Variante, welche ohne spezielle Join-Anweisung auskommt. Dies geschieht einfach
durch Ausnutzung des kartesischen Produkts, welches hier mit Hilfe der WHERE-Klausel einem
Inner-Join entspricht und wie folgt in SQL einfach gebildet werden kann:
SELECT T_CSEpisodes.EpName, T_CSEpisodes.Year
FROM
T_CSEpisodes, T_CSStaff
WHERE
(T_CSEpisodes.EpNo=T_CSStaff.EpNo)
AND (T_CSStaff.Function=’Director’)
AND (T_CSStaff.Name=’Malcom-Jamal Warner’);
Des weiteren existieren Query-Typen, die direkt oder indirekt die Funktionen der Relationenalgebra realisieren, wie z.B. eine Vereinigung-Query.
– 47 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
T CSStaff
EpNo Name
Function
T CSEpisodes
11 Malcom-Jamal Warner Actor
11 Bill Cosby
*EpNo EpName
Actor
Year
11 Bon Jour Sondra
1984
13 Malcom-Jamal Warner Actor
13 Rudy’s Sick
1984
13 Bill Cosby
19 Clair’s Case
1984
19 Malcom-Jamal Warner Director
23 Mr. Quiet
1984
19 Lisa Bonet
Actor
37 Vanessa’s Bad Grade
1985
19 Bill Cosby
Actor
41 Play It Again, Russell 1985
Actor
23 Malcom-Jamal Warner Actor
23 Bill Cosby
Ursprungsrelation 2
Actor
37 Malcom-Jamal Warner Actor
EpName
37 Bill Cosby
Play It Again, Russell 1985
Actor
41 Malcom-Jamal Warner Actor
Clair’s Case
Year
1984
41 Malcom-Jamal Warner Director
41 Bill Cosby
Ergebnis-Relation der SQL-Query
(siehe Abschnitt 3.5.1)
Actor
Ursprungsrelation 1
Abbildung 16: Join mit SQL
Aggregierung
SQL ermöglicht es, erweiterte Informationen aus Datenmengen zu gewinnen bzw. Datenmengen ein wenig weiterzuverarbeiten und stellt dazu verschiedene Zusatzfunktionen (Aggregierungen), bei welchen die WHERE-Klausel allerdings nicht mehr erlaubt ist, bereit, wie z.B.:
• GROUP BY (Gruppieren gleicher Datensätze),
• COUNT (Zählen aller Zeilen einer Query),
• SUM (Aufsummieren von Attributwerten),
• AVG (Durchschnittbildung von Attributwerten),
• MAX (Bestimmung des größten Attributwerts),
• MIN (Bestimmung des kleinsten Attributwerts).
Folgendes SQL-Beispiel bezieht sich auf die Relation T CSStaff“ aus Abbildung 16. Das
”
Resultat der Query beinhaltet nur die beiden Datensätze Malcom-Jamal Warner;Actor“ und
”
Malcom-Jamal Warner;Director“, was aufgrund des Tabelleninhalts nicht selbstverständlich
”
und auf die GROUP BY-Anweisung zurückzuführen ist:
SELECT
FROM
GROUP BY
HAVING
T_CSStaff.Name, T_CSStaff.Function
T_CSStaff
T_CSStaff.Name, T_CSStaff.Function
T_CSStaff.Name=’Malcom-Jamal Warner’;
In diesem speziellen Falle kann dasselbe Ergebnis auch ohne Aggregierung erreicht werden, da
die Option DISTINCT in SQL stets Duplikate in einer Query-Ausgabe eliminiert:
– 48 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
SELECT DISTINCT T_CSStaff.Name, T_CSStaff.Function
FROM
T_CSStaff
WHERE T_CSStaff.Name=’Malcom-Jamal Warner’;
Die Datensätze (Name;Function;Number) Malcom-Jamal Warner;Actor;5“ und Malcom”
”
Jamal Warner;Director;2“ ergeben sich aus folgendem Beispiel, bei welchem zum Vorschein
kommt, was die GROUP BY-Anweisung bewirkt, nämlich gleiche Datensätze ohne Eliminierung
zusammenzufassen. Nur daher kann z.B. COUNT zusätzlich noch deren Anzahl bestimmen:
SELECT
T_CSStaff.Name,
T_CSStaff.Function, Count(T_CSStaff.Name) AS Number
FROM
T_CSStaff
GROUP BY T_CSStaff.Name, T_CSStaff.Function
HAVING
T_CSStaff.Name=’Malcom-Jamal Warner’;
Dateneingabe
Operatoren zur Dateneingabe und Datenänderung sind in SQL ebenfalls realisiert, es handelt
sich dabei um: DELETE, INSERT und UPDATE. Das folgende Beispiel zeigt das Einfügen eines
Datensatzes in die Beispiel-Relation T CSStaff“ aus Abbildung 16:
”
INSERT INTO T_CSStaff
Values(13,’Bill Cosby’,’Actor’);
DELETE und UPDATE erlauben in Queries auch die Angabe von WHERE-Bedingungen, was u.a.
gerade bei großen Datenmengen sehr wichtig ist.
3.5.2
Strukturmanipulation
Für die Strukturmanipulation stellt SQL ebenfalls Anweisungen zur Verfügung, wobei sich
hierfür die Syntax der Queries ändert. Es existieren u.a. folgende Anweisungen:
• CREATE TABLE (Erstellen von Tabellen),
• DROP TABLE (Löschen von Tabellendefinitionen),
• ALTER TABLE (Ändern von Tabellenstrukturen),
• CREATE INDEX (Erstellen von Indizes, also effizienten Zugriffsstrukturen),
• DROP INDEX (Löschen von Indizes).
Das folgende ausführlichere Beispiel zeigt die Erstellung von etwas größeren logischen Strukturen inklusive Korrektheitsbedingungen:
CREATE TABLE T_Shows(
ID
INTEGER NOT NULL,
ShowName CHARACTER(80) NOT NULL,
FromYear DATE,
ToYear
DATE,
CONSTRAINT MyConstraint1 UNIQUE(ShowName),
CONSTRAINT MyConstraint2 PRIMARY KEY(ID));
– 49 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
CREATE TABLE T_Episodes(
ShowID
INTEGER NOT NULL,
EpNo
INTEGER NOT NULL,
EpName
CHARACTER(60) NOT NULL,
AirDate
DATE,
ProdNo
INTEGER NOT NULL,
Season
TINYINT,
CONSTRAINT MyConstraint3 PRIMARY KEY(ShowID, EpNo));
CREATE TABLE T_Staff(
ShowID
INTEGER NOT NULL,
EpNo
INTEGER NOT NULL,
LastName CHARACTER(20) NOT NULL,
FirstName CHARACTER(20),
Function CHARACTER(20));
Es werden also drei Tabellen erstellt, die miteinander in Beziehung stehen und zusammen eine
Datenbank für TV-Serien darstellen.
Dabei sind hier drei Arten zu sehen, mit denen es möglich ist, Korrektheitsbedingungen zu
definieren. Zunächst werden Werteingaben in Attribute vom Datentyp beschränkt, also z.B.
nur Ganzzahlen oder Zeichenketten bestimmter Länge. NOT NULL bei Attributen sorgt dafür,
daß für jeden Datensatz ein entsprechender Attributwert existiert bzw. eingegeben wird. Und
schließlich gibt es die Möglichkeit separat vielfältige CONSTRAINTs zu definieren. UNIQUE legt
beispielsweise fest, daß keine doppelten Werte in ein Attribut oder mehrere Attribute eingefügt
werden können. Aber auch das Festlegen von z.B. gültigen Eingabebereichen ist möglich.
Des weiteren ist durch die CONSTRAINT-Anweisung die Festlegung von Schlüsseln möglich.
Im Beispiel entsteht etwa der Primärschlüssel, welcher stets zwingend und automatisch UNIQUE
ist, von T Episodes“ aus zwei Attributen. ShowID“ ist als Fremdschlüssel Teil des Primär”
”
schlüssels, würde hier jedoch alleine nicht zum Primärschlüssel ausreichen. Auch wäre es hier
möglich Fremdschlüssel in einer Tabelle bzw. Relation explizit anzugeben.
Für weitere Details zu SQL sei hier nun auf das Literaturverzeichnis (ab Seite 119) verwiesen, beispielsweise auf [Mic00], [Inf98] oder auf jede andere gängige SQL-Dokumentation.
3.6
Applikationsentwicklung
Bei der Entwicklung von Applikationen, die Datenbanken nutzen – als Back-End, wird sehr
oft SQL verwendet, wenngleich in der entstehenden Endanwendung davon nichts zu sehen sein
muß, z.B. bei Benutzereingaben. SQL-Anweisungen lassen sich in gängiger Entwicklungssoftware einfach in den Programmcode einbetten.
Eine Methode zum Durchlaufen und Abfragen von einzelnen Datensätzen, also Navigieren
durch Datenmengen innerhalb eines Programmcodes ist der Einsatz von Cursorn, womit innerhalb der Applikation der Zugriff auf einen individuellen Datensatz einer Tabelle oder SQL-Query
und somit dessen Weiterverarbeitung möglich wird. Auch stellen verschiedene Hersteller von
Entwicklungsumgebungen solche Zugriffsmöglichkeiten durch eigene Techniken zur Verfügung,
wie z.B. das ResultSet bei Suns Java-Systemen (siehe [Sun04-1]) oder die ActiveX Data Objects (ADO) von Microsoft (siehe [Mic00]). Durch Cursor o.ä. erhält jede Applikation ihre
eigene individuelle Sicht auf eine Datenbank.
– 50 –
3
EINFÜHRUNG IN DATENBANKSYSTEME
Da verschiedene Datenbanken und Datenbanksysteme existieren, und es dennoch möglich
sein soll auf verschiedene Datenbanken zugreifen zu können, nutzt man meist die Open Database Connectivity (ODBC). ODBC stellt über einen jeweiligen individuellen Datenbank-Treiber
eine Verbindung zwischen einer Applikation und einer Datenbank her, worauf alle gängigen
Entwicklungsumgebungen zurückgreifen, z.B. Borland Delphi oder Microsoft Visual Studio.
Mittels Suns JDBC wird es auch möglich, SQL sowie ODBC bzw. an ODBC angelehnte
Systeme und somit die meisten Datenbanksysteme innerhalb von Suns Java-Systemen mit
allen Vorteilen zu nutzen.
Beim Zugriff auf Datenbanken ist zu beachten, auf welche Weise dieser geschieht. Man kann
durchaus z.B. aufgrund des direkten Zugriffs auf eine Datenbank große Teile des zugehörigen
Datenbank Management-Systems umgehen, was für Applikationen von Bedeutung sein kann.
Denn damit verzichtet man auf z.B. den Nutzen von Optimierungsmethoden, Transaktionen
oder Triggern (siehe Abschnitt 3.3) und muß Datenbankzugriffe dieser Art u.U. manuell im
Applikationscode realisieren. Allerdings kann dies auch von Vorteil sein, da man sich bzw.
die Applikation auf diese Weise nicht auf Eigenheiten eines DBMS spezialisiert und somit die
Wahl der Datenbank frei bleibt bzw. leicht änderbar ist, z.B. durch einfaches Wechseln des
ODBC-Treibers.
3.7
Hardware- und Softwareauswahl
Datenbanksysteme können stark von der verwendeten Hardware unterstützt werden. Die Hardware muß je nach Anforderung an das Datenbanksystem bzw. an die jeweilige Anwendung
ausgewählt werden, wie z.B. ein Main Memory-System oder ein Redundant Array of Inexpensive/Independent Disks (RAID). Bei RAID-Systemen etwa existieren viele Möglichkeiten und
auch Abhandlungen für deren Realisierung in Abhängigkeit von notwendiger Effizienz, erwarteter Parallel- oder Konkurrenzverarbeitung, Ausfallsicherheits- sowie Wiederherstellungsanforderungen.
Prominente Beispiele für Datenbanksysteme, also SQL-Server bzw. SQL-Server-Produkte,
sind MySQL, Informix, Oracle, IBM DB2 oder der Microsoft SQL-Server, um hier nur einige
zu nennen. Auch existieren XML-basierte Datenbanksysteme. Diese Produkte unterscheiden
sich sehr stark in den Anforderungen, welche an ein Datenbanksystem gestellt werden, z.B. in
der Eignung für mittelständische Unternehmen oder Großunternehmen. Bei MySQL handelt
es sich als einzige um eine OpenSource-Software, ist aber dennoch für kommerziellen Einsatz
nicht kostenlos. Auch existieren bei den genannten Produkten starke Preisunterschiede.
Des weiteren besitzt jedes dieser Datenbanksysteme seine Eigenheiten. Wie in diesem Kapitel beschrieben, existieren allgemeine Theorien und Prinzipien zu Datenbanksystemen. Jedoch
ist natürlich jedem Hersteller eines solchen Systems überlassen, auf welche Weise er diese umund einsetzt.
D.h., bei der Auswahl eines geeigneten Datenbanksystems bzw. Datenbank-Produkts sowie
der verwendeten Hardware für eine bestimmte Applikation müssen folgende Aspekte jeweils
abgewägt werden:
• Hardware- und Software-Anforderungen,
• Effizienz (z.B. bei Entwicklung und Betriebszustand),
• Kosten,
• Personalaufwand (z.B. für Betrieb und Wartung).
– 51 –
4
Datenbankapplikationen für TrustCenter
Nach den Einblicken in die Kryptographie, in TrustCenter-Strukturen und in das Gebiet der
Datenbanksysteme folgt nun in diesem Kapitel deren Zusammenführung. Wie schon kurz in
der Einleitung erwähnt, geht es nun um die Struktur des Datenbankmodells eines TrustCenter
bzw. der Registration Authority und entsprechender Datenbankapplikationen.
Hierbei spielen nun auch Aspekte der Sicherheit, aber vor allem der effizienten Entwicklung
und des effizienten Betriebs eine wesentliche Rolle. Eingeschlossen sind dabei flexible Änderungen an der TrustCenter-Struktur, um diese für verschiedene konkrete Anwendungsbereiche
einsetzbar machen zu können.
Dabei beziehen sich folgende Abschnitte einerseits auf allgemeine TrustCenter-Strukturen
und andererseits, sozusagen beispielhaft, auf das konkrete TrustCenter-Produkt FlexiTrust35
und auf Details zu dessen implementierter Registration Authority. Des weiteren werden die
Besonderheiten und Umstände von FlexiTrust beachtet und System-Lösungen anhand dessen
Eigenschaften exemplarisch vorgestellt.
D.h. ebenso, daß das bereits vorgestellte und definierte TrustCenter-Modell aus Abschnitt
2.3.1ff. erweitert wird. Details zu dessen Realisierung vor allem bzgl. der Registration Authority
werden daher beschrieben und nach definierten Zielen und Kriterien bewertet.
4.1
Datenbanken und Datenhaltung in TrustCentern
Basierend auf dem TrustCenter-Modell bzw. der TrustCenter-Struktur aus Abschnitt 2.3.1ff.
werden nun die Aufgaben der TrustCenter-Datenbank sowie deren Stellung im TrustCenterModell definiert. Des weiteren wird ein konkretes Datenmodell für das TrustCenter selbst
definiert und vorgestellt. Details zur Bedeutung, wie z.B. der verwendeten Relationen und
deren Schlüssel (siehe auch Abschnitt 3.4.3ff.), und Realisierung des Modells werden dabei vor
allem in den Abschnitten 4.6ff. und 4.10 schrittweise, auch anhand von anderen Varianten,
erläutert sowie ergänzt und erweitert.
Abbildung 17 zeigt einen Ausschnitt aus dem Datenmodell des TrustCenters, wobei dieses
Modell im Folgenden für weitere Argumentationen als Basis dient. Denn hier sind zunächst
alle wesentlichen Daten und deren Zusammenhänge erfaßt.
Wie in der Abbildung zu erkennen, werden in der TrustCenter-Datenbank, die auf diesem
Datenmodell aufbaut, neben Entities (siehe auch Abschnitt 2.4) ebenso Distinguished Names
und Zertifikate gespeichert. Entities werden im Datenmodell als mehrstufige Objekte behandelt
(siehe Abschnitt 4.6.2).
Die Datenbank des TrustCenters, welche der Registration Authority (RA) unterstellt ist
und auch von anderen TrustCenter-Komponenten genutzt wird, stellt einen äußerst wichtigen Bestandteil des TrustCenters dar. In dieser Datenbank wird der Registrierungsdatensatz
bzw. werden die Registrierungsdaten (siehe Abschnitt 2.4) eines PKI-Mitglieds und u.a., wie
im Datenmodell zu sehen, dessen Zertifikat gespeichert. Die TrustCenter-Datenbank hat im
wesentlichen folgende Aufgaben:
• Speichern von Personendaten sowie Registrierungsanträgen bzw. Antragsformularen,
• Verknüpfen von Registrierungsdaten und ausgestellten Zertifikaten,
• Aktivieren und Deaktivieren von PKI-Mitgliedschaften,
35 Bei FlexiTrust handelt es sich um eine mittlerweile renommierte TrustCenter-Implementierung, welche am Fachgebiet von
Prof. Buchmann an der TU Darmstadt entstand. Eines der bislang größten Projekte, bei dem FlexiTrust zum Einsatz kam,
entstand in Korporation mit T-Systems und der Regulierungsbehörde für Telekommunikation und Post (RegTP).
– 52 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 17: Ausschnitt aus dem Datenmodell eines TrustCenters
• Verwalten von Distinguished Names (siehe Abschnitt 2.7.6),
• Speichern von Zertifikaten und Zertifikatsinformationen (z.B. Revokation),
• Unterstützen des Verzeichnisdienstes.
Im Folgenden wird hauptsächlich auf die Handhabung der Registrierungsdaten eingegangen.
Denn die Sicherstellung der Verbindung von Registrierungsdaten und Zertifikaten ist essentiell,
um die allgemeinen TrustCenter-Ziele und -Aufgaben (siehe Abschnitt 2.1) erfüllen zu können.
Dabei wird im Folgenden auch das TrustCenter-Modell und die angedeutete Policy des
Modells aus Abschnitt 2.4ff. weiterverwendet sowie erweitert, z.B. bzgl. des Umgangs mit
Daten innerhalb des TrustCenters.36
Es ist zu beachten, daß Daten in der TrustCenter-Datenbank existieren, welche nur dort
vorhanden sind und nicht in ausgestellten Zertifikaten. Während Zertifikate signiert werden
können und somit alle im Zertifikat eingetragenen Daten, muß eine Datenbank auf andere
Weise geschützt werden. Bei TrustCentern gilt im besonderen Maße, daß die zugrundeliegende
Datenbank äußerst schützenswert ist und nur von autorisierten TrustCenter-Mitarbeitern bzw.
Datenbankapplikationen eingesehen werden darf.
Umgekehrt lassen sich Zertifikate in der TrustCenter-Datenbank, etwa in Verknüpfung zum
Registrierungsdatensatz eines PKI-Teilnehmers, ablegen. Datenbanksysteme bieten nämlich
auch die Möglichkeit Attribute für Binärdaten zu erzeugen, z.B. über den SQL-Datentyp Binary
36 In anderen TrustCenter-Modellen können die Aufgaben der RA und der TrustCenter-Datenbank durchaus anders definiert
sein, z.B. wenn keine Trennung von CMA und RA vorliegt oder die CMA eine Offline-Komponente darstellt (siehe auch Abschnitt
2.6). Ebenfalls kann mehr als eine Datenbank für die verschiedenen TrustCenter-Aufgaben existieren.
– 53 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Large Object (BLOB). Die Tabelle T Cert“ des Datenmodells aus Abbildung 17 kann damit
”
auch die Zertifikate selbst speichern.
Alle Abläufe rund um die TrustCenter-Datenbank müssen zum einen weitestgehend automatisiert vonstatten gehen. Dabei ist zu beachten, daß bei verschiedenen Stufen eines Registrierungsvorgangs TrustCenter-Mitarbeiter involviert sind, z.B. zur persönlichen Überprüfung
und Kontrolle von Personendaten anhand von Personalausweisen, wodurch ein automatischer
Ablauf nur zwischen einzelnen Stufen der Registrierung möglich ist. Zum anderen müssen
solche Abläufe und Datenbankapplikationen sicher ausgeführt werden. Denn die TrustCenterDatenbank hat, wie beschrieben, eine zentrale Stellung innerhalb des gesamten TrustCenters
und wird nicht nur von der Registration Authority sondern z.B. auch von der CMA und dem
Verzeichnisdienst (siehe auch Kapitel 2) genutzt.
4.1.1
Registrierungsdaten und Zertifikate
Wie schon in Abschnitt 4.1 ausführlicher beschrieben, kommt der TrustCenter-Datenbank eine
wichtige Rolle. Sie ist daher besonders schützenswert.
Vom TrustCenter ausgestellte Zertifikate und CRLs sind zentrale Stützen, um eine PKI zu
betreiben (siehe auch Kapitel 2). Dabei werden Zertifikate und CRLs mit dem Schlüssel des
TrustCenters signiert, womit ihre Gültigkeit für jeden nachweisbar und nachvollziehbar ist.
In der Praxis kommt es jedoch oftmals vor, daß Daten aus dem Registrierungsdatensatz (siehe Abschnitte 4.1 und 2.4) nicht im Zertifikat enthalten sind. Der Grund liegt zum einen in der
Menge und Veränderlichkeit von Daten, welche bei Registrierungsvorgängen und Datenerfassungen vorkommen können (siehe z.B. Abbildung 18). Zum anderen werden bestimmte Daten
zwar erfaßt, unterliegen jedoch dem Datenschutz und dürfen daher nicht in ein öffentliches
Zertifikat aufgenommen werden, z.B. die Matrikelnummer eines Studenten (siehe Abschnitt
4.2.1).
Des weiteren enthalten die Registrierungsdaten auch Informationen, welche lediglich für
Aufgaben innerhalb des Registrierungsablaufs gedacht sind, wie z.B. die reine Lieferadresse für
ein Zertifikat, so daß es keinesfalls sinnvoll ist, diese in ein Zertifikat einzufügen.
Dennoch müssen diese Daten, genauso wie ein öffentlicher Schlüssel, gleichermaßen einem
Zertifikat zugeordnet werden können, z.B. auch unter gesetzlichen Maßstäben was ein essentieller Sicherheitsaspekt von PKIs ist (siehe Abschnitt 2.1).37 D.h., auch solche Daten aus dem
Registrierungsdatensatz müssen verwaltet und gepflegt werden, z.B. die Postadresse eines Zertifikatinhabers. Die Zuordnung erfolgt eindeutig mittels des Distinguished Name, welcher stets
auch den Registrierungsdatensatz kennzeichnet bzw. dort mitgeführt wird. Dabei muß das
Datenmodell des TrustCenters einerseits geschützt und nachvollziehbar (siehe auch Abschnitt
4.10.1) sein. Andererseits muß die Vollständigkeit und Korrektheit der Registrierungsdaten
stets garantiert sein.
Bei der Realisierung eines TrustCenters bzw. einer Registration Authority, welche ausführliche Daten von PKI-Mitgliedern erfassen soll, muß demnach nicht nur die Personalisierung
eines öffentlichen Schlüssels durch ein Zertifikat sichergestellt werden, sondern ebenfalls die
eindeutige Verknüpfung von Zertifikat und Details zur Person, welche den Schlüsselinhaber
darstellt, also zu deren restlichen Registrierungsdaten. Natürlich werden die essentiellen Teile
dieser Daten, z.B. Nachname sowie Distinguished Name und Zertifikat-Seriennummer, in ein
Zertifikat eingefügt, da dieses vom TrustCenter, also der Certfication Authority, signiert wird.
37 Das Nachweisen der Korrektheit interner Vorgänge und der Einhaltung gesetzlicher Maßstäbe, wie etwa dem Signaturgesetz
(siehe auch Abschnitt 1.1.1), z.B. bei einem Gerichtsprozeß durch einen TrustCenter-Mitarbeiter als eine Art Sachverständigen,
ist alles andere als trivial. Folglich ist die Rechtssprechung über digitale und verbindliche Kommunikation äußerst komplex. Aber
auch diese muß u.U. durch das TrustCenter und dessen Umgang mit Daten möglich sein.
– 54 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Aufgrund der geschilderten Bedeutung des Teils der Registrierungsdaten, welcher nicht im
Zertifikat enthalten ist, wird deutlich, daß Zertifikate und Signaturen als notwendige Mittel
für den TrustCenter-Betrieb nicht ausreichen. Auch dieser Teil der Registrierungsdaten ist
äußerst schützenswert und kann je nach Anwendungsszenario stark variieren, z.B. bei einem
TrustCenter in einem Großunternehmen oder an einer Universität. Diese Informationen bzw.
Daten sind für Dritte also nicht einsehbar, aber dennoch in der Datenbank bzw. den Tabellen
des TrustCenters vorhanden und für einige Vorgänge innerhalb der jeweiligen PKI-Realisierung
unumgänglich, z.B. dem Ausliefern eines privaten Schlüssels.
Hierbei kann es sich um erweiterte Identitätsdaten handeln, z.B. schlicht um Postadresse
oder Telefonnummer, aber ebenso um andere personenbezogene Daten jeglicher Art innerhalb
einer Anwendung, z.B. zu erhebende Daten wie Zertifikatsinhalt, Pseudonyme oder Versandinformationen.
Bei einer heutigen PKI kommt es ebenfalls häufig vor, daß ein PKI-Mitglied mehrere Zertifikate besitzt und diese unter dem selben Distinguished Name oder unter verschiedenen
Distinguished Names (siehe Abschnitt 2.7.5) zugänglich sind. Auch die Verwaltung von vielen
Zertifikaten sowie Distinguished Names und die Verknüpfung dieser mit dem PKI-Mitglied bzw.
dessen Registrierungsdaten muß das Datenmodell der TrustCenter-Datenbank sicherstellen.
4.1.2
Import und Export von Daten
Wird ein TrustCenter in einem konkreten Anwendungsbereich installiert, z.B. einem Unternehmen oder einer Universität, so ist es wünschenswert, daß die Erfassung von Daten nicht
von Grund auf neubeginnen muß. Beispielsweise kann der Fall vorliegen, daß ein Unternehmen
bereits ausführliche Personendaten von Mitarbeitern und Angestellten auch elektronisch erfaßt
hat. Diese können nun die Basis für die TrustCenter-Datenbank bilden und importiert werden.
Auch gehört zu den Aufgaben einer Datenbankapplikation bzw. der Registration Authority
des hier behandelten TrustCenter-Modells, daß Daten in bestimmten Fällen nach außen gebracht, also exportiert, werden. Solche Fälle unterscheiden sich stark. Z.B. kann es notwendig
werden, die Daten eines Signatur-Absenders für einen Rechtsstreit offenzulegen, oder ein Unternehmen möchte in der eigenen, separat geführten, Angestelltendatenbank erfassen, welcher
Angestellte über ein Zertifikat verfügt. Daher muß die RA fähig sein, beliebige DatenbankStatistiken und Reports bzw. Berichte (siehe auch Abschnitt 4.10.6) zu erstellen.
4.2
Praktische Aspekte
Dieser Abschnitt soll einen kleinen Einblick in praktische und konkrete Umsetzungsaspekte
eines TrustCenters gewähren.
Wird ein TrustCenter wie FlexiTrust für ein konkretes Anwendungsszenario, also einem
Kunden“ oder Mandanten“ wie z.B. einem Unternehmen, eingerichtet, so gehen die Entwick”
”
ler von der Grundstruktur dieser Applikation bzw. Datenbankapplikation sowie der Datenbank
aus und modifizieren Quellcode sowie Datenmodell, um sie für das jeweilige Szenario anzupassen. Z.B. können der Datenbank neue Tabellen hinzugefügt werden, etwa T Autoschlosser“,
”
oder vorhandenen Tabellen werden neue Attributen hinzugefügt, wie etwa Fließbandnummer“
”
in “T Person“.
Wie in Abschnitt 2.4 beschrieben, existieren verschiedene individuelle Möglichkeiten für
den Umgang mit Registrierungsdaten und deren Erfassung, welche z.B. zentral oder dezentral erfolgen kann und nach verschiedenen Sicherheitsaspekten. Auch die Verteilung der
TrustCenter-Komponenten auf einem oder mehreren Rechnern bzw. Servern obliegt der je-
– 55 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
weiligen Sicherheitsanforderung. Techniken wie u.a. LDAP machen es ebenfalls möglich, eine
TrustCenter-Datenbank verteilt, also dezentral zu betreiben.
Die TrustCenter-Datenbank enthält dabei Tabellenstrukturen für den TrustCenter-Betrieb
und die Erfassung der PKI-Mitgliederdaten. Meist ist es nicht möglich bzw. erwünscht, daß das
TrustCenter direkt auf z.B. Angestelltendaten etc. eines Unternehmens zugreift. Das bedeutet,
daß die TrustCenter-Applikation stets eine eigene Datenbank und u.U. auch einen eigenen
Server besitzt. Damit verbunden ist das Synchronisieren bzw. Importieren und Exportieren von
Daten, da auf diese Weise Daten redundant existieren.
Abbildung 18 zeigt einen Auszug aus einer real vorkommenden Tabellendefinition, wobei
die Tabellendefinition als SQL-Anweisung dargestellt ist. Das Beispiel zeigt, welche Personendaten in der Praxis in einem TrustCenter vorkommen können und abgebildet werden müssen.
Die Original-Tabelle hat mehr als 60 Attribute, wobei diese Tabelle dann die vollständigen
Registrierungsdaten der PKI-Mitglieder enthält.
Abbildung 18: Praktisches Beispiel für eine real vorkommende Personentabelle
– 56 –
4
4.2.1
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
TrustCenter an einer Universität
FlexiTrust wurde bereits in verschiedenen Anwendungsszenarien eingesetzt, so auch an der
TU Darmstadt (siehe vor allem [Zoe03]). Im TrustCenter der Rechnerbetriebsgruppe (RBG)
des Fachbereichs Informatik findet die Registrierung von Mitarbeitern, z.B. auch Professoren,
dezentral (siehe Abschnitt 2.4) statt. Studenten hingegen haben eine feste Anlaufstelle. Diese
und die folgenden Regeln für den Registrierungsablauf sind natürlich in der zugehörigen Policy
des TrustCenters festgehalten, wobei es sich hierbei also um ein spezielles und konkretes
Anwendungsszenario handelt.
Der Fachbereich ist in verschiedene einzelne Fachgebiete, also Arbeitsgruppen von Professoren, unterteilt. In jedem dieser Fachgebiete existiert nun auch ein bestimmter Mitarbeiter,
welcher verantwortlich und berechtigt ist, Zertifikate für seine Kollegen zu beantragen. Denn
natürlich ist eine solche Person am besten über Mitarbeiterwechsel in seiner Arbeitsgruppe
informiert, weshalb auch die Policy so gestaltet wurde.
Die Antragsdaten werden nach ihrer Erfassung wiederum in der zentralen TrustCenterDatenbank abgelegt. Nun leitet die Registration Authority (siehe Abschnitt 2.4) den Zertifizierungsvorgang ein, und ein Zertifikat wird an z.B. die im Zertifikat enthaltene eMail-Adresse
(X.509v3-Extension, siehe Abschnitt 2.2) des entsprechenden Mitarbeiters verschickt. Der Distinguished Name wird dabei so gebildet, wie schon in Abbildungen 7 bzw. 5 gezeigt.
Das jeweilige Schlüsselpaar wird ebenfalls zentral erzeugt und als PKCS#12 -Datei (siehe
[RSA04]) per eMail verschickt. Es sollte klar sein, daß private Schlüssel selbstverständlich nicht
in öffentlichen Zertifikaten enthalten und auch besonders schützenswert sind. Die Vertraulichkeit des privaten Schlüssels wird dazu durch ein Paßwort sichergestellt. Der Schlüsselinhaber
gibt dieses Paßwort bei der Antragstellung an bzw. bekommt es mitgeteilt.
Abbildung 19 zeigt FlexiTrust als konkretes TrustCenter der Rechnerbetriebsgruppe mit
seinen Abläufen inklusive der TrustCenter-Datenbank.
4.3
TrustCenter-Implementierung mit Java
FlexiTrust und somit auch das in dieser Arbeit diskutierte TrustCenter-Modell haben u.a.
folgende spezielle Realisierungseigenschaften:
• Komponentenaufteilung (siehe Kapitel 2),
• Java-Implementierung,
• flexible Nutzung von verschiedenen Kryptosystemen.
Die Einbindung von Kryptosystemen beruht auf Java-Technologien von Sun (siehe [Sun04-1])
bzw. den Packages der Java Security API. Dabei wird die im Java Development Kit (JDK)
enthaltene Java Cryptography Architecture (JCA) und deren Erweiterung in Form der Java
Cryptography Extensions (JCE) genutzt. Diese stellen eine Interface-Architektur für die Implementierung von kryptographischen Systemen zur Verfügung. Eine konkrete auf dieser Architektur basierende Sammlung von implementierten Kryptosystemen wird Provider genannt.
So ist es nicht nur möglich Java-Applikationen zu entwickeln, die JCA-Kryptosysteme nutzen, sondern es ist ebenfalls möglich den jeweiligen Provider, also die jeweilige Implementierung
auf einfache Weise zu wechseln.
Eine freie OpenSource-Implementierung eines solchen Providers wurde am Fachgebiet von
Prof. Buchmann an der TUD entwickelt: Der FlexiProvider (siehe [Fle04]). Ein Zitat von der
zugehörigen Internet-Seite charakterisiert diesen sehr gut:
– 57 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 19: Grafik von der Arbeitsgruppe Prof. Buchmann über das RBG-TrustCenter
The FlexiProvider is a powerful toolkit for the Java Cryptography Architecture
”
(JCA/JCE). It provides cryptographic modules that can be plugged into every application that is built on top of the JCA.
The goal of our project is to supply fast and secure implementations of cryptographic
algorithms which are easy to use even for developers who are not well-footed in the
field of cryptography.“
Vorteile bei der Verwendung von Java, auch bzgl. einer TrustCenter-Applikation und deren
Datenbank, sind u.a.:
• Plattformunabhängigkeit,
• Kompatibilität,
• flexible Interface-Strukturen und Frameworks.
– 58 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Ein Nachteil von Java, welcher sich auch aus dessen Vorteilen ergibt, da es sich hierbei
um entgegengesetzte Ziele handelt, ist die reine Rechenleistung. Eine C-Implementierung eines speziellen kryptographischen Algorithmus wird in den meisten Fällen schneller sein als
eine entsprechende Java-Implementierung, da ein C-Compiler die speziellen Hardware- und
Betriebssystem-Voraussetzungen nutzt. Natürlich ist es dennoch möglich, bzgl. der Rechenleistung effiziente Java-Implementierungen zu entwickeln, und man gewinnt durch Java ein
hohes Maß an Kompatibilität und Flexibilität, was in der Kryptographie äußerst wichtig ist,
z.B. beim Austauschen und Nutzen von bestimmten Kryptosystemen. Des weiteren handelt es
sich bei einem TrustCenter um eine Anwendung mit einem hohen Anteil an Interaktionen, wie
z.B. der persönlichen Überprüfung von Personendaten im Registrierungsablauf, wodurch sich
eine etwas langsamere Rechenleistung kaum bemerkbar macht.
Datenbanksysteme können in Java-Umgebungen vollständig genutzt werden ebenso wie
ODBC-Treiber (siehe Abschnitt 3.6). Dies geschieht stets durch Suns JDBC, welches eine
Vielzahl an Zugriffsvarianten auf Datenbanksysteme bereitstellt.
Im Folgenden werden also allgemeine Datenbank-Lösungen sowie spezielle Java-Lösungen
vorgestellt, welche beide mehr oder weniger leicht auch auf andere Arten der TrustCenterImplementierung angewendet werden können. Für FlexiTrust gilt im besonderen, daß auch
Java-spezifische Lösungen möglich sind, da es sich hierbei um eine spezielle Java-Entwicklung
handelt.
4.3.1
Datenbankzugriffe unter Java mittels JDBC
Datenbankverbindungen werden unter Suns Java-Systemen mittels JDBC bewerkstelligt (siehe auch Abschnitt 4.7.1). Dabei gibt es mehrere Varianten von einfachen bis zu NetzwerkVerbindungen.
Eine Möglichkeit, um eine Verbindung mit einer Datenbank aufzunehmen, ist die JDBCODBC-Bridge. Dazu ist lediglich eine vorhandene ODBC-Datenquelle nötig, also eine im System durch einen ODBC-Treiber registrierte bzw. eingerichtete Datenbank. Die nötigen Elemente zur erfolgreichen Datenbankverbindung unter Java zeigt folgendes selbsterklärendes
Beispiel. Es setzt das Vorhandensein einer entsprechenden Tabelle T Person“ in der Daten”
bank voraus (zu sehen in Abbildung 20 auf Seite 74). Des weiteren zeigt es das Zugreifen auf
Datensätze sowie das Einfügen, Ändern und Löschen von Datensätzen dieser Tabelle:
import java.sql.*;
public class AccJDBC {
private Connection con;
private Statement stm;
private String url = "jdbc:odbc:MyTestDB"; // ***
// über ODBC im System registrierte Datenbank ’MyTestDB’
private ResultSet rs;
// Java-Cursor
public void accTest(){
// Code für Datenbankverbindung:
// (Für Datenbankverbindungen müssen
// Exceptions stets abgefangen werden)
System.out.println("Baue Datenbankverbindung auf...");
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // ***
}catch(ClassNotFoundException e){};
try{
– 59 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
con = DriverManager.getConnection(url);
stm = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
// ODER (sofern unterstützt):
// con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
//
ResultSet.CONCUR_UPDATABLE);
// Beispiel für das Einfügen eines neuen Datensatzes
// mittels SQL-Query zur Datenänderung:
stm.executeUpdate("INSERT INTO T_Person
Values(1964, ’Bond’, ’James’, ’#007’);");
// Ebenfalls denkbar:
stm.executeUpdate("UPDATE T_Person SET T_Person.
DienstNr = ’#000’ WHERE (((T_Person.Name)=’Bond’));");
stm.executeUpdate("DELETE T_Person.Name FROM T_Person
WHERE (((T_Person.Name)=’Bond’));");
/*
*/
/*
// Beispiel für das Einfügen eines neuen Datensatzes
// durch Java-Cursor ResultSet (sofern unterstützt):
rs = stm.executeQuery("Select * FROM T_Person");
rs.moveToInsertRow();
rs.updateString("Name", "Me");
rs.updateString("Vorname", "MeToo");
rs.updateString("DienstNr", "007");
rs.updateInt("PersID", 123);
rs.insertRow(); // schreiben in die Datenbank
// Bei einer lediglichen Änderung
// (ohne moveToInsertRow()):
// rs.updateRow();
*/
//
rs
//
//
//
//
Beispiel für reinen Lese-Zugriff
= stm.executeQuery("Select * FROM T_Person");
Auf diese Weise werden SQL-Queries ausgeführt und
deren Ergebnisse an einen Java-Cursor übergeben.
T_Person ist dabei eine Tabelle in der
Datenbank ’MyTestDB’.
String tmpName = new String();
String tmpVorname = new String();
// So läuft man mit dem Cursor in der
// Query-Ausgabe abwärts.
rs.beforeFirst();
while(rs.next()){
tmpName = rs.getString("Name");
tmpVorname = rs.getString("Vorname");
// ODER (in diesem Beispiel):
// tmpName = rs.getString(2);
// tmpVorname = rs.getString(3);
System.out.println(tmpName + ", " + tmpVorname);
} // Beispiel für Ausgabe aller Namen der Tabelle.
stm.close();
}catch(SQLException e){System.out.println(e);};
}
}
– 60 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
In späteren Code-Auszügen werden ähnliche Varianten immer wieder auftauchen.
Im obigem Beispiel werden SQL-Queries in den Java-Code direkt als String eingebettet,
was teilweise aufgrund der Länge einer Query unhandlich werden kann. Ebenso lassen sich
Queries als Strings natürlich nicht vom Java-Compiler überprüfen bzw. validieren, auch nicht
die Syntax. Lediglich zur Laufzeit eines Programms werden u.U. Fehlermeldungen ausgeworfen,
z.B. wenn angegebene Attribute bzw. Spaltennamen in einer Tabelle nicht vorhanden sind.
Zu dieser Vorgehensweise ergänzend ist im Interface Connection eine Möglichkeit zur
Parametrisierung von SQL-Anweisungen vorgesehen. Damit ist eine Vereinfachung im Umgang
mit SQL-Strings möglich, was z.B. bei FlexiTrust genutzt wird (siehe Klasse Student.java“
”
im Abschnitt 4.4.1).
Eine zweite Möglichkeit, eine Datenbankverbindung mit JDBC aufzubauen, ist über einen
speziellen JDBC-Treiber für das jeweilige Datenbanksystem bzw. die jeweilige Datengrundlage. Für das obige Beispiel ändern sich dabei lediglich die beiden mit ***“ markierten Zeilen
”
bzw. String-Angaben. Es existiert eine Vielzahl von JDBC-Treibern für bestimmte Datenbanksysteme oder auch z.B. reine Textdateien. Das Ansteuern einer Datenbank über eine
Netzwerk-Adresse bzw. URL ist ebenso leicht möglich.
Des weiteren bietet JDBC eine Unterstützung an, um sich an einem Datenbanksystem
anzumelden. D.h. also, die Angabe von Benutzername und Paßwort ist für eine Datenbankverbindung möglich, sofern eine Benutzerverwaltung für das Datenbanksystem existiert.
4.4
Konzept der FlexiTrust-OpenRA
Die OpenRA ist eine Datenbankapplikation innerhalb des Produkts FlexiTrust, welche die Registration Authority des TrustCenters realisiert (Details siehe vor allem [Dam01] und [Sch01]).
Auf die Ziele und Aufgaben der Registration Authority wurde bereits in Abschnitt 2.4 eingegangen.
Folgendes Zitat aus [Kan04] beschreibt den Registrierungsablauf mittels der OpenRA recht
gut, auch wenn sich das Konzept seither weiterentwickelt hat:
In der RA werden Formulare verwendet, um z.B. Zertifizierungsanträge entgegen
”
zu nehmen. Dabei ist das zugrundeliegende Framework so gestaltet, daß ohne Neukompilation und ohne das Schreiben von Java-Klassen neue Formulare generiert und
verarbeitet werden können, sofern die zur Verarbeitung benötigten Produkte bereits
existieren. Außerdem sind die Formulare prinzipiell unabhängig vom Ausgabeformat,
auch wenn es zum Teil sehr auf HTML ausgelegt ist.“
Der Registrierungsvorgang läuft dabei in mehreren Schritten ab. Der erste Schritt ist natürlich
ein Neuantrag, welcher je nach Anwendungsumgebung automatisch initialisiert wird, z.B. beim
Entstehen des TrustCenters, oder auf persönlichen Antrag erfolgt. In weiteren Schritten müssen
die Daten des digitalen RA-Antragsformular vervollständigt oder überprüft werden (siehe auch
Abschnitt 2.4). Erst im letzten Schritt, nach erfolgreicher Zertifizierung und Aufnahme eines
PKI-Teilnehmers, werden die Antragsdaten im TrustCenter-Konzept zu dauerhaften Registrierungsdaten und werden freigeschaltet, wodurch sie z.B. im Verzeichnisdienst auffindbar sind.
Bei verteilten TrustCenter-Systemen, z.B. bei verteilter Registrierung mit zentraler Datenbank, melden sich ausgewiesene Mitarbeiter über ihre eigene Workstation an der RADatenbank an und können entsprechende Registrierungsdaten eingeben oder vervollständigen.
Nach der erfolgreichen Überprüfung der Antragsdaten, leitet die RA u.a. die Erstellung von
Schlüsseln und Zertifikaten ein, indem sie die Antragsdaten entsprechend an die KA (siehe
auch Abschnitt 2.3.1ff.) weiterleitet, z.B. manuell über bestimmte TrustCenter-Mitarbeiter.
– 61 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Ähnlich verläuft dann die Weitergabe von Zertifikaten und die Ausgabe von Schlüssel-Paketen
an die CMA.
4.4.1
Datenbank-Abläufe rund um die OpenRA
Neben verschiedenen Hilfsklassen sind die zentralen Java-Klassen bei FlexiTrust bzw. bei der
OpenRA, welche für Datenbankzugriffe und Datenbank-Operationen zuständig sind, die folgenden:
• DBAccess.java (Zugriff auf eine Datenbank),
• Entity.java (Darstellen eines Datenbankobjekts als Java-Klasse),
• GenerateEntity.java (Generieren von Entity-Klassen).
Natürlich werden diese Klassen von jeder Teilanwendung FlexiTrusts genutzt, die auf Datenbankverbindungen angewiesen ist. Im Folgenden werden einige Auszüge aus diesen Klassen
gezeigt, damit ein kleiner Eindruck über die aktuelle Handhabung der Datenbankabläufe gewonnen werden kann.
DBAccess.java“ nutzt JDBC zum Zugriff auf eine beliebige Datenbank:
”
public class DBAccess {
private static DBAccess instance;
private Properties props;
private String dburl;
private Hashtable ConnectionPool = new Hashtable(20);
/** Creates new DBAccess */
public DBAccess() {
try {
String drivername =
RAPropertyHelper.getProperty("services.db.driver");
if (drivername == null) {
throw new RuntimeException("Error accessing database.
Not driver specified Halting!");
}
Driver driver =
(Driver) Class.forName(drivername).newInstance();
DriverManager.registerDriver(driver);
props = new Properties();
props.put("user", RAPropertyHelper.getProperty("DB_Username"));
String password =
RAPropertyHelper.getProperty("DB_Password").trim();
if ("<<SYSTEM_PROPERTY>>".equals(password)) {
props.put("password", System.getProperty("ra.dbpassword"));
} else {
props.put("password",password);
}
props.put("dbname", RAPropertyHelper.getProperty("DB_Name"));
this.dburl = RAPropertyHelper.getProperty("DB_Url");
} catch (SQLException e) {
[...]
}
}
/**
– 62 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
* get a connection to the database
* @return the Connection
*/
public Connection getConnection() throws SQLException {
Connection con = DriverManager.getConnection(this.dburl, props);
Statement stmt = con.createStatement();
stmt.execute("USE " + props.getProperty("dbname"));
return con;
}
/**
* get a connection for a given context. If the connection
* was already created, only the handle is given back.
*
* @param String Contextname
* @return Object of type Connection
*/
public Connection getConnection(String contextName)
throws SQLException {
Connection con = null;
if (ConnectionPool.containsKey(contextName)) {
con = (Connection)ConnectionPool.get(contextName);
if (con.isClosed()) {
con = getConnection();
ConnectionPool.put(contextName,con);
}
return con;
} else {
con = getConnection();
ConnectionPool.put(contextName, con);
return con;
}
}
/** DBAccess conforms to the pattern ’singleton’ */
public static DBAccess getInstance() {
if (instance == null) {
instance = new DBAccess();
}
return instance;
}
protected void finalize() {
Enumeration en;
String current;
for (en = ConnectionPool.keys(); en.hasMoreElements();) {
current = (String) en.nextElement();
try {
((Connection)ConnectionPool.get(current)).close();
} catch (SQLException se) {
StaticLogfile.write("RA","DBAccess",
StaticLogfile.EXCEPTION,"Couldn’t close a connetion");
StaticLogfile.writeException("RA","DBAccess",
StaticLogfile.EXCEPTION,se);
}
ConnectionPool.remove(current);
}
}
}
– 63 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Ausgehend von der Klasse Entity.java“ können weitere Entities abgeleitet werden, wobei die
”
zugehörige Java-Klasse durch die Vererbung ähnlich aufgebaut ist. Auch können alle abgeleiteten Entities anstelle der Klasse Entity in Java einfach genutzt werden, ohne daß besondere Code-Änderungen nötig werden. Ein Beispiel für eine solche abgeleitete Klasse ist Stu”
dent.java“. Attribute des Datenbankobjekts, z.B. die Matrikelnummer, finden sich natürlich
auch als Attribute bzw. Variablen in der passenden Java-Klasse:
public class Student extends Entity {
private static final String TABLE_NAME = "student";
private String lastName;
private String firstName;
private String matrikelNr;
private String accountName;
private String email;
private String mySelectString =
"select first_name,last_name,account_name,matrikel_nr,email "
+ "from "+TABLE_NAME+" where (subject_dn=? AND issuer_dn=?)";
private String myUpdateString =
"update "+TABLE_NAME+" set first_name=?, last_name=?, "
+ "account_name=?, matrikel_nr=?, email=?
where (issuer_dn=? AND subject_dn=?)";
private String myInsertString =
"insert "+TABLE_NAME+" set first_name=?, last_name=?, "
+ "account_name=?, matrikel_nr=?, email=?, issuer_dn=?,
subject_dn=?";
public Student(String SubjectDN, String IssuerDN,
String ExternKey, boolean printPIN) throws EntityException {
super(SubjectDN, IssuerDN, ExternKey,
"de.tud.cdc.flexiTrust.ra.entities.Student", printPIN);
StaticLogfile.write(
"RA",
"entities.Student",
StaticLogfile.DEBUG,
"Created Student with sDN=" + SubjectDN + " ,iDN="
+ IssuerDN +" ,ExternKey="+ExternKey);
}
[...]
/**
* Gets the LastName
* @return Returns a String
*/
public String getLastName() {
return lastName;
}
/**
* Sets the LastName
* @param myLastName The LastName to set
*/
public void setLastName(String myLastName) {
this.lastName = myLastName;
markDirty();
}
[...]
public void loadFromDB(Connection conn) throws EntityException {
– 64 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
super.loadFromDB(conn);
PreparedStatement ps = null;
ResultSet rs = null;
try {
ps = conn.prepareStatement(mySelectString);
ps.setString(1, getSubjectDN());
ps.setString(2, getIssuerDN());
rs = ps.executeQuery();
if (rs.next()) {
firstName = rs.getString(1);
lastName = rs.getString(2);
accountName = rs.getString(3);
matrikelNr = rs.getString(4);
email = rs.getString(5);
} else {
rs.close();
ps.close();
throw new EntityException(
"Student with issuer_dn=’"
+ getIssuerDN()
+ "’ and subject_dn=’"
+ getSubjectDN()
+ "’ does not exist.");
}
} catch (SQLException se) {[...]}
}
public void storeToDB(Connection conn) throws EntityException {
int rowCount;
try {
PreparedStatement ps = null;
if (isPersistent()) {
super.storeToDB(conn);
ps = conn.prepareStatement(myUpdateString);
} else {
//jezo:
if (!isExisting (getSubjectDN(), getIssuerDN())){
//new user
ps = conn.prepareStatement(myInsertString);
} else { //after revocation
ps = conn.prepareStatement(myUpdateString);
}
super.storeToDB(conn);
//before:
//super.storeToDB(conn);
//ps = conn.prepareStatement(myInsertString);
}
ps.setString(1, firstName);
ps.setString(2, lastName);
ps.setString(3, accountName);
ps.setString(4, matrikelNr);
ps.setString(5, email);
ps.setString(6, getIssuerDN());
ps.setString(7, getSubjectDN());
StaticLogfile.write(
"RA",
– 65 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
"entities.Student",
StaticLogfile.DEBUG2,
"running insert with statement:" + ps.toString());
rowCount = ps.executeUpdate();
if (rowCount != 1) {
throw new EntityException(
"Error storing Student object. " + rowCount +
" rows were affected!");
}
} catch (SQLException se) {
throw new EntityException(
"Error storing Student into database. Caught Exception!",
se);
}
}
}
Bisher bedient man sich bei der OpenRA zum Generieren einer solchen Entity-Klasse eines
Java-Programms, bei welchem der Text“ oder Inhalt einer Java-Klasse schlicht in eine neue
”
Datei eingefügt wird. Dieser Inhalt wird aus zuvor erstellten Tabellendefinitionen erzeugt:
public class GenerateEntity {
private static StringBuffer fileName;
private static String tableName;
private static String columns[];
private static FileWriter outFile;
private static void readColumnNames() throws Exception {
Connection con;
Statement stmt;
ResultSet rs;
ResultSetMetaData rsmd;
String tmp;
int i, j;
con = DBAccess.getInstance().getConnection();
stmt = con.createStatement();
rs = stmt.executeQuery("SELECT * FROM " + tableName);
rsmd = rs.getMetaData();
columns = new String[rsmd.getColumnCount() - 2];
j = 0;
for (i = 0; i < rsmd.getColumnCount(); i++) {
tmp = rsmd.getColumnName(i+1);
System.out.println("Reading "+tmp);
if (tmp.equals("status") || tmp.equals("formID"))
continue;
columns[j++] = tmp;
}
}
private static void writeHeader() throws Exception {
outFile.write(
"package de.tud.cdc.flexiTrust.ra.entities;\n"
+ "import java.security.Principal;\n"
+ "import java.sql.Connection;\n"
+ "import java.sql.Date;\n"
+ "import java.sql.PreparedStatement;\n"
+ "import java.sql.ResultSet;\n"
+ "import java.sql.SQLException;\n"
– 66 –
4
+
+
+
+
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
"\n"
"import de.tud.cdc.flexiTrust.ad.StaticLogfile;\n"
"\n"
"public class DGNPerson extends Entity {\n");
}
private static void declareStringVar(String name) throws Exception {
outFile.write("
private String " + name + ";\n");
}
private static void writeColList() throws Exception {
for (int i = 0; i < columns.length; i++) {
if (i != 0)
outFile.write(",");
outFile.write(columns[i]);
}
}
private static void writeColSetList() throws Exception {
for (int i = 0; i < columns.length; i++) {
if (i != 0)
outFile.write("=?,");
outFile.write(columns[i]);
}
}
private static void writeSelectString() throws Exception {
outFile.write("\n
private String selectString =\n");
outFile.write(
"
\"SELECT * FROM "
+ tableName
+ " WHERE (subject_dn=? AND issuer_dn=?)\";\n");
}
[...]
public static void main(String[] args) {
try {
tableName = args[0];
if (args.length != 1) {
System.out.println(
"Wrong command format: GenerateEntity table");
return;
}
fileName = new StringBuffer(args[0]);
if (Character.isLowerCase(args[0].charAt(0))) {
fileName.setCharAt(
0,
Character.toUpperCase(fileName.charAt(0)));
}
fileName.append(".java");
System.out.println("OUTPUT TO ’" + fileName.toString() + "’");
outFile = new FileWriter(fileName.toString());
readColumnNames();
writeHeader();
for (int i = 0; i < columns.length; i++) {
declareStringVar(columns[i]);
}
writeSelectString();
writeUpdateString();
writeInsertString();
outFile.write(’\n’);
– 67 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
for (int i = 0; i < columns.length; i++) {
writeSetStmt(columns[i]);
}
outFile.write(’\n’);
for (int i = 0; i < columns.length; i++) {
writePutStmt(i + 1, columns[i]);
}
for (int i = 0; i < columns.length; i++) {
writeStringSetter(columns[i]);
}
outFile.write(’\n’);
[...]
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
Diese Methode ist vielleicht weniger elegant, dennoch ist sie nicht unbedingt ineffizient.
4.4.2
Erweiterungsmöglichkeiten für das OpenRA-Konzept
Im Folgenden werden zu lösende Aufgaben und Ziele bei der OpenRA bzw. FlexiTrust aus Sicht
eines Datenbank-Entwicklers, abgeleitet aus den Merkmalen der OpenRA, zusammengefaßt.
• Hohe Flexibilität ist eine zentrale Eigenschaft von FlexiTrust. Dabei bezieht sich Flexibilität vor allem auf Verwendung von Kryptosystemen und die Anpassungsfähigkeit für
verschiedenste Anwendungsszenarien. So ist es z.B. möglich, Teile der OpenRA, wie die
Verwaltung für Antragsformulare, in unterschiedlichen Umgebungen einzusetzen, ohne
Quelltexte neu schreiben oder kompilieren zu müssen.
Entities, also Datenbankobjekte wie Personendaten, werden bisher jedoch als feste JavaKlasse repräsentiert. Zwar existieren hier Standard-Klassen, diese müssen jedoch u.U.
angepaßt werden. Es ist also sinnvoll, hier ein ähnlich flexibles Datenmodell zu erstellen
wie bei RA-Formularen, so daß keine neuen Klassen oder Neukompilationen nötig sind.
Die jeweiligen Datenbankobjekte, z.B. Personendaten, werden dabei bisher ebenfalls in
festen Tabellen abgelegt und der Zugriff darauf ist im Quellcode eingebettet.
• Die vorhandenen Datenbankzugriffe sind stark SQL-lastig, etwa zum Suchen von Formularen oder anderen Datenbankobjekten, was jedoch nicht zwingend nachteilig sein
muß. Problematischer ist das Erstellen von Datenbankzugriffen für ein individuelles Projekt. Z.Z. geht man von einem Standard-Schema aus, welches angepaßt wird. Solch ein
Vorgehen ist natürlich fehleranfällig und der Entwickler muß seine Arbeit stets genau
überprüfen und testen.
• Bisherige eingesetzte Datenmodelle hatten teilweise Schwächen in der Festlegung des
Primärschlüssels, da hierfür auch Distinguished Names verwendet wurden, etwa SubjectDN und IssuerDN. Da diese jedoch, z.B. bei zeitlich begrenzt ausgestellten Zertifikaten, mehrfach in einer TrustCenter-Datenbank vorkommen, sind sie oftmals ungeeignet. Ihr Vorteil liegt allerdings offensichtlich in der Nachvollziehbarkeit, da DatenbankOperationen bei ihrer Verwendung beispielsweise stets bestimmten Entities bzw. Personen
zugeordnet werden können. Automatisch vergebene eindeutige Kennzeichner, welche bei
Datenbanken meist verwendet werden, bieten eine derartige Transparenz nicht. Daher ist
eine Verknüpfung beider Kennzeichnungsarten sinnvoll (siehe Abschnitt 4.10.2).
– 68 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
• Aufgrund der flexiblen Nutzung von Datenbank-Treibern und somit von Datenbanksystemen ist es nicht möglich spezielle Eigenschaften von Datenbanksystemen, wie z.B.
Transaktionen oder Trigger, auszunutzen. Jedoch gibt es hierfür unter Berücksichtigung
der Flexibilität bzgl. der Wahl eines Datenbanksystems für das TrustCenter Alternativen
unter Java (siehe auch Abschnitt 4.10.7).
4.5
Persistierung von Daten
Dieser Abschnitt beschreibt die Vorgehensweise für das Persistieren von Daten innerhalb einer
allgemeinen Datenbankapplikation und eines TrustCenter.
4.5.1
Datengattungen
Man kann bei Datenbankapplikation verschiedene Arten von zu persistierenden Daten unterscheiden:
• Objekte eines Datenmodells,
• Objekte einer Programmiersprache,
• Kombination beider Objektarten.
Ein Beispiel für eine Anwendung, die nur auf Daten oder Informationen bzw. Objekte in einer
vorhandenen Datenbank zugreift, ist eine Adhoc-Query, mit welcher lediglich Daten direkt
abgefragt oder eingefügt werden. Ein weiteres Beispiel hierfür ist eine Suchmaske, welche einer
Person ohne Datenbankkenntnisse einen einfachen Zugriff auf eine Datenbank zur Verfügung
stellen soll, was durch Umwandlung der Eingabe in die Suchmaske in SQL-Code bzw. in eine
SQL-Query möglich ist.
Objekt-Relationales-Mapping hingegen hat zum Ziel bei der Implementierung einer Applikation mit einer objektorientierten Entwicklungsumgebung oder Programmiersprache, vorkommende Objekte zu persistieren, genauer auf relationale Datenbanken abzubilden. Ein Beispiel
hierfür ist die Implementierung einer ausfallsicheren Druckerwarteschlange. Dabei sind zunächst
keine speziellen zu persistierenden Informationen vorhanden. Die Objekte, also Druckaufträge
in der Warteschlange jedoch sollen bei ihrem Eingang als erstes in die Datenbank eingefügt
werden. Der Entwickler sorgt demnach dafür, daß die Objekte bzw. Klasseninstanzen, welche die Druckaufträge darstellen, derart in der Datenbank abgelegt werden, daß die Objekte
selbst einfach wiederhergestellt werden können. Dabei ist es z.B. unerheblich, ob die Daten in
der Datenbank lesbar sind. Auch könnte man in bestimmten Fällen u.U. auf den Einsatz von
Datenbanken verzichten und solche Objekte beispielsweise in Dateien speichern.
Ebenfalls kann es vorkommen, daß man bei Datenbankapplikationen beide Gattungen von
zu persistierenden Objekten kombiniert, etwa wenn man Objekte einer Datenbank auch als
Objekte, also Klasseninstanzen einer Programmiersprache repräsentieren möchte oder umgekehrt. Z.B. kann es sinnvoll sein bei einer Applikation basierend auf einer Personendatenbank,
auch eine Klasse Person zu implementieren, deren Variablen die Attribute des Datenbankobjekts darstellen. Bei solchen Klassen bzw. Klassenstrukturen handelt es sich also um eine
Repräsentationsschicht oder Zugriffsschicht für die Datenbankobjekte.
In einem TrustCenter und vor allem bei FlexiTrust liegt die letzte vorgestellte Variante vor.
– 69 –
4
4.5.2
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Entwickeln von Datenbankapplikationen für TrustCenter
Man kann einem Entwickler von Datenbankapplikationen nicht ersparen, Datenmodelle zu
entwickeln. Dazu gehört das Festlegen von zu persistierenden Daten, Attributen, Datentypen
usw. Der Idealfall ist somit, daß dies nur einmal erfolgen muß.
Im Falle einer TrustCenter-Implementierung stehen u.a. Personendaten im Mittelpunkt. Dabei ist zu beachten, daß je nach Anwendungsumgebung für ein TrustCenter unterschiedliche
Personendaten aufkommen. Man vergleiche z.B. die notwendigen Personendaten, welche ein
TrustCenter erfassen muß, für Studenten an einer Universität und Mitarbeiter eines pharmazeutischen Unternehmens. Im Falle der Studenten sind dies Daten wie die Matrikelnummer oder
der Immatrikulationsstatus, bei den Mitarbeitern hingegen Daten wie etwa die Raumnummer
des Büros oder der Name der Abteilung.
Für das Einrichten konkreter Datenbanken für Datenbankapplikationen, genauer, zugehöriger Tabellendefinitionen, gibt es nun zwei Möglichkeiten. Einerseits ist es typischerweise möglich von der Datenbanksicht auszugehen, also erst Tabellen einzurichten und daraufhin den
Applikationscode anzupassen. Andererseits kann man aus dem Applikationscode heraus entsprechende Tabellen erzeugen lassen. Automatisierungen in beiden Fällen sind für Entwickler
natürlich sehr interessant, da so die Entwicklungs- und Einrichtungszeit verkürzt werden kann.
Ein Ziel bei der Entwicklung von Datenbankapplikationen ist folglich, nur von einer Seite –
Datenbankseite oder Codeentwicklungsseite – aus zu entwickeln und die andere automatisch
erzeugen zu lassen. Dazu muß man sich entscheiden, von welcher Seite aus man als Entwickler
arbeiten möchte.
Dabei ist zu beachten, daß eine übliche Möglichkeit zum Zugreifen auf eine Datenbank
innerhalb einer Applikation bzw. des Applikationscodes darin besteht, direkt auf Tabellenstrukturen zu zugreifen. D.h., Tabellennamen etc. werden in den Code eingebettet und explizit
angegeben, meist in Form von SQL-Anweisungen. Bei vielen Applikationen ist dies ausreichend,
weil sich Tabellenstrukturen eher selten oder gar nicht ändern, anders bei einer TrustCenterAnwendung und z.B. der zugehörigen Personendatenbank. Natürlich gibt es bei TrustCentern
eine gewisse feste Grundstruktur, die für den TrustCenter-Betrieb notwendig ist, z.B. Attribute
für Distinguished Names von PKI-Mitgliedern.
Selbst wenn man nicht manuell Datenbankstrukturen erzeugen muß, z.B. wenn aus einer
entwickelten Klassenstruktur automatisch Datenbankstrukturen erzeugt werden, hat man wiederum durch den Aufbau der entsprechenden Klassen ebenso manuell“ die zu persistierenden
”
Daten festgelegt.
D.h. also, ein Entwickler von Datenbankapplikationen muß auf die eine oder andere Weise
stets auch Daten und deren Struktur, sprich das Datenbankmodell, ausarbeiten und entwickeln,
z.B. die notwendigen Entities mit ihren Attributen und Abhängigkeiten oder die Bestimmung
des Primärschlüssels. Dazu existiert keine Alternative. Es ist z.B. nicht möglich für beliebige
Applikationen ausschließlich auf Standarddefinitionen zurückzugreifen.
Auch ist dies im Rahmen eines TrustCenters und von unterschiedlichen hier vorliegenden
Szenarien für Personendaten impraktikabel. Im Gegenteil, bei TrustCentern muß eine hohe
Flexibilität bei der zugehörigen Datenbankapplikation vorhanden sein.
4.5.3
Einrichten von Datenbanken und logischen Strukturen
Wird ein TrustCenter bzw. ein TrustCenter-Produkt an einer bestimmten Stelle eingerichtet,
schließt dies das Installieren eines zuvor ausgewählten Datenbanksystems ein, z.B. für das
Speichern von Personendaten etc.
– 70 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Des weiteren müssen die logischen Strukturen bzw. Tabellen der TrustCenter-Datenbank
erstellt werden. Dazu gibt es z.B. folgende Möglichkeiten und zwar mittels:
• Direkte Eingabe am Datenbanksystem,
• Eingabe über Datenbank-Tools,
• SQL.
Datenbanksysteme bieten die Möglichkeit, Tabellen über System-eigene Kommandos zu definieren, wie z.B. MySQL. Es existieren natürlich auch viele graphische sowie System-fremde
Datenbank-Werkzeuge, welche dies ermöglichen.
Da alle gängigen Datenbanksysteme SQL unterstützen, lassen sich Tabellen auch über
SQL-Anweisungen (siehe Abschnitt 3.5.2) erstellen: Zum einen über deren direkte Eingabe mit
Hilfe eines passenden Werkzeugs und zum anderen über z.B. ein Java-Programm. Letzteres
ist natürlich für FlexiTrust interessant.
Dabei läßt sich der SQL-Code in Java einbetten oder über eine einfache Text-Datei einlesen.
Im zweiten Fall wäre keine Neukompilation des entsprechenden Programms notwendig.
Bei einer Datenbank-Lösung wie dynamischen Strukturen (siehe Abschnitt 4.8.3) würden
zusätzlich stets nur dieselben Tabellen erstellt, womit also eine automatische Einrichtung von
Datenbanksystem und Datenbank-Struktur möglich ist. Die manuelle Festlegung der eigentlichen Tabellen erfolgt bei dynamischen Strukturen dann über Dateneingaben.
4.5.4
Ziele der Persistierung allgemein und in einem TrustCenter
Die im Folgenden definierten sowie beschriebenen Ziele dienen auch als Bewertungskriterien
und werden daher bei der Bewertung von Persistierungslösungen in deren jeweiligen Abschnitten und schließlich in Abschnitt 4.9 zugrundegelegt. Bewertet wird die Persistierungslösung –
im Hinblick auf die Erreichung der Ziele – dabei nicht nur im Allgemeinen sondern auch im
Kontext einer TrustCenter-Applikation.
Persistierung hat zum einen das Ziel, Daten dauerhaft aufzubewahren. Andererseits reicht
es natürlich nicht, Daten irgendwo zu speichern, da man diese auch wiederfinden können muß.
D.h., ein weiteres und gleichrangiges Ziel der Persistierung ist das einfache Wiederfinden und
Wiederherstellen von Daten oder Datenbankobjekten. Ein solcher Vorgang ist stets mit einer
Art von Datensuche unter bestimmten Kriterien verbunden, die im Idealfall eindeutig sind,
etwa der Distinguished Name im Kontext eines Registrierungsdatensatzes eines TrustCenters.
Weitere Ziele der Persistierung im Allgemeinen bzw. bei einer Datenbankapplikation werden
im Folgenden beschrieben, wobei sich diese oftmals stark überschneiden.38
• Automatisierung der Persistierung: Das Entwickeln von Datenmodellen ist unumgänglich.
Der Entwicklungsaufwand bei diesem Vorgang soll jedoch minimiert werden (siehe vor
allem Abschnitt 4.5.2).
Beispielsweise muß der Entwickler nur auf Codeentwicklungsseite tätig werden, wenn es
die Persistierungsmethode erlaubt, logische Strukturen in einer Datenbank aufgrund des
Inhalts einer Java-Klasse, welche das entwickelte Datenmodell beinhaltet, automatisch
zu erstellen.
38 Die aufgezeigten Ziele sind bei FlexiTrust bzw. bei der Persistierung von Personendaten und Entities innerhalb der OpenRA
zum großen Teil noch nicht erfüllt.
– 71 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
• Weitestgehend automatisches Zusammenspiel zwischen Datenbankobjekten und Repräsentationsschichten: Die Java-Repräsentationsschichten für Datenbankobjekte, wie Personendaten, sind bei FlexiTrust (siehe z.B. Klasse Student.java“ in Abschnitt 4.4.1) zwar
”
ähnlich aufgebaut, aber für jedes Anwendungsszenario individuell nachbearbeitet. Dazu
ist auch eine Nachpflege und Neukompilation des Quellcodes aller Teile der Datenbankapplikation vonnöten. Dies ist ein typisches Problem.
Es ist wünschenswert, daß solche Vorgänge soweit wie möglich automatisiert vonstatten
gehen und vereinfacht werden. Idealzustände für die Entwicklung von Datenbankapplikationen sind hierbei:
– Kein Schreiben neuer Klassen oder Ändern vorhandenen Quellcodes notwendig,
– keine Neukompilation des Quellcodes notwendig,
– feste logische Strukturen bzw. Tabellenstrukturen.
Natürlich ist dieses Ideal schwer zu erreichen, da individuelle Anwendungsszenarien auch
individuelle Datenmodelle, welche bei TrustCentern hauptsächlich auf Personendaten verschiedenster Art beschränkt sind, hervorrufen.
• SQL-Code minimieren: Das Minimieren von notwendigen SQL-Anweisungen zum Datenbankzugriff erleichtert die Applikationsentwicklung. Gleiches gilt für die Minimierung der
Anzahl der Stellen, bei welchen eine Anpassung von SQL-Anweisungen für ein spezielles
Anwendungsszenario jeweils notwendig ist.
• Flexibilität in der Wahl des Datenbanksystem-Produkts: Für manche Datenbankapplikationen ist es sinnvoll, keine speziellen Eigenheiten eines bestimmten Datenbanksystems
in den Quellcode zu setzen. Damit bleibt man unabhängig in der Wahl des Datenbanksystem-Produkts, z.B. auch hinsichtlich eines Wechsels ggü. vorangegangener Umsetzungen. Die Applikation ist damit nicht an ein bestimmtes Produkt gebunden oder auf
ein bestimmtes Produkt beschränkt, sondern richtet sich ausschließlich nach Standards,
welche von allen Produkten unterstützt werden, wie z.B. SQL (siehe auch Abschnitt
4.10.7).
Allerdings ist dieses Vorgehen nicht für jede Datenbankapplikation erforderlich, da nicht
immer ein derartiges Maß an Flexibilität nötig ist, z.B. bei einer speziellen und festen
Anwendung mit geringen Anteilen an Datenbankzugriffen, die ausschließlich auf MySQL
aufbaut.
• Kostengünstig und effizient.
In einem TrustCenter hat die Persistierung und der Umgang mit Datenbanken zusätzlich folgende Ziele.
• Flexibilität: Neben der Flexibilität beim Einsatz von Kryptosystemen muß ein TrustCenter
seine Datenbankapplikation auf verschiedene Anwendungsszenarien, also auch verschiedene Datenmodelle, übertragen können, weil sich diese meist stark unterscheiden (siehe
Abschnitt 4.1.1).
Auch darf die Wahl eines zugrundeliegenden Datenbanksystems nicht beschränkt sein, da
diese Wahl z.B. sehr vom Anwendungsszenario oder Kundenwunsch“ abhängt. Hierbei
”
handelt es sich um einen speziellen Aspekt bei einem TrustCenter-Produkt, da dieses
in unterschiedlichen Szenarien, z.B. bzgl. der zu erhebenden Registrierungsdaten, zum
Einsatz kommt. So muß das TrustCenter sowohl für z.B. ein kleineres Unternehmen mit
– 72 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
50 Mitarbeitern wie auch für ein Großunternehmen mit 10000 Mitarbeitern geeignet sein.
Wie schon in Abschnitt 3.7 erläutert, existieren dabei in beiden Fällen unterschiedliche Anforderungen an das zugrundeliegende Datenbanksystem für die TrustCenter-Applikation.
So würde im ersten Falle sicher nicht Oracle als Wahl des Datenbanksystem-Produkts in
Frage kommen aber im zweiten Fall (weitere Details siehe Abschnitt 4.10.7).
• Nachvollziehbarkeit und u.U. Beweisbarkeit des korrekten Umgangs mit Daten: Gerade die
Verknüpfung von Personendaten und Zertifikaten bzw. Signiervorgängen ist ein äußerst
wichtiges Ziel in der PKI (siehe auch Abschnitt 4.10.1).
• Korrekte Suchvorgänge innerhalb von PKIs: Der Suchvorgang, z.B. nach einem Zertifikat
(siehe auch Abschnitt 2.7), in einer PKI muß stets unter sicherheitsrelevanten Aspekten
erfolgen, da sonst PKI-Techniken umgangen werden können. Auch die bei einer Datenbankapplikation ständig erforderliche Suche nach Datenbankobjekten, wie Personendaten,
muß solche Aspekte erfüllen und beispielsweise ein eindeutiges Ergebnis liefern.
Effizienz
Ein großes Ziel der Persistierung ist die Erreichung von Effizienz. Dabei bezieht sich Effizienz
auf folgende Bereiche (siehe auch Abschnitt 3.7), welche leider oftmals sehr konträr sind:
• Applikationsentwicklung,
• Betrieb (z.B. Benutzbarkeit, Rechenleistung),
• Wartung,
• sonstige Anwendungen (z.B. Datenbank-Berichte/Reports).
Der Aspekt der Effizienz läßt sich ausgiebig diskutieren, soll hier aber nur angerissen werden.
Auch überträgt sich Effizienz natürlich auf den Bereich der Kosten, etwa der Entwicklungskosten.
Im Bereich der Applikationsentwicklung wirkt Effizienz beispielsweise auf die Entwicklungszeit. So ist diese minimierbar, wenn der Entwickler einer Datenbankapplikation bei der Persistierung z.B. Tabellenstrukturen nur an einer Stelle angeben muß und nicht für Datenbank und
Applikationsquellcode separat. Denn dadurch verringert sich die Fehleranfälligkeit und die Notwendigkeit zur manuellen Überprüfung. Aus Benutzersicht kann sich Effizienz beispielsweise
durch Erleichterung von Benutzereingaben bemerkbar machen.
Andererseits können sich derartige Vorgehensweisen, wie effizientere Applikationsentwicklung, negativ auf den Betrieb bzw. die Rechenleistung auswirken oder das Erstellen von
Datenbank-Auszügen erschweren. Hier muß also stets eine Abwägung erfolgen.
4.6
Möglichkeiten zur Persistierung und Repräsentation
Im Folgenden werden verschiedene Persistierungslösungen und Repräsentationsklassen vorgestellt. Es existieren hierfür etliche Systeme und Möglichkeiten, z.B. in Form von Datenbankmodellen und Java-Lösungen. Hier werden jedoch nur einige im Kontext eines TrustCenters bzw.
von FlexiTrust (siehe u.a. Kapitel 2) bedeutsame Varianten vorgestellt und bewertet (siehe
Abschnitt 4.9).
Ebenfalls werden die unterschiedlichen Varianten anhand von Beispielen demonstriert. Die
Beispiele sind teilweise stark vereinfacht, da viele Varianten vorgestellt werden, und beziehen
sich daher auf die Persistierung von einfachen Personendaten, wie die Tabelle T Person“ in
”
– 73 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 20. Doch natürlich sind sie auch auf ein Datenaufkommen wie aus Abbildung 18
oder auf mehrstufige Objekte anwendbar. Letzteres wird ebenfalls teilweise an einigen Varianten
exemplarisch demonstriert.
Die später gezeigten Beispiele bestehen ebenfalls aus Teilen von Java-Quellcodes und Klassen. Diese sollen nicht nur einen Eindruck vom jeweiligen System geben, sondern auch die
Umsetzung des jeweiligen Systems verdeutlichen. Daher enthalten die Codes, welche teilweise
auf das Wesentliche beschränkt sind, zum besseren Verständnis ebenfalls Kommentare.
T Person
PersID Name
Vorname DienstNr
123456 Homann Frank
000001
123457 Schmidt Harald
000002
Abbildung 20: Einfache Personentabelle
4.6.1
Persistierungsmöglichkeiten im Überblick
Es existieren natürlich viele Möglichkeiten, um innerhalb einer Datenbankapplikation Persistierung vorzunehmen. Im Falle von FlexiTrust hat man ebenfalls Objekt-basierte Java-Lösungen
und nicht nur reine Datenbank-basierte Lösungen zur Auswahl. Geeignet für die Anwendung
im TrustCenter FlexiTrust sind die folgenden:
• Manuelle Persistierung mit reinem JDBC,
• Serialization“,
”
• JDO o.ä.,
• Datenzugriffe über Cursor,
• Steuer- bzw. Hilfstabellen,
• Dynamische Strukturen bzw. Tabellendefinitionen.
Im Detail erläutert werden diese sodann in den Abschnitten 4.7 und 4.8. Man beachte, daß
bei allen Lösungen stets JDBC für die Grundlagen einer Datenbankverbindung genutzt wird
bzw. werden muß.
Persistierung bei einer Datenbankapplikation bezieht sich nicht nur auf das Speichern von
Daten oder Objekten in einer Datenbank sondern immer auch auf die Repräsentation von
Datenbankobjekten innerhalb des Applikationscodes, nämlich in Form von Repräsentationsschichten oder Repräsentationsklassen. Auch hierzu existieren unterschiedliche Lösungen, welche in Abschnitt 4.6.2 beschrieben werden. Da diese jedoch eng mit der Persistierung zusammenhängen, werden einige von ihnen auch in den Abschnitten über die Persistierungsmöglichkeiten gezeigt.
Des weiteren unterscheiden sich die später erläuterten Persistierungslösungen in ihrer jeweiligen Entwicklungssicht, also ob die Datenbankapplikation von Datenbankseite oder Codeentwicklungsseite aus beeinflußt wird (siehe auch Abschnitt 4.5.2).
– 74 –
4
4.6.2
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Repräsentationsschichten für einstufige und mehrstufige Objekte
In Abschnitt 4.5.1 wurde die Notwendigkeit zu Repräsentationsschichten bzw. Zugriffsschichten
für Datenbankobjekte, z.B. Personendaten, innerhalb einer Datenbankapplikation wie einem
TrustCenter erläutert. Solche Schichten bestehen aus einer oder mehreren Repräsentationsklassen, im Folgenden Java-Klassen, und können durchaus auch mehrstufig sein. Zur Realisierung
solcher Klassen existieren mehrere Möglichkeiten, sinnvoll sind:
• Allgemeine Repräsentationsklassen mit allgemeinen Datenbankoperationen,
• spezielle Repräsentationsklassen ohne Datenbankoperationen,
• spezielle Repräsentationsklassen mit allgemeinen Datenbankoperationen,
• spezielle Repräsentationsklassen mit speziellen Datenbankoperationen.
Der letzte Fall liegt z.Z. bei der FlexiTrust-OpenRA vor und wurde bereits in Abschnitt 4.4.1 in
Form der Klassen Entity.java“ bzw. Student.java“ gezeigt. Ein Nachteil dieser Möglichkeit ist
”
”
offensichtlich, nämlich die notwendige Neukompilation des Quellcodes nach der individuellen
Gestaltung entsprechender Klassen für ein Anwendungsszenario, z.B. der Angabe von speziellen
Attributen und Attributsnamen.
Eine Neukompilation ist hingegen bei allgemeinen Repräsentationsklassen nicht notwendig,
sofern Datenbankoperationen von Datenbankseite aus konfiguriert werden können. Dies hängt
von der jeweiligen Persistierungsweise ab.
Eine spezielle Repräsentationsklasse ohne Datenbankoperationen bedeutet, daß die Datenbankapplikation ausschließlich von der Codeentwicklungsseite aus gestaltet werden kann (siehe
z.B. Abschnitt 4.7.3 über JDO), was jedoch wiederum stets Neukompilationen nach sich zieht.
Folglich läßt sich sagen, daß alle Arten von Repräsentationsklassen bzw. derartigen Klassenstrukturen eine Objektrepräsentation darstellen. Es existiert also stets eine solche JavaObjektinstanz innerhalb einer Datenbankapplikation, wenn auf ein Datenbankobjekt zugegriffen werden soll, wobei die Repräsentationsklasse ebenfalls die Datenmanipulation zuläßt und
verwaltet.
Die Persistierung von geänderten Daten geschieht mittels Datenbankoperationen, die in der
Repräsentationsklasse enthalten oder separat implementiert sein können. Im letzten Falle wird
die Instanz der Repräsentationsklasse an die separate Implementierung übergeben.
Das folgende Beispiel zeigt einen Auszug aus einer speziellen Java-Repräsentationsklasse
ohne Datenbankoperationen. Das Beispiel bezieht sich dabei auf die Tabelle aus Abbildung 20:
public class PersonOnly{
private String name;
private String vorname;
private String dienstNr;
private int persID;
// klassischer Konstruktor
public PersonOnly(String name, String vorname,
String dienstNr, int persID){
this.name=name;
this.vorname=vorname;
this.dienstNr=dienstNr;
this.persID=persID;
}
– 75 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
public PersonOnly(){}
// klassische Setter-Methoden
public void setName(String name){
this.name=name;
}
// usw.
// klassische Getter-Methoden
public int getPersID(){
return persID;
}
// usw.
// z.B. für Tests
public void print(){
System.out.println(name + ", " + vorname + ", " + dienstNr + ", " + persID);
}
}
Hierbei sind klassische Set- und Get-Methoden, Setter und Getter, zu sehen. Diese bieten anderen Klassen und Applikationen die Möglichkeit, auf einzelne Attribute zu zugreifen und diese
auch zu verändern. Ein Vorteil der expliziten Modellierung von Attributen, dies beinhaltet etwa
die Angabe von speziellen Attributnamen, unter Java ist, daß man mittels Javadoc detaillierte
Erläuterungen zu den Attributen und z.B. ihren Settern im Quellcode angeben kann, woraus
sich automatisch Hilfen in HTML-Form erzeugen lassen. Daß dies bei der Eingabe von z.B.
Personendaten in einem bestimmten Kontext notwendig ist, ist natürlich nicht allgemeingültig.
Der Vorteil der folgenden allgemeinen Variante von Klassen-Konstruktoren, Settern und
Gettern, welche gleichermaßen zu allgemeinen Varianten von Datenbankoperationen ausgebaut werden können, ist, daß andere Klassen zum Zugriff auf die Repräsentationsklasse Attribute nicht explizit im Quellcode angeben müssen, sondern dies z.B. auf Konfigurationsdateien
ausgelagert werden kann. Ein Nachteil der allgemeinen Variante, also dem nicht expliziten
Modellieren von Attributen, gegenüber der klassischen ist, daß Javadoc nicht mehr direkt
anwendbar ist:
// allgemeiner Konstruktor
public PersonOnly(String[] Attributs, String[] AttributeValues){
for (int i=0;i<Attributs.length;i++){
if (Attributs[i].equals("Name")){
name=AttributeValues[i];
}
if (Attributs[i].equals("Vorname")){
vorname=AttributeValues[i];
}
if (Attributs[i].equals("DienstNr")){
dienstNr=AttributeValues[i];
}
if (Attributs[i].equals("PersID")){
persID=Integer.parseInt(AttributeValues[i]);
}
}
// usw.; Datentypen müssen natürlich beachtet werden.
// Dazu ist auch evt. eine separate Klasse denkbar, welche z.B.
// die Konvertierung von SQL nach Java vornimmt (mit Meta-Daten
– 76 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
// und der Hilfe des Interfaces java.sql.ResultSetMetaData).
}
// allgemeine Setter
public void setAttributs(String[] Attributs, String[] AttributeValues){
for (int i=0;i<Attributs.length;i++){
if (Attributs[i].equals("Name")){
name=AttributeValues[i];
}
if (Attributs[i].equals("Vorname")){
vorname=AttributeValues[i];
}
if (Attributs[i].equals("DienstNr")){
dienstNr=AttributeValues[i];
}
if (Attributs[i].equals("PersID")){
persID=Integer.parseInt(AttributeValues[i]);
}
}
}
public void setAttribute(String AttributeName, String AttributeValue){
if (AttributeName.equals("Name")){
name=AttributeValue;
}
if (AttributeName.equals("Vorname")){
vorname=AttributeValue;
}
if (AttributeName.equals("DienstNr")){
dienstNr=AttributeValue;
}
if (AttributeName.equals("PersID")){
persID=Integer.parseInt(AttributeValue);
}
}
// usw.
Die Modellierung von Attributen geschieht hier also über ein String-Array, wobei auch eine
noch allgemeinere Variante mittels Object[] AttributeValues möglich ist. Attribute nicht
explizit zu modellieren bedeutet, daß Informationen wie Attributnamen oder Datentypen der
Repräsentationsklasse anderweitig mitgeteilt werden müssen, etwa über Steuertabellen. Gerade bei den Datentypen geht jedoch die Typsicherheit der Attribute verloren, die man bei
expliziter Modellierung besitzt, z.B. durch die explizite Angabe des Datentyps Integer für ein
bestimmtes Attribut. Bei der Umwandlung von SQL-Datentypen auf der Datenbankseite zu
Java-Datentypen auf der Codeentwicklungsseite müssen jedoch stets verschiedene Probleme
beachtet werden, wie z.B. die Umwandlung eines String-Werts beliebiger Länge unter Java
in einen String-Wert fester Länge der Datenbank. Das Thema Typsicherheit wird jedoch im
Folgenden nicht weiter betrachtet und bleibt wie im obigen Beispiel nur angedeutet.
Basierend auf dieser Art der Modellierung von Attributen, zeigt das nachfolgende Beispiel
eine allgemeine Repräsentationsklasse mit allgemeinen Datenbankoperationen, wobei hier nur
die Lese- oder Lade-Operation implementiert ist. Auch hier werden nur allgemeine Setter- und
Getter-Varianten verwendet. Das Instanzieren einer bestimmten Klasse von Datenbankobjekten
geschieht dabei über einen entsprechenden zusätzlichen Parameter, hier der String Entity“:
”
– 77 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
import java.sql.*;
public class Entities{
private Connection con;
private Statement stm;
private String url = "jdbc:odbc:MyTestDB";
private ResultSet rs;
private String EntityName;
private String[] Attributs=new String[0];
private String[] AttributeValues=new String[0];
// Konstruktor; auch ein Einzel-Konstruktor ist denkbar
public Entities(String Entity, String[] Attributs, String[] AttributeValues){
System.arraycopy(Attributs,0,this.Attributs,
0,Attributs.length);
System.arraycopy(AttributeValues,0,this.AttributeValues,
0,AttributeValues.length);
// Alle Datentypen werden zunächst als Strings behandelt.
// Über ResultSetMetaData.getColumnType(...) bekommt man
// den SQL-Datentyp wieder. Binary-Typen müßten separat
// behandelt werden.
}
public Entities(){};
// Setter
public void setAttributs(String[] Attributs, String[] AttributeValues){
System.arraycopy(Attributs,0,this.Attributs,
0,Attributs.length);
System.arraycopy(AttributeValues,0,this.AttributeValues,
0,AttributeValues.length);
}
// Einzel-Setter
public void setAttribute(String AttributName, String AttributeValue){
int i;
for (i=0;i<Attributs.length;i++){
if (Attributs[i].equals(AttributName)){
break;
}
}
AttributeValues[i]=AttributeValue;
}
// Getter
public String[] getAttributNames(){
return Attributs;
}
// Getter
public String[] getAttributValues(){
return AttributeValues;
}
// Einzel-Getter
– 78 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
public String getAttribute(String AttributName){
int i;
for (i=0;i<Attributs.length;i++){
if (Attributs[i].equals(AttributName)){
break;
}
}
return AttributeValues[i];
}
// Aus DB laden
public void loadEntity(String Entity, String[] Attributs,
String[] AttributeValues){
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}catch(ClassNotFoundException e){};
try{
con = DriverManager.getConnection(url);
stm = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
rs = stm.executeQuery("Select * FROM T_" + Entity + " WHERE "
+ Attributs[0] + "=’" + AttributeValues[0] + "’;");
// nur beispielhaft; Eigentlich müßte hier der vollständige
// SQL-String über eine Schleife, aber automatisch,
// konstruiert werden.
ResultSetMetaData rsmd = rs.getMetaData();
rs.first();
String tmpAttributs[]= new String[rsmd.getColumnCount()];
String tmpAttributeValues[]= new String[rsmd.getColumnCount()];
int i;
for (i=0;i<rsmd.getColumnCount();i++){
tmpAttributs[i]=rsmd.getColumnName(i+1);
// Hiermit erhält man die Attributsnamen der Entity.
}
for (i=0;i<tmpAttributs.length;i++){
tmpAttributeValues[i]=rs.getString(tmpAttributs[i]);
// Hiermit erhält man die Attributswerte der Entity.
}
stm.close();
this.Attributs=tmpAttributs;
this.AttributeValues=tmpAttributeValues;
}catch(SQLException e){System.out.println(e);};
}
// In DB ablegen
public void storeEntity(){
// ähnlich loadEntity;
// z.B. über SQL od. Update-Methoden von ResultSet
}
// z.B. für Tests
public void print(){
int i;
for (i=0;i<Attributs.length;i++){
System.out.println(Attributs[i] + ": " + AttributeValues[i]);
}
– 79 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
}
}
Es wird hier deutlich, daß man beim Aufrufen einer Methode wie loadEntity nicht nur wissen
muß, welche Klasse von Datenbankobjekten gewünscht wird bzw. vorhanden ist sondern auch
welche Attribute vorhanden sind. Realisierungsmöglichkeiten zum automatischen Auslesen dieser Informationen bzw. Daten werden in den Abschnitten 4.7.1 und 4.8 vorgestellt.
Des weiteren ist für das Aufrufen von loadEntity usw. eine Fehlerbehandlung einzuführen
und zu entwickeln. Denn das Auftreten einiger Fehlerfälle ist durchaus möglich, wie z.B. die
Angabe von:
• fehlerhaften Attributnamen,
• nicht eindeutigen Suchkriterien (wodurch z.B. mehrere Datensätze gefunden werden),
• einer nicht ausreichenden Anzahl an Attributen für das Speichern.
Hier ist also die Entwicklung und das Einbinden weiterer Klassen für die Fehlerbehandlung
nötig aber auch möglich.39
Natürlich ist es möglich, den Code für die Datenbankverbindung auszulagern. Auch wird
der Tabellenname im Beispiel vom Entity-Namen abgeleitet, könnte jedoch ebenfalls z.B. in
einer Konfigurationsdatei oder Hilfstabelle (siehe Abschnitt 4.8.2) gespeichert werden. Die
Voraussetzung für dieses Beispiel ist also das Vorhandensein einer speziellen Tabelle, wie z.B.
T Person“ aus Abbildung 20.
”
Wie man im Beispiel erkennen kann, wird der Java-Cursor ResultSet und die zugehörigen
Meta-Daten, wie z.B. Attributsnamen einer Tabelle, zum Lese- und Schreib-Zugriff auf die
Daten verwendet. Dabei kann der Zugriff auf Attribute über einen Index bzw. Zählwert oder
über den Attributsnamen geschehen. Im letzten Falle wird dieser dann einfach als String-Wert
übergeben.40 So wird es ermöglicht, auf Attributsnamen dynamisch zu zugreifen und diese
somit für den Quellcode konfigurierbar zu machen. Alternativ läßt sich die Datenmanipulation
auch sinnvoll über SQL betreiben (siehe auch Abschnitt 4.3.1).
Mehrstufige Objekte bzw. Klassen entstehen in der Objektorientierung durch Vererbung
und sind dort selbstverständlich. Diese lassen sich ebenfalls in einer Datenbank abbilden und
entstehen durch die Verknüpfung entsprechender Tabellen bzw. deren Beziehung (siehe auch
Abschnitt 3.4.3).
Im folgenden Beispiel wird aus der bereits gezeigten Klasse PersonOnly.java“ eine Klasse
”
ChefFromPersonOnly.java“ abgeleitet. Objektorientierung und Vererbung sind wohlbekannt
”
(siehe z.B. [Ull00]), daher wird an dieser Stelle auf eine nähere Erläuterung dieser Prinzipien
verzichtet und das für den Kontext wesentliche hervorgehoben:
import PersonOnly;
public class ChefFromPersonOnly extends PersonOnly{
private String DienstwagenNr;
private String ChefsesselNr;
private String AddrStr;
private String AddrOrt;
39 Das Interface ResultSetMetaData bietet beispielsweise die Möglichkeit mittels der Methode isNullable optionale Attribute
logischer Strukturen abzufragen. Ein andere Möglichkeit wäre es mit Hilfe von Steuertabellen manuell festzulegen, z.B. auch für
den speziellen Anwendungskontext, welche Attribute angegeben werden müssen und welche nicht.
40 Dies ist eine übliche Entwicklungsstrategie und wird auch bei anderen Cursor-System verwendet, z.B. Microsoft ADO.
– 80 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
// Simpler Konstruktor
public ChefFromPersonOnly(String name, String vorname,
String dienstNr, int persID){
super(name, vorname, dienstNr, persID);
}
// Setter-Beispiel
public void setChef(String DienstwagenNr, String ChefsesselNr,
String AddrStr, String AddrOrt){
this.DienstwagenNr=DienstwagenNr;
this.ChefsesselNr=ChefsesselNr;
this.AddrStr=AddrStr;
this.AddrOrt=AddrOrt;
}
// z.B. für Tests (gibt nur die Chef-relevanten Attribute aus)
public void printChef(){
System.out.println(DienstwagenNr + ", " + ChefsesselNr
+ ", " + AddrStr + ", " + AddrOrt);
}
// Alternativ könnte man z.B. alle Methoden und Attribute der
// Ursprungsklasse überschreiben.
}
Ob die Verteilung von Attributen in diesem Beispiel sinnvoll ist, sei dahingestellt. Zu beachten
ist, daß hier ChefFromPersonOnly“ alle Attribute und Methoden der übergeordneten Klasse
”
PersonOnly“ erbt und somit ebenfalls besitzt. Auch ist es denkbar, daß weitere Klassen direkt
”
von PersonOnly“ oder von bereits abgeleiteten Klassen erneut abgeleitet werden, dabei spricht
”
man von Spezialisierung.
Nun muß auch bei solchen abgeleiteten Repräsentationsklassen, eine Umwandlung von
Codeobjekt in ein Datenbankobjekt erfolgen. Eine übliche Methode der Persistierung einer
Objekt-Instanz, von ChefFromPersonOnly“ beispielsweise, mit allen konkreten Attributwer”
ten auch seiner Oberklasse, hier PersonOnly“, erfolgt dazu über Beziehungen bzw. Fremd”
schlüssel-Beziehungen (siehe auch Abschnitt 3.4.3), wobei für die Repräsentationsklassen jeweils eine Tabelle vorgesehen ist. D.h., in der zugehörigen Datenbank können zwei Tabellen
existieren, nämlich die Basistabelle T Person“ und T Chef“, wobei dann für jeden Daten”
”
satz in T Chef“ stets auch ein zugehöriger Datensatz in T Person“ existieren muß, um die
”
”
referentielle Integrität zu gewährleisten (siehe auch 4.10.8).
Die zu den beiden Repräsentationsklassen implementierten Datenbankoperationen für das
Laden und Speichern eines Datenbankobjekts sowie dessen Umwandlung in ein Codeobjekt
und umgekehrt, verwalten die Verknüpfung der Tabellen. Diese erfolgt durch die Angabe des
Fremdschlüssels und des passenden Tabellennamens, was bei mehreren abgeleiteten Klassen
meist unumgänglich ist, in T Chef“. Der Fremdschlüssel ist gleichzeitig Primärschlüssel in
”
T Person“, womit eine eindeutige Zuordnung zwischen den Tabellen möglich wird. Solche
”
Beziehungen zwischen Tabellen sind bei der Entwicklung von Datenbanken üblich, wobei die
Datenbank in einer solchen Beziehung keine Vererbung sieht.
Das obige Beispiel ist nur eine andere und vereinfachte Form der Variante, wie sie schon
in Abschnitt 4.4.1 bei der OpenRA gezeigt wurde. Dort wurde aus der allgemeinen Enti”
ty.java“, die nur mit in einem TrustCenter notwendigen Attributen und Methoden, z.B. für
Distinguished Names, ausgestattet ist, die Klasse Student.java“ abgeleitet, welche wiederum
”
etwa das Attribut Matrikelnummer“ enthält. Das Besondere hierbei ist, daß in der Enti”
”
ty.java“ bereits ein Attribut vorgesehen ist, welches über einen String-Wert den eindeutigen
– 81 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Bezeichner, nämlich hier als Package-Identifikation, der abgeleiteten Entity-Klasse speichert.
Dies ist z.B. dann hilfreich, wenn eine Auflistung von Daten aller Entity-Klassen erfolgen muß.
Denn auf diese Weise ist es möglich, nur aufgrund des Wertes dieses Attributs, welches alle
Entities besitzen, die Zuordnung der Daten zu einer bestimmten Entity-Klasse bzw. zu einem
bestimmten Entity-Typ zu vollziehen.
Entity.java“, Student.java“ und andere Klassen wurden bei FlexiTrust im Anwendungs”
”
szenario der Universität eingesetzt (siehe Abschnitt 4.2.1). Das Persistieren dieser Klassen
erfolgt auch hier zunächst über die Basistabelle, z.B. T Entity“, in welcher alle zugehöri”
gen Attribute der allgemeinen Klasse gespeichert werden. Andere Tabellen, z.B. T Student“,
”
speichern hingegen die Attribute der speziellen bzw. abgeleiteten Klassen. Die Verknüpfung
beider Tabellen erfolgt durch einen Fremdschlüsseleintrag in z.B. T Student“, wobei auch
”
der Name der Oberklasse bzw. Basistabelle, hier T Entity“, angegeben sein muß. Über diese
”
Verknüpfung erhält man dann vollständig die Attribute und Daten des Typs Student“. Von
”
der Codeentwicklungsseite aus stammen alle Datenbankobjekte von der Klasse Entity.java“
”
ab.
Für das hier entwickelte TrustCenter-Modell werden also mehrstufige Objekte verwendet,
was auch bereits im Datenmodell aus Abbildung 17 von Seite 53 zu sehen ist (siehe auch
Abschnitt 4.1). Ihr Vorteil ist die Spezialisierung von notwendigen Daten für eine bestimmte
Entity, z.B. Chef“, sowie die Nutzung von und der Zusammenhang zu vorhandenen Entities,
”
z.B. Person“.
”
Eine alternatives Modell dazu ist in Abbildung 18 auf Seite 56 angedeutet. Alle Entities
werden zu einer zusammengefaßt und auch in einer einzigen gemeinsamen Relation mit allen
zugehörigen Attributen festgehalten. Die hier fehlende Verteilung von Daten hat zum Nachteil,
daß keine speziellen Entity-Klassen auf Datenbankebene existieren, sondern Entities nur durch
die jeweiligen Daten charakterisiert sind, und viele Attribute für jeweilige Entities schlichtweg
ungenutzt bleiben.
Die unterschiedlichen, hier gezeigten Repräsentationsschichten unterscheiden sich stark in
der Art und Notwendigkeit zur Nutzung von SQL-Queries für Datenbankoperationen. Dies ist
unproblematisch, wenn SQL-Queries einmalig entwickelt werden müssen, z.B. für eine sich
später nicht mehr ändernde allgemeine Repräsentationsklasse. Bei speziellen Repräsentationsklassen mit Datenbankoperationen hingegen, kann eine ständige Änderung der SQL-Queries
im Kontext einer TrustCenter-Entwicklung nötig sein. Dies wirkt sich auf die Zeit und Fehleranfälligkeit der Entwicklung aus.
Weitere Details zu Repräsentationsschichten inkl. notwendiger Datenbankoperationen werden in den Abschnitten 4.7 und 4.8 erläutert. Eine Methode etwa, die gänzlich ohne Klassenattribute auskommt und auf dem Java-Cursor ResultSet basiert, findet sich in Abschnitt
4.8.1.
4.7
Objekt-basierte Java-Lösungen
Neben der objektorientierten Programmierung existieren seit einiger Zeit auch objektorientierte
Datenbanksysteme. Diese haben zum Ziel, z.B. die Erstellung von Tabellen auch auf Basis von
Prinzipien der Objektorientierung, wie Vererbung, integriert durchzuführen und nicht etwa
manuell wie in Abschnitt 4.6.2 gezeigt. Auch hierfür gibt es Konzepte und Standards, wie z.B.
spezielle DBMSs, sowie Datenbanksysteme, die diese unterstützen. Da es sich jedoch um eine
im Vergleich zu relationalen Datenbanken jüngere Entwicklung handelt, sind objektorientierte
Datenbanksysteme noch nicht weitverbreitet, wenngleich es sich auch hierbei um ein gutes
Prinzip zur Realisierung einer Datenbank handelt (siehe z.B. [Heu00]).
– 82 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Da also einfache relationale Datenbanken z.Z. wesentlich verbreiteter sind, soll sich der
Entwickler einer Datenbankapplikation zur Persistierung von Daten auf diese beschränken.
Objekt-basierte Persistierungsmöglichkeiten, also Werkzeuge für das Objekt-RelationaleMapping, haben zum Ziel, einem Applikationsentwickler sämtliche Datenbankoperationen abzunehmen, so daß dieser rein objektorientiert entwickeln kann. Das bedeutet, daß der Entwickler etwa von SQL-Anweisungen vollständig entbunden wird.
Werkzeuge für das Objekt-Relationale-Mapping sind größtenteils Persistenz-Frameworks.
Ein Persistenz-Framework bildet dabei nach oben geschilderten Grundlagen Objekte der entsprechenden objektorientierten Programmiersprache automatisch in Tabellen der der Applikation zugrundeliegenden Datenbank ab. Dies ist beim manuellen Mapping, wie z.B. in den
Abschnitten 4.4.1 und 4.6.2 gezeigt, nicht der Fall, wo Datenbankoperationen zum Laden und
Schreiben manuell erstellt wurden.
Persistenz-Frameworks hingegen können ebenfalls mit abgeleiteten Klassen bzw. mehrstufigen Objekten umgehen, eine manuelle Verwaltung dieser, z.B. durch Tabellen-Beziehungen,
ist nicht nötig (siehe auch Abschnitt 4.6.2).
In Java existieren für die Persistierung von Objekten viele Möglichkeiten, welche im Folgenden auch diskutiert werden. Das geeignetste Persistenz-Framework unter Java ist JDO.
Hierbei handelt es sich um eine junge, vielseitige und prominente Interface-Struktur, welche
im Mai 2001 von vielen Entwicklergruppen erstellt und später standardisiert wurde, u.a. von
Sun, IBM und Apple.
David Jordan, ein Mitentwickler der Java Data Objects (JDO), faßt das Entwickeln einer
Datenbankapplikation unter Java ohne automatisches Objekt-Relationales-Mapping wie folgt
noch einmal zusammen:
An application is forced to deal with two very different data models: The Java
”
Object Model and the Relational Data Model.“
Neben JDO existieren auch andere Werkzeuge bzw. Frameworks für das Objekt-RelationaleMapping, wenngleich sie nicht die vorliegende Standardisierung und Einfachheit von JDO
bieten können:
• ObjectStore PSE,
• JPOM (API mit automatischer Erzeugung von SQL-Anfragen, entstanden aus einem
Universitätsprojekt; siehe auch [Jav04]),
• DbGen von 2LINK,
• TopLink (renommierte Mapping-Produkte angefangen bei Smalltalk und auch für Java),
• SimpleORM,
• Quasar Persistence (OpenSource, leider mit radikaler Klassenänderung verbunden; siehe
z.B. [Ern04] oder sourceforge.net).
Bis auf letzteres System handelt es sich hier um kommerzielle Produkte und natürlich ist man
bei entsprechender Nutzung auf dieses spezielle System beschränkt sowie davon abhängig.
Die Grundlage aller Systeme für die reine Datenbankverbindung ist hier meist JDBC, wie
z.B. auch im Falle von JDO.
– 83 –
4
4.7.1
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Manuelle Persistierung mit reinem JDBC
In Abschnitt 4.3.1 wurde gezeigt, wie man unter Java eine Datenbankverbindung aufbaut und
Datenbankoperationen ausgeführt werden können. Das Ausführen von SQL-Queries und das
Erzeugen eines Cursor-Objekts wurde dort ebenfalls demonstriert.
Alle diese Systeme macht man sich nun bei der manuellen Persistierung mit reinem JDBC
zunutze, um eine individuelle manuelle Mapping-Methode zu entwickeln. D.h., man erstellt ein
eigenes System zum Objekt-Relationalen-Mapping, mit welchem man eine Repräsentationsklasse auf eine relationale Datenbank abbilden kann. Dies liegt z.B. bei der OpenRA vor und
wurde bereits u.a. in Abschnitt 4.4.1 gezeigt.
Beim manuellen Persistieren bzw. Mapping von Objekten übernimmt der Entwickler folgende Tätigkeiten:
• Manuelle Codierung der Transformation eines Codeobjekts in ein Datenbankobjekt bzw.
in das Datenmodell,
• Manuelle Codierung der umgekehrten Transformation eines Datenbankobjekts zu einer
Instanz einer Codeklasse,
• Entwickeln von SQL-Queries und/oder Cursor-Operationen für Einfügen, Ändern und
Laden,
• Behandeln bereits geladener oder noch nicht geladener Datenbankobjekte.
Letzteres ist eigentlich stets und bei jeder Persistierungsmöglichkeit erforderlich. Dazu gehört
vor allem eine Konzeptentwicklung für den jeweiligen Anwendungskontext.
Manuelles Mapping wurde bereits z.B. im Abschnitt 4.6.2 gezeigt und ist bei der Klasse
Entities.java“ etwa anhand der Methode loadEntity zu sehen. Dort wird die Transformation
”
eines Datenbankobjektes in die Form einer Java-Klasse bzw. Repräsentationsklasse vollzogen.
Dies geschieht durch das Auslesen der entsprechenden Tabellenattribute und das Setzen der
lokalen Variablen der Java-Klassen.
D.h., bei dieser Realisierungsweise werden die notwendigen Mapping-Methoden, also Datenbankoperationen etwa für Laden und Speichern eines Objekts, eigenständig und individuell
entwickelt. Nach dieser Entwicklung ist allerdings ein automatisches Persistieren von Objekten
im Anwendungskontext möglich. Eine solche individuelle Mapping-Entwicklung hat zwar den
Nachteil des Entwicklungsaufwands, aber natürlich gleichermaßen den Vorteil, daß eine Anpassung für jegliche Anwendungsszenarien möglich ist. Diese Variante ist also äußerst flexibel.
Bei der OpenRA liegt dieser Fall ebenfalls vor, wobei hier spezielle Repräsentationsklassen
verwendet werden, die entsprechende Datenbankoperationen bzw. Mapping-Methoden enthalten.
Des weiteren müssen bei der OpenRA immer beide Entwicklungsseiten, nämlich die Seite der Codeentwicklung und der Datenbankentwicklung, in Anspruch genommen werden. Dies
bedeutet, daß neben der speziellen Repräsentationsklasse für ein Anwendungsszenario auch die
Datenbankstruktur entwickelt werden muß. Letztere besteht also stets aus individuellen Tabellendefinitionen, welche im Quellcode direkt angesprochen werden, wobei hier auch StandardMuster für SQL-Anweisungen verwendet werden, um den Entwicklungsaufwand zu minimieren.
Jedoch ist es ebenfalls möglich, manuelles Mapping mit allgemeinen Repräsentationsklassen zu betreiben, z.B. mit einer Klasse wie der Entities.java“. Dies würde bedeuten, fast
”
ausschließlich von Datenbankseite aus entwickeln zu können. Dazu ist es allerdings notwendig, der allgemeinen Repräsentationsklasse sowie anderen Applikationsteilen zum Zugriff auf
bestimmte Datenbankobjekte deren Struktur mitzuteilen, so daß der Typ der gewünschten
– 84 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Datenbankobjekte einfach instanziert werden kann, z.B. über einen Parameter. So wäre eine
Änderung von SQL-Anweisungen ebenfalls nicht notwendig sondern lediglich eine Erstentwicklung.
Lösungen, welche es für das manuelle Mapping mit allgemeinen Repräsentationsklassen erlauben, Tabellenstrukturen automatisiert auszulesen, sind z.B. Steuertabellen oder dynamische
Strukturen (siehe auch Abschnitte 4.8.2 und 4.8.3).
Bei mehrstufigen Objekten muß für eine allgemeine Repräsentationsklasse (siehe Abschnitt
4.6.2) in einer reinen JDBC-Lösung mit individuellen Tabellen eine Steuertabelle eingeführt
werden, die der Repräsentationsschicht die Beziehung der verschiedenen Entities bzw. Datenbankobjekte mitteilt. Eine solche Steuertabelle ist T Relation(FromTab,FromAttr,ToTab,To”
Attr)“, sie macht es möglich, daß in einer Repräsentationsklasse alle Attribute eines mehrstufigen Objekts automatisch eingefügt werden können. Die allgemeine Repräsentationsklasse
erhält dazu z.B. im Konstruktor, wie schon gezeigt, einen zusätzlichen Parameter, welcher die
gewünschte Klasse von Datenbankobjekten angibt. Auch der Umgang mit mehr als einer Stufe
ist hier möglich sowie durch zusätzliche Erweiterungen mit 1:n“-Beziehungen, welche aber
”
zwischen Entity-Objekten in der Regel nicht auftreten.
Abbildung 21 zeigt beispielhaft, wie sich die Tabelle T Relation“ an entsprechender Stelle
”
im ursprünglichen TrustCenter-Datenmodell aus Abbildung 17 einfügt.
Abbildung 21: Tabelle T Relation im TrustCenter-Datenmodell
Für den Join (siehe auch Abschnitt 3.5.1) bzw. das Zusammensetzen eines mehrstufigen
Objekts, z.B. eines vollständigen Datenbankobjekts Chef“ (siehe auch Abschnitt 4.6.2), wird
”
nun die Tabelle T Relation“ herangezogen, welche einen Datensatz enthält, der die Ver”
knüpfung der Tabellen T Person“ und T Chef“ darstellt. Sei z.B. das Attribut PersonID“
”
”
”
der Fremdschlüssel in T Chef“ bzgl. T Person“ und das Attribut ID“ der Primärschlüssel
”
”
”
in T Person“. Dann lautet der entsprechende Datensatz in T Relation“, der die Fremd”
”
schlüssel-Beziehung (siehe auch Abschnitt 3.4.3) zwischen den Tabellen leicht auslesbar macht,
T Chef;PersonID;T Person;ID“. Bei gleicher Benennung der Attribute für die Schlüssel, würde
”
sogar eine kürzere Tabellendefinition für T Relation“ ausreichen (siehe Abbildung 21). Auf
”
diese Weise lassen sich alle Attribute und Attributswerte eines Datenbankobjekts Chef“ aus
”
beiden Tabellen automatisiert bestimmen.
Auch das Erzeugen einer Instanz einer allgemeinen Repräsentationsklasse für ein beliebiges
mehrstufiges Objekt ist auf diese Weise also ohne Codeänderungen stets möglich. Der Nachteil
dieser Variante im Vergleich zur direkten Implementierung von Tabellen-Beziehungen, also ohne T Relation“, ist, daß das Lesen eines zusätzlichen Datensatzes oder mehrerer, nämlich aus
”
T Relation“, für das Auslesen eines jeden Datenbankobjekts notwendig wird. Dadurch ist die
”
– 85 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Tabelle T Relation“ auch stark frequentiert. Beides wirkt sich natürlich je nach Anzahl der
”
Datenbankzugriffe negativ auf die Rechenleistung der Datenbankapplikation aus. Des weiteren
muß nach dem Festlegen der Datensätze in T Relation“ für ein bestimmtes Anwendungssze”
nario eine zusätzliche Fehlerkontrolle erfolgen, z.B. bzgl. der Vollständigkeit der dargestellten
Tabellen-Beziehungen usw.
Bei der OpenRA werden hingegen spezielle Repräsentationsklassen genutzt. Das manuelle
Mapping für mehrstufige Objekte in diesem Fall wurde jedoch bereits an zwei Beispielen in
Abschnitt 4.6.2 erläutert.
Vorteile
• Das manuelle Mapping bedeutet zwar Entwicklungsaufwand, der bei der Erstentwicklung
sicherlich am größten ist bzw. war, auf der anderen Seite ist die Variante äußerst flexibel und auch auf ungewöhnliche sowie sehr individuelle Anwendungsszenarien ist eine
Anpassung möglich.
• Diese Variante ist von keiner externen Entwicklung oder Systemlösung abhängig.
• Das benutzte und entwickelte Datenmodell läßt sich direkt auf Tabellen abbilden, wodurch
auch die abgelegten Daten und somit Informationen in der Datenbank sehr direkt erfaßbar
und lesbar sind.
• Durch den direkten Zugriff auf spezielle Tabellenstrukturen ist diese Variante effizient, was
die Rechenleistung, Wartung sowie Erstellung von Datenbank-Berichten bzw. DatenbankAuszügen betrifft.
Nachteile
• Beim Nutzen spezieller Repräsentationsklassen liegt ein ständiger Entwicklungsaufwand
für das Anpassen an individuelle Anwendungsszenarien vor, was notwendige Neukompilationen mit einschließt. Dies ist ein spezieller Nachteil im Kontext einer TrustCenterApplikation, welche in verschiedenen Anwendungsszenarien zum Einsatz kommen kann.
Im Gegensatz dazu steht der Entwicklungsaufwand des manuellen Mappings bei einer
Datenbankapplikation für einen einzigen bestimmten Anwendungsfall. Denn hierbei ist
nur eine einmalige Entwicklung inklusive Tests und Fehlerkontrolle notwendig.
Fehler können beim manuellen Mapping beispielsweise durch die vom Entwickler selbst
vorzunehmende Umwandlung von Datentypen der Datenbank in Datentypen des Quellcodes vorkommen. Das Problem der Typsicherheit (siehe auch Abschnitt 4.6.2) besteht beim
manuellen Mapping dabei unabhängig vom Typ der gewählten Repräsentationsklasse.
• Je nach genutzter Repräsentationsform muß der Entwickler stets SQL-Anweisungen individuell anpassen, auch wenn ihm dazu Standard-Muster vorliegen.
• Dadurch, daß keine Standard-Strukturen genutzt werden, liegen von der Codeentwicklungsseite ebenfalls keine offensichtlich nachvollziehbaren Strukturen und Systeme vor,
was in TrustCentern problematisch sein kann. Denn auch die Korrektheit der Funktionalität der individuell entwickelten TrustCenter-Applikation muß gewährleistet und u.U.
nachweisbar sein.
– 86 –
4
4.7.2
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Serialization“
”
Serialization bzw. die Serialisierung eines Objekts ist eine unter Java gebräuchliche Vorgehensweise, um eine Objektinstanz als Ganzes zu behandeln. Dazu wird das Objekt in einen
serialisierten Bytestrom, also einen Binärwert, umgewandelt. Dies ist die einfachste Art, um
Objekte zu persistieren, da so Objekte direkt z.B. in Dateien gespeichert werden können. Auch
wird diese Vorgehensweise bei der Java Remote Method Invocation (RMI) genutzt, um Objekte
über ein Netzwerk zwischen Computern zu verschicken (siehe [Sun01]).
In jedem Falle erlaubt Serialization die Nutzung von speziellen und allgemeinen Repräsentationsklassen, wobei Datenbankoperationen sinnvollerweise separat implementiert werden. Denn
die Repräsentationsklasse ist es auch, welche als Objektinstanz durch Serialisierung persistiert
wird. Unter Java muß diese Klasse dazu das Interface Serializable implementieren. Man
beachte dabei, daß dieses Interface folgendes Aussehen hat:
package java.io;
public interface Serializable {
}
Es gehört so zum offiziellen JDK und dient sozusagen nur zur Kennzeichnung von Klassen
bzw. Objekten, die serialisiert werden sollen. Primitive Datentypen lassen sich dabei einfach
und direkt serialisieren und somit auch Objekte, die aus solchen bestehen. Andere Datentypen
sind jedoch ebenfalls serialisierbar, was hier aber nicht näher erläutert wird (siehe z.B. [Ull00]).
Das folgende Beispiel zeigt eine einfache Repräsentationsklasse für Personen, die serialisiert
werden soll:
import java.io.Serializable;
public class PersonSerial implements Serializable{
private String name;
private String address;
// "transient" vor Variable verhindert
// die Persistierung;
// komplexere Datentypen ggf. durch
// Sonderbehandlung persistierbar!
public void setPerson(String myName, String myAddress){
name=myName;
address=myAddress;
}
}
Das folgende ausführbare Programm erzeugt nun ein entsprechendes Objekt und persistiert es
auch gleich, als Beispiel in eine Datei:
import PersonSerial;
import java.io.*;
public class testPersonSerial{
public static void main (String args[]){
System.out.println("Erzeuge Personen-Objekt...");
PersonSerial myPerson = new PersonSerial();
– 87 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
myPerson.setPerson("Dr. Huxtable",
"Stickwood Avenue 10, Brooklyn - New York");
try{
FileOutputStream out =
new FileOutputStream("testPersonSerial.txt");
try{
ObjectOutputStream os = new ObjectOutputStream(out);
os.writeObject("HIERBINICH");
// nur als Kennzeichner für die Datei :-)
os.writeObject(myPerson);
os.flush();
os.close();
}catch(FileNotFoundException e){};
}catch(IOException e){};
System.out.println("Ende der Datei-Persistierung
(siehe testPersonSerial.txt).");
}
}
Über die Strukturen des InputStream ist natürlich ähnlich auch das Wiedereinlesen von Objekten, aus z.B. der Datei, möglich.
Zur Persistierung in Kombination mit einer Datenbank ist die Methode der Serialisierung
jedoch nicht grundsätzlich vorgesehen. D.h., es existieren keine standardmäßigen Klassen, die
es erlauben, ein serialisiertes Objekt in eine Datenbank zu schreiben oder daraus zu laden.
Es ist jedoch denkbar, die Methoden des OutputStreams zu überschreiben, wie die Methode
writeObject. Dies hat zur Folge, daß Verwaltungsmethoden und somit Datenbankoperationen selbst entwickelt werden müssen.
So kann man ein serialisiertes Codeobjekt als Binärwert im Datensatz einer Tabelle, welcher das passende Datenbankobjekt darstellt, abspeichern. Damit wären beide Objektarten
eindeutig verknüpft. Eine Lademethode, also das Wiedereinlesen eines serialisierten Codeobjekts, ist damit leicht zu implementieren, was ein Ziel der Persistierung darstellt. So ist es
beispielsweise nicht nötig wie beim manuellen Mapping die Attributwerte eines Datensatzes
einzeln in Variablen einer Repräsentationsklasse einzufügen. Eine Alternative ist, in der Datenbank nicht die vollständigen Datenbankobjekte zu sichern, weil diese Daten im jeweiligen
abgelegten Codeobjekt vorhanden sind, sondern nur die minimalen und zur Suche notwendigen
Daten.
Beachtenswert ist es offensichtlich, Datenbankobjekte und abgelegte serialisierte Codeobjekte mit eigenen Methoden synchron zu halten, was hier ebenfalls implementiert werden muß.
Dies ist nämlich nötig, um ein Objekt aus einer Datenbank wie oben beschrieben (neu) zu
laden, da zunächst ein entsprechender Suchvorgang, z.B. über eine Tabelle, vorausgeht. Dieser
Vorgang findet auf Basis der Datenbankobjekte statt, auf welche, etwa mittels Indexstrukturen, wesentlich effizienter zur Suche zugegriffen werden kann und die im Gegensatz zu den
Codeobjekten nicht erst als Java-Objekt instanziert werden müssen, um sie zu lesen.
Zur Implementierung derartiger Datenbankoperationen für die Serialisierung müssen also
Methoden verwendet werden, die sich stark mit denen des manuellen Mappings überschneiden
(siehe auch Abschnitte 4.3.1 und 4.7.1).
Statt also weiter die Methode der Serialisierung zu verfolgen, welche keine grundsätzliche
Unterstützung für Datenbanken bietet, ist es sinnvoller JDO zu betrachten, welches genau das
– 88 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
und eine ähnliche Einfachheit wie die Serialisierung bietet.
Diese Aspekte der und weitere Details zur Serialisierung unter Java finden sich z.B. in [Ull00]
im Kapitel Persistente Objekte und Serialisierung“ oder in [Kru00] im Kapitel Serialisierung“.
”
”
Vorteile
• Serialisierung ist eine altbekannte und für verschiedene Anwendungsbereiche StandardLösung unter Java.
• Die reine Persistierung setzt keine Entwicklung von speziellen Java-Klassen voraus, die
zu persistierende Klasse muß lediglich durch die Implementierung des entsprechenden Interfaces quasi gekennzeichnet werden, was eine einfache Persistierungslösung ermöglicht.
Auch mehrstufige Objekte werden standardmäßig unterstützt.
Nachteile
• Die Intention hinter der Serialisierung ist nicht die Abbildung auf eine relationale Datenbank und wird demzufolge auch nicht ohne Zusatzaufwand unterstützt.
• Für eine Datenbank-Lösung mit Serialisierung, etwa beim Ablegen des serialisierten Objekts als Binärwert im passenden Registrierungsdatensatz bei einem TrustCenter, müssen
zusätzliche Methoden zur Datenbankverwaltung implementiert werden, etwa zum Synchronisieren von Codeobjekt und Datensatz.
Durch den Zusatzaufwand für die Entwicklung von Datenbankoperationen leidet die Effizienz bei der Applikationsentwicklung sowie im Betrieb, und die Einfachheit der Serialisierung geht verloren.
Des weiteren muß ein ähnlicher Entwicklungsaufwand betrieben werden, wie beim manuellen Mapping, was jedoch im Vergleich zur Serialisierung mehr Vorteile besitzt (siehe
auch Abschnitt 4.7.1).
• Auch wenn die Serialisierung direkt im JDK nutzbar ist und unterstützt wird, ist JDO
eine geeignetere, wenn auch teilweise kommerzielle, Lösung für Datenbanken.
4.7.3
JDO
Die Persistierung mittels JDO ist noch einfacher möglich als bei der Serialisierung und vor
allem speziell für Datenbanken entwickelt worden. JDO greift dabei lediglich für die reine
Datenbankverbindung auf JDBC zurück.
Der Entwickler kann sich bei JDO auf die reine Codeentwicklung unter Java konzentrieren.
Er entwickelt dazu z.B. eine spezielle Repräsentationsklasse ohne Datenbankoperationen. Diese
ist nun die einzige Zugriffsmethode auf Objektattribute für die gesamte Datenbankapplikation.
Das Laden und Speichern von Objekten geschieht über JDO-Methoden fast automatisch, vor
allem im Vergleich zum manuellen Mapping. JDO schreibt dazu die vollständige Objektinstanz in die zugrundeliegende Datenbank und stellt ebenfalls effiziente Suchmethoden für das
Wiederherstellen zur Verfügung. Auch mehrstufige Objekte müssen nicht durch eine Sonderbehandlung persistiert werden.
Der Entwickler der Datenbankapplikation beschäftigt sich also gar nicht mehr mit der
Datenbankentwicklung sondern mit der reinen Applikationsentwicklung. Das Erstellen logischer
Strukturen etwa wird von JDO übernommen und geschieht automatisch.
– 89 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Zu beachten ist, daß es sich bei JDO einerseits um einen Standard für das JDK und
andererseits um ein Framework bzw. eine Interface-Struktur handelt. Eine Implementierung
dieser ist zum Benutzen von JDO notwendig. Dies ist vergleichbar mit den Strukturen, wie sie
beim JCA vorliegen, was in Abschnitt 4.3 anhand des zugehörigen FlexiProviders eingeführt
wurde.
Eine Implementierung der JDO-Interfaces nennt man ebenfalls Provider. Leider ist für JDO
noch keine kostenlose bzw. freie Implementierung vorhanden. Das grundlegende Prinzip eines
derartigen Frameworks wie JDO bietet jedoch die Möglichkeit, einen Providerwechsel äußerst
einfach durchzuführen, womit die eigene Applikation zumindest flexibel ist.
Im Folgenden sind verschiedene JDO-Implementierungen bzw. JDO-Produkte aufgeführt,
die sich in ihrer Leistungsfähigkeit sicherlich nicht sehr unterscheiden:
• FastObjects von Poet Software GmbH,
• intelliBO von Signsoft,
• Kodo JDO von Solarmetric,
• ObJectRelationalBridge (OJB).
Hervorzuheben bleibt, daß es sich hierbei fast ausschließlich um kommerzielle Produkte handelt,
wobei die Entwicklung von OJB als bisher einzige freie Entwicklung noch nicht vollständig fertig
gestellt ist.
FastObjects (siehe auch [Poe03]) ist eine empfehlenswerte kommerzielle Implementierung
mit ausführlicher Spezifikation sowie Dokumentation und trotz des jungen Alters von JDO in
der Praxis schon etabliert, wobei dies sicherlich ebenso für andere Produkte gilt. Ein Pressetext
von Poet zeigt ein Anwendungsbeispiel:
Mit über 13.500 Kunden bundesweit gehört TurboMed zu den führenden Unter”
nehmen in der Branche der Praxisverwaltungssysteme. Natürlich muß dann auch die
integrierte Datenbank-Lösung einen wartungsfreien Betrieb in den Praxen gewährleisten können.“
Der Umgang mit und die Einfachheit von JDO bei der Persistierung von Objekten soll am
folgenden Beispiel demonstriert werden. Ähnlich wie bei der Serialization wird eine spezielle
Repräsentationsklasse ohne jegliche Datenbankoperationen entwickelt (vgl. Klasse PersonOn”
ly“ in Abschnitt 4.6.2):
package MyJDOExample;
public class JDOPerson{
private String name;
private String vorname;
private String dienstNr;
private int persID;
// klassischer Konstruktor
public JDOPerson(String name, String vorname, String dienstNr, int persID){
this.name=name;
this.vorname=vorname;
this.dienstNr=dienstNr;
this.persID=persID;
}
– 90 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
// klassische Setter-Methoden
public void setName(String name){
this.name=name;
}
// usw.
// klassische Getter-Methoden
public int getPersID(){
return persID;
}
// usw.
}
Im folgenden ausführbaren Programm wird beispielhaft eine solche Person erzeugt und mittels
JDO in einer Datenbank persistiert. Für das Setzen der Optionen für die Datenbankverbindung
wird auf die Klasse Properties zurückgegriffen, was diese Optionen aufgrund der Nutzung
von Strings leicht konfigurierbar macht, z.B. über eine Konfigurationsdatei. Das Programm
ist natürlich ohne eine konkrete JDO-Implementierung nicht lauffähig, wobei dazu an der mit
***“ gekennzeichneten Stelle eine entsprechende Klasse angegeben werden muß:
”
package MyJDOExample;
import javax.jdo.*;
import java.util.Properties;
import MyJDOExample.JDOPerson;
class testJDOPerson{
private
private
private
private
static
static
static
static
PersistenceManagerFactory pmf;
PersistenceManager pm;
Transaction transaction;
Properties props;
public static void main (String args[]){
System.out.println("Erzeuge JDOPerson...");
JDOPerson people=new JDOPerson("Schmitt", "Harald", "000002", 123457);
System.out.println("Erzeuge Datenbankverbindung...");
// Datenbankverbindung konfigurieren
Properties props = new Properties();
props.setProperty("javax.jdo.option.ConnectionURL", "jdbc:odbc:MyTestDB");
props.setProperty("javax.jdo.option.PersistenceManagerFactoryClass",
"com.sun.jdori.common.PersistenceManagerFactoryImpl"); // ***
// [...]
System.out.println("Erzeuge PMF...");
pmf = JDOHelper.getPersistenceManagerFactory(props);
System.out.println("Erzeuge PM und TX...");
// neuen PersistenceManager von der Factory erzeugen lassen
pm = pmf.getPersistenceManager();
transaction = pm.currentTransaction();
transaction.begin();
// das Personen-Objekte persistent machen:
– 91 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
pm.makePersistent(people);
transaction.commit(); // persistiert
transaction.begin();
people.setName("Schmidt"); // Namen korrigieren
transaction.commit(); // Änderung persistiert
// Alle Ressourcen wieder freigeben
pm.close();
System.out.println("Ende der Objekt-Persistierung.");
}
}
Natürlich ist es möglich und sinnvoll, die Persistierungsmethoden für eine individuelle Applikation in einer separaten Klasse zu kapseln.
Des weiteren benötigt JDO jedoch eine XML-Steuerdatei, in welcher JDO mitgeteilt wird,
welche Klassen persistiert werden sollen. Für das Beispiel sieht die Datei, testJDOPerson.jdo“,
”
so aus:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jdo SYSTEM "jdo.dtd">
<jdo>
<package name="MyJDOExample">
<class name="JDOPerson" identity-type="datastore">
</class>
</package>
</jdo>
Wie man am gesamten Beispiel erkennen kann, wurden zum Speichern des Objekts weder
SQL-Anweisungen verwendet noch Tabellen angegeben. Letzteres ist auch innerhalb der anzugebenen Properties für die Datenbankverbindung nicht nötig.
Es existieren drei Möglichkeiten, um mit JDO Datenbankobjekte wiederherzustellen. Davon
sind zwei ähnlich einfach wie das Persistieren mit JDO:
Methods of Interface javax.jdo.PersistenceManager
java.lang.Object getObjectById(java.lang.Object oid,
boolean validate)
This method locates a persistent instance
in the cache of instances managed by
this PersistenceManager.
java.lang.Object getExtent(java.lang.Class
persistenceCapableClass, boolean subclasses)
The PersistenceManager manages a collection
– 92 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
of instances in the data store based on
the class of the instances.
Die dritte Möglichkeit ist das variable Suchen, welches im Framework JDO ebenfalls über ein
Interface bewerkstelligt wird, nämlich Query. Dieses Interface läßt sich selbstverständlich auch
mittels SQL implementieren. Das Ziel ist es, eine Möglichkeit ähnlich dem Parametrisieren
von SQL-Strings (siehe Abschnitt 4.3.1) zur Verfügung zu stellen, womit eine individuelle
Query validiert bzw. kompiliert werden kann. Dies geschieht auf Basis von Java-Methoden,
mit welchen die Elemente einer Query, z.B. Suchkriterien, separat festgelegt werden. Dieser
Teil von JDO wird als JDOQL bezeichnet.
Natürlich ist die variable Suche ein wesentlicher und wichtiger Bestandteil der Persistierung
selbst. Daher werden die wichtigsten Methoden von JDOQL im Folgenden gezeigt:
Methods of Interface javax.jdo.Query
void compile()
Verify the elements of the query and provide
a hint to the query to prepare and
optimize an execution plan.
void declareImports(java.lang.String imports)
Set the import statements to be used to
identify the fully qualified name of
variables or parameters.
void declareParameters(java.lang.String parameters)
Declare the list of parameters query execution.
void declareVariables(java.lang.String variables)
Declare the unbound variables to be used in the query.
java.lang.Object execute()
Execute the query and return the filtered
Collection.
Ein Query-Objekt erhält man ebenfalls vom PersistenceManager u.a. mit Methoden wie
newQuery(). Alle Objekte, also java.lang.Objects, die von obigen Methoden zurückgegeben werden, sind zuvor persistierte Objektinstanzen.
Im Vergleich zu SQL hat JDOQL jedoch einige Nachteile, da JDOQL weder standardisiert
noch formal definierbar ist wie SQL. Auch ist SQL eine äußerst mächtige und unterstützte sowie
weitverbreitete Sprache. Dennoch ist JDOQL stark an SQL angelehnt, womit sich die Frage
ergibt, ob ein Applikationsentwickler tatsächlich von der Entwicklung von Queries entlastet
wird, wie es ein System für das Objekt-Relationale-Mapping zum Ziel hat.
Ein Problem von JDO, das nicht in jedem Kontext beachtenswert ist aber bei TrustCentern,
ist die noch fehlende Unterstützung von BLOBs. Bei FlexiTrust z.B. werden Zertifikate in den
Tabellen der TrustCenter-Datenbank unter der Nutzung dieses Datentyps abgelegt. Dazu ein
Zitat aus der aktuellen JDO-Spezifikation (siehe [Rus01]) und zwar aus dem Ausblick für die
zukünftige Entwicklung:
– 93 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
JDO implementations can choose to implement mapping from java.sql.Blob data”
type to byte arrays, and java.sql.Clob to String or other java type; but these mappings
are not standard, and may not have the performance characteristics desired.“
In der Tat existieren JDO-Implementierungen, welche BLOBs unterstützen, wie z.B. die FastObjects. Ob die Nutzung dieser Unterstützung unter dem Aspekt der Flexibilität sinnvoll
ist, hängt von evt. nötigen Änderungen in der eigenen Applikation ab, falls man die JDOImplementierung wechseln möchte.
Man beachte, daß es sich zu diesem Zeitpunkt bei JDO um eine sehr junge Technologie
handelt, die z.Z. auch noch in einigen Grundlagen, z.B. der BLOB-Unterstützung, weiterentwickelt wird. Die Konzepte von JDO sind sehr gut und die Persistierung, wie gezeigt, ist sehr
einfach. Da es sich bei JDO bereits um einen Standard handelt, welcher von vielen Entwicklergruppen, z.B. bei Sun, genutzt und gepflegt wird, ist eine weitere sowie stärkere Verbreitung
und Nutzung von JDO in der Zukunft wahrscheinlich (siehe z.B. [Fro01] oder [Jor02-1]). Des
weiteren ist JDO als offizielles Framework Bestandteil des JDK von Sun.
Vorteile
• Die Datenbank-Persistierung von Objekten mit JDO könnte nicht einfacher sein. JDO ist
dazu äußerst leistungs- sowie anpassungsfähig und dennoch auch für Anwendungen mit
großem Aufkommen an Datenbankzugriffen geeignet.
• JDO ist eine reine Objekt-basierte Persistierungslösung, bei welcher der Applikationsentwickler von der Datenbank-Entwicklung vollständig entbunden wird.
Alle Datenbankoperationen erfolgen über Java-Klassen sozusagen automatisch und sind
vorgegeben. Der Applikationsentwickler muß lediglich eine spezielle Repräsentationsklasse
ohne Datenbankoperationen entwickeln. JDO übernimmt die vollständige Persistierung,
was z.B. die automatische Erzeugung von logischen Strukturen einschließt.
• JDO ist ein Standard und bietet daher bei der Nutzung für die eigene Datenbankapplikation den Vorteil der Nachvollziehbarkeit, was bei TrustCentern und deren Zielen bei
Registrierungsvorgängen enorm wichtig ist.
• Ein wesentliches Ziel von JDO ist nicht nur die einfache Entwicklung von Datenbankoperationen sondern ebenfalls deren Effizienz, wodurch JDO als Standard eine hohe Rechenleistung aufgrund seines Performance-Konzepts“ bietet.
”
• Aufgrund der Interface-Struktur von JDO ist man sehr flexibel in der Wahl der JDOImplementierung und die Kompatibilität einzelner Implementierungen ist gewährleistet.
• Im Vergleich zu allen anderen für Java geeigneten Methoden des Objekt-RelationalenMappings schneidet JDO am besten ab, nicht zuletzt aufgrund der Einfachheit und der
Standardisierung.
• JDOQL stellt eine Art alternativer Query-Sprache unter Java dar, bei welcher es möglich
ist, mit Queries nicht über reine String-Werte umzugehen. Statt dessen sind hier Queries
kompilierbar, d.h., ihre Syntax wird vom Java-Compiler direkt überprüft.
Nachteile
• Da es sich bei JDO um ein Framework, also eine Interface-Struktur handelt, ist man
für das Nutzen von JDO in der eigenen Datenbankapplikation auf eine Implementierung
– 94 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
des Frameworks angewiesen, sofern man dieses nicht selbst implementieren möchte, und
somit von einer externen Systemlösung abhängig. Des weiteren existiert z.Z. noch keine kostenlose OpenSource-Implementierung. Da es sich bei JDO aber um eine junge
Entwicklung handelt, kann sich dies in Zukunft ändern.
• Da man von Codeentwicklungsseite aus agiert, wird für jedes individuelle Anwendungsszenario der Datenbankapplikation, wie bei TrustCentern, eine Neukompilation notwendig.
• Da JDO die Datenbankseite, wie z.B. logische Strukturen, der Datenbankapplikation
automatisch erzeugt, werden direkte Zugriffe darauf je nach Anwendungsszenario und
verwendeten Java-Klassen schwierig. Dies kann jedoch beispielsweise bei der Erstellung
von Datenbank-Auszügen oder -Statistiken notwendig sein (siehe auch Abschnitt 4.10.6).
• Ein Nachteil für Applikationen, welche auf BLOBs angewiesen sind, wie etwa TrustCenter
beim Speichern von Zertifikaten, ist die z.Z. noch fehlende Unterstützung für diesen
Datentyp im JDO-Standard. Hier sind jedoch schon Implementierungen vorhanden oder
manuelle Hilfslösungen möglich.
• Anders als JDO ist JDOQL noch kein Standard und kann sich nicht nur daher mit
der Mächtigkeit von SQL nicht messen, wenngleich eine JDOQL-Implementierung SQL
nutzen kann. SQL hingegen ist äußerst stark verbreitet und findet Unterstützung in allen
Datenbanksystemen oder Datenbankwerkzeugen. Des weiteren ist SQL ein Standard und
bietet eine große Effizienz bzw. allgemeine Optimierungsmethoden.
• Die Umstellung einer auf Basis von manuellem Mapping implementierter Persistierungslösung auf JDO ist gerade bei einer großen Datenbankapplikation mit vielen Subapplikationen sehr aufwendig.
4.8
Datenbank-basierte Lösungen
Die im Folgenden erläuterten Verfahren sind allgemein gehalten, also nicht auf Java beschränkt,
wenngleich sie anhand von Java erläutert werden. Es handelt sich hierbei um allgemeine Datenhaltungstechniken.
4.8.1
Datenzugriffe über Cursor
Wie in Abschnitt 3.6 erläutert, bieten sogenannte Cursor einem Entwickler die Möglichkeit
innerhalb einer Applikation auf eine Menge von Datensätzen zu zugreifen, die z.B. das Ergebnis
einer SQL-Query sind.
Auch wenn Cursorsteuerungen bereits in SQL definiert sind, bieten Entwicklungsumgebungen eigene Varianten an, welche auch Operationen auf Datensätzen ermöglichen, wie z.B. das
Einfügen neuer oder das Ändern vorhandener Datensätze.
In Java übernimmt dies das Interface bzw. die Klasse ResultSet. Es handelt sich hierbei
zwar um ein Interface, jedoch erhält man eine operable Instanz, sobald man einen gültigen
Datenbankzugriff erzeugt hat. Diese und ähnliche Vorgehensweisen wurden schon mehrfach
gezeigt und erläutert (z.B. in Abschnitt 4.3.1).
Eine Möglichkeit, um auf Datenbankobjekte auch als Instanz einer Java-Klasse zugreifen
zu können, also die Datenbankobjekte auch als Java-Objekte zu erhalten, ist eine entsprechende Repräsentationsklasse nur mit ResultSet zu definieren. Der Vorteil einer solchen reinen
– 95 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Cursorsteuerung ist es, daß keine lokalen Klassenvariablen für Objektattribute benutzt werden. Lediglich die üblichen Datenbankoperationen werden benötigt, um einen entsprechenden
ResultSet bereitzustellen.
Das folgende kurze Beispiel soll eine solche Repräsentationsklasse andeuten und funktioniert
dazu z.B. mit der Tabelle T Person“ aus Abbildung 20:
”
import java.sql.*;
public class PersonAccResset{
private Connection con;
private Statement stm;
private ResultSet rsIn;
private String url = "jdbc:odbc:MyTestDB";
// über ODBC im System registrierte Datenbank
public void GetAcc(){
System.out.println("Baue Datenbankverbindung auf...");
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}catch(ClassNotFoundException e){};
try{
con = DriverManager.getConnection(url);
stm = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
}catch(SQLException e){System.out.println(e);};
}
public void CloseAcc(){
System.out.println("Baue Datenbankverbindung ab...");
try{
stm.close();
}catch(SQLException e){System.out.println(e);};
}
public ResultSet AccRead(String Entity, String[] Attributs,
String[] AttributeValues){
// Mögliche Rückgabe-Beschränkung wäre, daß die Datensatzauswahl
// eindeutig war und sonst eine Exception geworfen wird.
try{
rsIn = stm.executeQuery("Select * FROM T_" + Entity + " WHERE "
+ Attributs[0] + "=’" + AttributeValues[0] + "’;");
// nur beispielhaft; Eigentlich müßte hier der vollständige
// SQL-String über eine Schleife, aber automatisch,
// konstruiert werden.
}catch(SQLException e){System.out.println(e);};
return rsIn;
}
/*
public void AccWriteNew(...){...}
// z.B. über SQL-Queries
}
– 96 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
public void AccWriteUpdate(...){...}
// z.B. über SQL-Queries
}
*/
}
Bei diesem Beispiel handelt es sich also um eine vollwertige Repräsentationsklasse, welche
je nach Anforderungsbereich ausgebaut werden kann. Dies bedeutet auch, daß für jedes Datenbankobjekt wie üblich eine Instanz dieser Klasse erzeugt wird. Auch ist es denkbar, diese
Klasse um allgemeine Setter- und Getter-Methoden für einzelne Attribute zu ergänzen, was
eine alternative Zugriffsmethode zur reinen ResultSet-Rückgabe ist.
Für die Repräsentation von mehrstufigen Objekten ist z.B. der Einsatz von Steuertabellen
sowie Arrays von ResultSets möglich.
Vorteile
• Da bei dieser Vorgehensweise keine lokalen Variablen für Objektattribute benötigt werden,
ist z.B. auch kein separiertes Einlesen von Werten und Setzen dieser Variablen notwendig, wie bei anderen Varianten, z.B. der reinen JDBC-Lösung. Damit wird nicht nur
Entwicklungsaufwand vermieden, sondern gleichermaßen Effizienz bzw. Rechenleistung
gewonnen.
Im Gegensatz dazu wird beispielsweise beim manuellen Mapping (siehe Abschnitt 4.7.1)
nachdem Bestimmen eines ResultSet, dieses noch in Variablen der Repräsentationsklasse umgesetzt. Letzteres wird bei der reinen Cursor-Lösung nicht getan.
• Wenn innerhalb aller Applikationsteile der Umgang mit dem Java-Cursor unterstützt wird,
sind bei der Nutzung von allgemeinen Repräsentationsklassen, evt. unter Zuhilfenahme
von z.B. Steuertabellen, keine Neukompilationen des Applikationscodes notwendig.
• Diese Methode ist mit anderen Persistierungsideen, z.B. Steuertabellen, kombinierbar und
anpassungsfähig, da es sich hierbei nur um eine Form der Repräsentation handelt.
Nachteile
• Alle Applikationsteile sind bei dieser Lösung auf die Nutzung von ResultSets angewiesen
und müssen diese umsetzen sowie sich dazu ggf. umstellen.
4.8.2
Steuer- bzw. Hilfstabellen
Gewisse Daten aus einem Quellcode auszulagern, um diesen einfach und evt. sogar ohne Neukompilation konfigurierbar zu machen, ist eine gängige Idee. Mit Konfigurationsdateien etwa
läßt sich dann entsprechend das Verhalten einer Applikation verändern und steuern, ohne
Änderungen im Quellcode vorzunehmen. Diese Daten sind also nicht mehr fest im Quelltext
eingebettet. Auch bei FlexiTrust wird diese Methode bereits eingesetzt, wobei Konfigurationsdateien die Form *.properties haben.
Natürlich ist es ebenso denkbar, solche Daten in Tabellen abzulegen, die dann als Hilfs- oder
Steuertabellen bezeichnet werden. Bei einer Datenbankapplikation macht dies besonders Sinn,
weil auf Datenbanken zurückgegriffen wird und auf diese Weise auch komplexere Datenstrukturen als Konfigurationsdaten dienen können, falls dies erforderlich ist. Des weiteren lassen
sich diese Daten so auch direkt in SQL-Queries einbinden, was u.U. sinnvoll und effizienter
sein kann.
– 97 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Ein Beispiel für eine solche Steuertabelle, die nur schwer als Konfigurationsdatei realisiert
werden kann, ist T Relation“ aus Abschnitt 4.7.1. Ein einfacheres Beispiel findet sich in
”
Abbildung 22. Es zeigt, wie man mittels vereinbarter Keywords Optionen setzen kann.
Bezogen auf TrustCenter zeigt das Beispiel, wie man gewisse Informationen über relevante
Tabellenstrukturen festhalten kann. Dies kann z.B. die Nutzung von allgemeinen Repräsentationsklassen trotz vielfältiger Anwendungsszenarien unterstützen, wodurch ein automatisches
Einlesen von Tabellenstrukturen ohne Änderungen im Quelltext auf flexible Weise möglich ist.
Details zur Realisierung hängen von der jeweiligen Umsetzung für eine bestimmte Datenbankapplikation ab und können sehr individuell sein.
Bei TrustCentern muß beachtet werden, daß beim Nutzen von Konfigurationsdateien oder
Steuertabellen stets die Sicherheit vor unbefugten Änderungen gewahrt wird, um auch die Ziele eines TrustCenters (siehe auch Abschnitt 2.1) zu garantieren. Denn können Angreifer das
Verhalten der TrustCenter-Applikation auf diese Weise verändern, sind die Ziele des TrustCenters bzw. einer PKI gefährdet. Für Steuertabellen gilt, daß sie im selben Bereich, nämlich der
TrustCenter-Datenbank, abgelegt werden, wie z.B. die Registrierungsdaten. D.h., sie obliegen
dem selben Schutzniveau wie diese äußerst schützenswerten Daten.
T Control
Keyword
Value
MainRegdataTab T Person
SubRegdataTab
T SubPerson
PrimKeyAttr
StaffID+DistinguishedName
CertRelevantAttr Name
CertRelevantAttr FirstName
Abbildung 22: Umsetzungsmöglichkeit für eine einfache Steuertabelle
Es ist denkbar zu dieser Lösung eine Art Validierungsklasse zu entwickeln, mit deren Hilfe
man die Gültigkeit des Zustandes der Steuertabelle überprüfen kann, etwa indem das Vorhandensein einer vorgegeben Liste von Keywords sowie u.U. deren Zusammenhängen und
Korrektheit überprüft sowie kontrolliert wird.
Vorteile
• Konfigurierbare Daten, welche u.U. sogar im Quellcode und somit fest eingebettet sind,
werden ausgelagert. Damit wird z.B. eine Neukompilation von Quelltexten vermieden.
Statt dessen müssen in einem Quelltext zunächst Daten aus einer Steuertabelle eingelesen
werden, womit der Entwicklungscode und somit die Applikation konfigurierbar wird.
• Das Auslesen von solchen Daten, z.B. zur Konfiguration, aus Tabellen und nicht aus
Dateien hat den Vorteil, daß diese Daten direkt in einer SQL-Anweisung eingebunden bzw.
verarbeitet werden können, was natürlich nur bei einer Datenbankapplikation sinnvoll und
effizient ist.
Nachteile
Bei dieser Variante handelt es sich um eine übliche Methode. Das Zusammensuchen ausgelagerter Daten kann sich nur unter bestimmten Voraussetzungen zum Nachteil entwickeln, etwa
wenn:
– 98 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
• Keine Konfiguration erwünscht ist (z.B. bei sicherheitskritischen Daten),
• die Konfiguration undurchschaubar wird,
• zu lösende Probleme auf die Konfiguration verschoben werden.
Im Falle eines TrustCenters gilt, daß die zugrundeliegende Datenbank äußerst schützenswert
und sicherheitskritisch ist. Denn hier werden u.a. Registrierungsdaten gespeichert, welche einen
wichtigen Bestandteil zur Realisierung der Ziele einer PKI sowie eines TrustCenters (siehe
z.B. Abschnitt 2.1) darstellen. Folglich hängen die Sicherheit, welche das jeweilige TrustCenter bieten kann, und die Sicherheitsaspekte bzgl. der TrustCenter-Datenbank eng zusammen.
Demnach können auch sicherheitskritische Daten aus einer Applikation des TrustCenters in
die Datenbank bei Bedarf ausgelagert werden.
4.8.3
Dynamische Strukturen bzw. Tabellendefinitionen
Das Ziel von dynamischen Strukturen ist es, in einem bestimmten Anwendungskontext Applikationsentwicklung und Datenbankentwicklung gleichermaßen ausschließlich mittels Dateneingabe und Datenmanipulation vorzunehmen. Dies bedeutet auch, daß Applikationsänderungen
und Erstellung logischer Strukturen einer Datenbank nur über Datenmanipulation möglich sein
soll.
Folglich sind für eine Anpassung einer Datenbankapplikation, z.B. eines TrustCenters, für
ein bestimmtes Anwendungsszenario nur Datenänderungen vonnöten, etwa durch direkte Bearbeitung, SQL oder Java-Programme. Damit dies möglich wird, ist selbstverständlich ein recht
großer Aufwand bei der Erstentwicklung nötig, welche den individuellen Anforderungen für eine
solche Lösung angepaßt sein muß.
Was für ein solches System dynamischer Strukturen notwendig ist, soll im Folgenden
erläutert und näher beschrieben werden. Bei einer gewöhnlichen Tabelle, wie der bereits bekannten T Person“ aus Abbildung 20, muß der Datenbankentwickler beim Hinzufügen eines
”
neuen Attributs stets die Tabellendefinition ändern, da diese dafür um eine Spalte erweitert
wird. Abbildung 23 soll diesen Vorgang verdeutlichen.
Nun soll dieser Vorgang mit der Idee von dynamischen logischen Strukturen umgesetzt werden. Die Basis eines einfachen Beispiels hierfür sollen die Tabellen T Tabellen“ und T Daten“
”
”
bilden. Dabei handelt es sich um die einzigen Tabellen, die für die Realisierung einer passenden
Datenbankapplikation in der zugehörigen Datenbank angelegt werden müssen.
Auch wird sich diese Tabellenstruktur bei anderen Anwendungsszenarien, z.B. anderen beliebigen Personendaten, nicht ändern. Individuelle Tabellen werden in die vorhandenen dynamisch
eingepflegt. Die Abbildungen 24 ( T Tabellen“) und 25 ( T Daten“) zeigen nicht nur den Auf”
”
bau einer solchen dynamischen Struktur, sondern demonstrieren auch auf welche Weise der
oben geschilderte Vorgang der Erweiterung der Tabelle T Person“ mit solchen Strukturen
”
vollzogen werden kann.
Es ist leicht zu sehen, daß eingepflegte individuelle Tabellen mit ihren Daten aus den
vorhandenen Tabellen der dynamischen Struktur erst ausgelesen werden müssen, etwa für
einen Datensatzzugriff. Dies bedeutet, ein einfacher Datenbankzugriff erfolgt nicht mehr ausschließlich über das Datenbanksystem, sondern muß von einer zu den dynamischen Strukturen
entwickelten Basisapplikation verwaltet werden.
Folgendes Beispiel stellt keine Repräsentationsklasse dar sondern nur eine Klasse für den
Datenbankzugriff bzw. die notwendigen Datenbankoperationen bei den gezeigten Strukturen.
Sie erzeugt jedoch ein Objekt der Klasse PersonOnly.java“, wobei es sich hier um die speziel”
le Repräsentationsklasse ohne Datenbankoperationen aus Abschnitt 4.6.2 handelt. Um dieses
– 99 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 23: Tabellendefinitionen durch Strukturmanipulation
Codeobjekt erzeugen zu können, muß die Zugriffsklasse die Attributwerte des Datenbankobjekts aus Einzeldatensätzen der fixen Tabellen T Tabellen“ und T Daten“ zusammensetzen:
”
”
import java.sql.*;
import PersonOnly;
public class Acc2DynTab{
private Connection con;
private Statement stm;
private ResultSet rsIn;
private ResultSet rsOut;
private PersonOnly onePerson;
private String url = "jdbc:odbc:MyTestDB";
// über ODBC im System registrierte Datenbank
public void GetAcc(){
System.out.println("Baue Datenbankverbindung auf...");
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}catch(ClassNotFoundException e){};
try{
con = DriverManager.getConnection(url);
stm = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
}catch(SQLException e){System.out.println(e);};
}
public void CloseAcc(){
System.out.println("Baue Datenbankverbindung ab...");
try{
stm.close();
}catch(SQLException e){System.out.println(e);};
}
– 100 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 24: Dynamische Tabellendefinitionen durch Datenmanipulation
public PersonOnly AccRead(String[] Attributs, String[] AttributeValues){
ResultSet rsIn;
try{
rsIn = stm.executeQuery(
"SELECT T_Tabellen.Attribut, T_Daten.Wert "
+ "FROM (T_Daten AS T_Daten_1 INNER JOIN T_Tabellen"
+ " AS T_Tabellen_1 ON T_Daten_1.TabID = T_Tabellen_1.TabID)"
+ " INNER JOIN (T_Tabellen INNER JOIN T_Daten"
+ " ON T_Tabellen.TabID = T_Daten.TabID) ON"
+ " T_Daten_1.TupelID = T_Daten.TupelID "
+ "WHERE ((T_Daten_1.Wert=’Homann’)" // ***
+ " AND (T_Tabellen_1.Attribut=’Name’)"
+ " AND (T_Tabellen_1.Tabelle=’T_Person’));");
// An dieser Stelle müssen eigentlich die
// Suchkriterien aus den Argumenten gesetzt werden.
rsIn.beforeFirst();
onePerson = new PersonOnly();
while(rsIn.next()){
onePerson.setAttribute((String)rsIn.getString(1),
(String)rsIn.getString(2));
}
}catch(SQLException e){System.out.println(e);};
return onePerson;
}
// ähnlich dann je eine "Write"-Methode für Änderungen
// und neue Datensätze
}
– 101 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 25: Attributwerte bzw. Datensätze bei dynamischen Tabellen
Da es sich hier nur um ein Beispiel handelt, ist die mit ***“ gekennzeichnete Stelle nicht
”
weiter ausformuliert bzw. nicht variabel. Eine Visualisierung der verwendeten größeren SQLAnweisung ist in Abbildung 26 zu sehen.
Ebenfalls ist es hier natürlich denkbar, den Objekttyp bzw. dessen Repräsentationsklasse
zu parametrisieren, wie schon z.B. in der Klasse Entities.java“ aus Abschnitt 4.6.2 gesehen,
”
sowie allgemeine Repräsentationsklassen zu verwenden.
Mehrstufige Objekte lassen sich mit dynamischen Strukturen sehr leicht realisieren. Dazu
muß das gezeigte System jedoch ein wenig modifiziert werden. Hierfür existieren viele Möglichkeiten. Es ist z.B. denkbar, die Tabelle T Tabellen“ um ein Attribut ParentID“ zu erweitern,
”
”
womit eine Hierarchie der Tabellen bzw. Datenbankobjekte realisiert ist. Die zu verknüpfenden
Attribute der Tabellen, meist Schlüssel, müssen ebenfalls noch gekennzeichnet werden. Dies ist
möglich, durch ein weiteres Attribut oder Flag in den Tabellen T Daten“ oder T Tabellen“.
”
”
Auch könnte man sich einer Steuertabelle behelfen, wie etwa T Relation“ aus Abschnitt 4.7.1.
”
Natürlich ist es auch möglich bei dynamischen Strukturen mehrere und verschiedene Datentypen direkt zu behandeln. Dazu ist es zunächst nötig, eine Basistabelle für alle eigentlichen
Daten zu entwickeln. Diese verweist dann zu den eigentlichen Attributwerten auf andere Tabellen, bei welchen die Spalte mit dem jeweiligen Wert einen individuellen Datentyp besitzen kann.
Bei dieser Variante ist es auch denkbar, definierte Attribute bzw. Felder wiederzuverwenden
und zwar schon bei der Tabellendefinition.
Dann würde man die Attributsdefinition sowie Zuweisung zu Tabellen auch separat und
ausführlich betreiben. Man könnte etwa auch Attributsbeschreibungen oder Wertbeschränkungen einführen o.ä. Die Verknüpfung zwischen Tabellendefinitionen und Attributsdefinitionen
wird dann über eine gesonderte Steuertabelle vollzogen, welche die Primärschlüssel der Tabellen- und Attributsdefinitionen in Beziehung setzt.
Vorteile
• Auch bei dieser Lösung läßt sich prinzipiell ausschließlich von Codeentwicklungsseite aus,
also z.B. von Java aus, arbeiten, da die Datenbank zur Applikation immer dieselben festen
logischen Strukturen besitzt und folglich immer gleich unabhängig vom Anwendungsszenario eingerichtet wird.
– 102 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Abbildung 26: SQL-Anweisung zum Zusammensetzen von Daten aus dynamischen Tabellen
• Diese Variante erlaubt es mehrstufige Objekte einfach zu pflegen. Auch müssen dafür
z.B. keine verschiedenen Tabellen pro Objekttyp angelegt werden.
• Das Erstellen von individuellen Typen und Tabellen für Datenbankobjekte geschieht ausschließlich über Datenmanipulation. Des weiteren lassen sich natürlich allgemeine Repräsentationsklassen verwenden. Somit ist ein flexibles und schnelles Anpassen einer Datenbankapplikation für ein bestimmtes Anwendungsszenario möglich.
Zum Vergleich: Beim manuellen Mapping mit speziellen Repräsentationsklassen ist es
dafür nötig, Änderungen an der Datenbank, an der Repräsentationsschicht und bei den
SQL-Anweisungen für die Datenbankzugriffe vorzunehmen.
• Dynamische Strukturen müssen nicht als alleinige Persistierungslösung genutzt werden,
sondern lassen sich mit anderen Lösungen kombinieren. So kann man z.B. auch Teilbereiche von dynamischen Strukturen als Steuertabelle für andere Persistierungsarten, z.B.
dem manuellen Mapping, verwenden.
• Diese Variante ist ebenfalls am besten geeignet, wenn auch nicht im Kontext eines TrustCenters, falls sich innerhalb einer Datenbankapplikation Tabellenstrukturen bei Fernzugriffen oft ändern müssen, diese Änderungen von verschiedenen Benutzern durchgeführt
werden können bzw. werden dürfen oder Benutzer gar freie Tabellen definieren können
sollen. Denn meist können Datenbanksysteme mit Datenmanipulation besser und flexibler
umgehen als mit Strukturänderungen, da es sich bei logischen Strukturen um eine statische Datenbankeigenschaft handelt (siehe auch Abschnitt 3.4.1). Dies gilt gerade bei
Fernzugriffen, wie etwa über ODBC oder das Internet.
Nachteile
• Datenbankzugriffe auf Daten sowie Datensätze werden über SQL gesteuert und SQL
muß dazu auch stark genutzt werden. Dadurch wird der Quellcode teilweise sehr SQLlastig, was bei einer einmaligen Entwicklung für die Entwicklungszeit nicht sehr relevant
– 103 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
ist. Relevant wird dies jedoch bei der Betriebsleistung, da Datensätze manuell aus mehreren Tabellenzugriffen sozusagen zusammengesucht werden müssen, wodurch je nach
Aufkommen an Datenbankzugriffen eine u.U. ineffiziente Rechenleistung entsteht.
• Durch das manuelle Implementieren gängiger Datenbankmethoden, wie z.B. dem Zugriff
auf einen einfachen Datensatz, verliert man einige Vorteile, aber keinesfalls alle, eines
Datenbank Management-Systems (siehe auch Abschnitt 3.2).
• Durch das hier notwendige Zusammensetzen eines einzigen Datensatzes, z.B. im Vergleich zu individuellen Tabellen, ist eine Dateneinsicht, etwa für einen Datenbank-Auszug
oder einen Datenbank-Bericht, nur durch Programmieraufwand möglich. Dies wird gerade
bei der Verwendung von mehreren verschiedenen Datentypen bei dynamischen Strukturen deutlich. Adhoc-Queries sind natürlich möglich, aber wesentlich umfangreicher und
schwieriger zu entwickeln (siehe z.B. Abbildung 26).
• Bei dieser Variante muß man den Anforderungen der eigenen Applikation entsprechend
einen anfänglich großen Entwicklungsaufwand betreiben.
4.9
Bewertung der Persistierungslösungen
Die Persistierungslösungen aus den Abschnitten 4.6, 4.7 und 4.8, welche in Abbildung 27 noch
einmal zusammengefaßt sind, müssen vor allem unter den Aspekten des TrustCenter-Betriebs
aus Abschnitt 4.1 sowie den Aspekten der Ziele aus Abschnitt 4.5.4 bewertet werden, welche
bereits als Bewertungskriterien vorgestellt wurden.
Des weiteren erfolgt die Bewertung im Kontext des TrustCenter-Produkts FlexiTrust (siehe Kapitel 2 und Abschnitt 4.4) und der vorliegenden Java-Implementierung, welche bereits
auf manuellem Mapping basiert. Doch natürlich können die gezeigten Persistierungssysteme
zumindest teilweise auch auf andere Applikationen übertragen werden.
Abbildung 27: Zusammenfassung der Persistierungsmöglichkeiten
– 104 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Die vorhandene OpenRA-Implementierung entstand zwar nicht unter dem Aspekt der optimalen Persistierung von Personendaten, ist diesbezüglich aber dennoch sehr zweckmäßig.
Nichtsdestotrotz ist eine Erweiterung bzw. Änderung des vorhandenen Systems möglich sowie sinnvoll und kann bei entsprechender Gelegenheit nach Diskussion sowie Absprache der
FlexiTrust-Entwickler erfolgen. Von einer solchen Änderung sind viele Teile von FlexiTrust
betroffen.
Man kann durchaus sagen, die Wahl einer der vorgestellten Persistierungslösungen ist teilweise Geschmacks- bzw. Ansichtssache. Auch sind mehrere dieser für den TrustCenter-Einsatz
geeignet, da sie sich jeweils den Zielen und Idealen aus Abschnitt 4.5.4 nähern. Es wird noch
einmal darauf hingewiesen, daß alle Lösungen auf JDBC für die Datenbankverbindung unter
Java angewiesen sind. Folgende Lösungen kommen in Betracht und erfüllen, wie auch bereits
in den zugehörigen Abschnitten gezeigt, die Bewertungskriterien (siehe Abschnitt 4.5.4) am
besten:
• Dynamische Strukturen mit einer allgemeinen Java-Repräsentationsschicht,
• JDO mit speziellen Java-Repräsentationsschichten ohne Datenbankoperationen,
• reines JDBC bzw. manuelles Mapping um allgemeine Java-Repräsentationsschichten erweitert.
Diese Lösungen unterscheiden sich stark in ihrer grundsätzlichen Erneuerungsnotwendigkeit
zur bisherigen OpenRA-Implementierung und der SQL-Lastigkeit. Hingegen erreichen alle diese Lösungen das Ziel der einseitigen Festlegung, also von Datenbankseite oder Codeentwicklungsseite aus, eines individuellen Datenmodells für die RA, womit die Entwicklungszeit und
z.B. Zeit für Fehlerkontrolle stark verkürzt werden kann.
Bei JDO geschieht dies von der Java-Seite aus, indem stets eine individuelle Repräsentationsschicht entwickelt wird. Damit wird zwar immer eine Neukompilation dieser und vorhandener Klassen notwendig, aber die Repräsentationsschicht enthält keinerlei Datenbankmethoden
bzw. -operationen, da diese von JDO automatisch übernommen werden. Auch ist es denkbar,
über eine Hilfstabelle mit JDO allgemeine Repräsentationsschichten zu verwenden, was jedoch
nicht sinnvoll ist sowie die Bedeutung und Effizienz von JDO in Frage stellt.
Bei dynamischen Strukturen und einer reinen JDBC-Lösung, wie in Abschnitt 4.7.1 beschrieben, ist durch die mögliche Verwendung von allgemeinen Repräsentationsschichten bei
individuellen Datenmodellen für TrustCenter-Szenarien keine Neukompilation des OpenRAQuellcodes notwendig. Dafür werden Tabellen bzw. logische Strukturen der Datenbank manuell entwickelt bzw. erstellt. Der große Vorteil von dynamischen Strukturen (siehe Abschnitt
4.8.3) ist, daß die zu definierenden Tabellen immer dieselben sind, da die individuellen Tabellen
mittels Datensätzen definiert werden, anders als bei der reinen JDBC-Lösung, bei welcher stets
individuelle Tabellendefinitionen erstellt werden. Die gezeigte reine JDBC-Lösung wiederum ist
leicht und schnell in das vorhandene OpenRA-Konzept zu integrieren, da sie darauf direkt aufbaut und keine grundlegende Erneuerung darstellt. Des weiteren hat die reine JDBC-Lösung
bzw. das manuelle Mapping den großen Vorteil, äußerst flexibel und auch auf ungewöhnliche
sowie sehr individuelle Anwendungsszenarien einstellbar zu sein.
Der Nachteil von JDO ist die fehlende Unterstützung von SQL für spezielle Datenbankoperationen und das notwendige Benutzen von JDOQL für individuelle Suchvorgänge nach
Datenbankobjekten, z.B. nach dem vom TrustCenter vergebenen Distinguished Name für ein
PKI-Mitglied. Denn JDOQL hat sich noch nicht durchgesetzt und ist ebenfalls noch nicht
standardisiert. SQL ist wesentlich mächtiger und bietet im Gegensatz zu JDOQL den großen
– 105 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Vorteil der Verbreitung sowie Unterstützung in allen Datenbanksystemen und Datenbankwerkzeugen, der Standardisierung und der Effizienz bzw. allgemeinen Optimierungsmethoden
etc. Des weiteren handelt es sich bei JDO selbst zwar um einen Standard aber ebenfalls nur
um eine API, für die es z.Z. noch keine kostenlose Implementierung gibt. Jedoch kann man
die jeweilige JDO-Implementierung auf einfache und flexible Weise wechseln. Dennoch ist zu
erwähnen, daß JDO für Datenbank-lastige Applikationen gedacht ist, also für Applikationen
mit dem Augenmerk auf Datenbankoperationen und einem äußerst großen Aufkommen an
Datenbankzugriffen.
Der Nachteil von dynamischen Strukturen ist u.U. der ineffizientere Betrieb bzw. die ineffizientere Rechenleistung, da z.B. viele SQL-Zugriffe für einen einfachen Datensatz-Zugriff
nötig sind. Dies ist etwa bei der reinen JDBC-Lösung nicht der Fall, womit sie recht effizient
wird.
Weitere Anmerkungen bzgl. der Realisierung einer TrustCenter-Datenbank finden sich in
Abschnitt 4.10. Die dort geschilderten Aspekte beeinflussen die Weiterentwicklung von FlexiTrust ebenfalls grundlegend und somit auch die Wahl einer Persistierungslösung.
4.10
Weiterführende Überlegungen
In diesem Abschnitt werden weitere mögliche Datenbank-Anwendungen innerhalb von TrustCentern und von FlexiTrust sowie weitere wichtige Aspekte und Ausbaumöglichkeiten für
TrustCenter-Datenbanken beschrieben.
Diese bedeuten neben Änderungen an der gezeigten Datenbankapplikation ebenfalls Änderungen am ursprünglichen TrustCenter-Datenmodell aus Abbildung 17 auf Seite 53.
4.10.1
Administration und Absicherung von Datenbanken
Z.Z. existiert bei FlexiTrust kein ausgewogenes System bzgl. der Benutzerverwaltung für die
TrustCenter-Datenbank. Statt dessen wird beim zugehörigen Datenbanksystem ein Benutzer
eingerichtet, welcher von allen berechtigten Personen für Datenbankänderungen benutzt wird
und dazu autorisiert ist. Bei zentraler Antragstellung mit zentraler Datenbank ist diese Vorgehensweise noch akzeptabel, sie wird jedoch z.B. auch bei dezentraler Antragstellung mit
zentraler Datenbank (siehe auch Abschnitte 2.4 und 4.2) verwendet.
Alle gängigen Datenbanksysteme bieten eine ausführliche Benutzerverwaltung an, z.B. für
die Verwaltung von Lese- und Schreibrechten, und mittels JDBC hat man auch die Möglichkeit, sich für eine Datenbankverbindung per Benutzernamen und Paßwort an dieser Datenbank
anzumelden. Es ist ebenfalls zu beachten, daß u.U. benutzte Persistenz-Frameworks mit der
Benutzerverwaltung, z.B. eines SQL-Servers, umgehen und die von JDBC vorgesehene Datenbankanmeldung nutzen können. Des weiteren muß natürlich auch bei der Datenbankapplikation, wie z.B. der OpenRA bei FlexiTrust, die individuelle Anmeldung, etwa mit Benutzername
und Paßwort inkl. deren vorheriger Vergabe, vorgesehen sein bzw. eingefügt werden.
Eine alternative Lösung ist es, eine Benutzerverwaltung unabhängig von der des Datenbanksystems in der Datenbankapplikation selbst zu realisieren. Dann würden beispielsweise
Benutzername und Paßwort in eigenen Tabellen gespeichert, und die Anmeldung an die Datenbank würde durch den eigenen Applikationscode erfolgen, und z.B. nicht über JDBC. Damit
erhält man eine beliebige Granularität bzgl. der Zugriffssteuerung für Daten, man muß jedoch
auch für ausreichend Sicherheit durch die eigene Applikationsentwicklung sorgen, z.B. bei
Fernanmeldungen an die Datenbank.
Führt man eine ausführlichere Benutzerverwaltung bei der TrustCenter-Datenbank bzw.
Datenbankapplikation ein, hat dies einige Vorteile. So ist es möglich, detaillierte und individuelle
– 106 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Logs bzw. Aufzeichnungen zu führen, unabhängig vom benutzten Datenbanksystem sowie von
dessen Angebot und Granularität. Dies steigert die Nachvollziehbarkeit und Rückverfolgung
von Aktionen, sofern solche Logs41 gespeichert und abgesichert werden. Festhalten folgender
Sachverhalte bzgl. Datenbankveränderungen ist beispielsweise denkbar:
• Welche Änderungen wurden durchgeführt,
• welche Person hat Änderungen durchgeführt,
• wann wurde die Änderung durchgeführt usw.
Solche Logs können teilweise über Systeme erstellt werden, die das jeweilige Datenbanksystem
anbietet, z.B. Vermerk des Einfügedatums eines Datensatzes. Andererseits kann man über die
Datenbankapplikation selbst beliebige Aufzeichnungen festlegen und gestalten. So ist es z.B.
vorstellbar, Tabellenstrukturen zu verdoppeln und Vorgänger von geänderten Datensätzen als
Log zu sichern, wobei hier auch stets der Bezug zum an der Datenbank angemeldeten Benutzer
möglich ist.
Das Führen derartiger Logs kann natürlich die Effizienz bzw. Rechenleistung der Datenbankapplikation beeinflussen. Die Stärke der Beeinflussung ist je nach Anforderung an die Datenbankapplikation spürbar, also etwa weniger spürbar bei Applikationen, deren Schwerpunkt
nicht bei Datenbankzugriffen liegt.
Neben Administration der Datenbank und Führen von Logs ist die weitere Absicherung der
Datenbank bei lokalen Zugriffen und Fernzugriffen wichtig und überlegenswert.
Während Zertifikate stets signiert werden und deren Gültigkeit dadurch gesichert ist, ist
eine Signierung von Registrierungsdaten in der TrustCenter-Datenbank nicht sinnvoll. Da der
Standort der Datenbank in der Praxis stets abgesichert sein muß, ist dies auch nicht notwendig.
Dennoch ist es denkbar, die Datenbank z.B. auf ein verschlüsseltes Dateisystem aufzusetzen.
Bei zentraler TrustCenter-Datenbank und dezentraler Registrierung von potentiellen PKIMitgliedern (siehe z.B. Abbildung 19) sind Fernzugriffe auf die TrustCenter-Datenbank und
somit Anmeldungen an der Datenbank bzw. Authentifikationsvorgänge unumgänglich. Die
Authentifikation ist hierbei sehr sicherheitskritisch, da der Schutz von Registrierungsdaten und
von deren Verknüpfung mit Zertifikaten ein hohes Ziel des TrustCenters als Vertrauensinstanz
einer PKI ist (siehe auch Abschnitte 2.4 und 4.1).
Auf die Verwaltung von verschiedenen Benutzern für Datenbankzugriffe wurde bereits eingegangen. Deren Vorteile sind natürlich auch auf Fernzugriffe übertragbar. Des weiteren muß
bei Fernzugriffen die Übertragung zwischen lokaler Applikation und TrustCenter-Datenbank
bzw. zentraler Datenbankapplikation geschützt werden, z.B. zwischen einem Web-Formular
und dem Server bei der OpenRA. So müssen folgende Aspekte sichergestellt sein:
• Registrierungsdaten müssen verschlüsselt und integer übertragen werden,
• Registrierungsdaten dürfen nur von autorisierten Personen eingefügt werden,
• Paßwort-basierte Authentifikation findet nur verschlüsselt statt und ist auch gegen ReplayAttacken gesichert.
Bei Fernzugriffen ist dies deshalb unumgänglich, weil es z.B. möglich ist, Übertragungen mitzuhören oder zu verändern. Das Absichern einer Fernverbindung kann dabei einerseits durch
die Datenbankapplikation erfolgen, wodurch die genutzten Methoden, z.B. kryptographische
41 Bei FlexiTrust werden bereits Logs geführt, allerdings in Form einer Datei bzw. eines Logfiles, wie z.B. in der DBAccess.java“
”
(siehe Abschnitt 4.4.1) zu sehen.
– 107 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Protokolle, genau festgelegt werden können und müssen. Andererseits kann man sich z.B.
im Falle des Web-Formulars auch externen Sicherheitsstrukturen bedienen, wie der TLSImplementierung des verwendeten Browsers.42
Details zum Absichern von Verbindungen über JDBC sind z.B. in [Sam04] beschrieben. Des
weiteren ist statt oder ergänzend zu einer Personen-basierten Datenbank-Anmeldung ebenso
eine Workstation-basierte denkbar. Und auch die dezentrale Erfassung von Registrierungsdaten
bei dezentraler TrustCenter-Datenbank, also deren Verteilung über mehrere Standorte, ist
möglich und muß von der Datenbankapplikation abgesichert werden.
4.10.2
Vergabe von Distinguished Names
Innerhalb einer PKI (siehe z.B. Abschnitt 2.7.6) kommen den Distinguished Names eine wichtige Bedeutung zu, nämlich als eindeutige aber lesbare Kennzeichner von Zertifikaten bzw.
PKI-Mitgliedern.
Bei der Antragstellung besteht das Problem, daß zu einem bestimmten Zeitpunkt einem
Antragsteller bzw. dessen Registrierungsdatensatz ein Distinguished Name zugeteilt werden
muß und zwar weit vor der Freischaltung des PKI-Mitgliedskontos. Denn vor der Freischaltung
muß z.B. das Zertifikat des potentiellen PKI-Teilnehmers erstellt werden.
Da die Antragstellung bzw. -prüfung, also der Registrierungsvorgang, innerhalb der OpenRA
von FlexiTrust in mehreren Schritten erfolgt, muß also ein bestimmter Distinguished Name
passend zum Antrag reserviert und u.U. auch wieder freigegeben werden. Doch zunächst
wird einer Entity in Form eines Registrierungsdatensatzes bzw. eines Datenbankobjekts ein
eindeutiger Zahlenwert als Kennzeichner bzw. Primärschlüssel zugeteilt, wie z.B. beim Attribut
EntityNo“ aus dem hier benutzten Datenmodell aus Abbildung 17 auf Seite 53.
”
Während ein solcher eindeutiger Kennzeichner ausschließlich interne Verwendung findet,
sind Distinguished Names auch nach außen hin sichtbar, z.B. in Zertifikaten, und fördern
vor allem die Nachvollziehbarkeit von PKI-Vorgängen (siehe auch Abschnitt 2.7.6). Es ist
daher sinnvoll innerhalb des Reservierungsvorgangs für einen Distinguished Name ebenfalls
eine Verknüpfung des Distinguished Names und des zugehörigen Datensatz-Kennzeichners,
hier mit dem Attribut EntityNo“ als Fremdschlüssel, vorzunehmen.
”
Die Grundlage für einen solchen Reservierungsvorgang kann die Tabelle T DNreserved(En”
tityNo,DN,InUse,Expires,Expired)“ bilden, welche dann zur Vergabe von Distinguished Names
herangezogen wird. Diese Tabelle stellt dabei den Ersatz der Tabelle T DNs“ im Datenmodell
”
aus Abbildung 17 dar. Um die Vergabe zu vereinfachen, sollten alle Distinguished Names in
dieser Tabelle gespeichert werden, also auch die bereits vergebenen. Letztere können durch
das Flag -Attribut InUse“ gekennzeichnet werden.
”
Wird nun ein Antrag für eine PKI-Mitgliedschaft gestellt, folgt die Bestimmung eines passenden potentiellen Distinguished Names für den neuen PKI-Teilnehmer. Anschließend wird
geprüft, ob dieser noch nicht vergeben ist, indem man die Tabelle T DNreserved“ nach ihm
”
durchsucht.43 Ist er nicht enthalten, darf er vergeben werden und die Tabelle erhält einen
neuen Datensatz.
Dieser Distinguished Name gilt nun als reserviert bis der Registrierungsvorgang, z.B. inkl.
Überprüfung der Antragsdaten und persönlichem Erscheinen des Antragstellers bei der Registrierungsstelle, abgeschlossen ist und etwa ein entsprechendes PKI-Zertifikat erstellt44 sowie
42 Es
existieren hier vielerlei Angriffsmöglichkeiten, z.B. einfaches Abhören des Netzwerkverkehrs mittels dem Programm Ethereal. Aber auch zum Absichern existieren viele Lösungen, wie das Signieren von Java-Archiven oder eben TLS etc. Die Details
hierzu wurden bereits in Kapitel 1 geschildert.
43 Ein effizienter Zugriff auf das Attribut DN“ der Tabelle T DNreserved“ ist durchaus z.B. durch die Definition einer primären
”
”
Indexstruktur auf dieses Attribut in der jeweiligen Datenbank möglich.
44 Die Verfahrensweise für Sonder- und Fehlerfälle im Ablauf der Vergabe von Distinguished Names ist keinesfalls trivial. Ein
– 108 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
zugestellt wurde, er kann also ebenfalls wieder verfallen. In das Attribut Expires“ wird eine
”
Frist für die Reservierung eingetragen, welche der speziellen individuell festgelegten Frist für
Registrierungsanträge entspricht, da diese üblicherweise nicht unbegrenzt bestehen, z.B. für
den Fall wenn der Antragsteller obwohl gefordert niemals persönlich erscheint.
Innerhalb dieses Zeitraums kann der Distinguished Name also nicht für eine andere Person reserviert werden und gilt quasi als vergeben, ist jedoch nach außen nicht sichtbar. Soll
nach Ablauf des Zeitraums bzw. der Frist der Distinguished Name für einen anderen neuen
Teilnehmer reserviert werden, so kann dies geschehen und im Zuge dieses Vorgangs wird der
alte abgelaufene Reservierungsdatensatz gelöscht oder mit dem Flag-Attribut Expired“ ge”
kennzeichnet. Auf diese Weise ist auch eine Art Historienaufzeichnung möglich. Jedoch muß
dann die Vergabe eines Distinguished Names unter Beachtung dieses Flags erfolgen, da ein
Distinguished Name, der nur als Expired“ gekennzeichnet ist und sonst nicht in der Tabelle
”
vorkommt, erneut vergeben werden darf.
Ist der Registrierungsvorgang erfolgreich beendet, wird das Flag InUse“ gesetzt sowie der
”
Distinguished Name auch in anderen Tabellen der TrustCenter-Datenbank genutzt, er ist also
nun aktiv.
Beim Verfall eines reservierten Distinguished Name ist eine weitere spätere Reservierung
bzw. Vergabe sinnvoll, denn dieser Distinguished Name wurde noch nicht aktiv genutzt. Anders
verhält es sich, bei bereits verwendeten aber abgelaufenen Distinguished Names (siehe auch
Abschnitt 4.10.3). Dies kann z.B. auftreten, wenn ein Teilnehmer eine PKI verläßt. Hierbei kann
die erneute Vergabe eines alten Distinguished Names, z.B. bei Namensgleichheit, problematisch
sein. Für solche Fälle ist es möglich, die Tabelle T DNreserved“ um das Attribut-Flag Dead“
”
”
zu erweitern, um derartige Distinguished Names zu kennzeichnen.
Bei einer Vorgehensweise dieser Art hat die Tabelle T DNreserved“ natürlich keinen Pri”
märschlüssel, da selbst EntityNo“ und DN“ doppelte Attributwerte enthalten können, dies
”
”
ist aber auch nicht notwendig. Mit Hilfe von folgender SQL-Anweisung z.B. erhält man eine
Liste aller z.Z. reservierten Distinguished Names. Man kann ebenfalls zusätzlich noch einen
Distinguished Name als Kriterium in die Anweisung einfügen, nach welchem im Speziellen
gesucht wird:
SELECT T_DNreserved.DN
FROM
T_DNreserved
WHERE (T_DNreserved.Dead=No) AND (T_DNreserved.InUse=No)
AND ((T_DNreserved.Expires)<=#9/30/2004#)
AND ((T_DNreserved.Expired)=No));
Des weiteren müssen vor der Vergabe eines Distinguished Names separat die Dead“-, Ex”
”
pired“- und InUse“-Werte abgeprüft werden. Auch muß nach gewissen Kriterien das Expi”
”
red“-Flag gesetzt werden. Eine Alternative zum Umgang mit den einzelnen Flag-Attributen,
also InUse“, Expired“ und Dead“, ist eine Kombination dieser zu einem einzigen Zahlenfeld
”
”
”
als Attribut.
Ebenso ist das Führen von Logs über Veränderungen zu empfehlen (siehe Abschnitt 4.10.1),
weil damit die Nachvollziehbarkeit gerade bzgl. Distinguished Names als lesbare Kennzeichner
und deren Verknüpfung mit Zahlenwerten als Kennzeichner sowie Zertifikaten gefördert wird.
Folglich wird das Ziel der eindeutigen Verknüpfung von erweiterten Registrierungsdaten, also
auch von Daten, welche nicht im Zertifikat enthalten sind, und Zertifikaten erreicht.
solcher Fall ist das Festlegen der Distinguished Names für zwei Personen, die potentiell beide den selben Namen erhalten müßten.
Ein weiteres Beispiel ist das Behandeln reservierter Distinguished Names, bei welchen der zugehörige Registrierungsvorgang
erfolgreich verlief, jedoch das Erstellen des Zertifikats fehlschlug.
– 109 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Man beachte, daß im Falle der Zustellung von zentral erzeugten privaten Schlüsseln mittels der CMA ein PKI-Mitgliedskonto erst freigeschaltet wird, wenn die Ankunft des privaten
Schlüssels beim vorgesehenen Empfänger, dem jeweiligen PKI-Teilnehmer, bestätigt ist. Auch
dessen Entry innerhalb des Verzeichnisdienstes (siehe auch Abschnitt 2.7) wird erst danach
freigeschaltet und für andere PKI-Teilnehmer sichtbar, wenngleich dieser u.U. bereits besteht.45
4.10.3
Multiple Zertifikate und multiple Distinguished Names
Wie in den Abschnitten 2.7.5 und 4.1.1 beschrieben, können bei heutigen PKIs durchaus mehrere Zertifikate und auch Distinguished Names pro einem einzigen PKI-Mitglied vorkommen.
Dies muß auch von der Datenbankapplikation des TrustCenters verwaltet werden können.
Da Zertifikate über Distinguished Names angesprochen und eindeutig zugeordnet werden
können, läßt sich die Verwaltung von multiplen Zertifikaten durch die Verwaltung von multiplen
Distinguished Names realisieren, etwa mit einer Tabelle T Certs(DN,Cert,Valid)“. Dennoch
”
könnte man eine Tabelle zur Speicherung von Zertifikaten in der TrustCenter-Datenbank, wie
bereits bei FlexiTrust vorhanden, erweitern und spezielle Zertifikatseigenschaften (siehe auch
Abschnitt 2.7.5) erfassen. Auch ist es denkbar, für verschiedene Zertifikatstypen verschiedene
Tabellen zu verwalten und nur eine Gesamttabelle als Verbindung oder Verknüpfung dieser
Subtabellen zu führen. Klar ist, daß aus dem Zertifikat selbst z.B. dessen Gültigkeitszeitraum
oder aktuell zugeordneter Distinguished Name hervorgeht. Diese Daten kann man auch zwecks
einfachem Datenbankzugriff in die Tabelle T Certs“ einfügen. Auch ist es möglich, alte und
”
abgelaufene Zertifikate zu archivieren, z.B. durch das Attribut Valid“, oder sie gänzlich zu
”
entfernen.
Die Zuordnung von Zertifikaten zu PKI-Teilnehmern bzw. deren Registrierungsdaten kann
durchaus mittels eines Distinguished Names des Teilnehmers erfolgen. Die Vergabe von einfachen Distinguished Names wurde in Abschnitt 4.10.2 bereits erläutert und auch die Zuordnung
von Registrierungsdaten und Distinguished Names wurde dort beschrieben. Daher lassen sich
Zertifikate unter Beachtung ihres Gültigkeitszeitraums und von Revokationen über den Distinguished Name und u.U. dessen Gültigkeitszeitraum einem Registrierungsdatensatz eindeutig
zuordnen.
Dabei stört es nicht, wenn ein Teilnehmer mehrere Zertifikate besitzt. Eine Verwaltung etwa
über die Tabelle T Certs“ ist trotzdem einfach möglich. Jedoch muß in diesem Falle natürlich
”
bei der Suche nach einem passenden Zertifikat ein eindeutiger Parameter, neben einem Namen
oder Distinguished Name, angegeben werden, um das gesuchte Zertifikat identifizieren zu
können. Dieser Parameter ist stark abhängig vom Kontext der jeweiligen PKI, ein Beispiel ist
die Suche nach dem Zertifikat eines PKI-Mitglieds zum Signieren oder Verschlüsseln – innerhalb
einer PKI, bei welcher eine solche Trennung von Zertifikaten durchgeführt wird (siehe auch
Abschnitt 2.7.5).
Zur Verwaltung von multiplen Distinguished Names läßt sich das Datenmodell von FlexiTrust ebenfalls erweitern, z.B. auch basierend auf der Tabelle T DNreserved“ aus Abschnitt
”
4.10.2. Dazu muß eine Verknüpfung zwischen Zertifikaten trotz verschiedener Distinguished
Names zu einer bestimmten Person bzw. zu einem bestimmten PKI-Teilnehmer dennoch eindeutig erfolgen.
Es erscheint hierfür sinnvoll, einer solchen Person für interne Vorgänge eine eindeutige
Kennzeichnung in Form eines festgelegten Zahlenwerts zu vergeben, eine ID. Im Datenmodell
wird z.B. in den Personentabellen, z.B. Entity“, sowieso eine solche ID als Primärschlüssel
”
45 Siehe
auch [Kar04] über das Verwalten von PKI-Aufgaben mittels CMA bzw. Verzeichnisdienst. Dabei geht es ebenso u.a.
um Zustellung von Schlüsseln und Absichern von Verzeichnisdiensten.
– 110 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
benutzt. Eine separate Tabelle, wie etwa T DNToEntity(DN,EntityNo,Valid)“, kann dann die”
se IDs mit Distinguished Names verknüpfen. Zusätzliche Informationen, wie Gültigkeitsbeginn
und -ende oder aktuelle Gültigkeit an sich sowie weitere sinnvolle Daten, für den jeweiligen
Distinguished Name können dann ebenfalls dort gespeichert werden.
Nach einer solchen Auslagerung der Distinguished Name-Verwaltung ist es möglich, einer
bestimmten registrierten Person, mehrere Distinguished Names eindeutig zu zuordnen und evt.
ebenfalls Aufzeichnungen zum Lebenszyklus veralteter Distinguished Names aufzubewahren
(siehe auch Abschnitt 4.10.1). Natürlich muß durch die Datenbankapplikation des TrustCenters
gewährleistet sein, daß Distinguished Names weiterhin eindeutig vergeben werden und was mit
abgelaufenen aber bereits genutzten Distinguished Names im Sinne der PKI geschehen soll.
Ebenfalls denkbar ist es, die Verwaltung von multiplen Zertifikaten ähnlich wie bei multiplen
Distinguished Names auf Basis der Personen-ID zu gestalten. Da Zertifikate aber öffentlich
sind und aufgrund ihrer Signierung einen Distinguished Name jeweils fest integriert haben,
müssen sich Zertifikate bei Veränderungen der Distinguished Names ebenfalls ändern, womit
sie direkt von den Distinguished Names abhängig sind – zumindest für manche Anforderung
der Praxis (siehe z.B. Abschnitt 2.7).
4.10.4
Multiple TrustCenter
Es ist denkbar, FlexiTrust an einem Standort oder auf einem Server nicht nur als einzelnes
spezielles TrustCenter zu betreiben, sondern dort auch mehrere TrustCenter-Anwendungen,
z.B. für verschiedene Gruppierungen bzw. Kunden, zu verwalten.
Dazu gehört, die Zuordnung zwischen Entities bzw. deren Tabellen sowie den verschiedenen
Kunden herzustellen. Eine einfache Möglichkeit dafür wird von einigen Datenbanksystemen,
z.B. dem Microsoft SQL-Server, zur Verfügung gestellt, indem man an einem einzigen auf
einem Server installierten Datenbanksystem mehrere Datenbankserver aufbauen kann. Diese
können dann individuelle Namen erhalten sowie Tabellen beinhalten und sind voneinander vor
allem beim Datenbankzugriff streng getrennt.
Um weiterhin flexibel zu bleiben, kann man diese Zuordnung aber auch in die Datenbankapplikation von FlexiTrust und deren Datenmodell direkt integrieren. Hierfür existieren viele
Erweiterungsmöglichkeiten des vorhandenen Datenmodells, Beispiele werden im Folgenden beschrieben.
• Hilfstabelle hinzufügen: Mit Hilfe einer neuen Tabelle T Customers(TableName,Customer) könnte man Tabellen und Entities in der TrustCenter-Datenbank einem speziellen
Kunden-TrustCenter mit eindeutigem Kundennamen zuordnen.
• Konfigurationsdateien hinzufügen: Ähnlich wie bei den Hilfstabellen könnte man Kunden
und deren Daten in Konfigurationsdateien definieren.
• Dynamische Tabellendefinitionen erweitern: Bei dynamischen Tabellen (siehe Abschnitt
4.8.3) könnte man eine weitere feste Tabelle T Customers(CustomerName,TrustCenter”
ID,TableID)“ einführen oder die vorhandene T Tabellen“ zur T Tables(Tab,Attr,Tab”
”
ID,TrustCenterID)“ erweitern. Im letzten Fall wäre die Definition der T Customers“
”
kleiner. Bei beiden Varianten wären z.B. Entity-Tabellen direkt mit dem jeweiligen speziellen Kunden-TrustCenter verbunden. Der Vorteil dieser Lösung ist, daß die als Daten
dynamisch verwalteten Tabellen natürlich auch mehrfach vorkommen dürfen, also beispielsweise mit identischen Namen. Der Primärschlüssel zur eindeutigen Kennzeichnung
einer bestimmten Tabelle besteht bei dieser Variante aus den Attributen TabID“ und
”
– 111 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
TrustCenterID“, wobei auch das Verbinden mit dem Distinguished Name des speziellen
”
TrustCenters vorstellbar ist.
• Entity-Tabellen erweitern: Bei Entity-Tabellen könnte man ein neues zusätzliches Attribut TrustCenterID“ einfügen. Die Zuordnung von Kunden und Kundennamen zur
”
TrustCenterID“ kann dabei über Hilfstabellen oder Konfigurationsdateien erfolgen, wo”
bei auch hier wieder das Verbinden mit dem Distinguished Name des speziellen TrustCenters vorstellbar ist. Konkrete Personendaten könnten dann z.B. über eine Tabelle
Entity(...,TrustCenterID)“ gespeichert und jeweils einem der Kunden-TrustCenter zuge”
ordnet werden.
Bei allen hier gezeigten Möglichkeiten zur Realisierung von multiplen TrustCentern muß der
Quellcode von FlexiTrust verändert werden, um mit einer der Lösungen umgehen zu können.
Die Repräsentationsklassen der OpenRA etwa, also der Datenbankapplikation, können dazu
um einen zusätzlichen Parameter erweitert werden, womit z.B. eine Entity eines eindeutig
bezeichneten Kunden angefordert werden kann.
Für jeden Teil der TrustCenter-Applikation bedeutet das Vorhandensein multipler TrustCenter, also mehrerer verschiedener Issuer, grundlegende Änderungen. Denn unterschiedliche Issuer
führen zu unterschiedlich strukturierten Distinguished Names, was natürlich ebenfalls Auswirkungen auf die Verwaltung von Distinguished Names und das ursprüngliche Datenmodell aus
Abbildung 17 hat. Um diese zu unterstützen, müssen alle Applikationsteile dementsprechend
angepaßt werden.
Des weiteren muß man sichere administrative Vorgänge zur strikten Trennung der Datenquellen für einzelne Kunden entwickeln. Die bisherige Vorgehensweise bei FlexiTrust bzgl. der
Benutzerverwaltung der Datenbank (siehe auch Abschnitt 4.10.1) etwa ist dann nicht mehr
fortzuführen. Denn auch bei einem TrustCenter-Produkt, welches geeignet ist, viele verschiedene TrustCenter zugleich zur Verfügung zu stellen, müssen grundlegende Ziele von PKIs (siehe
auch Abschnitt 2.1) gewährleistet werden, wie z.B. die isolierte Kommunikation innerhalb eines
bestimmten Personenkreises.
4.10.5
Unterstützen des Verzeichnisdienstes
Es ist ebenfalls möglich, die TrustCenter- bzw. RA-Datenbank oder genauer das zugrundeliegende Datenbanksystem für den LDAP-Verzeichnisdienst des TrustCenters zu nutzen. Je nach
Aufteilung von TrustCenter-Komponenten (siehe Abschnitt 2.3.1) ist dies überhaupt möglich,
sinnvoll oder sicher (siehe auch [Kar04]). Es kann auch notwendig sein, RA-Datenbank und
Verzeichnisdienst zu trennen, obwohl beide mit sich überschneidenden Daten arbeiten.
OpenLDAP (siehe Abschnitt 2.7.3 bzw. [Ope04]) beispielsweise besitzt einerseits eine integrierte Datenbank als Back-End, aber es ist andererseits ebenfalls möglich, ODBC-Datenbanken als Back-End zu verwenden.
Eine mögliche Anwendung für die Kombination von RA-Datenbank und Verzeichnisdienst
liegt bei einer Verzeichnisdienst-Realisierung mit LDAP und Attribute Extraction (siehe Abschnitt 2.7ff.) vor. So könnte man in diesem Falle bestimmte Attribute aus der RA-Datenbank
für die Zertifikat-Suche auf dem LDAP-Tree zur Verfügung stellen, z.B. Telefonnummer falls
vorhanden, und zwar indem man diese auch im jeweiligen LDAP-Entry ablegt.
4.10.6
Erstellen von Datenbank-Berichten bzw. Datenbank-Auszügen
Es ist in der Praxis oftmals sinnvoll oder notwendig Datenbank-Berichte zu erstellen, etwa für
Statistiken oder zur Bestimmung fehlerhafter Datensätze.
– 112 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Um solche Berichte bei FlexiTrust bzw. innerhalb der OpenRA zu erstellen und auszugeben,
existieren u.a. folgende Möglichkeiten:
• Erstellen von Java-Klassen für gängige und allgemeine Berichte,
• Anbieten einer direkten SQL-Schnittstelle zur Datenbank,
• Nutzen von zusätzlichen Datenbank-Werkzeugen.
4.10.7
Wahl des Datenbanksystems und Spezialisierungsbeispiel
Offensichtlich ist es sinnvoll, in der Wahl eines Datenbanksystem-Produkts für eine bestimmte
Datenbankapplikation frei bleiben oder zumindest sich schnell anpassen zu können.
Unter Java existieren durch JDBC viele Möglichkeiten, eine Datenbankverbindung aufzubauen, z.B. über ODBC oder einen speziellen Datenbank-Treiber. Diese beiden Möglichkeiten
haben jeweils ihre Vorteile und sind schlichtweg Alternativen. Des weiteren erfolgt die Festlegung einer solchen Verbindungsmethode unter Java über die Angabe eines einfachen Strings,
womit einzelne Varianten leicht auszutauschen und z.B. über Konfigurationsdateien einlesbar sind. Im letzteren Fall wäre also nicht einmal eine Neukompilation des Quellcodes der
Datenbankapplikation vonnöten.
Auch kann man mittels ODBC die Notwendigkeit zur Änderung der Angabe von Strings
für die Datenbankverbindung umgehen. Für eine konkrete Datenbankapplikation könnte man
einen einmaligen bzw. eindeutigen Namen für die zugehörige im System registrierte ODBCDatenbank wählen, z.B. FlexiDB“ bei FlexiTrust. Somit wären für die Datenbankverbindung
”
keine Änderungen im Quellcode oder in Konfigurationsdateien nötig, da stets dieser Name
verwendet wird (siehe auch Abschnitt 4.3.1). Natürlich muß bei dieser Variante stets die
ODBC-Datenquelle vor Ort eingerichtet werden.
Bleibt man flexibel in der Wahl des Datenbanksystems, z.B. beim Einsatz eines TrustCenters aufgrund von jeweiligen Anforderungen oder des möglichen Kundenwunschs (siehe auch
Abschnitt 3.7), hat dies natürlich auch Nachteile. Denn man darf im Quellcode Besonderheiten eines speziellen Datenbank Management-Systems (DBMS; siehe Abschnitt 3.2) und auch
dessen Vorteile nicht nutzen, z.B. im Umgang mit Transaktionen oder Triggern.
Bei einem TrustCenter liegt das Augenmerk jedoch nicht hauptsächlich auf der zugehörigen Datenbank. Denn einerseits ist die wichtigste Aufgabe eines TrustCenters die Realisierung
einer PKI und der Umgang mit Kryptosystemen und andererseits sind die technischen Anforderungen an eine TrustCenter-Datenbank nicht mit z.B. denen einer aktiven Datenbank oder
eines Online-Shops vergleichbar. Hierbei wiederum ist der Einsatz von Stored Procedures,
Transaktionen, Triggern, Methoden des Recoverys usw. äußerst notwendig.
Bei der Java-Implementierung FlexiTrust kommen also keine DBMS-speziellen Schnittstellen für Datenbankzugriffe zum Einsatz sondern allgemeine Standard-Wege, wie z.B. JDBC
und ODBC. Probleme werden mit Java-Methoden gelöst. Ein Beispiel für die Nutzung der
Besonderheiten eines Datenbanksystems bzw. Datenbank Management-Systems ist dennoch
bei FlexiTrust zu sehen. Hier wird z.Z. MySQL46 als Back-End für die Datenbankapplikation
genutzt. Eigenheiten von MySQL finden bei diesen beiden Java-Klassen Beachtung:
• Entity.java,
• XMLFormManager.java.
46 Im Unterschied zu manch anderem Datenbanksystem unterstützt MySQL keinerlei Trigger-Funktionen (siehe z.B. [Ste99]).
Da diese aufgrund des Ziels der Flexibilität aber nicht genutzt werden würden und weil MySQL eine kostengünstige OpenSourceEntwicklung ist, eignet es sich gut als Back-End bei FlexiTrust.
– 113 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
In der Entity.java“ wird der Datentyp der Java-Booleans in Integer umgewandelt, weil
”
MySQL keine Booleans unterstützt. Diese Vorgehensweise kann allerdings beibehalten werden,
da sie auch auf andere Datenbanksysteme übertragbar ist, und deren evt. Unterstützung für den
Typ Boolean nicht genutzt werden muß.47 Außerdem ist in der Praxis bei der Datenerfassung in
einigen Fällen die Nutzung von Booleans, also Ja oder Nein“-Werten, nicht empfehlenswert,
”
zumindest falls ein entsprechendes Attribut nicht auch den Wert NULL (siehe Abschnitt 3.5.2)
zugewiesen bekommen kann. Immer möglich ist es, auch mit dem Verzicht auf Booleans,
mittels Zahlenwerten die Kombination Ja, Nein, unbekannt“ zu realisieren mit unbekannt“
”
”
als Standardwert.
Bei der XMLFormManager.java“ wird an einer Stelle, bei welcher das Laden eines For”
mular-Objekts realisiert wird, eine spezielle SQL-Anweisung des Datenbanksystems MySQL
benutzt:
query.append(" ORDER BY serialno LIMIT 1");
Diese hat zum Zweck, die Anzahl der zurückgegebenen Datensätze in der Query-Ausgabe zu
beschränken und zwar auf einen Datensatz.
Java bietet hier jedoch eine äquivalente Lösung an, die somit unabhängig von Eigenheiten
eines Datenbanksystems ist. Das Interface java.sql.Statement, aus welchem stets der JavaCursor ResultSet resultiert, sieht die folgende Methode vor:
void setMaxRows(int max)
Sets the limit for the maximum number of rows
that any ResultSet object can contain to the given number.
Bei der Wahl des zugrundeliegenden Datenbanksystems kommen Transaktionen und deren
Unterstützung von Seiten des DBMS für bestimmte Datenbankapplikationen, wie dem vorgestellten TrustCenter-Modell mit dessen Datenmodell, eine wichtige Rolle zu. Auf diese wird in
Abschnitt 4.10.8 näher eingegangen.
4.10.8
Bedeutung von Transaktionen
Die Notwendigkeit, daß ein Datenbanksystem, welches als Grundlage für die Datenbankapplikation des vorgestellten TrustCenter-Modells dient, Transaktionen und die ACID-Eigenschaften
(siehe auch Abschnitt 3.3) unterstützen muß, wird im Folgenden näher erläutert.
Transaktionen und die ACID-Eigenschaften sind die Voraussetzung, daß verschiedene der
gezeigten Datenbankoperationen auf dem vorgestellten Datenmodell (siehe Abbildung 17 auf
Seite 17) fehlerfrei funktionieren und nicht zu inkonsistenten Datenbeständen führen.
Daher muß ein entsprechendes DBMS beide Merkmale, Transaktionen und ACID, besitzen,
wobei diese innerhalb von Datenbankverbindungen mittels JDBC auch genutzt werden können.
Man beachte, daß Transaktionsmodelle nicht nur für Datenbankoperationen existieren sondern ebenfalls für den Umgang mit reinen Codeobjekten. Im letzteren Falle muß also kein Bezug
zu einer Datenbank vorhanden sein. Ein Transaktionsmodell für Java ist das Java Transaction
Application Programming Interface bzw. Java Transaction API (JTA), welches Bestandteil der
Java 2 Enterprise Edition (J2EE) ist. Hierbei handelt es sich auch um eine Java-Schnittstelle
zum Object Transaction Service (OTS) der Common Object Request Broker Architecture
(CORBA). Damit wird der Aufbau einer Transaktionsverwaltung für Java-Objekte möglich,
was beispielsweise beim synchronen Datenaustausch zwischen Clients und Servern wichtig ist.
47 Wahrheitswerte werden nicht immer in allen Systemen unterstützt, wie z.B. bei Programmiersprachen. Bei C etwa muß man
sich zu deren Realisierung ebenfalls mit anderen Datentypen behelfen.
– 114 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
In der vorgestellten Datenbankapplikation des TrustCenter-Modells werden sowohl reine
Datenbankobjekte sowie Codeobjekte, also Instanzen von Repräsentationsklassen, verwendet.
Es reicht für die Datenbankapplikation jedoch nicht aus, eine reine Transaktionsverwaltung für
Java-Objekte zu nutzen.
Denn für Operationen auf der zugrundeliegenden Datenbank muß auch das DBMS Transaktionen zur Verfügung stellen sowie die ACID-Eigenschaften gewährleisten. Diese beiden Merkmale sind beispielsweise an essentieller Stelle unumgänglich, nämlich beim Umgang mit mehrstufigen Entity-Objekten (siehe auch Abschnitt 4.6.2) des Datenmodells aus Abbildung 17. Sie
gewährleisten hier die referentielle Integrität (siehe Abschnitt 3.4.5) des Datenbestandes und
sorgen dafür, daß keine Inkonsistenzen entstehen.
Folgendes einfaches aber konstruiertes Beispiel zeigt, wie ein inkonsistenter Datensatz entstehen kann, welcher die referentielle Integrität verletzt:
Einfügen eines Datensatzes in T_Student
[...]
(Einfügen erfolgreich)
- Systemabsturz Vorgesehenes Einfügen des passendes Datensatzes in T_Person
(Findet nicht mehr statt)
Vorgesehenes Aktualisieren des Fremdschlüssels in T_Student
(Findet nicht mehr statt)
Zum Zeitpunkt nach dem Systemabsturz ist in T Student“ ein Datensatz zu finden, für den
”
kein Datensatz in T Person“ existiert. Mit Hilfe des Einsatzes von Transaktionen kann ein
”
solcher Fall jedoch verhindert werden. Die Aktualisierung bzw. das Einfügen von mehrstufigen
Objekten erfolgt dann allgemein so:
BOT
[...]
Datenmanipulation an zwei oder mehr Tabellen
[...]
EOT
Geschieht hier beispielsweise während der Transaktion, also noch vor EOT, ein Systemabsturz,
so garantiert das DBMS, daß keine Änderungen an der Datenbank sichtbar sind. Nach einem
erfolgreichen EOT jedoch, sind alle Änderungen persistent.
Ein solches Vorgehen ist bei der Nutzung von JDBC und Java ebenfalls einfach möglich und
wird durch folgendes Zitat aus der API-Dokumentation zum Interface java.sql.Connection
gut beschrieben:
By default a Connection object is in auto-commit mode, which means that it automatically commits changes after executing each statement. If auto-commit mode
has been disabled, the method commit must be called explicitly in order to commit
changes; otherwise, database changes will not be saved.
Die vorgestellte Variante einer JDO-Realisierung für die Datenbankapplikation nutzt das JDOeigene Interface javax.jdo.Transaction (siehe Klasse testJDOPerson.java“ aus Abschnitt
”
4.7.3). Hierbei handelt es sich um ein separates Transaktionsmodell speziell für JDO im Umgang mit Datenbanken. Auch Concurrent Transactions“ werden hier unterstützt.
”
– 115 –
4
DATENBANKAPPLIKATIONEN FÜR TRUSTCENTER
Letzteres, also die Unterstützung des Mehrbenutzerbetriebs (siehe auch Abschnitt 3.2),
ist ebenfalls für das vorgestellte TrustCenter-Modell bzw. dessen Datenbankapplikation unumgänglich. Der Mehrbenutzerbetrieb setzt voraus, daß das benutzte DBMS die ACID-Eigenschaften gewährleistet und sich somit parallele Transaktionen nicht behindern. Z.B. darf ein
von einer Transaktion eingefügter Datensatz erst nach Beendigung des gesamten Einfügevorgangs für andere Transaktionen sichtbar sein (Isolation; siehe Abschnitt 3.3).
D.h., selbst beim Verzicht auf mehrstufige Objekte, wodurch also stets nur auf einer Tabelle
innerhalb einer Transaktion operiert würde, ist ein DBMS mit ACID-Eigenschaften für den
Mehrbenutzerbetrieb der Datenbankapplikation erforderlich.
– 116 –
A
Anhang
A.1
Beigefügte Software bzw. Dateien
Zu dieser Arbeit gehören die folgenden Java-Klassen und Dateien, welche auch zum Teil in
Kapitel 4 genauer beschrieben wurden:
• Acc2DynTab.java,
• AccJDBC.java,
• ChefFromPersonOnly.java,
• Entities.java,
• JDOPerson.java,
• jdori-1 0-fcs-src-04 Mar 2002.zip,
• MyTestDB.mdb,
• MyTestDB.zip,
• PersonSerial.java,
• PersonAccResset.java,
• PersonOnly.java,
• testAcc2DynTab.java,
• testAccJDBC.java,
• testChefFromPersonOnly.java,
• testEntities.java,
• testJDOPerson.java,
• testJDOPerson.jdo,
• testPersonAccResset.java,
• testPersonSerial.java,
• testPersonSerial.txt.
Hierbei sind die Dateien test*.java ausführbare Programme bzw. einfache Test-Klassen für
die restlichen bereits in dieser Arbeit vorgestellten Java-Klassen. Des weiteren ist für das JDOBeispiel ein ZIP-Archiv beigefügt, welches das JDO-Paket inkl. Dokumentationen enthält.
– 117 –
A
A.1.1
ANHANG
Beispiel-Datenbank
MyTestDB.mdb ist eine Access-Datenbankdatei, die für verschiedene Beispiele dieser Arbeit als
relationale Datenbank dienen kann und mittels ODBC bzw. JDBC-ODBC-Bridge angesprochen
wird.
Die Vorteile einer solchen – sehr leistungsfähigen – Datenbank bzw. Datenbankdatei sind:
• Gute Eignung für Tests,
• einfache Weitergabe und dies ohne Installation,
• einfache Kontrolle von Dateninhalten.
Zur Nutzung als reine Datengrundlage muß man nicht im Besitz des Erzeugerprogramms Mi”
crosoft Access“ sein sondern nur eines passenden ODBC-Treibers. Unter Microsoft Windows“
”
erfolgt die Einrichtung dieser Datei bzw. Datenbank einfach über die Systemsteuerung bzw.
den Menüpunkt ODBC-Datenquelle“ und dort über Benutzer-DSN hinzufügen“. An dieser
”
”
Stelle gibt man den Pfadnamen zur MDB-Datei an und wählt einen Namen für die ODBCQuelle, z.B. MyTestDB“ wie in den Beispielen dieser Arbeit.
”
Selbstverständlich kann als Datenbankgrundlage für die vorgestellten Java-Klassen auch
jedes andere Datenbanksystem mittels JDBC und ggf. ODBC genutzt werden, wobei die notwendigen Tabellen für die Beispiele in den jeweiligen Abschnitten dieser Arbeit angegeben
sind. Des weiteren enthält die Archiv-Datei MyTestDB.zip Textdateien mit allen benutzten
Tabelleninhalten und SQL-Anweisungen.
A.2
Technische Voraussetzungen
Die Java-Quelltexte zu dieser Arbeit (siehe Abschnitt A.1) wurden mit Ant 1.4.1“ unter dem
”
JDK 1.2.2“ kompiliert und getestet.
”
JDO bzw. JDORI von Sun, aus dem Internet heruntergeladen – siehe [Sun04-1], wurde in
der Version 1.0.1 eingesetzt. Beim Ausführen des JDO-Beispiels waren die folgenden JavaArchive aus dem JDO-Paket im CLASSPATH:
• btree.jar,
• jdo.jar,
• jdori.jar,
• jdori-enhancer.jar.
– 118 –
Literatur
[Ada02] Carlisle Adams & Steve Lloyd, Understanding PKI: Concepts, Standards, and Deployment Considerations, Addison-Wesley, Second Edition, 2002
[Bes97] Bestavros et alii, Real-time Database Systems – Issues and Applications, Kluwer Academic Publishers, 1997
[Boe02] Dr. W. Böhmer, VPN – Virtual Private Networks, Carl Hanser-Verlag, 2002
[Buc04] Prof. Dr. Johannes Buchmann, Einführung in die Kryptographie, 3. Auflage, SpringerVerlag, 2004
[Bus02] Dr. Christoph Busch & S. Wolthusen, Netzwerksicherheit, Spektrum Akademischer
Verlag, 2002
[Cha00] David W. Chadwick, Secure Directories, 2000
[Cha03-1] David W. Chadwick, Deficiencies in LDAP when used to support Public Key Infrastructures, 2003
[Cha03-2] David W. Chadwick, Modifying LDAP to Support X.509-basedPKIs, 2003
[Dam01] Jens Dambruch, OpenRA – Framework zur flexiblen Formularverarbeitung, Diplomarbeit an der TU Darmstadt – Fachbereich Informatik, 2001
[Dat03] Date, An Introduction to Database Systems, Addison Wesley, 2003
[Eck02] Prof. Dr. Claudia Eckert, IT-Sicherheit, Oldenbourg-Verlag, 2002
[Elm94] Elmasri & Navathe, Fundamentals of Database Systems, Addison Wesley, 1994
[Ern04] Andreas Ernst, Quasi-stellares Objekt, Javamagazin, S.85ff., 03/2004
[Fle04] FlexiProvider, www.flexiprovider.de, 2004
[Fro01] Daniel Fröhlich et alii, Java Data Objects (JDO) im Überblick, Java Spektrum,
04/2001
[Gro93] Grolier Inc., New Grolier Multimedia Encyclopedia/Grolier’s Academic American Encyclopedia, 1993
[Hae99] Härder et alii, Datenbanksysteme – Konzepte und Techniken der Implementierung,
Springer-Verlag, 1999
[Heu00] Heuer & Saake, Datenbanken – Konzepte und Sprachen, Thomson Publishing, 2000
[Hom04-1] Frank Homann, Randomized Addition-Subtraction Chains as a Countermeasure
against Power Attacks, Seminarvortrag und -ausarbeitung nach dem gleichnamigen Paper
an der TU Darmstadt – Fachbereich Informatik, 2004
[Hom04-2] Frank Homann, Verzeichnisdienst in der PKI, Seminarvortrag und -ausarbeitung
an der TU Darmstadt – Fachbereich Informatik, 2004
[Inf98] Informix Software Inc., Informix Guide to SQL, 1998
[Jak04] Robert Jakimovski, JDO-Anwendungen entwerfen, Java Spektrum, 01/2004
– 119 –
LITERATUR
[Jav04] Java Persistence Object Manager (JPOM), www.jpom.de, 2004
[Jor02-1] David Jordan, A comparison between Java Data Objects (JDO), Serialization and
JDBC for Java persistence, JDOcentral.com, 03/2002
[Jor02-2] David Jordan, JDOQL – The JDO Query Language, Javapro.com, 07/2002
[Jor03] David Jordan & Craig Russell, JDO or CMP?, ONJava.com, 05/2003
[Kan04] Sebastian Kanthak, XML-Formulare in der RA, Praktikumsarbeit an der TU Darmstadt – Fachbereich Informatik, 2004
[Kar02-1] Vangelis Karatsiolis, Publishing PKI Information, Vortrag an der TU Darmstadt,
2002
[Kar02-2] Vangelis Karatsiolis, Certificate Management and Directories, Vortrag an der TU
Darmstadt, 2002
[Kar04] Vangelis Karatsiolis et alii, Using LDAP Directories for Management of PKI Processes,
2004
[Kru00] Guido Krüger, Go To Java 2 – Handbuch der Java-Programmierung, 2. Auflage,
Addison Wesley, 2000
[Men96] A. Menezes & P. van Oorschot & S. Vanstone, Handbook of Applied Cryptography,
CRC Press, 1996
[Mey90] Meyers Lexikonverlag, Meyers Lexikon, 1990
[Mic00] Microsoft, Microsoft Developer Network (MSDN) Library, 2000
[Mue02] Klaus Müllner et alii, Java-basierte Datenhaltung, Java Spektrum, 11/2002
[Nzz01] NZZ Online, Versteckspiele mit der Musikindustrie,
www.nzz.ch/2001/04/27/em/page-article7CTK0.html, 2001
[Ope04] OpenLDAP Project, www.openldap.org, 2004
[Osw01] Elisabeth Oswald & Manfred Aigner, Randomized Addition-Subtraction Chains as a
Countermeasure against Power Attacks, Graz University of Technology, 2001
[Poe03] Poet Software GmbH, Performance with FastObjects for JDO, 08/2003
[Ram00] Ramakrishnan, Database Management Systems, McGraw Hill, 2000
[RSA04] RSA Laboratories, Public-Key Cryptography Standards, www.rsasecurity.com, ab
1991
[Rus01] Craig Russell, Java Data Objects - Proposed Final Draft 3, Sun Microsystems Inc.,
2001
[Sal97] Arsalan Saljoughy, Object persistence and Java, Javaworld.com, 05/1997
[Sam04] Dr. Bruce J. Sams, Sicheres JDBC, Javamagazin, S.42ff., 03/2004
[Sch01] Markus Schuster, OpenRA – Framework zur flexiblen Formularverarbeitung, Diplomarbeit an der TU Darmstadt – Fachbereich Informatik, 2001
– 120 –
LITERATUR
[Sol03] SolarMetric, Persistence Frameworks – JDO simplifies the “Buy versus Build“ decision,
2003
[Sta03] Hans Stadtherr, JDO im Einsatz, Java Spektrum, 03/2003
[Ste99] Guido Stepken, MySQL Datenbankhandbuch, 1999
[Sun01] Sun Microsystems, RMI Specification – RMI API and System, 2001
[Sun04-1] Sun Java-Systeme, java.sun.com, 2004
[Sun04-2] Sun-Entwicklerartikel zum Thema Sicherheit“,
”
developer.java.sun.com/developer/technicalArticles/Security, 2004
[Tei97] J. Teich, Digitale Hardware/Software-Systeme, Springer-Verlag, 1997
[Ull00] Christian Ullenboom, Java ist auch eine Insel, 2000
[Ver99] VeriSign, Directories and Public Key Infrastructure (PKI), 1999
[Wan04] Gerhard Wanner et alii, Persistenzoperationen mit Mustern optimieren, Java Spektrum, 01/2004
[Wid96] J. Widom & S. Ceri, Active Database Systems – Triggers and Rules for Advanced
Database Processing, Morgan Kaufmann, 1996
[Zoe02] Jens Zörkler & Torsten Hofacker, FormsServlet – A servlet for the RegistrationAuthority, Praktikumsarbeit an der TU Darmstadt – Fachbereich Informatik, 2002
[Zoe03] Jens Zörkler, Einführung einer Public-Key-Infrastruktur in einer Universität, Diplomarbeit an der TU Darmstadt – Fachbereich Informatik, 2003
– 121 –
Abbildungsverzeichnis
Athene – Symbol der TU Darmstadt . . . . . . . . . . . . . . . . . . . . . . . .
1
Einfache Verschlüsselung mit Buchstaben-Tauschsystem . . . . . . . . . . .
2
Symmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . .
3
Asymmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . .
4
Erstellen und Verifizieren digitaler Signaturen . . . . . . . . . . . . . . . . .
5
Beispiel für ein Zertifikat mit Distinguished Names . . . . . . . . . . . . . .
6
Struktur des TrustCenters FlexiTrust . . . . . . . . . . . . . . . . . . . . .
7
Auszug aus dem LDAP-Tree am Fachbereich Informatik der TUD . . . . . .
8
Namensgebung der PKI am Fachbereich Informatik der TUD . . . . . . . . .
9
Struktur eines Datenbank Management-Systems . . . . . . . . . . . . . . .
10 Daten ohne und mit Struktur . . . . . . . . . . . . . . . . . . . . . . . . .
11 Nicht-verteilte Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 ERM-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13 Beispiel für eine Vereinigung in der Relationenalgebra . . . . . . . . . . . . .
14 Beispiel für ein Kartesisches Produkt in der Relationenalgebra . . . . . . . .
15 Einfache Selektion mit SQL . . . . . . . . . . . . . . . . . . . . . . . . . .
16 Join mit SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17 Ausschnitt aus dem Datenmodell eines TrustCenters . . . . . . . . . . . . .
18 Praktisches Beispiel für eine real vorkommende Personentabelle . . . . . . .
19 Grafik von der Arbeitsgruppe Prof. Buchmann über das RBG-TrustCenter . .
20 Einfache Personentabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 Tabelle T Relation im TrustCenter-Datenmodell . . . . . . . . . . . . . . .
22 Umsetzungsmöglichkeit für eine einfache Steuertabelle . . . . . . . . . . . .
23 Tabellendefinitionen durch Strukturmanipulation . . . . . . . . . . . . . . .
24 Dynamische Tabellendefinitionen durch Datenmanipulation . . . . . . . . . .
25 Attributwerte bzw. Datensätze bei dynamischen Tabellen . . . . . . . . . . .
26 SQL-Anweisung zum Zusammensetzen von Daten aus dynamischen Tabellen
27 Zusammenfassung der Persistierungsmöglichkeiten . . . . . . . . . . . . . .
– 122 –
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
7
11
12
16
24
26
32
36
38
41
42
44
45
46
47
48
53
56
58
74
85
98
100
101
102
103
104
Index
AES, 11
Angriffe, 17
Anonymität, 9, 15
Attacken, 17
Authentifikation, 8, 10, 14, 107
Authentifizieren, 8, 14
authentisch, 15
Authentisieren, 8
Authentizität, 8, 9, 15, 25
Autorisierung, 8
Brechen, 20
Brute Force-Attacke, 17
Certificate Management Authority, 25, 29
Chipkarten, 20
CMOS-Transistor, 19
Codekarte, 8
CORBA, 114
Cross-Zertifizierung, 33
Daten, 40
Datenbank, 37
Backup, 37
Cursor, 50
Java-Cursor, 50, 80, 82, 95, 114
Recovery, 37
Relationale, 34, 43
Zugriff, 51
Datenbank Management-System, 37
ACID, 39
Atomarität, 39
Backup, 40
Concurrency Control, 40
Correctness Criteria, 40
Coupling Modes, 39
Dauerhaftigkeit, 39
Isolation, 39
Konsistenz, 39
Recovery, 40
Transaktion, 39
Trigger, 39
Datenbankmodell, 6, 52
Back-End, 50, 112
Effizienz, 73
Hilfstabelle, 97
Klassenstruktur, 69
Repräsentationsklasse, 72, 75, 84
Repräsentationsschicht, 69
Steuertabelle, 97
Tabellenstruktur, 99
Zugriffsschicht, 69
Datenbanksystem, 37
Datenhaltung, 52
Datenmodell, 40, 41
Beziehungen, 42–44, 46
Datensatz, 41
Entity, 68
Korrektheitsbedingungen, 41
Objekt, 41
Objekttyp, 41
Operatoren, 41
Relationales, 43
Relationen, 43
Relationenalgebra, 43
Schlüssel, 43
Strukturen, 41
Tupel, 41
Datenunabhängigkeit, 37, 39
Datiertheit, 8, 16
Datierung, 8
DES, 11, 17
Diffie-Hellman, 12, 18
Direct Trust, 22
Directory Service, 25
DoS-Attacke, 18
DPA, 19
ECC, 13
eCommerce, 9
Effizienz, 6, 39, 43, 72, 73, 105, 106, 108
Applikationsentwicklung, 51, 52, 73, 89
Benutzbarkeit, 73
Bereiche, 73
DBMS, 37, 38
Hardware, 51
hocheffizient, 39, 40
Indizes, 49
Kryptosysteme, 8, 12–15, 17, 19
Query, 45
Rechenleistung, 51, 52, 73, 86, 89, 94,
97, 104, 107
Software, 51
SQL, 45, 95, 106
– 123 –
INDEX
Eingebettete Systeme, 7
EC-Karte, 7
Handy, 7
ElGamal, 12
eMail, 8, 9, 19, 25, 29
Enigma, 7
Entschlüsselung, 10
Ethereal, 108
Flexibilität, 6, 23, 52, 57–59, 68–70, 72, 86,
94, 98, 103, 106, 111, 113
FlexiTrust, 6, 22, 26, 28, 55, 57, 59, 61,
62, 69, 71, 72, 74, 104–106, 108,
110–113
OpenRA, siehe OpenRA
Struktur, 25
Framework, 23, 58, 61, 83, 93, 106
Funkverbindung, 9, 20, 21
Hash-Funktionen, 14
Message Digest, 14
HMAC, 15
Home-Banking, 8
IBM DB2, 51
Implementierung, 17
Indizes, 49
Informationen, 30, 37, 40, 41, 43, 55, 69
Informix, 51
Integrität, 8, 15
Internet, 9, 20, 21
IPSec, 21
ISO, 20
J2EE, 57, 87, 89, 114, 118
JDBC, 51, 59, 83, 113
JDO, 83, 89
Join, 43, 46
JTA, 114
Kerberos, 20
Kerckhoff-Prinzip, 17
Key Authority, 25, 28
Keylogger, 7
Kompatibilität, 31, 34, 43, 58, 59, 94
Kryptoanalyse, 7, 17
Kryptographie, 7, 17
Kryptologie, 17
Kryptosystem, 10
Kryptoverfahren, 10
Laufzeit, 13
MAC, 14, 15
Tag, 14
Verifizieren, 14
Man in the Middle, 18, 23
Matrizenmultiplikation, 11
Microsoft SQL-Server, 51, 111
MySQL, 51, 71, 72, 113, 114
Nicht-Abstreitbarkeit, 9
Objekt-Relationales-Mapping, 69, 83
Objektorientierung, 41, 82
Klasse, 41
Konstruktoren, 42
mehrstufige Objekte, 74, 75, 80, 85
Objekt, 41
Vererbung, 64, 80
ODBC, 51, 59, 112, 113
OpenRA, 52, 61, 62, 66, 68, 71, 75, 81, 84,
86, 105–108, 112, 113
Flexibilität, siehe Flexibilität
Formulare, 61
Oracle, 51
OSI-Modell, 20
Paßwort, 8
Persistierung, 6, 37, 39, 82, 95
Objekt-basiert, 82–84, 87, 89
Ziele, 71
PGP, 20, 22
PKCS, 57
PKI, 21, 22
Aufgabe, 22
Certification Authority, 22, 32, 33
Policy, 23
Schlüsselmanagement, 22, 29
Sicherheitspolitik, 23
Teilnehmer, 22, 33
Plattformunabhängigkeit, 58
Privatheit, 9
Protokolle, 16, 18, 21
Quantencomputer, 8
Registration Authority, 25–27, 52, 62
dezentral, 57
OpenRA, siehe OpenRA
Personalisierung, 28
Registrierungsdaten, 27
Replays, 18
Repräsentationsschicht, 75
Revokation, 24
RMI, 87
RSA, 12
Schlüssel, 10, 16
Angriff auf, 19
Austausch, 13, 29
geheimer, 11
Identität, 13, 21
– 124 –
INDEX
Key Authority, 28
öffentlicher, 11, 14, 21–23, 29
Personalisierung, 23, 25
privater, 11, 14
Schlüssellänge, 13
Sitzungsschlüssel, 14
symmetrischer, 11, 13, 14
Schlüsseltext, 10
Schutzziele, 8, 15, 20
Script Query Language (SQL), 45
Abfrage, 41
Aggregierung, 48
Applikationen, 50
Dateneingabe, 49
Datenmanipulation, 46
Datenzugriff, 46
Einbettung, 50
Einfaches Beispiel, 46
Join, 46
Query, 37, 41, 45
Query-Optimierung, 45
Query-Sprachen, 45
Strukturmanipulation, 49
Seiteninformation, 19, 20
Seitenkanal-Angriff, 17, 19
Session-Hijacking, 18
SHA-1, 15
Signieren, 7, 9
digitale Signatur, 10, 15, 25
Signatur, 9, 35
Verifikation, 15
SPA, 19
Spoofing, 18
Sprachanalysen, 18
SSL, 21
Steganographie, 8
Stromverbrauch, 19
Telefonbuch, 29
Time Stamp Service, 26, 36
Zeitstempel, 15, 36
TLS, 21
Transaktionen, 37, 39, 51, 69
Coupling Modes, 39
Trigger, 39
TrustCenter, 9, 15, 16, 21, 22, 25, 71
Datenmodell, 52, 82, 85, 106, 108, 111
UMAC, 15
Unveränderlichkeit, 8
Urheber, 8
Verbindlichkeit, 9, 15, 25
Verfügbarkeit, 9
Verschlüsselung, 10, 15
asymmetrisch, 11
hybrid, 14
Praxis, 13
symmetrisch, 10
Verteiltes System, 37
Vertrauensinstanz, 9, 15, 21
Vertraulichkeit, 9, 15
Verzeichnisdienst, 26, 29
Attacke, 33
Attribute Extraction, 34
Aufgaben, 30
Baumebenen, 36
Client, 31
Component Matching, 34
DAP, 30
Datenbank, 30
Directory Service, 26, 29
Distinguished Name, 24, 31, 32, 35, 36
Entry, 30, 32
Internet, 30, 31
LDAP, 30–33, 35
OpenLDAP, 33, 112
TC-Datenbank, 54, 61, 110, 112
userCertificate, 32
Verzeichnis, 30
X.500, 30, 35
X.509, 31
X.509-attribute Parsing Server, 34
VPN, 21
Wahlen, 9
Wiedereinspielung, 18
XML, 51, 92
Zertifikat, 22, 23, 29
ASN.1, 33
Aussteller, 24, 32
Austausch, 29
CRL, 23, 30
Distinguished Name, 24
Gültigkeitszeitraum, 24
Inhaber, 24
Kommunikationspartner, 29
mehrere Zertifikate, 35
Revokation, 24
Seriennummer, 24
Telefonbuch, 29
Veröffentlichung, 23, 29, 32
X.509v3, 24, 31, 33
Zufallszahlen, 19
– 125 –