Paper - Lehre und Forschung Thorsten Strufe

TECHNISCHE UNIVERSITÄT ILMENAU
Fakultät für Informatik und Automatisierung
Institut für Praktische Informatik und Medieninformatik
Fachgebiet Telematik
Diplomarbeit
Konzeption einer dynamischen, verteilten Anwendung
zur sicheren Integration von Backendsystemen.
verantw. Hochschullehrer:
Hochschulbetreuer:
betrieblicher Betreuer:
Univ. Prof. Dr.-Ing. habil. Dietrich Reschke
Dipl.-Inf. Thorsten Strufe
Dr.-Ing. Gunter Hegewald
Autor:
Christian Stötzer
Datum: Schwarzhausen, 01.07.2003
Inventarisierungsnummer: 2003-07-02/047/IN96/2253

Inv.-Nr.:2003-07-02/047/IN96/2253
Vorwort
Mit dieser Diplomarbeit möchte ich mein Studium der Informatik an der Technischen
Universität Ilmenau abschließen. Sie entstand in enger Zusammenarbeit mit
der Firma Häcker-Automation Schwarzhausen.
Danksagung
An dieser Stelle möchte ich es nicht versäumen, den Personen zu danken, die mich
während meiner Studienzeit und der Erstellung dieser Diplomarbeit unterstützt
haben.
Insbesondere möchte ich mich bei meinen beiden Betreuern, Herrn Dipl.-Inf.
Thorsten Strufe und Herrn Dr.-Ing. Gunter Hegewald bedanken, die mir mit Rat
und Tat zur Seite standen.
Ich möchte zudem der Firma Häcker-Automation Schwarzhausen und ihren
Mitarbeitern danken, die mir die Möglichkeit gegeben haben, in einem großartigen
Umfeld zu arbeiten.
Weiterhin geht mein Dank an meine Eltern für die finanzielle und moralische
Unterstützung während des gesamten Studiums sowie an meine Frau Jacqueline
für ihr Verständnis und die unzähligen Male Korrekturlesen.
Warenzeichen
In dieser Arbeit werden eingetragene Warenzeichen, Handelsnamen und Gebrauchsnamen
verwendet. Auch wenn nicht ausdrücklich gekennzeichnet, gelten
die entsprechenden Schutzbestimmungen.
I

Inv.-Nr.:2003-07-02/047/IN96/2253
Selbstständigkeitserklärung
Hiermit erkläre ich, Christian Stötzer, dass ich diese Arbeit selbstständig verfasst
und keine anderen als die angegebenen Quellen benutzt habe. Alle Stellen, die wörtlich
oder sinngemäß aus Quellen entnommen wurden, habe ich als solche gekennzeichnet.
Schwarzhausen, 01.07.2003
Christian Stötzer
II

Inv.-Nr.:2003-07-02/047/IN96/2253
Inhaltsverzeichnis
1 Einleitung 1
2 Grundlagen und Begriffsabgrenzungen 2
2.1 Ziele der Informationssicherheit . . . . . . . . . . . . . . . . . . . 3
2.2 Sicherheits-Grundfunktionen . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Organisatorische Maßnahmen . . . . . . . . . . . . . . . . 4
2.2.2 Zugangskontrollen . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Zugriffskontrollen . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Übertragungssicherung . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Nachweisführung . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.6 Wiederaufbereitung . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Bedrohung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Täterkreis (Wer) . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Information (Was) . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Motivation des Angreifers (Warum) . . . . . . . . . . . . . 14
2.3.4 Methoden des Angriffs (Wie) . . . . . . . . . . . . . . . . 15
2.4 Kryptologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Alice, Bob und Mallory !?! . . . . . . . . . . . . . . . . . . 18
2.4.2 Symmetrische und asymmetrische Kryptosysteme . . . . . 18
2.4.3 Kryptographische Hashfunktionen . . . . . . . . . . . . . . 22
2.4.4 Digitale Signaturen . . . . . . . . . . . . . . . . . . . . . . 23
2.4.5 Schlüsselzertifikate . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Kommunikationssicherheit . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1 Verschlüsselungsalgorithmen . . . . . . . . . . . . . . . . . 25
2.5.2 Sichere Übertragungsprotokolle . . . . . . . . . . . . . . . 31
2.6 Das DPAC Informationssystem . . . . . . . . . . . . . . . . . . . . 38
3 Mobiler Code 39
3.1 Sicherheitsbedrohungen . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 Bedrohungen für den mobilen Code . . . . . . . . . . . . . 40
3.1.2 Bedrohungen für den Gastrechner . . . . . . . . . . . . . . 41
3.2 Sicherheitsmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 Schutz des mobilen Codes . . . . . . . . . . . . . . . . . . 41
3.2.2 Schutz des Gastrechners . . . . . . . . . . . . . . . . . . . 42
3.3 Die Programmiersprache Java . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Sicherheitsarchitektur und -modelle in Java . . . . . . . . . 45
3.3.2 Bewertung des Java-Sicherheitskonzepts . . . . . . . . . . 52
3.4 Java-Web-Start, eine Alternative zu Applets . . . . . . . . . . . . . 53
3.4.1 Warum Java-Web-Start? . . . . . . . . . . . . . . . . . . . 54
3.4.2 Das Java Network Launching Protokoll . . . . . . . . . . . 56
3.4.3 Sicherheitsmechanismen und -werkzeuge . . . . . . . . . . 63
3.4.4 Bewertung von Java-Web-Start und Verbesserungsvorschläge 68
III

Inv.-Nr.:2003-07-02/047/IN96/2253
4 Sichere Kommunikation zwischen Front- und Backend 71
4.1 Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.1 Einführenden Erläuterungen . . . . . . . . . . . . . . . . . 72
4.1.2 Sicherheit in RMI . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.3 Sicherung der RMI-Kommunikation . . . . . . . . . . . . . 74
4.1.4 Probleme beim Einsatz von RMI . . . . . . . . . . . . . . . 80
4.2 Virtual Private Networks (VPNs) . . . . . . . . . . . . . . . . . . . 81
4.2.1 Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.2 Layer-3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.3 VPNs und das DPAC-Informationssystem . . . . . . . . . . 85
5 Das DPAC-Informationssystem 86
5.1 Entwicklungs- und Testumgebung . . . . . . . . . . . . . . . . . . 87
5.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3 Das DPAC-Frontend . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.1 WebStart . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.2 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4 Der DPAC-Anwendungsserver . . . . . . . . . . . . . . . . . . . . 97
5.4.1 Arbeitsweise des Servers . . . . . . . . . . . . . . . . . . . 97
5.5 Absicherung der Kommunikation . . . . . . . . . . . . . . . . . . . 100
5.5.1 RMI-Socket-Factory . . . . . . . . . . . . . . . . . . . . . 101
5.6 Nutzerauthentifikation . . . . . . . . . . . . . . . . . . . . . . . . 102
6 Zusammenfassung und Ausblick 106
A Anhang I
A.1 Thesen dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . I
A.2 Erstellen von Secure Sockets mit Hilfe der JSSE . . . . . . . . . . . II
A.2.1 Clientseitig . . . . . . . . . . . . . . . . . . . . . . . . . . II
A.2.2 Serverseitig . . . . . . . . . . . . . . . . . . . . . . . . . . IV
IV

Inv.-Nr.:2003-07-02/047/IN96/2253
1 Einleitung
Die Vielzahl der heute existierenden Informationstechnologien sind aus unserem
wirtschaftlichen und gesellschaftlichen Leben nicht mehr wegzudenken. Wir befinden
uns mit rasantem Tempo auf dem Weg zur globalen Informationsgesellschaft.
Immer komplexere und schnellere informationstechnische Systeme übernehmen
immer weitreichendere Aufgaben.
Wir sehen uns beim Surfen im Internet einer Unmasse von Informationen gegenüber,
die wir, wenn wir es wollen, auch noch via Mobilfunk von fast jedem
Punkt der Erde aus nutzen können. Briefe und Daten jagen per E-Mail oder
Download in sekundenschnelle durch die verschiedensten Kommunikationsnetze.
Unternehmen machen sich durch ihren Auftritt im Internet einer weltweiten
Öffentlichkeit bekannt, vergrößern den Kreis der potentiellen Kunden und bieten
ihre Produkte an. Durch die Einrichtung moderner, schneller Daten- und Kommunikationsnetze
können auch Firmen, die territorial weit voneinander entfernt liegen,
Kooperationen aufbauen und Daten sowie Wissen austauschen.
Dies sind nur einige wenige Beispiele aus der Informationstechnik, die wir heute
schon nutzen können und als mehr oder weniger selbstverständlich ansehen. Aber
mit dem Nutzen sind auch die Risiken gewachsen. Es wird immer häufiger notwendig,
der Informationstechnik auch sensible Daten anzuvertrauen, wobei der Schutz
dieser Daten vor unberechtigten Zugriffen mehr und mehr in den Vordergrund rückt.
Die Information stellt gerade für Unternehmen ein besonders kostbares und
schutzwürdiges Gut dar. Ein Verlust kann sich für eine Firma existenzbedrohend
auswirken.[20] Es ist also von immenser Bedeutung, unternehmensbezogene
Konzepte zu entwickeln, die den Schutz der Information gewährleisten. Dies
betrifft vor allem die Bereiche der Verarbeitung, Speicherung und Übertragung der
Information.
Immer mehr Unternehmen entschließen sich aus den verschiedensten Gründen,
ihre infomationstechnologische Infrastruktur an öffentlich zugängliche Netze wie
das Internet anzubinden. Neben den Vorteilen, wie beispielsweise die Verbesserung
des Produkt- und Kundenmanagements, birgt eine solche Internetanbindung
eine Menge Sicherheitsrisiken. Fragen wie ”Ist es für Mitbewerber möglich, an
firmeninterne Daten zu gelangen?”, ”Gibt es ausnutzbare Schwachstellen?” und
”Welcher Aufwand ist notwendig, um diese zu beseitigen?” sollten unbedingt vor
einer Anbindung gestellt und beantwortet werden.[20]
Ziel dieser Diplomarbeit soll es sein, ein Sicherheitskonzept zu entwickeln,
das eine sichere Integration des DPAC 1 -Informationssystems der Firma Häcker-
Automation in das Intra- bzw. Internet ermöglicht. Dazu werden im weiteren
Verlauf verschiedene Integrationstechniken vorgestellt, auf ihre Sicherheitsaspekte
hin untersucht und ihre Einsetzbarkeit im DPAC-System bewertet. Ein ganz
wichtiger Punkt in Bezug auf die Einsetzbarkeit ist dabei die Benutzerakzeptanz,
ohne die sich eine auch noch so sichere Integrationstechnik nicht duchsetzen
würde.
1 DPAC: Database for Process Administration and Controlling
1

Inv.-Nr.:2003-07-02/047/IN96/2253
2 Grundlagen und Begriffsabgrenzungen
Dieser Abschnitt soll dazu genutzt werden, Begriffe, die im weiteren Verlauf der
Arbeit verwendet werden, näher zu beschreiben und abzugrenzen sowie eine grundlegende
Einführung in das Thema Informationssicherheit zu geben.
Sicherheit Im allgemeinen versteht man unter Sicherheit, dass in einem System
keine unerwünschten Vorfälle auftreten, sodass es zu jeder Zeit in der gewünschten
Art und Weise funktioniert und reagiert. Der englische Sprachgebrauch kennt
im Gegensatz zum deutschen zwei Begriffe für das Wort Sicherheit, die aber
nicht gleichbedeutend sind: safety und security. Während man unter safety den
Schutz vor unbeabsichtigten Schäden wie beispielsweise durch Blitzschlag,
Überschwemmungen, Festplatten-Crashes oder Ähnliches versteht, bezeichnet
security die Sicherheit vor beabsichtigten Störungen, wie zum Beispiel Sabotage,
Systemeinbrüche oder das Erschnüffeln von geheimen Daten. [24] Da es aber im
Rahmen dieser Arbeit keine Betrachtungen zum Thema safety geben soll, wird im
weiteren Verlauf security mit Sicherheit gleichgesetzt.
Gleich zu Anfang sei gesagt, eine hundertprozentige Sicherheit kann es weder
im Leben noch in der Technik geben. [20] Deshalb können die im Anschluss
einführend erläuterten Schutzmaßnahmen keine absolute Sicherheit gewährleisten.
Zumal auch die ökonomischen Faktoren und damit die Kosten, die entstehen
können, um ein System zu schützen, nicht außer Acht gelassen werden dürfen.
Ausgehend von einem für die Sicherheitsvorkehrungen zur Verfügung stehenden
finanziellen Rahmen sollte man versuchen, ein ausgewogenes Verhältnis zwischen
Aufwand und Nutzen zu finden. Abbildung 1 aus [20] zeigt, wie sich bei exponentiellem
Anstieg der Kosten für Sicherheitsmaßnahmen die Sicherheitsrisiken
minimieren lassen.
Abbildung 1: Kosten / Nutzen Verhältnis für Sicherheitsvorkehrungen
2

Inv.-Nr.:2003-07-02/047/IN96/2253
Die parabelähnliche Kurve für die Gesamtaufwendungen berechnet sich aus der
Summe der beiden Kostenkurven. In ihrem Tiefpunkt ist demnach das beste Verhältnis
zwischen Investitionen für Maßnahmen zur Schadensabwehr und noch verbleibendem
Restrisiko. Von den Sicherheitsanforderungen einer Organisation hängt es
nun ab, wo sie sich auf der Parabel wiederfindet. Während sich Unternehmen mit
”normalen” Sicherheitsansprüchen in der Nähe das Minimums bewegen, sollten
sich Kreditinstitute in der rechten Häfte der Kurve einordnen.
Der Gesamtwert der zu schützenden Güter geht als feste Größe in die Betrachtung
ein. Überschreiten die Kosten für Schutzmaßnahmen diesen Wert, wäre das Sicherheitskonzept
unter ökonomischen Gesichtspunkten nicht akzeptabel.[20]
2.1 Ziele der Informationssicherheit
Unter dem Begriff der Informationssicherheit versteht man das Verhindern von unberechtigter
Nutzung von Ressourcen. Unbefugte Nutzung liegt dann vor, wenn ein
Benutzer Informationen zur Kenntniss nimmt, ändert oder generell das System nicht
entsprechend den Vorstellungen des Betreibers verwendet.[19] Grundsätzlich kann
man die Informationssicherheit in zwei wichtige Aspekte aufteilen:
• Rechnersicherheit Bei der Rechnersicherheit steht der Schutz der Information
im Rechnersystem im Vordergrund.
• Kommunikationssicherheit Spricht man hingegen von Kommunikationssicherheit,
so ist der Schutz der Information während der Datenübertragung
zwischen zwei Rechnersystemen in einem Netzwerk gemeint.
In dieser Arbeit soll hauptsächlich die Kommunikationssicherheit betrachtet
werden.
Durchgehend beschreibt die zahlreiche Literatur, die sich mit dem Thema Informationssicherheit
beschäftigt (vergl. [19][20][4][7]), die folgenden klassischen
Ziele:
Vertraulichkeit (Geheimhaltung) Schutz vor unberechtigter Kenntnisnahme
von Informationen. Dies schließt auch den Schutz von Informationen ein, die für
sich ”harmlos” erscheinen, aber dazu benutzt werden können, um Zugriff auf vertrauliche
Informationen zu erhalten.
Integrität (Vollständigkeit) Die Sicherstellung der Korrektheit (Unversehrtheit)
von Daten (Datenintegrität) bzw. der korrekten Funktionsweise von Systemen (Systemintegrität).
Daten dürfen ohne Berechtigung weder modifiziert noch gelöscht
werden können. Nur dann ist sichergestellt, dass mit ihnen verlässlich gearbeitet
werden kann.
Verfügbarkeit Schutz vor unbefugter Beeinträchtigung der Funktionalität des
Systems. Alle verarbeiteten Daten sowie die zur Verarbeitung notwendigen Systeme
und Betriebsmittel müssen jederzeit verfügbar und funktionsbereit sein, wenn
3

Inv.-Nr.:2003-07-02/047/IN96/2253
ein autorisierter Benutzer darauf zugreifen will.
Besonders für die Kommunikationssicherheit sind folgende Ziele wichtig:
Authentizität (Echtheit) Sicherstellung der äußerlich korrekten und gültigen
Darstellung von Informationen. Authentizität ist dann gegeben, wenn die Informationen
wahr, wirklich oder ursprünglich sind, weil sie mit der Realität übereinstimmen
[7]. Mit Hilfe der Authentizität kann keine Aussage über die inhaltliche Richtigkeit
der Daten getroffen werden.
Verbindlichkeit Der Urheber einer Nachricht kann die Urheberschaft nicht leugnen.
Beispielsweise bei Vertragsabschlüssen mit einer digitalen Unterschrift.
Anonymität Die beteiligten Instanzen an einem Nachrichtenaustausch bleiben
geheim. Wünschenswert bei elektronischen Zahlungssystemen und in Verfahren
elektronischer Wahlen.
Um Sicherheitsmaßnahmen zum Schutz eines Systems entwickeln zu können, sollte
man eine ganzheitliche Betrachtung der oben formulierten Ziele vornehmen. Nur
so kann gewährleistet werden, dass man Sicherheitslecks nicht hinterherläuft und
nachträglich ”abdichtet”, sondern schon bei der Systementwicklung auf mögliche
Probleme, die während der Laufzeit auftreten können angemessen reagiert.
2.2 Sicherheits-Grundfunktionen
Um die oben skizzierten Ziele der Informationssicherheit erreichen zu können,
sollen in diesem Abschnitt einige grundlegende Sicherheitsfunktionen besprochen
werden. Diese beinhalten Maßnahmen zum Schutz eines Systems vor möglichen
Bedrohungen 2 . Abbildung 2 gibt einen Überblick über die in der Literatur [7][19]
zu findenden und im weiteren Verlauf beschriebenen Sicherheits-Grundfunktionen.
2.2.1 Organisatorische Maßnahmen
Im Umfeld der Informationsverarbeitung sollten gewisse organisatorische Maßnahmen
durchgeführt werden, um Systeme vor Angriffen zu schützen. Zu ihnen zählen
zum Beispiel:[7]
• die physischen Schutzmaßnahmen, die den Schutz vor Bedrohungen von
außen mittels baulicher Maßnahmen, Überwachungssystemen sowie peripheren
Systemen sichern sollen
• die Erzeugung von Backups, durch das möglichst dezentrale Anlegen von
redundanten Kopien das Datenbestandes
2 Im Abschnitt 2.3 werden Bedrohungen genauer untersucht.
4

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 2: Sicherheits-Grundfunktionen
• das Erstellen von Sicherheitskonzepten auf der Grundlage einer Risikoanlalyse
3
• das Herausbilden eines Sicherheitsbewusstseins durch Training und Weiterbildung,
um das menschliche Handeln und Verhalten gezielt beeinflussen zu
können
2.2.2 Zugangskontrollen
Zugangskontrollen sollen ein System schützen und gewährleisten, dass es nicht berechtigten
Personen unmöglich ist, irgendwelche Operationen mit diesem System
durchzuführen.[19] Die zwei wesentlichsten Aspekte der Zugangakontrolle sind die
Identifizierung und die Authentifizierung 4 gegenüber einem System.
Identifizierung Die Identifizierung stellt sicher, dass ein Benutzer dem System
bekannt ist [7]. Überall dort wo Sicherheit eine Rolle spielt, darf es keine unbekannten
Benutzer geben. Abgesehen von wenigen Ausnahmen, bei denen die Anonymität
durchaus erwünscht ist (vergl. Abschnitt 2.1 - Anonymität).
Ein wesentlicher Aspekt der Systemsicherheit ist die Vergabe von individuellen,
nutzerbezogenen Rechten auf Daten und Systemresourcen. Mittels Identifizierung
und damit Bekanntmachung eines Nutzers am System wird eine solche spezifische
Rechtevergabe möglich.
Authentifizierung Damit sich ein Benutzer gegenüber einem System identifizieren
kann, benötigt er seine eigene Benutzer-Identifikation. Diese muss ein eindeutiger
Name sein, der die Identität des Nutzers im System repräsentiert.[19]
3 Die Risikoanalyse umfasst alle Maßnahmen zur Informationssicherheit in Unternehmen.
4 vom englischen Wort authentication = (Bestätigen, Beglaubigen); in der deutschsprachigen Literatur
werden dafür die Begriffe Authentisierung, Authentifikation oder Authentifizierung gleichbedeutenden
verwendet
5

Inv.-Nr.:2003-07-02/047/IN96/2253
Da man nun davon ausgehen kann, dass Benutzer-Identifikationen nicht geheim
sind und dass auch durch gezieltes Probieren eine legale Identifikation gefunden
werden kann, ist es notwendig, die Identifikation durch ein weiters Verfahren zu
ergänzen, welches eine Überprüfung der angegebenen Identifikation auf deren Korrektheit
ermöglicht. Man bezeichnet dieses Verfahren als Authentifizierung oder
auch Authentifikation.[19] Authentifizierung ist also die Sicherstellung der Identität,
ein Benutzer muss die Richtigkeit der von ihm behaupteten Identität nachweisen.
Im folgenden sollen die wichtigsten Authentifizierung-Verfahren vorgestellt werden.
Sie konzentrieren sich jeweils auf das Vorhandensein bestimmter menschlicher
Aspekte: Wissen, Besitz und Körpermerkmale.
• Authentifizierung durch Wissen
Das wohl gebräuchlichste Authentifizierungs-Verfahren ist die Authentifizierung
durch Wissen. Hier wird der Benutzer aufgefordert, neben seiner Identifikation
ein geheimes und nur ihm und dem System bekanntes Passwort
anzugeben. Ein Rechner überprüft nun das eingegebene mit dem im System
gespeicherten Passwort und gibt bei Übereinstimmung den Zugang zum System
frei. Der Nutzer hat somit seine Identität nachweisen können, da ja nur
er das geheime Passwort, welches zu seiner Benutzer-Identifikation gehört,
kennt. Dieses einfach zu realisierende und auch einfach zu bedienende Verfahren
bietet einen ausreichenden Schutz, wenn bestimmte Regeln bei der
Implementierung eingehalten werden [19]:
– Passwörter dürfen unter keinen Umständen auf dem Bildschirm des
Benutzers im Klartext erscheinen. Der Diebstahl eines Passworts wäre
sonst durch einfaches ”über die Schulter schauen” möglich.
– Passwörter sollten eine gewisse Zeichenlänge nicht unterschreiten. Andernfalls
sind die Passwörter leicht durch Probieren zu bestimmen.
– Passwörter sollten vom Benutzer änderbar sein. Damit soll verhindert
werden, dass ein Systemverwalter alle Passwörter kennt und möglicherweise
selbst ein Sicherheitsrisiko darstellt.
– Umgekehrt sollten Passwörter einzelner Benutzer aber auch unveränderlich
sein, um eine Überwachung dieser Nutzer durch einen ”Sicherheits-
Beauftragten” zu gestatten.
– Passwörter sollten so gewählt werden, dass sie nicht einfach zu erraten
sind, sie sollten aber auch nicht zu kompliziert gestaltet werden, um das
Notieren und sei es nur als Gedächtnisstütze zu verhindern.
– Es darf nicht möglich sein, Benutzer-Identifikation einzurichten, die
kein Passwort haben
Ein weiteres Authentifizierungs-Verfahren, bei dem das Wissen des jeweiligen
Benutzers von Bedeutung ist, ist der Authentifizierungs-Dialog. Dem
Nutzer wird von einem Rechner eine Reihe von Fragen gestellt, die er zur
Authentisierung seiner Identifikation richtig beantworten muss. So gesehen,
ist der Authentifizierungs-Dialog eine Variante des Passwort-Verfahrens mit
6

Inv.-Nr.:2003-07-02/047/IN96/2253
mehreren Passwörtern. Es ist naheliegend, dass es sich hierbei um Fragen
handeln muss, die die Person betreffen und deren Antworten nicht aus allgemeinen
oder einfach zugänglichen Quellen beschafft werden können.[19]
• Authentifizierung durch Besitz
Ein Benutzer, der Zugang zu einem System sucht, weist sich bei diesem Verfahren
durch den Besitz eines bestimmten Gegenstandes aus, der ihm als berechtigten
Benutzer zur Verfügung gestellt wurde. Ein solcher Gegenstand
kann ein Schlüssel, eine Chip- oder Magnetkarte oder ein Ausweis sein.
Nachteile diese Verfahrens sind die Diebstahls- und Fälschungsgefahr sowie
die unberechtigte, bewusste Weitergabe des Gegenstandes an Dritte. [7] Es
sei jedoch erwähnt, dass der Diebstahl eines Gegenstandes viel besser festgestellt
werden kann als beispielsweise der Diebstahl eines Passworts, was das
Einleiten effizienter Gegenmaßnahmen deutlich erleichtert. [19]
• Authentifizierung durch Körpermerkmale
Authentifizierungs-Verfahren, die die Analyse von Körpermerkmalen einer
bestimmten Person zur Verifizierung ihrer Identität nutzen, bezeichnet man
als Biometrische-Verfahren. Dabei werden bestimmte menschliche Charakteristika,
wie angeborene physische Eigenschaften oder ein erlerntes stabiles
Verhalten gemessen bzw. erfasst, in eine digitale Form umgewandelt und mit
den abgespeicherten Charakteristika (Referenzdaten) verglichen. Zu den angeborenen
physischen Eigenschaften eines Menschen zählen zum Beispiel:
die Anatomie der Hand, die Gesichtszüge, der Fingerabdruck oder die Verzweigung
der Blutgefäße der Retina. Ein erlerntes stabiles Verhalten ist beispielsweise
die Form und die Dynamik einer Unterschrift. [7] [19] [20]
Durch die Kombination der oben besprochenen Verfahren zur Authentifizierung
ist eine Steigerung der Sicherheit möglich. Ein klassisches Beispiel für
eine solche Kombination ist die Kredit- oder Bankkarte. Bei ihr kommen die
Authentifizierungs-Verfahren durch den Besitz (die Karte selbst), das Wissen (Geheimnummer)
und die Körpermerkmale (Unterschrift und möglicherweise Foto) zur
Anwendung.
Was alle drei Verfahren gemeinsam haben, ist, dass im System Referenzdaten gepeichert
sein müssen, die beim Authentifizierungsvorgang für Vergleichsoperationen
benötigt werden. Dem Schutz dieser Referenzdaten, seien sie in einer einfachen Datei
oder einer Datenbank gespeichert, gilt ein besonderes Augenmerk. Eine Manipulation
könnte es einem unberechtigten Nutzer ermöglichen, Zugang zum System
zu erlangen.
2.2.3 Zugriffskontrollen
Zugriffskontrollen sind im allgemeinen in Betriebssystemen oder Datenbanken verankert.
Mit ihrer Hilfe wird überprüft, ob ein Benutzer die Berechtigung hat, in der
gewünschten Art und Weise auf Systemresourcen oder Daten zuzugreifen. [33] Im
engen Zusammenhang stehen dabei auch die Begriffe Autorisierung 5 und Rechteverwaltung.
5 von lateinisch ”auctorizare”= Vollmacht geben
7

Inv.-Nr.:2003-07-02/047/IN96/2253
Autorisierung Hat sich ein Benutzer nach erfolgter Identifizierung und Authentifizierung
(vergl. Abschnitt 2.2.2) an einem System angemeldet, so ist es nur in
den seltensten Fällen wünschenswert, dass er von nun an das System ohne Einschränkungen
nutzen kann. Deshalb wird der Authentifizierung die Autorisierung
nachgeschaltet, um dem Benutzer spezifische Rechte zuzuweisen, die ihn in Bezug
auf die Verwendung von Systemressourcen oder Daten einschränken können. Diese
Rechte werden von speziell hierfür verantwortlichen Personen (zum Beispiel: Systemadministratoren)
aufgrund extern festgesetzer Richtlinien vergeben.[19] Dieser
Vorgang ist von entscheidender Bedeutung für die Sicherheit des Gesamtsystems
[7].
Rechteverwaltung Die Vergabe, der Entzug und die Veränderung von Rechten
ist die primäre Aufgabe der Rechteverwaltung. Darüber hinaus werden auch die
Folgen der Weitergabe von Daten und Rechten geregelt, um zu verhindern, dass
durch die Übertragung von Rechten ein verdeckter Kanal entsteht oder geschaffen
werden kann.[33]
Die Rechtevergabe erfolgt im allgemeinen nach einem der folgenden Grundprinzipien
[33]:
• Prinzip der Vergabe minimaler Privilegien
Dem einzelnen Nutzer werden nur die Zugriffsrechte eingeräumt, mit denen
es ihm möglich ist, eine Aufgabe (gerade noch) zu erfüllen. - geschlossenes
System
• Prinzip der Vergabe maximaler Privilegien
Die Daten und Ressourcen eines Systems können mit Ausnahmen von wenigen
Einschränkungen von allen Nutzer genutzt werden. - offenes System
Zwei Modelle der Rechteverwaltung, in denen diese Prinzipien in mehr oder
weniger reiner Form [33] umgesetzt werden, sind das DACM (engl: discretionary
access control model) oder das MACM (engl: mandatory access control model).
Discretionary Access Control Model
Dieses Modell verfolgt den Ansatz der diskreten Kontrolle von Zugriffsrechten. Dabei
wird davon ausgegangen, dass es prinzipiell möglich ist, für jedes Datenobjekt
separat die Schutzanforderungen dieses Datenobjektes anzugeben. Im wesentlichen
wird für die einzelnen Benutzer festgelegt, welche Operationen sie auf dieses
Datenobjekt anwenden dürfen. Generell ist es dabei zunächst unerheblich, ob die
Schutzrechte direkt an das Datenobjekt gebunden und für die einzelnen Benutzer
spezifiziert werden, oder ob jedem Benutzer eine Liste von Rechten gegeben ist, die
beschreibt, welche Operationen er auf einzelne Datenobjekte anwenden darf.[19]
In der Praxis erfolgt im allgemeinen die Vergabe von Zugriffsrechten entweder
explizit durch den Eigentümer eines Datenobjektes (Eigentümermodell) oder
implizit bei der Erstellung der Benutzerkennung durch Zuteilung einer bestimmten
Rolle oder Zuordnung zu einer Benutzergruppe.
Der Hauptvorteil der diskreten Zugriffskontrolle ist ihre hohe Flexibilität und
8

Inv.-Nr.:2003-07-02/047/IN96/2253
Anpaßbarkeit an die individuellen Schutzbedürfnisse einzelner Datenobjekte sowie
an individuelle Zugriffserfordernisse einzelner Benutzer [19]. Was jedoch auf der
einen Seite ein großer Vorteil ist, ist auf der anderen nicht ganz unproblematisch,
denn gerade beim Eigentümermodell unterliegt der Schutz der Datenobjekte
letztendlich der Willkür des Einzelnen. So kann es bei Vergesslichkeit oder
ungenügendem Sicherheitsbewusstsein vorkommen, dass wichtige Datenobjekte
nicht ausreichend geschützt werden.
Ein klassisches Beispiel für die diskrete Kontrolle von Zugriffsrechten ist das
Modell der Zugriffsmatrix, welches konzeptionell erstmals 1971 von Lampson
formuliert wurde. Abbildung 3 zeigt eine solche Matrix (Tabelle), in der sich
eine Menge von Subjekten und Objekten gewissermaßen gegenüberstehen. Die
Tabelleneinträge bestehen aus Rechten (beispielsweise Schreiben, Lesen oder
Ausführen), die es dem Subjekt ermöglichen, bestimmte Operationen auf das Objekt
anzuwenden. Wird davon ausgegangen, dass Subjekte und Objekte systemweit
eindeutige Namen besitzen, müssen die beiden Mengen nicht notwendigerweise
disjunkt sein. Es kann durchaus vorkommen, dass ein Objekt (z.B. ein Programm)
zu einem Subjekt ”mutiert”, weil es Zugriff auf ein anders Objekt (z.B. eine Datei)
benötigt.[19]
Abbildung 3: Beispiel einer Zugriffsmatrix [19]
Die Nachteile einer solchen Zugriffsmatrix liegen zum einen darin, dass die
Matrix in der Regel nur dünn besetzt ist, weshalb sich eine vollständige Speicherung
nicht lohnt, zum anderen in der hohen Dynamik, der sie unterworfen ist, wenn sich
Subjekte und vor allem Objekte häufig ändern. Diese Nachteile brachten die beiden
folgenden Alternativen hervor:
• Zugriffskontrolllisten Eine Liste, welche die zugriffsberechtigten Subjekte
enthält, wird zusammen mit den Zugriffsrechten beim Objekt gespeichert -
also nur die (nicht leeren) Matrixspalten.
• Befugnislisten Eine Liste, welche Objekte enthält, wird zusammen mit den
Zugriffsrechten beim Subjekt gespeichert - also nur die (nicht leeren) Matrixzeilen.
9

Inv.-Nr.:2003-07-02/047/IN96/2253
Mandatory Access Control Model
Die grundlegende Idee des Mandatory Access Control Model (im Deutschen auch
oft als regelbasierte Modelle bezeichnet) ist es, dass ein systemweites Regelwerk
existiert, welches den Zugriff von Subjekten auf Objekte kontrolliert. [33]
Dabei wird jeder Zugriffsversuch gegen den Inhalt des Regelwerks geprüft
und genehmigt, falls . . .
1. eine Regel existiert, die den Zugriff explizit erlaubt (geschlossenes System).
2. keine Regel existiert, die den Zugriff explizit verbietet (offenes System).
Bei diesem Modellansatz werden die Befugnisse an bestimmten Objekten gewissermaßen
zwingend vorgeschrieben. Dadurch wird eine mehr oder weniger
willkürliche Rechtevergabe, wie es bei den diskreten Zugriffskontrollen der Fall
ist, vermieden.
Schutzklassensysteme (auch Schutzklassenmodelle genannt) sind typische
Vertreter der regelbasierten Zugriffskontrolle. Schutzklassenmodelle definieren
neben den Subjekten und Objekten eine vollständig hierarchisch geordnete Menge
von Schutzstufen (auch Schutzklassen genannt). Eine solche Menge stellt sich
beispielsweise so dar:
unklassifiziert (offen)

Inv.-Nr.:2003-07-02/047/IN96/2253
beispielsweise Zugangs- oder Zugriffskontrollen nicht mehr und es müssen kryptographische
Verfahren eingesetzt werden. Gegen den Verlust der Vertraulichkeit
werden die Informationen verschlüsselt, gegen Manipulation finden kryptogarphische
Prüfsummen ihre Verwendung.[7][19]
Der Abschnitt 2.5 Kommunikationssicherheit beschäftigt sich später noch genauer
mit dem Thema Übertragungssicherung. Dort wird dann auch auf die oben angesprochenen
kryptographischen Verfahren näher eingegangen.
2.2.5 Nachweisführung
Da nicht davon ausgegangen werden kann, das es eine absolute Sicherheit gibt,
ist es erforderlich, sicherheitsrelevante Vorgänge im System zu überwachen und
zu protokollieren. Die dazu verwendete Sicherheitsgrundfunktion wird als Nachweisführung
bezeichnet. Sie hat die Aufgabe der Beweissicherung und muss an
zentraler Stelle im System verankert sein, damit sie nicht ohne weiteres ausgeschaltet
oder umgangen werden kann.[19]
Unter Verwendung von Audit-Logs 6 und Monitoring 7 als Mittel der Nachweisführung
können Sicherheitsverstöße auch im Nachhinein entdeckt und untersucht
werden, um somit eventuelle Sicherheitslöcher zu stopfen und Angreifer zu
identifizieren.
Audit-Logs Audit-Logs zeichnen für die Sicherheit relevante Vorgänge wie zum
Beispiel Systemstart und -beendigung, Benutzer-Autorisierung, abgewiesene Anmeldungen
oder Versuche zum Erraten von Passwörtern auf, um später genau nachvollziehen
zu können, wer zu welchem Zeitpunkt welche Operationen auf welche
Daten angewendet hat. Bei der Auswertung von Audit-Logs sind geeignete Selektierungsmechanismen
von immenser Wichtigkeit. Nur durch sie kann gewährleistet
werden, dass die aus der aktuellen Situation heraus gesuchten sicherheitsrelevanten
Vorgänge nicht in der Flut der zur Zeit als belanglos eingestuften Vorgänge untergehen.
Die in Audit-Logs enthaltenen Informationen sind unbedingt vor Manipulation zu
schützen, da sie gegebenenfalls Beweiskraft haben.[19] [7]
Monitoring Die Zielstellung des Monitoring ist eine etwas andere als die
der Audit-Logs. Während sich Audit-Logs im wesentlichen auf einen längeren
Zeitraum beziehen, bietet das Monitoring die Möglichkeit, aktuelle Vorgänge und
Abläufe im System quasi gleichzeitig zu beobachten.[19]
Die Mechanismen zur Nachweisführung müssen so gestaltet werden, dass
keine Konflikte mit dem Datenschutz entstehen. Es dürfen keine Nutzerprofile auf
Grundlage der Daten zur Beweissicherung erstellbar sein.[7]
6 audit von engl. auditing = überwachen und log von engl. logging = protokollieren
7 engl. monitoring = beobachten
11

Inv.-Nr.:2003-07-02/047/IN96/2253
2.2.6 Wiederaufbereitung
Die mehr im Gebiet der Betriebssysteme beheimatete Sicherheitsgrundfunktion
Wiederaufbereitung soll hier nur der Vollständigkeit halber kurz angerissen werden.
Da die in Rechnersystemen verfügbaren Betriebsmittel 8 nur im endlichen Umfang
vorhanden sind, kommt es insbesondere bei Speicherbereichen auf Datenträgern
und Hauptspeicher zu häufigen Wiederverwendungen. Die Wiederaufbereitung
soll unerwünschte und unzulässige Informationsflüsse über solche Speicherbereiche
verhindern und dafür Sorge tragen, dass diese Bereiche bei erneuter Verwendung
keine zugreifbaren Informationen alter Verwendungen mehr enthalten.[19]
2.3 Bedrohung
Bevor man damit beginnt, geeignete Strategien zur Absicherung eines Systems vor
drohenden Risiken zu entwickeln, um daraus entsprechende Schutzmechanismen
abzuleiten, sollte man sich zuerst Gedanken über mögliche Bedrohungen machen.
Bedrohungen sind Umstände, die direkt oder indirekt zu Schäden oder einem Verlust
der Sicherheit führen können.[7] Prinzipiell lassen sie sich in drei Hauptkategorien
unterteilen: Natürliche Bedrohungen, unbeabsichtigte Bedrohungen und
beabsichtigte Bedrohungen.
Natürliche Bedrohungen Unter dieser Art von Bedrohungen versteht man die
natürlichen Gefahren für Rechnersysteme, wie beispielsweise Feuer, Hochwasser,
Stromausfall, Erdbeben, Blitzschlag aber auch Einflüsse aus der Umwelt wie Staub
und hohe Luftfeuchte.
Unbeabsichtigte Bedrohungen Unbeabsichtigte Bedrohungen werden meist
durch menschliche Nachlässigkeit und unzureichendes Sicherheitsbewustsein hervorgerufen.
Als Beispiele sind hier der ungenügend aus- oder fortgebildete Systemadministrator
oder der Benutzer zu nennen, der sich einen Merkzettel mit seinen
Zugangsdaten am Monitor befestigt.
Beabsichtigte Bedrohungen Die dritte Hauptkategorie beinhaltet die beabsichtigten
Bedrohungen. Diese wohl ”interessantesten” Berdohungen können
sowohl von innen (ein berechtigter Systembenutzer versucht Zugriffsrechte
zu erlangen, die seinem Nutzerprofil nicht entsprechen) als auch von außen (ein
Angreifer versucht sich unberechtigt Zugang zum System zu verschaffen) kommen.
Um der Vielzahl natürlicher Bedrohungen nicht hilflos gegenüberzustehen,
kommen meist Verfahren aus baulichen und technischen Bereichen wie Blitzschutzanlagen,
Notstromversorgungen oder Brandmeldesysteme zum Einsatz.
Hierdurch können die Risiken zwar nicht negiert, jedoch auf ein erträgliches Maß
reduziert werden. Den unbeabsichtigten Bedrohungen begegnet man am besten
mit Training und Fortbildung von Systemnutzern und -administratoren, um deren
8 Betriebsmittel sind elementare Komponenten eines Rechnersystems: Hardware, Software und
Daten.[7]
12

Inv.-Nr.:2003-07-02/047/IN96/2253
Wissen über mögliche Risiken auf einem weitestgehend aktuellen Stand zu halten
und, um das Sicherheitsbewusstsein eines jeden Einzelnen weiter auszuprägen.
Weitaus schwieriger gestaltet sich die Ergreifung von Schutzmaßnahmen gegen
beabsichtigte Bedrohungen. Hierbei bedarf es dem Einsatz einer ganzen Reihe
verschiedenster Sicherheitsmechanismen. Um diese Sicherheitsmechanismen
adäquat einsetzen zu können, sollte man sich folgende wichtige Frage vor Augen
führen. [23]
Welche Informationen oder Daten könnten aus welchen Gründen für wen von
Interesse sein und wie kann er an sie gelangen?
Diese Frage beinhaltet wesentliche Merkmale der beabsichtigten Bedrohungen: die
interessanten Informationen oder Daten (Was), die Motivation für einen Angriff
(Warum), den Angreifer selbst (Wer) und die Methode des Angriffs (Wie).
2.3.1 Täterkreis (Wer)
Es stellt sich als überaus schwierig dar, einen Angreifer (Täter) einem bestimmten
Personenkreis zuzuordnen. Grundsätzlich könnte sich hinter jedem, der sich im
Gebiet der elektronischen Datenverarbeitung auskennt, ein potentieller Täter verbergen.
Betrachtet man beispielsweise das Intranet 9 eines Unternehmens, welches räumlich
getrennt als eine Art Insel existiert, so beschränkt sich die Anzahl möglicher
Täter weitestgehend auf Mitarbeiter, Besucher, Wartungs- und Reinigungspersonal
und auf solche Personen, die sich unerlaubt Zutritt zu den Unternehmensräumen
verschaffen (Einbrecher). Sobald aber damit begonnen wird, ein solches Intranet
an ein für jedermann zugängliches Netzwerk wie das Internet anzuschließen, vergrößert
sich unweigerlich der Kreis potentieller Angreifer um ein Vielfaches und
die Wahrscheinlichkeit steigt, gelegentlich ungebetene Gäste zu Besuch zu haben.
Gerade im Internet ist vom Teenager, der aus sportlichem Ehrgeiz die Homepage
unbemerkt nach seinen Vorstellungen verschönert, bis zum professionellen Industriespion,
der im Auftrag der Konkurenz vertrauliche Dokumente entwendet, alles
vertreten. [20]
Allgemein lässt sich festhalten, dass eine Person dann zum Angreifer werden kann,
wenn die folgenden Faktoren auf sie zutreffen:
• sie benötigt aus bestimmen Gründen Informationen, Daten oder Ressourcen
• sie hat die Gelegenheit, sich diese zu beschaffen
• sie hat keine moralischen Skrupel, die ihr Tun verhindern könnten
Bei der Entwicklung von Sicherheitskonzepten sollte man versuchen, dass diese
drei Faktoren bei einer Person nie zusammenkommen. Es ist aber leicht einzusehen,
dass auf Bedarf und Moral nur im äußerst begrenzten Maß Einfluss genommen
werden kann. Das Hauptaugenmerk liegt darauf, der Person erst gar keine Gelegenheit
zum Angriff zu bieten.
9 Ein Intranet ist ein Netzwerk, das Personal-Computer innerhalb eines Unternehmens miteinander
verbindet.
13

Inv.-Nr.:2003-07-02/047/IN96/2253
2.3.2 Information (Was)
Wie schon erwähnt, ist der Bedarf einer Person an bestimmten Informationen ein
wichtiger Aspekt, der zu einem Angriff führen kann. Informationen gelten heute als
wirtschaftliches Gut und stellen oftmals einen großen Wert für den Besitzer dar.[20]
Es gilt also zu untersuchen, welche Informationen für Außenstehende von besonderem
Interesse sein könnten und welchen Schaden der Verlust der Vertraulichkeit
dieser Informationen nach sich zieht. Auf Basis dieser Untersuchungen kann
dann entschieden werden, ob bestimmte Informationen besonders geschützt werden
müssen oder nicht.
Als Beispiel wären hier auf der einen Seite Unternehmensdaten wie Forschungsergebnisse
zu nennen, bei denen der Verlust der Vertraulichkeit gegenüber der Konkurenz
einen immensen Schaden bedeuten würde, und die deshalb eines besonderen
Schutzes bedürfen. Auf der anderen Seite das sich wöchentlich ändernde Menüangebot
der unternehmenseigenen Kantine, welches im Intranet zu finden ist und dessen
Schutzwürdigkeit gegen Null geht.
2.3.3 Motivation des Angreifers (Warum)
Die Motive, die ein Angreifer haben kann, sind vielfältig. Die Palette reicht von
niedrigen Beweggründen bis hin zur Verfolgung vermeintlich ehrwürdiger Ziele.
Stellvertretend sollen im Folgenden ohne Anspruch auf Vollständigkeit einige Motive
kurz skizziert werden.
Ruhm: Nicht immer steht der gezielte ”Datenklau” im Vordergrund. Manche Angreifer
brüsten sich gerne in der Öffentlichkeit, erfolgreich in bekannte Unternehmen
wie Microsoft oder Institutionen wie das FBI eingebrochen zu sein.
Spaß an der Sache: Die Freude darüber, ein vermeintlich sicheres System geknackt
zu haben, spielt bei dieser Art von Motivation eine wichtige Rolle. Die wenigen
”echten” Hacker arbeiten unter einer Art ”Ehrenkodex” und verfolgen vorrangig
das Ziel, Schwachstellen in der Sicherung von Systemen und dem Schutz
von Daten aufzudecken ohne größeren Schaden zu hinterlassen.
Emotionen: Wut, Hass oder Rache sind Emotionen, die möglicherweise (Ex-)
Mitarbeiter dazu veranlassen, gegen den (früheren) Arbeitgeber einen Angriff zu
starten. Denkbar ist, dass ein solcher Mitarbeiter Insiderwissen über Sicherheitsmechanismen
besitzt, was ihn besonders gefährlich macht.
Wirtschaftliche Interessen: Last but not least stehen die wirtschaftlichen und finanziellen
Interessen. Man stelle sich einen Mitarbeiter vor, der firmeninterne Forschungsergebnisse
sammelt und diese dann an den meistbietenden Konkurrenten
verkauft.
14

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 4: Angriffszyklus [20]
2.3.4 Methoden des Angriffs (Wie)
Ein potentieller Angreifer kann sich heutzutage aus einem reichhaltigen Pool von
Angriffsmethoden die aussuchen, die nach eigenem Ermessen am effektivsten zu
seinem äußerst fragwürdigen Ziel führen. Da wären unter anderem Spoofing, DoS-
Attacken, Lauschangriffe, Trojanische Pferde, Social Engineering und Replay zu
nennen. Die meisten dieser Angriffsmethoden setzten ein fundiertes technisches
Verständnis und Fachwissen voraus. Wer jedoch annimmt, dass das den potentiellen
Täterkreis auf Technik-Freaks und professionelle Industriespione einschränkt,
liegt angesichts des reichhaltigen Funduses an Angriffswerkzeugen, die sich im Internet
finden lassen, leider falsch. Solche Tools wie beispielsweise CRACK 10 oder
Juggernaut 11 befähigen inzwischen auch Gelegenheitshacker, einige komplizierte
Attacken per Knopfdruck durchzuführen. [20]
Wie bereits angedeutet, bestehen die meisten Angriffe aus vielschichtigen und komplizierten
Prozessen, die einer systematischen Vorgehensweise und einem guten
Verständnis von Netzwerken und Betriebssystemen bedürfen. Besonders die Identifizierung
möglicher Schwachstellen im System ist ein wichtiger Schritt zum Erfolg.
Das Vorgehen des Angreifers beim Attackieren eines Systems wird in [20] als einen
Zyklus dargestellt, der solange durchlaufen wird bis das gesetzte Ziel erreicht ist.
Abbildung 4 zeigt einen solchen Angriffszyklus. Typischerweise beginnt ein Angriff
damit, dass der Eindringling versucht, möglichst viele Informationen über das
Zielsystem zu sammeln. (1) Auf Grundlage dieser Informationen lassen sich möglicherweise
Rückschlüsse auf das verwendete Betriebssystem und dessen Release-
Stand ziehen, die ihrerseits wiederum zur Identifizierung von Schwachstellen dienen
können. (2) Hat der Angreifer solche Schwachstellen entdeckt, wird er diese
ausnutzen, um direkte Schutzmechanismen zu umgehen. (3) Hat er auch die-
10 vergl.: [20] Seite 110
11 vergl.: [20] Seite 113
15

Inv.-Nr.:2003-07-02/047/IN96/2253
se Hürde überwunden, werden durch die im ersten Angriffszyklus unrechtmäßig
erworbenen Berechtigungen (4) weitere Informationen gesammelt, die zur Überwindung
des nächsten Hindernisses hilfreich sein könnten, und so weiter. Je mehr
Schutzmechanismen dem Angreifer im Weg stehen, um so öfter muss er den Zyklus
durchlaufen und um so schwieriger wird sein Unterfangen. [20]
Nach der bis jetzt weitestgehend allgemeinen Betrachtung soll die nun folgende
Übersicht die oben bereits erwähnten Angriffsmethoden etwas näher beleuchten.
Spoofing Unter Spoofing (dt. Schwindeln, Vortäuschen) versteht man das Vorgaukeln
einer falschen Identität. Der Angreifer versucht, sich dadurch Zugang zu
geschützten Systemen oder Diensten zu verschaffen. Spoofing richtet sich also gegen
die Zugangskontrolle 12 eines Systems.
Denial-of-Service-Attacken (DoS) Denial-of-Service-Attacken (dt. Serviceverweigerungsangriffe)
richten sich immer gegen die Verfügbarkeit 13 eines Systems.
Der Angreifer versucht durch bewusst herbeigeführte Überlastung die Funktionalität
des attackierten Systems entscheident zu stören. Das Gefährliche an diesen
Angriffen ist, dass sie in der Regel ohne großen Aufwand durchführbar sind und
man sich nur schwer gegen sie wehren kann. Der Schaden, den sie verursachen,
hält sich dagegen gewöhnlich in Grenzen, da der Angreifer keine Berechtigungen
auf dem attackierten System erhält. Denial-of-Service-Attacken sind oft Bestandteil
eines mehrstufigen Angriffsplans, um beispielsweise störende Reaktionen dritter
Systeme zu unterbinden. [20] [4]
Lauschangriffe Netzwerke dienen nicht nur als Transportmittel einer Attacke,
sondern können auch selber Ziel eines Angriffs werden. Bei einem Lauschangriff
versucht der Täter Datenströme abzuhören, um unberechtigt an die darin enthaltenen
Informationen zu gelangen. Dabei kommt ihm die Tatsache entgegen, dass
immer noch viele Anwendungsprotokolle, wie zum Beispiel FTP 14 ihre Nutzdaten
überwiegend unverschlüsselt, also im Klartext, übertragen.
Das Abhören geschieht für die betroffenen Anwender völlig transparent und ist nur
mit hohem messtechnischen Aufwand feststellbar. [20] [3]
Trojanische Pferde Das aus der griechischen Mythologie bekannte Trojanische
Pferd stand bei der Namensgebung von Programmen oder Skripten Pate, die neben
ihrer bekannten und erwarteten Arbeitsweise hinter dem Rücken des Anwenders
unberechtigt, vorzugsweise vertrauliche Daten im System sammeln und an den Angreifer
zurücksenden. Diese Vorgehensweise kann wie bei den Lauschangriffen für
den Anwender transparent sein und auch nach der Entdeckung eines Trojaners kann
man oft nur schwer sagen, wie tief er in das System eingedrungen ist und welche
Daten er bereits ausgespäht und versendet hat. [3] [20]
12 vergl.: Abschnitt 2.2.2 Zugangskontrollen
13 vergl.: Abschnitt 2.1 Verfügbarkeit
14 File Transfer Protokoll
16

Inv.-Nr.:2003-07-02/047/IN96/2253
Social Engineering Beim Social Engineering nutzt der Angreifer die Naivität der
Mitarbeiter eines Unternehmens und deren Bedürfnis, hilfreich zu sein aus, um an
die gewünschten Informationen zu gelangen, die er an anderer Stelle verwerten
kann. Der Telefonanruf eines unter Zeitdruck stehenden Mitarbeiters beim Administrator,
der angeblich sein Passwort vergessen hat oder einen Gastzugang benötigt,
reicht unter Umständen aus, jeden noch so aufwendigen Sicherheitsmechanismus
durch menschliches Fehlverhalten außer Kraft zu setzen. 15 [3] [20]
Replay Speichert ein Angreifer abgefangene Nachrichten, um sie später wieder
unverändert abzusenden, so nennt man das eine Replay- (dt. Wiedereinspielungs-)
Attacke. In Bezug auf Authentisierungsdaten, wie Benutzerkennung und Passwort
kann er sich so, unter Vortäuschung einer falschen Identität, unberechtigt Zugang
zu einem System verschaffen. Dabei ist es vollkommen belanglos, ob die Daten in
verschlüsselter Form oder im Klartext übertragen wurden, da ihr Inhalt eigentlich
nicht von Interesse ist. [3] [4]
2.4 Kryptologie
Die Kryptologie 16 ist ein Bereich der Mathematik, der sich mit dem Verbergen von
Informationen beschäftigt. Im Oberbegriff Kryptologie werden die beiden Teilgebiete
Kryptograhie und Kryptoanalyse zusammengefasst. [5] [24] [21]
Kryptographie Kryptographie ist die Lehre von den Methoden zur Ver- und Entschlüsselung
(Chiffrierung / Dechiffrierung) von Daten, um eine Geheimhaltung
der beinhalteten Informationen gegenüber Unbefugten (Angreifern) sicherzustellen.
Die beiden wichtigsten Hilfsmittel der Krytographie sind zum einen die Mathematik.
Denn nur durch mathematische Denkweise und Kenntnisse lassen sich
Verfahren zur sicheren Ver- und Entschlüsselung von Daten entwickeln. Zum anderen
der Computer, der die Verschlüsselungsverfahren durchführt und sie auf mögliche
Schwachstellen hin untersuchen kann.
Krytographische Methoden werden in den unterschiedlichsten Bereichen der Informationssicherung
eingesetzt. Besonders bei der Gewährleistung der sicheren Übertragung
von Daten über unsichere Kanäle, wie Telefon, Internet oder Funkstrecken,
spielen sie eine wichtige Rolle.[5] [24]
Kryptoanalyse Die Kryptanalyse ist das Teilgebiet der Kryptologie, das sich
damit beschäftigt, Sicherheitslücken kryptografischer Verfahren aufzudecken.
Eine Hauptanwendung liegt in der Entschlüsselung bereits chiffrierter Daten ohne
Kenntnis über den verwendeten Schlüssel.
In der Praxis sind Kryptoanalyse und Kryptographie eng miteinander verbunden,
da zur Entwicklung sicherer kryptographischer Verfahren stets eine kritische
15 Ein Beispiel vom geglücktem Social Engineering findet man unter: Vorsicht vor Pseudo-eBay
(Update) - http://www.heise.de/newsticker/data/cgl-18.01.02-001
16 griechisch: kryptó = verstecken, verbergen
17

Inv.-Nr.:2003-07-02/047/IN96/2253
Beurteilung gehört. [5] So ist beispielsweise der Zeitaufwand, den die Kryptoanalyse
zur vollständigen und korrekten Dechiffrierung einer Information
im Bezug auf die zur Verfügung stehenden Ressourcen benötigt ein wichtiges
Maß für die Qualität eines kryptographischen Verfahrens. Je größer Zeitaufwand
und Ressourcenverbrauch zur Entschlüsselung sind, um so sicherer ist das
Verschlüsselungsverfahren.
2.4.1 Alice, Bob und Mallory !?!
Wie die Literatur zeigt, hat es sich bewährt kryptographische Verfahren mit Hilfe
der Personen Alice, Bob und Mallory zu erläutern. Personennamen sind anschaulicher
als beispielsweise Einzelbuchstaben und tragen somit zum besseren Verständnis
bei der Darstellung von Kryptosystemen und Sicherheitsprotokollen bei.
Auch in dieser Arbeit soll von folgendem allgemeinen Modell ausgegangen werden:
Alice und Bob tauschen über einen unsicheren Kanal Daten aus. Dieser Kanal
ist in der Regel ein Rechnernetzwerk wie das Internet, könnte aber auch die Telefonleitung,
eine Funkverbindung oder die Transportstrecke einer Diskette sein.
Mallory ist der Angreifer im Modell. Er versucht mit allen ihm zur Verfügung stehenden
Mitteln, den unsicheren Übertragungskanal abzuhören und die Übertragung
zu beeinflussen. Mallory kann also alle Daten, die Alice und Bob austauschen in
beliebiger Weise abfangen, manipulieren und anschließend weiterleiten.
Um sich nun vor Mallory zu schützen, verwenden Alice und Bob kryptographische
Verfahren zur Verschlüsselung ihrer gemeinsamen Kommunikation.
2.4.2 Symmetrische und asymmetrische Kryptosysteme
Ein kryptographisches System (kurz Kryptosystem) legt fest, wie Klartexte in Kryptotexte
transformiert (verschlüsselt) und Kryptotexte wieder in Klartexte zurück
transformiert (entschlüsselt) werden könnnen. Jedes Kryptosystem besteht aus folgenden
6 Komponenten: [5]
1. Einer nicht leeren endlichen Menge von Klartexten M.
2. Einer nicht leeren endlichen Menge von Krypto- bzw. Chiffretexten C.
3. Einer nicht leeren Menge von Verschlüsselungsschlüsseln EK.
4. Einer nicht leeren Menge von Entschlüsselungsschlüsseln DK.
5. Einem Verschlüsselungsverfahren E: M×EK→C.
6. Einem Entschlüsselungsverfahren D: C×DK→M,
mit der Eigenschaft das für zwei Schlüssel k E ∈ EK und k D ∈ DK
mit f (k E ) = k D gilt:
∀m ∈ M: D(E(m, k E ), k D ) = m.
18

Inv.-Nr.:2003-07-02/047/IN96/2253
Das Zusammenwirken dieser Komponenten veranschaulicht Abbildung 5. Jedes in
des Praxis eingesetzte Verschlüsselungssystem kann dadurch beschrieben werden.
[5]
Abbildung 5: Komponenten eines Kryptosystems [5]
Der Sender (Alice) chiffriert die Klartextnachricht m mit Hilfe des Verschlüsselungsverfahrens
E und des Schlüssels k E . Der daraus entstandene Chiffretext c
wird über einen Kommunikationskanal an den Empfänger (Bob) versandt. Dort
angekommen, erfolgt die Rücktransformation unter Verwendung des Entschlüsselungsverfahrens
D und des Schlüssels k D in die ursprüngliche Klartextnachricht m.
Man kann davon ausgehen, dass ein Angreifer (Mallory) auf den übertragenen
Chiffretext zugreifen kann, da das Abhören offener Kommunikationsnetze unter
Verwendung geeigneter Hilfsmittel denkbar ist. Mit dem abgefangenen Chiffretext
und den ihm zur Verfügung stehenden Zusatzinformationen I versucht Mallory
nun, die zugehörige Klartextnachricht zu ermitteln. Eine Zusatzinformation könnte
beispielsweise der Hinweis sein, dass die Nachricht in deutscher Sprache verfasst
wurde.
Kryptographische Systeme können in drei Klassen eingeteilt werden. ”Klassische”
symmetrische- und ”moderne” asymmetrische Kryptosysteme bilden die
ersten beiden. In der dritten Klasse finden sich Kombinationen aus symmetrischen
und asymmetrischen, die sogenannten hybriden Kryptosysteme wieder.
Symmetrische Kryptosysteme Das Charakteristikum der symmetrischen Kryptosysteme,
auch Secret-Key-Verfahren genannt, ist, dass Alice und Bob im Besitz
des gleichen, für alle anderen geheimen Schlüssels (engl. secret key) sein müssen,
um vertraulich miteinander kommunizieren zu können. Über diesen Schlüssel
müssen sich beide vor Beginn der Übertragung verständigen und ihn gegebenenfalls
über einen sicheren Kanal austauschen. Die Sicherheit einer Kommunikation mittels
symmetrischer Verfahren hängt also nicht nur von der kryptographischen Stärke
der verwendeten Verschüsselungsverfahren ab, sondern auch maßgeblich von der
sicheren Aufbewahrung, Verwaltung und dem initialen Austausch, des geheimen
19

Inv.-Nr.:2003-07-02/047/IN96/2253
Schlüssels. [5] [24] [20]
Eine vertrauliche Kommunikation unter Nutzung eines symmetrischen Kryptosystems
durchläuft grob die folgenden Protokollschritte: [5]
1. Alice und Bob vereinbaren einen gemeinsamen, geheimen Schlüssel
k E = k D = k A,B .
2. Um eine Nachricht m an Bob zu versenden, verschlüsselt Alice den Text m
mittels k A,B , also c = E(m, k A,B ), und sendet c an Bob.
3. Bob entschlüsselt c mittels k A,B und erhält daraus die ursprüngliche Nachricht
m von Alice, also m = D(c, k A,B ) = D(E(m, k A,B ), k A,B )
Unter Verwendung eines guten Verschlüsselungsverfahrens ist es für Alice und
Bob bei Kenntnis des geheimen Schlüssels einfach, die chiffrierte Nachricht zu
entschlüsseln. Für Mallory, der nur Zugriff auf das Chiffrat hat, ist es ohne Kenntnis
des Schlüssels dagegen schwer bis unmöglich, selbst wenn er das Verschlüsselungsverfahren
genau kennt. [24]
Symmetrische Verschlüsselungsverfahren lassen sich in Block- und Stromchiffren
klassifizieren. Blockchiffren teilen die Originalnachricht in Eingabeblöcke
fester Länge, wobei jeder Block mit der gleichen Funktion verschlüsselt wird. Eine
typische Blockgröße beträgt 64 Bit. Stromchiffren hingegen sind sequentielle Chiffren,
die eine Folge von kleinen Klartexteinheiten (Zeichen) mit einer variierenden
Funktion verschlüsseln. Gängige Zeichengrößen eingesetzter Stromchiffren sind
1 Bit oder 1 Byte.[5] [20]
Ein entscheidender Vorteil der symmetrischen Kryptosysteme ist der hohe Datendurchsatz.
Software-Lösungen erreichen auf leistungsfähigen Intel-Maschinen
akzeptable Verschlüsselungsraten von bis zu 1 MBit/s. [20] Sie eignen sich
daher besonders gut zur Verschlüsselung großer Datenmengen. Nachteilig wirkt
sich jedoch der Umstand aus, dass beide Kommunikationspartner im Besitz des
gemeinsamen Schlüssels sein müssen bevor sie Nachrichten ver- und entschlüsseln
können. Steht von vornherein kein vertrauenswürdiges Medium zum Schlüsselaustausch
zur Verfügung ist eine spontane, gesicherte Kommunikation nicht möglich.
Abschnitt 2.5.1 stellt zwei bekannte symmetrische Verschlüsselungsverfahren
vor, die in der heutigen Praxis häufig Verwendung finden. Die dreifache Anwendung
des Data Encryption Standard (kurz 3DES) und den IDEA-Algorithmus.
Asymmetrische Kryptosysteme Um das Schlüsselaustauschproblem der symmetrischen
Kryptosysteme zu lösen, wurden Mitte der 70er Jahre asymmetrische
Kryptosysteme (engl. public key) als eine neue Klasse kryptographischer Verfahren
vorgestellt. Grundidee des Public-Key-Verfahrens ist es, dass stets zwei
Schlüssel pro verschlüsselter Nachricht verwendet werden. Den einen kennt nur
der Empfänger, es ist sein geheimer, persönlicher Schlüssel. Der andere ist nicht
geheim und kann öffentlich bekannt gegeben werden. Beide Schlüssel sind mathematisch
voneinander abhängig und werden in der Regel einer Person zugeordnet,
20

Inv.-Nr.:2003-07-02/047/IN96/2253
weshalb man auch von Bob’s öffentlichem und Bob’s privatem Schlüssel spricht.
Will nun Alice an Bob eine verschlüsselte Nachricht senden, dann durchläuft das
Kommunikationsprotokoll grob die folgenden Schritte: [5]
1. Alice und Bob erzeugen ihre eigenen Schlüsselpaare (k A E,k A D) bzw. (k B E,k B D),
wobei die Schlüssel k A D und k B D die jeweiligen geheimen privaten Schlüssel
sind.
2. Die Schlüssel k A E und k B E werden öffentlich bekannt gegeben. Sie könnten
beispielsweise in einer öffentlichen Datenbank oder einem öffentlich zugänglichen
Schlüssel-Server verwaltet werden.
3. Alice verschlüsselt ihre Nachricht m mit Bob’s öffentlichem Schlüssel, also:
E(m,k B E) = c, und sendet c an Bob.
4. Bob wiederum entschlüsselt c mit seinem privaten Schlüssel, also:
D(c,k B D) = m.
5. Will Bob eine Nachricht an Alice zurückschreiben, so benötigt er den öffentlichen
Schlüssel von Alice k A E, um den Text zu verschlüsseln.
Auch das Public-Key-Verfahren arbeitet also mit geheimen Schlüsseln, die sicher
zu verwalten sind. Sie müssen jedoch im Gegensatz zu den symmetrischen Systemen
nicht vor Kommunikationsbeginn über ein sicheres Medium ausgetauscht
werden.
Um eine sichere Kommunikation mit Hilfe asymmetrischer Kryptosysteme
gewährleisten zu können, müssen sie die nachstehenden Grundanforderungen
erfüllen:
• Das Ver- und Entschlüsseln von Nachrichten muss mittels öffentlichem bzw.
privatem Schüssel und einem geeigneten Verfahren leicht durchführbar sein.
• Der private Schlüssel darf nur dem rechtmäßigen Besitzer bekannt sein.
• Der öffentliche Schlüssel des Kommunikationspartners muss verfügbar sein.
• Mallory kann gar nicht, oder nur sehr schwer aus einem öffentlichen
Schlüssel Rückschlüsse auf den zugehörigen privaten Schlüssel ziehen.
• Der öffentliche Schüssel muss so beschaffen sein, dass ihn Mallory nicht dazu
benutzen kann, das abgefangene Chiffrat zu entschlüsseln.
Durch die Entwicklung der Public-Key-Verfahren ist es möglich geworden,
spontane Kommunikationsbeziehungen über unsichere Netzwerke vertraulich
abzuwickeln. Die öffentlichen Schlüssel lassen sich bedenkenlos verteilen, da
sie nur zur Ver- und nicht zur Entschlüsselung verwendet werden können. Die
Vertraulichkeit des privaten Schlüssels gegenüber anderen ist jedoch von enormer
Wichtigkeit. Sollte er in die Hände eines Angreifers geraten so ist es diesem
möglich, die Kommunikation zu belauschen oder Nachrichten zu verändern.[20]
21

Inv.-Nr.:2003-07-02/047/IN96/2253
Nachteilig wirkt sich vor allem die Geschwindigkeit der asymmetrischen Kryptosysteme
aus. Die Verschlüsselung einer Datei erfolgt mit DES vergleichsweise
100mal schneller.[20]
Zu den bekanntesten Vertretern der Klasse der asymmetrischen Systeme gehört das
RSA-Verfahren [5], welches im Abschnitt 2.5.1 vorgestellt wird.
Hybride Kryptosysteme Hybride Kryptosysteme kombinieren die Vorteile der
symmetrischen und asymmetrischen Systeme und versuchen, die Nachteile außen
vor zu lassen. Die Funktionsweise ist denkbar einfach: Zuerst generiert Alice einen
zufälligen Sitzungsschlüssel (engl. session key), dieser besitzt meist nur Gültigkeit
für einen gewissen Zeitraum oder die aktuelle Kommunikationsbeziehung (Sitzung).
Mit ihm verschlüsselt Alice ihre Nachricht für Bob nach dem symmetrischen
Verfahren. Den Sitzungsschlüssel selbst chiffriert sie mit Bob’s öffentlichem
Schlüssel aus dem Public-Key-Verfahren. Beide Chiffren werden nun zu Bob übermittelt,
der seinerseits mittels privatem Schüssel zuerst den Sizungsschlüssel dechiffriert
und diesen wiederum benutzt um, die eigentliche Nachricht von Alice zu
entschlüsseln.
Bei den hybriden Kryptosytemen wird also die hohe Leistungsfähigkeit eines
symmetrischen Algorithmus mit der sicheren Schlüsselverteilung des Public-Key-
Verfahrens vereint.
2.4.3 Kryptographische Hashfunktionen
Hashfunktionen haben zunächst erstmal nichts mit Kryptographie im engeren Sinne
zu tun. Sie kommen in vielen Teilbereichen der Informatik zum Einsatz, unter
anderem, um den Zugriff auf Objekte effizient zu gestalten. Mathematisch gesehen,
ist eine Hashfunktion f eine nicht injektive 17 Abbildung eines Eingabewerts m auf
einen Hashwert h, es gilt die Beziehung: h = f (m). Der Hashwert h kann dabei
nur eine begrenzte Menge von Werten annehmen, während m aus einer deutlich
größeren oder gar beliebig großen Menge auswählbar sein muss.
Dieser Umstand und der Umstand, dass Hashfunktionen nicht injektiv sind, führt
möglicherweise zum Auftreten von Kollisionen. Als Kollision bezeichnet man das
Verhalten einer Hashfunktion, wenn sie zwei unterschiedliche Eingabewerte m 1 ,
m 2 auf den gleichen Hashwert abbildet, f (m 1 ) = f (m 2 ), m 1 ≠ m 2 . Bei einer guten
Hashfunktion sollten Kollisionen möglichst selten vorkommen.
Im Bereich Kryptograpie dienen spezielle Hashfunktionen zum Schutz vor
Integritätsverletzungen. Auch sie akzeptieren als Eingabe einen Wert (Nachricht)
m beliebiger Größe und liefern einen Wert h fester Länge zurück. Dieser Hashwert
h repräsentiert dann den Inhalt der Nachricht, weshalb man ihn auch als ”digitalen
Fingerabdruck” oder Message Digest (MD) bezeichnet.
Die Kryptographie stellt im Vergleich zu anderen Anwendungsgebieten zusätzliche
Anforderungen an eine Hashfunktion:[24]
17 f : A → B heißt injektiv, genau dann, wenn ∀ x,y ∈ A gilt: x ≠ y ⇒ f (x) ≠ f (y).
22

Inv.-Nr.:2003-07-02/047/IN96/2253
• Innerhalb wie außerhalb der Kryprographie gilt gleichermaßen, dass ein
Hashwert etwa gleich oft vorkommen soll.
• Jede noch so kleine Änderung des Eingabewerts muss eine Änderung des
resultierenden Hashwert nach sich ziehen.
• Außerhalb der Kryptographie eher unbekannt ist die Forderung, dass es
möglichst schwierig sein muss, Kollisionen herbeizuführen. Zu einem gegebenen
Eingabewert darf es mit realistisch vertretbarem Aufwand nicht
möglich sein, einen zweiten mit gleichem Hashwert zu finden. Das impliziert
natürlich, dass keine Umkehrvorschrift f −1 existiert, die aus einem gegebenen
Hashwert wieder die Originalnachricht reproduzieren könnte.
Erfüllt eine Hashfunktion die drei genannten Anforderungen, so bezeichnet man
sie als kryptographische Hashfunktion oder sichere Einwegfunktion. Der aus einer
kryptographischen Hashfunktion generierte Hashwert heißt dann entsprechend
kryptographischer Hashwert.
Zu den bekanntesten Verfahren zur Erzeugung von kryptographischen Haschwerten
gehören die von Ron Rivest entwickelten Algorithmen MD4 18 und MD5 19 .
Beide Algorithmen generieren aus der jeweiligen Eingabe einen 128 Bit langen,
digitalen Fingerabdruck. Einen 160 Bit langen Hashwert liefert der von der US-
Standardisierungsbehörde NIST 20 in Zusammenarbeit mit der NSA 21 entwickelte
Secure Hash Algorithm kurz SHA. Ein vorläufiger Design-Fehler wurde im heutzutage
gebräuchlichen SHA-1 korrigiert. Der SHA bietet im Vergleich zu MD5 aufgrund
des längeren Hashwerts eine höhere Sicherheit, ist dafür aber auch deutlich
langsamer.
In [28] werden eine ganze Reihe von kryptographischen Hashfunktionen ausführlich
beschrieben und deren Stärken und Schwächen aufgezeigt.
2.4.4 Digitale Signaturen
Vergleicht man die digitale Signatur mit der realen Welt, so kommt sie der Unterschrift
unter einem Dokument ziemlich nahe. Sie hat die Aufgabe, Daten, die über
ein unsicheres Medium transportiert werden sollen, vor unbemerkter Modifikation
zu schützen und sie an den Eigentümer eines bestimmten privaten Schlüssels zu
binden. Zur Erstellung einer digitalen Signatur kommt das Public-Key-Verfahren in
entgegengesetzter Richtung zum Einsatz. Das heißt, die Verschlüsselung erfolgt bei
der digitalen Signatur nicht mit dem öffentlichen Schlüssel, sondern mit dem privaten.
Das Entschlüsseln findet demzufolge mit dem zum privaten Schlüssel gehörenden
öffentlichen Schlüssel statt. Da aber das Verschlüsseln der gesamten Datenmenge
aufgrund der Komplexität asymmetrischer Verfahren unter Umständen sehr lange
dauern kann, kommen die bereits angesprochenen kryptographischen Hashfunktion
zum Einsatz, um die zu übertragenden Daten auf wenige Bytes zu verdichten.
18 vergl.: RFC 1320
19 vergl.: RFC 1321
20 National Institute of Standards and Technology
21 National Security Agency
23

Inv.-Nr.:2003-07-02/047/IN96/2253
Ist der Hashwert der Daten ermittelt, wird anschließend mit dem privaten Signaturschlüssel
des Absenders verschlüsselt. Danach werden die Daten zusammen mit
der Signatur zum Empfänger versandt. Dieser berechnet erneut den Hashwert der
erhaltenen Daten mit Hilfe der gleichen Hashfunktion wie der Absender und decodiert
mit dem öffentlichen Schlüssel des Unterzeichners die digitale Signatur. Sind
beide Hashwerte gleich, so kann er sicher sein, dass die empfangenen Daten nach
der Signierung nicht mehr modifiziert wurden und dass sie vom entsprechenden
Absender stammen. Voraussetzung hierfür ist allerdings, dass der private Schlüssel
des Absenders ausschließlich ihm und keiner anderen Person zur Verfügung steht
und dass nachweisbar ist, dass der zum Decodieren der digitalen Signatur verwendete
öffentliche Schlüssel eindeutig zum entsprechenden Absender gehört. Einen
solchen Nachweis kann beispielsweise ein Schlüsselzertifikat erbringen.
Zu den bekanntesten Signaturverfahren zählt der RSA-Algorithmus und der von
der amerikanischen Regierung entwickelte und bevorzugte Digital Secure Standard
(kurz DSS). [20][30]
2.4.5 Schlüsselzertifikate
Ein Problem, das im Zusammenhang mit der Verwendung von öffentlichen
Schlüsseln auftritt, ist, dass man ihnen nicht ohne weiteres ansieht, zu wem sie
gehören. Es bedarf deshalb einiger Zusatzinformationen, die zusammen mit den
eigentlichen Schlüsseldaten Auskunft über den Schlüsselinhaber geben. An dieser
Stelle kommen Schlüsselzertifikate ins Spiel. Die Zertifizierung eines öffentlichen
Schlüssels beglaubigt ähnlich wie ein Personalausweis im normalen Leben die Identität
des Besitzers.
Genau wie beim Personalausweis benötigt man für die Ausstellung eines Schlüsselzertifikates
eine vertrauenswürdige unabhängige Institution. Diese sogenannte Zertifizierungsinstanz
(engl. Certification Authority, CA), im deutschsprachigen Raum
auch Trust-Center genannt, überprüft, ob ein zur Beglaubigung eingereichter öffentlicher
Schlüssel und eine Person mit eindeutigem Namen wirklich zusammengehören.
Ist dies der Fall, so erzeugt die CA ein elektronisches Schlüsselzertifikat.
Als Standard für Zertifikate hat sich der ITU 22 -Standard X.509 durchgesetzt.
Ein nach diesem Standard ausgestelltes Schlüsselzertifikat beinhaltet unter anderem
eine Zertifikatsnummer zur Identifizierung, den Namen der ausstellenden Instanz
(CA), den Namen des Besitzers, den Gültigkeitszeitraum, den öffentlichen
Schlüssel des Besitzers und die digitale Signatur der ausstellenden Instanz, um es
vor unbemerkten Modifikationen zu schützen. Der exakte Aufbau eines X.509 Zertifikates
ist beispielsweise in [20] auf Seite 152 und in [30] auf Seite 22 zu finden.
2.5 Kommunikationssicherheit
Die Kommunikationssicherheit befasst sich mit der Frage: Wie können Daten bzw.
Nachrichten, die einen Computer verlassen haben, vor Abhörern und Manipulierern
geschützt werden? Ziel ist es also, die Vertraulichkeit, Authentizität und Integrität
von Daten zu gewährleisten, die über ein unsicheres Medium zwischen zwei
22 ITU: International Telecommunication Union
24

Inv.-Nr.:2003-07-02/047/IN96/2253
oder mehreren Kommunikationspartnern ausgetauscht werden. Bei einem unsicheren
Medium könnte es sich beispielsweise um das öffentlich zugängliche Internet
oder im gewissen Sinne auch um ein firmeninternes Intranet handeln. In beiden
passieren Nachrichten mehr oder weniger viele Netzwerkknotenpunkte, wie zum
Beispiel Router, die zu einem Angriffsziel werden könnten, um Nachrichten abzuhören
oder zu manipulieren. Die Mittel der Wahl zur Wahrung der Kommunikationssicherheit
sind in Bezug auf die Integrität und Authentizität von Nachrichten
die schon besprochenen kryptographischen Hashfunktionen sowie digitale Unterschriften.
Zum Schutz der Vertraulichkeit kommen Verschlüsselungsalgorithmen
zum Einsatz.
2.5.1 Verschlüsselungsalgorithmen
Aus der Vielzahl der existierenden Verschlüsselungsalgorithmen sollen im Folgenden
die wichtigsten und heutzutage gebräuchlichsten kurz vorgestellt werden. Das
sind zum einen 3DES, IDEA, AES als Vertreter der symmetrischen- und zum anderen
RSA als Vertreter der asymmetrischen Verfahren. Zum Zeitpunkt der Verlegung
dieser Arbeit sind diese Algorithmen als sichere Verfahren eingestuft, was aber keinesfalls
heißen soll, dass ihre Sicherheit bewiesen ist. Vielmehr ist es noch keinem
Kryptoanalytiker gelungen, ihre Unsicherheit nachzuweisen.
DES Der Data Encryption Standard kurz DES wurde Anfang der 70er Jahre bei
IBM in den USA entwickelt und bildet die Grundlage für 3DES. 1977 wurde er
von der NIST (damals noch NBS 23 ) als Standard für die Datenverschlüsselung anerkannt.
Der DES ist eine Blockchiffre, die einen 64 Bit langen Eingabeblock mit einem 64
Bit Schlüssel, von dem aber nur 56 Bit relevant sind, zu einem 64 Bit langen Ausgabeblock
verschlüsselt. Er kann sowohl zur Ver- als auch zur Entschlüsselung von
Daten verwendet werden. Die Funktionsweise des DES ist in Abbildung 6 dargestellt.
Der zu verschlüsselnde 64 Bit Eingabeblock wird nach einer Anfangspermutation
(IP) in zwei gleichgroße Hälften L (für Links) und R (für Rechts) aufgeteilt,
die jeweils aus 32 Bit bestehen. Anschließend wird der gleiche Vorgang, in dem die
Daten mit dem Schlüssel kombiniert werden 16-mal wiederholt (man spricht auch
von den 16 Runden des DES):
• Auf L wird die Funktion F angewendet. Deren Ausgabe wird mit R exklusivoder-verknüpft
und das Ergebnis dieser Verknüpfung wird zu einem neuen L
für die nächste Runde.
• Die ”alte” linke Hälfte L wird zur ”neuen rechten” Hälfte R.
Nach Beendigung der 16 Runden erfolgt eine Schlusspermutation (IP −1 ) der
zusammengeführten Hälften L und R, welche den 64 Bit langen Ergebnisblock der
Verschlüsselung liefert.
Die Funktion F verarbeitet den 32 Bit langen Eingabeblock, indem sie ihn zunächst
permutiert und durch doppelte Verwendung einiger Bits auf 48 Bit ausdehnt.
23 National Bureau of Standards
25

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 6: Funktionsweise des DES [24]
Anschließend erfolgt eine exklusiv-oder-Verknüpfung mit einem 48 Bit langen
Teilschlüssel (K i ), den die Schlüsselaufbereitung liefert. Das Ergebnis dieser
Verknüpfung wird durch acht Substitutionsboxen (S-Boxen) gesandt, die 32 neue
Bits erzeugen. Eine Abschlusspermutation erzeugt dann die Ausgabe der Funktion.
Das Entschlüsseln bei DES funktioniert nach dem gleichen Prinzip wie die
Verschlüsselung. Der einzige Unterschied liegt in der Schlüsselaufbereitung: Die
16 Teilschlüssel werden in der umgekehrten Reihenfolge wie beim Verschlüsseln
verwendet.
Das größte Manko des Data Encryption Standard ist wohl der mit 56 Bit zu
kurze Schlüssel. Von den eigentlichen 64 Schlüsselbits sind nur 56 frei wählbar,
die restlichen acht dienen als Paritätsbits. Die vollständige Schlüsselsuche über
den Schlüsselraum von 2 56 ∼ 7, 2 · 10 16 stellt heute mit der entsprechenden
Rechnerleistung kein wirklich großes Problem mehr da. Das zeigen die erfolgreichen
Known-Plaintext-Attacken von 1997, 1998 und 1999. (vergl.: [24] Seite
76f.) Trotz dieser Tatsache findet man DES heutzutage noch in vielen Bereichen.
Für Anwendungen mit kurzen Transaktions- und Übertragungszeiten ist er auch
durchaus noch geeignet. Handelt es sich jedoch um extrem wertvollen Daten oder
Neuimplementierungen sollte man von der Verwendung von DES absehen.
3DES Der wichtigste Nachteil des DES, die relativ kurze Schlüssellänge, soll
Triple-DES (kurz 3DES) aus der Welt schaffen. Dabei handelt es sich bei 3DES
keinesfalls um einen neuen Verschlüsselungsalgorithmus, sondern vielmehr um,
wie der Name schon sagt, die dreimalige Hintereinanderanwendung des Data
Encryption Standard mit drei möglichst verschiedenen Schlüsseln (Abbildung 7).
26

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 7: Triple-DES [28]
Da sich das Verschlüsseln beim DES nicht wesentlich vom Entschlüsseln unterscheidet,
ist es üblich, die mittlere der drei Verschlüsselungen des Triple-DES
durch eine Entschlüsselung zu ersetzen [24]. Das hat in Bezug auf die Sicherheit
keinen Einfluss und den Vorteil, dass das Triple-DES Verfahren zu DES kompatibel
ist, wenn alle drei Schlüssel gleich sind K 1 = K 2 = K 3 . Verwendet man
hingegen 3 verschiedene Schüssel K 1 ≠ K 2 ≠ K 3 , so beträgt die Schlüssellänge
3 × 56 = 168 Bit 24 . In der Praxis kommt auch die 2Key3DES Variante zum Einsatz,
bei der erster und letzter Schlüssel gleich sind, also K 1 = K 3 aber K 1 ≠ K 2 . Die
Schlüssellänge beim 2Key3DES ist dann folglich nur noch 2 × 56 = 112 Bit.
Ein naheliegender Nachteil von Triple-DES ist, dass das Verfahren verständlicherweise
dreimal langsamer ist als DES. In Bezug auf die Schlüssellängen gehen
die Meinungen in der Literatur weit auseinander. Während [24] die 112 Bit der
2Key3DES Variante eindeutig für ausreichend hält, ist [5] der Meinung, dass man
mit den 168 Bit des Triple-DES auf längere Sicht nicht auskommen wird.
IDEA Die derzeit wichtigste Alternative zu DES und Triple-DES ist das von Xuejia
Lai und James Massey 1990 entwickelte Verschlüsselungsverfahren IDEA (International
Data Encryption Algorithm). Es verfügt über einen größeren Schlüsselraum
als DES und ermöglicht auch schnellere Implementationen in Hard- und Software.
Der International Data Encryption Algorithm ist eine Blockchiffre, die einen 64 Bit
Eingabeblock mit einem 128 Bit langen Schlüssel verschlüsselt. Genau wie DES
verwendet IDEA relativ einfache Grundoperationen: die Addition modulo 2 16 , die
Multiplikation modulo 2 16 + 1 sowie die exklusiv-oder-Verknüpfung. Um einen 64
Bit Klartextblock zu verschlüsseln, wird dieser zunächst in vier Blöcke zu je 16 Bit
aufgeteilt, die als Eingabe für die erste Runde dienen. Insgesamt gibt es bei IDEA
acht Runden. In jeder Runde werden die vier Teilblöcke untereinander und mit
sechs 16 Bit langen Teilschlüsseln exklusiv-oder-verknüpft, addiert (modulo 2 16 )
und multipliziert (modulo 2 16 + 1). Zwischen den jeweiligen Runden erfolgt eine
Vertauschung der zweiten und dritten Teilblöcke. Zum Abschluss kombiniert eine
24 Die effektive Schlüssellänge beträgt beim Triple-DES aufgrund möglicher meet-in-the-middle
Angriffe nur 108 Bit (vergl.: [5]).
27

Inv.-Nr.:2003-07-02/047/IN96/2253
Ausgabetransformation die vier 16 Bit Blöcke mit vier Teilschlüsseln zum Chiffretext.
Die Entschlüsselung eines IDEA-Chiffreblocks erfolgt mit dem gleichen
Verfahren wie die Verschlüsselung. Der einzige Unterschied ist der, dass die Teilschlüssel
in umgekehrter Reihenfolge und leicht verändert (invertiert) verwendet
werden.
IDEA zählt zweifellos zu den besten symmetrischen Verschlüsselungsverfahren, die
derzeit zur Verfügung stehen. Mit einer Schüssellänge von 128 Bit und einem daraus
resultierenden Schlüsselraum von 2 128 ∼ 10 38 ist ein Angriff auf das Verfahren
über eine vollständige Schlüsselsuche effektiv unmöglich. Eine Softwareimplementation
von IDEA arbeitet durch die geringere Rundenzahl und den Verzicht auf Permutationen
und Substitutionen doppelt so schnell wie eine von DES. Der einzige
Nachteil des Verfahrens ist die Tatsache, dass IDEA patentiert ist und für die kommerzielle
Nutzung Lizenzgebühren erhoben werden. Ein Softwarepaket, das IDEA
einsetzt, ist das weit verbreitet PGP 25 .
AES Im Jahre 1998 lief die letzte Zertifizierungsperiode des Data Encryption
Standard aus und eine neue Zetifizierung fand nicht mehr statt. Schon ein Jahr zuvor
erfolgte eine Ausschreibung mit dem Ziel, einen Nachfolger für DES zu finden,
der Advanced Encryption Standard, kurz AES heißen sollte. Bis Mitte 1998 konnten
Vorschläge für die Funktionsweise des AES bei der NIST eingereicht werden.
Gewünscht wurde eine 128 Bit Blockchiffre, die sich für Hard- und Softwareimplementationen
gleichermaßen eignet und frei von Patentrechten ist. Das Verfahren
sollte unterschiedliche Schlüssellängen von 128, 192 und 256 Bit erlauben. Am 20.
August 1998 veröffentlichte die NIST eine Liste mit 15 AES-Kandidaten, von denen
es die folgenden 5 bis in die Endauswahl schafften:[24]
• Twofish ist ein Verfahren, das unter Leitung von Bruce Schneier entwickelt
wurde und hervorragend dokumentiert ist. Es zeichnet sich durch seine Flexibilität
aus, da es die Einstellung der verschiedensten Parameter erlaubt und
somit auf die Bedürfnisse des Anwenders eingeht.
• MARS ist der Name des offiziellen AES-Kandidaten von IBM.
• Serpent wurde von Ross Anderson, Eli Biham und Lars Knudsen entwickelt
und ist mit seinen 32 Runden ein vergleichsweise langsames Verfahren.
• RC6 besticht durch seine Schnelligkeit sowie Einfachheit und ist eine Entwicklung
von Ron Rivest und seinen Mitarbeitern.
• Rijndael (Aussprache: ”Reindahl”) ist ein Algorithmus, der von den Belgiern
Joan Daelmen und Vincent Rijmen entwickelt wurde. Er ist schnell, einfach
und benötigt nur wenig Speicherplatz.
Am 20. Oktober 2000 gab die NIST schließlich Rijndael als Gewinner bekannt.
Dieser setzte sich gegenüber den anderen Kandidaten aufgrund der etwas besseren
Performance durch.
25 Pretty Good Privacy ist ein frei erhältliches Programm zur Sicherung elekronischer Post. http:
//www.pgpi.org
28

Inv.-Nr.:2003-07-02/047/IN96/2253
Rijndael ist eine vergleichsweise einfache Blockchiffre [24], die Klartexte
auf Basis mehrerer identischer Runden verschlüsselt, wobei in jede Runde ein
anderer Teilschlüssel eingeht. Die Anzahl der Runden ist von der Block- und
Schlüssellänge abhängig, sie liegt zwischen 10 und 14.
Das von der NIST durchgeführte AES-Auswahlverfahren wurde von der Fachwelt
gelobt, insbesondere die Nachvollziehbarkeit und Offenheit.[24]
RSA RSA ist ein Public-Key-Krypto-Verfahren, welches 1978 entwickelt wurde
und nach seinen Erfindern Ron Rivest, Adi Shamir und Leonard Adleman benannt
ist. Die Einsatzgebiete von RSA sind neben der eigentlichen Ver- und Entschlüsselung
von Daten, der sichere Austausch von Kommunikationsschlüsseln für symmetrische
Kryptosysteme, wie beispielsweise IDEA und die Erstellung und Überprüfung
von digitalen Signaturen.
RSA arbeitet wie alle asymmetrischen Kryptosysteme auf Grundlage einer
Falltürfunktion 26 und eines Schlüsselpaars. Die Funktionsweise soll anhand des folgenden,
einfach gehaltenen Beispiels kurz erläutert werden: [24][16]
• Zuerst werden der öffentliche und geheime Schlüssel generiert. Dazu wählt
man sich zufällig zwei große 27 und ungefähr gleich lange Primzahlen p und
q aus. Typische Werte für die Länge sind 1024 oder 2048 Bit. Aus p und q
wird mit Hilfe der Multiplikation der Modulus n berechnet.
p = 3
q = 5
n = p ∗ q = 15
• Als Nächstes wird die Eulersche Totientenfunktion ϕ(n) = (p-1)(q-1) berechnet.
ϕ(n) = (3-1)(5-1) = 8
• Nun erfolgt mit: ed ≡ 1 (mod ϕ(n)) die Berechnung der Werte e und d,
welche Bestandteile des öffentlichen bzw. geheimen Schlüssels sind. Dazu
wird zunächst ein e zufällig gewählt, das zu ϕ(n) Teilerfremd ist und danach
d mittels erweiterten euklidischen Algorithmus berechnet: d = e −1 (mod ϕ(n))
e = 3
d = 3 −1 (mod 8) = 11
26 Einwegfunktionen sind Funktionen, die sich leicht berechnen lassen, deren Umkehrung sich jedoch
nur mit sehr großem Aufwand oder gar nicht berechnen lässt. Existiert für eine solche Einwegfunktion
eine ”versteckte Abkürzung”, also eine Zusatzinformation, mit der die ansonsten schwierige
Umkehrung einfach durchzuführen ist, spricht man von einer Falltürfunktion. [24]
27 Im hier aufgeführten Beispiel werden nur kleine Primzahlen verwendet, um zu einem besseren
Verständnis beizutragen.
29

Inv.-Nr.:2003-07-02/047/IN96/2253
• Das Zahlenpaar e, n (3, 15) bildet den öffentlichen Schlüssel und das Zahlenpaar
d, n (11, 15) den privaten Schlüssel. Die Primzahlen p und q sowie die
Hilfsgröße ϕ(n) werden für die weitere Verfahrensweise nicht mehr benötigt
und können gelöscht werden.
• Will man nun den Klartext m = 12130508 in einen Chiffretext c verschlüsseln,
so muss der Klartext zunächst in Blöcke aufgeteilt werden, die jeweils kleiner
sind als n (12, 13, 05, 08). Auf diese Teilblöcke wird dann die Rechenvorschrift
c = m e mod n angewandt, sodass sich der Chiffretext c = 03 07 05 02
ergibt.
12 3 = 1728; 1728/15 = 115 Rest 03
13 3 = 2197; 2197/15 = 146 Rest 07
05 3 = 125; 125/15 = 8 Rest 05
08 3 = 512; 512/15 = 34 Rest 02
• Die Entschlüsselung arbeitet nach dem gleichen Prinzip mit dem einzigen
Unterschied, dass jetzt der private Schlüssel d zum Einsatz kommt.
m = c d mod n = 12 13 05 08.
03 11 = 177147; 177147/15= 11809 Rest 12
07 11 = 1977326743; 1977326743/15= 131821782 Rest 13
05 11 = 48828125; 48828125/15= 3255208 Rest 05
02 11 = 2048; 2048/15= 136 Rest 08
Aus der Beschreibung des Algorithmus ist ersichtlich, dass beim RSA-Verfahren
zur Ver- und Entschlüsselung Potenzberechnungen auf natürlichen Zahlen angewandt
werden. Es ist also notwendig, den zu verschlüsselnden Klartext zunächst
in eine numerische Repräsentation zu transformieren. Eine Implementierung
des RSA-Verfahrens erfordert effiziente Algorithmen zur Berechnung großer
Primzahlen, zur Berechnung der multiplikativen Inversen sowie zur Berechnung
von Potenzen großer Zahlen. Durch diese zeitlich sehr aufwendigen Berechnungen
sind die Softwareimplementationen von RSA etwa 100 mal langsamer als die von
DES.
Man geht heute davon aus, dass die Sicherheit von RSA im westlichen vom
mathematischen Problem der Faktorisierung von großen Zahlen abhängt. Dies ist
jedoch nur eine Vermutung, die bis zum jetzigen Zeitpunkt noch nicht widerlegt
werden konnte [5]. Gelänge es mit Hilfe eines schnellen Algorithmus zur Faktorisierung
und dem Modulus n, die beiden Primzahlen p und q in einer vertretbaren
Zeit zu ermitteln, würde die Sicherheit des RSA-Verfahrens nicht mehr gegeben
sein, da mit p, q und e der geheime Schlüssel d berechnet werden kann.
Wie für die meisten Krypto-Verfahren gilt auch für RSA: Je länger der Schlüssel,
desto sicherer das Verfahren. [24] Viele Anwendungen, die RSA einsetzen,
arbeiten derzeit noch mit einem 512 Bit langen Modulus, was einer Dezimalzahl
mit 155 Stellen entspricht. Im Jahre 1999 gelang es einer Forschungsgruppe eine
solche Dezimalzahl zwar mit erheblichem Aufwand aber dennoch erfolgreich
30

Inv.-Nr.:2003-07-02/047/IN96/2253
zu faktorisieren. Der Angriff hat gezeigt, dass heutzutage für den Modulus eine
Mindestlänge von 1024 Bit, für sicherheitskritische Anwendungen mindestens
2048 Bit erforderlich ist.
2.5.2 Sichere Übertragungsprotokolle
Protokolle zur Errichtung sicherer Verbindungen zwischen Kommunikationspartnern
lassen sich grob in zwei Klassen von Ansätzen unterteilen. Zum einen
in die Klasse von Protokollen, die eine Ende-zu-Ende Verschlüsselung realisieren
und zum anderen in die Klasse, in der sich Protokolle wiederfinden,
die eine Verbindungsverschlüsselung ermöglichen. Betrachtet man das ISO/OSI-
Schichtenmodell 28 so sind die Ende-zu-Ende Sicherheitsprotokolle auf den höheren
Schichten drei bis sieben angesiedelt, die Sicherheitsprotokolle zur Verbindungsverschlüsselung
hingegen auf den Schichten eins und zwei.
Zwei der bekanntesten Protokolle, die eine gesicherte Ende-zu-Ende Übertragung
ermöglichen, sollen im Folgenden etwas eingehender erörtert werden.
SSL SSL steht für das Secure Socket Layer Protokoll, welches 1995 von der
Firma Netscape entwickelt und mit gleichnamigem Bowser vertrieben wurde.
Hauptziel für die Entwicklung von SSL war es, den Aufbau von sicheren HTTP 29 -
Verbindungen zu ermöglichen. SSL wurde nach seiner initialen Einführung in
vielerlei Hinsicht verbessert und weiterentwickelt und die 1996 fertig gestellte
Version 3.0 wurde zu einem de facto Internet-Standard, nicht zuletzt wegen der
frei verfügbaren Spezifikationen. [16] Ebenfalls 1996 gründete die IETF 30 eine
Arbeitsgruppe mit der Zielstellung, SSL zu einem offiziellen Internet-Standard zu
machen und weiter zu entwickeln. Als Ergebnis entstand das TLS-Protokoll 1.0,
(Transport Layer Security) (vergl.: RFC 2246) eine geringfügige Überarbeitung
von SSL 3.0, weswegen es auch als SSL 3.1 bekannt ist.
SSL ist ein verbindungsorientiertes Protokoll, das auf der Transportschicht
des ISO/OSI-Modells angesiedelt ist und auf jedes zuverlässige Transportprotokoll
aufgesetzt werden kann. Typischerweise findet TCP 31 als zuverlässiges Transportprotokoll
Verwendung. Praktisch wird daher eine vollständige Unabhängigkeit von
Applikationen ermöglicht, dass heißt mit SSL kann im Grunde jedes Anwendungsprotokoll,
welches TCP benutzt, sicher gemacht werden. Die Hauptaufgaben von
SSL sind die Authentifikation der Kommunikationspartner unter Verwendung von
asymmetrischen Verschlüsselungsverfahren und digitalen Zertifikaten 32 , die vertrauliche
Datenübertragung unter Nutzung eines gemeinsamen Sitzungs-Schlüssels
und schließlich auch die Sicherstellung der Integrität der transportierten Daten
28 Das ISO/OSI-Schichtenmodel ist ein von der internationalen Standardsierungsorganisation ISO
genormtes Modell für das Zusammenspiel von Protokollen. Eine ausführlich Beschreibung findet
man in [42], ab Seite 45.
29 HTTP: Hyper Text Transfer Protocol
30 IETF: Internet Engineering Task Force
31 TCP: Transmission Control Protocol
32 Digitale Zertifikate sind digitale Dokumente, die eine bestimmte Identität einer Person oder
eines Servers/Clients bezeugen.
31

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 8: Die Teilschichten des SSL-Protokolls im TCP/IP Modell [42][24]
unter Nutzung von Message Authentication Codes [5].
Das SSL-Protokoll legt sich nicht auf die Anwendung eines bestimmten kryptographischen
Verfahrens oder einer bestimmten Hashfunktion fest, vielmehr wird
ermöglicht, dass sich Client und Server pro Verbindung auf geeignete Verfahren
und Funktionen verständigen. Die Spezifikation von TLS erlaubt beispielsweise
den Einsatz von RC2, RC4, DES, 3DES und IDEA als symmetrische Verschlüsselungsverfahren.
Für den Schlüsselaustausch können RSA sowie Diffie-Hellman 33
verwendet werden und als kryptographische Hashfunktionen SHA oder MD5. Das
SSL-Protokoll gliedert sich intern, wie Abbildung 8 zeigt, in fünf Teilprotokolle,
die zwei übereinander liegende Schichten bilden. Besondere Aufmerksamkeit ist
dem Handshake-Protokoll zu widmen, dessen Aufgabe es ist, die zu verwendenden
kryptographischen Verfahren und Parameter festzulegen. Es besteht aus einer Folge
von Nachrichten, die sich Client und Server einander zusenden. Dabei geht man
davon aus, dass der Client der Initiator der Kommunikation ist. Der genaue Ablauf
des Handshake-Protokolls hängt von verschiedenen Optionen ab. Vereinfacht
dargestellt, läuft das Handshake-Protokoll typischerweise folgendermaßen ab: [24]
1. Der Client beginnt den Handshake mit dem Senden einer Client-Hello-
Nachricht, in der er anzeigt, dass er SSL einsetzen möchte. Die Nachricht
enthält eine Liste der unterstützten Krypto-Verfahren (kryptographische Hashfunktionen,
symmetrische- und asymmetrische Verschlüsselungsverfahren)
sowie eine Zufallszahl, die später zu Berechnung des Sitzungsschlüssels
benötigt wird.
2. Der Server antwortet auf die Client-Hello-Nachricht seinerseits mit einer
33 Das 1976 von von W. Diffie und M.E. Hellman vorgestellte Verfahren ermöglicht es zwei Kommunikationspartnern,
ein gemeinsames Geheimnis (i.d.R. einen Schlüssel für ein nachfolgendes
symmetrisches Verschlüsselungsverfahren) über ein unsicheres Medium zu vereinbaren, ohne dass
ein mithörender Angreifer an das Geheimnis gelangen könnte.
32

Inv.-Nr.:2003-07-02/047/IN96/2253
Server-Hello-Nachricht, in der er angibt, welche Verfahren er sich aus der
Liste von Vorschlägen (sogenannte Cipher-Suites) des Clients ausgesucht hat
und nun verwenden möchte. Desweiteren enthält auch diese Nachricht eine
Zufallszahl und darüber hinaus ein digitales Zertifikat des Servers.
3. Der Client generiert nun das sogenannte Pre-Master-Secret, welches zusammen
mit den Zufallszahlen die Grundlage für die Berechnung des
Master-Secret bildet. Wird beispielsweise das RSA-Verfahren für den
Schlüsselaustausch angewandt, so verschlüsselt der Client das Pre-Master-
Secret mit dem aus dem Server-Zertifikat stammenden öffentlichen Schlüssel
des Servers und sendet es ihm anschließend zu.
Nun sind beide Kommunikationspartner in der Lage, das geheime Master-
Secret zu berechnen (vergl.: [44] Seite 88f), welches in der SSL-Record-
Protokoll-Schicht zur Verschlüsselung und zur Integritätskontrolle mit
schlüsselabhängiger Hashfunktion eingesetzt wird.
4. Zum Abschluss des Handshakes wird eine Finish Nachricht ausgetauscht, die
bereits durch die ausgehandelten kryptograhischen Verfahren und Parameter
geschützt ist. Sie enthält eine Prüfsumme über alle gesendeten Handshake-
Daten und soll sicherstellen, dass Client und Server dieselben Handshake-
Daten ”gesehen” haben und keine Man-In-The-Middle-Attacke 34 irgendwelche
Daten verändert hat.
Nach dem Abarbeiten des Handshake-Protokolls teilt das ChangeCipherSpec-
Protokoll der darunter liegenden Record-Schicht mit, welche kryptograhischen Verfahren
und Parameter vereinbart wurden und ab jetzt verwendet werden sollen. Das
Teilprotokoll kommt aber auch dann zum Einsatz, wenn sich Verfahren und Parameter
ändern.
Die Aufgabe des Alert-Protokolls ist das Versenden von Fehlermeldungen an die
oberen Schichten, wenn der Datenaustausch nicht planmäßig läuft.
Im Gegensatz zu den anderen Protokollen, die nur zur Initialisierung, zum Verfahrenswechsel
und bei Störungen abgearbeitet werden und daher den Ausnahmefall
bilden, ist das ApplicationData-Protokoll dasjenige, welches im Regelfall in der
oberen Schicht im Einsatz ist. Es ist für die Durchreichung der oben ankommenden
Anwendungsdaten an das Record-Protokoll zuständig.
Die Abbildung 9 zeigt die Arbeitsweise des fünften und letzten Teilprotokolls.
Das SSL-Record-Protokoll hat die Aufgabe, auf die von oben übergebenen Daten
ein schlüsselabhängiges Hashverfahren anzuwenden und diese Daten samt Hashwert
symmetrisch zu verschlüsseln. Dazu werden die Daten zunächst in Blöcke
sinnvoller Größe zerlegt und diese anschließend optional komprimiert. Anschließend
erfolgt die Anwendung der Hashfunktion auf den Datenblock, die ihrerseits
einen Hashwert zurückliefert. Schließlich werden Datenblock und Hashwert
gemeinsam verschlüsselt und dem Kommunikationspartner über die zugeordne-
34 Der Angreifer schaltet sich in die Kommunikation zwischen zwei Kommunikationspartnern ein
und versucht, die ausgetauschten Nachrichten zu seinen Gunsten zu verändern, um möglicherweise
weiterführende Angriffe durchzuführen.
33

Inv.-Nr.:2003-07-02/047/IN96/2253
te TCP-Verbindung übermittelt. Durch eine Umkehrung der Transformationen auf
Empfängerseite wird der ursprüngliche Datenblock wiederhergestellt. [24][4]
Abbildung 9: Das SSL-Record-Protokoll [4]
Die Sicherheit des gesamten SSL-Protokolls hängt im wesentlichen von der Sicherheit
des Handshake-Protokolls ab. Gelänge es einem Angreifer, dafür zu sorgen,
dass die Kommunikationspartner schwache Verschlüsselungsverfahren aushandeln,
so könnte er anschließend mit großer Aussicht auf Erfolg versuchen, den berechneten
Kommunikationsschlüssel zu brechen. Für das Gelingen eines solchen Angriffs
wäre jedoch eine Modifikation des Handshake-Nachrichten erforderlich, welche
wiederum dazu führen würde, dass Client und Server unterschiedliche Hashwerte
für ihre jeweiligen Finish-Nachrichten berechnen würden. Diese Tatsache hätte
dann ein wechselseitiges Ablehnen der Finish-Nachrichten und das erfolglose Terminieren
des Verbindungsaufbaus zur Folge. [5]
Die gute Integrationsfähigkeit von SSL ist unter anderem ein Grund dafür, dass es
wohl gegenwärtig das meistverwendetste Verschlüsselungsprotokoll im Internet ist.
Für den Einsatz von SSL sind keine (oder nur geringe) Änderungen auf Anwendungsebene
nötig. Von Nachteil ist jedoch, dass es nur über TCP, nicht aber über
UDP 35 verwendbar ist. Somit lassen sich viele Dienste wie DNS 36 oder auch die
Internet-Telefonie mit SSL nicht absichern. [24]
IPsec Das in der Vermittlungsschicht (Schicht 3 des ISO/OSI-Modells) angesiedelte
und in seiner Version 4 derzeit weit verbreitete Internetprotokoll IPv4 stellt
von sich aus keinerlei Sicherheitsdienste wie Authentizität, Vertraulichkeit oder
Integrität zur Verfügung. IPsec (IP Security Protocol) ist eine Sicherheitsarchitektur
für IPv4 und dessen Nachfolger IPv6, die dieses Manko beseitigen soll. Innerhalb
der IETF entwickelt und standardisiert, ist IPsec fester Bestandteil der Version 6 des
Internetprotokolls (IPv6), die in den kommenden Jahren das jetzige IPv4 ersetzen
35 UDP: User Datagram Protocol
36 DNS: Domain Name Service
34

Inv.-Nr.:2003-07-02/047/IN96/2253
soll. Entsprechend der Einordnung in die Vermittlungsschicht können mittels
IPsec sichere Kommunikationskanäle zwischen Endsystemen, zwischen Gateways
(z.B. Router) und Endsystemen sowie zwischen Gateways aufgebaut werden.
Das Protokoll legt einige kryptogaphische Verfahren fest, die jedes IPsec-System
anbieten muss, um eine gewisse Interoperabilität zwischen verschiedenen Implementierungen
zu ermöglichen. Die eigentlichen Sicherheitsdienste werden von
zwei Bestandteilen der IPsec Spezifikation erbracht, die unabhängig voneinander
nutzbar sind. [5] [24]
Der erste Bestandteil, der Authentication Header (AH) ist im RFC 37 2402
beschrieben und hat die Aufgabe, die Authentizität und die Integrität eines verbindungslos
übermittelten Paketes sowie optional einen Schutz vor Wiedereinspielung
zu gewährleisten. AH definiert dazu ein zusätzliches Header-Feld, in dem unter
anderem das Resultat einer schlüsselabhängigen Hashfunktion und eine Sequenznummer
übermittelt wird. Die Hashfunktion wird auf die Nutzlast und auf nicht
veränderliche Header-Felder des IP-Pakets angewandt und ist somit der Garant
für die Authentizität und Integrität. In der RFC-Spezifikation ist vorgeschrieben,
dass mindestens die beiden Hash-Verfahren HMAC 38 -MD5 und HMAC-SHA1 von
jedem IPsec-System anzubieten sind. Die optionale Sequenznummer, die für jedes
gesendete Paket monoton erhöht wird, soll Replay-Attacken verhindern.
Das Encapsulating Security Payload (ESP), der zweite Bestandteil von IPsec,
ist im RFC 2406 beschrieben. Es umfasst neben den Diensten, die bereits für den
Authentication Header angegeben wurden zusätzlich noch die Fähigkeit, Daten verschlüsselt
zu transportieren. ESP fügt genau wie AH den bisherigen Header-Feldern
weitere hinzu, diese erlauben es, dem Kommunikationspartner das eingehende
Paket einem bestimmten Kontext zuzuordnen. Eine ESP-Implementierung muss
laut RFC 2406 mindestens das Verschlüsselungsverfahren DES im CBC 39 -Modus
sowie die schlüsselabhängigen Hashfunktionen HMAC-MD5 und HMAC-SHA1
enthalten.
IPsec kann mit seinen zentralen Bestandteilen AH und ESP in den zwei Modi
Transport und Tunnel betrieben werden. Am Beispiel des Encapsulating Security
Payloads sollen beide Modi kurz erläutert werden:
• Im Transportmodus werden ausschließlich die Nutzdaten des IP-Paketes authentifiziert
und verschlüsselt. Alle anderen Teile der Nachricht (also im Prinzip
der IP-Header) bleiben unverändert.
• Im Tunnelmodus wird dagegen ein gesamtes IP-Paket vor der Übertragung
authentifiziert sowie verschlüsselt und anschließend in den Nutzdatenanteil
eines weiteren Paketes gepackt. Dadurch, dass die Header des ursprünglichen
37 RFC: Request for Comment – RFCs sind Schriftstücke, mit denen die IETF Spezifikationen,
Vorschläge und Informationen veröffentlicht.
38 HMAC: Keyed-Hashing for Message Authentication (vergl.: RFC 2104)
39 CBC: Cipher Block Chaining – Blockchiffriermodus, der den vorangehenden Chiffretextblock
mit dem aktuell zu verschlüsselnden Klartextblock kombiniert.
35

Inv.-Nr.:2003-07-02/047/IN96/2253
IP-Pakets nicht mehr lesbar sind, kann beispielsweise der Tunnelmodus dazu
genutzt werden, um eine transparente Verbindung zwischen zu schützenden
Endsystemen oder Teilnetzten über Sicherheits-Gateways aufzubauen. Der
Tunnelmodus ist also insbesondere im Zusammenhang mit virtuellen privaten
Netzen interessant.
Die Abbildung 10 verdeutlicht noch einmal graphisch den Einsatz von AH und
ESP im Transport- und Tunnelmodus.
Abbildung 10: Anwendung von IPsec auf IP-Pakete [14]
Umfang und Eigenschaften einer aktuellen IPsec-Verbindung werden mit dem
Konzept der Security Association (SA) beschrieben. Eine SA stellt im Prinzip
eine Art Abkommen zwischen den Kommunikationspartnern dar und enthält
Informationen, wie das zu verwendende Authentifikations- und Verschlüsselungsverfahren,
die erforderlichen Schlüssel (AH und ESP), den potentiell benötigten
Intitalisierungsvektor (nur für ESP) sowie die Lebensdauer der Schlüssel bzw. der
ganzen SA. [5] Die SAs sind bei den jeweiligen Endsystemen in einer Security
Association Database (SAD) zusammengefasst. Für jedes ankommende und
abgehende IP-Paket wird in der SAD eine zugehörige SA gesucht und die dort
beschriebenen Verfahren, Regeln und Parameter angewandt. Die Identifikation
einer SA erfolgt über den Security Parameter Index (SPI) zusammen mit der
IP-Adresse des Kommunikationsendpunktes. Beide Informationen sind aus dem
IPsec-Header des IP-Pakets zu entnehmen.
Neben der SAD definiert die IPsec-Spezifikation noch eine weitere Datenbank.
In der Security Policy Database (SPD) ist die Sicherheitspolitik eines IPsec
Endsystems oder Gateways beschrieben. Beispielsweise kann der Administrator
36

Inv.-Nr.:2003-07-02/047/IN96/2253
eines Systems hier festlegen, für welche Verbindungen IPsec verwendet werden
muss und für welche nicht.
Das IPsec-Protokoll ist für sich genommen nicht verhandlungsfähig und setzt
voraus, dass die Kommunikationspartner über einen gemeinsamen geheimen
Schlüssel verfügen. IPsec trifft keine Festlegungen darüber, wie eine Verbindung
tatsächlich aufgebaut werden soll oder wie ein dynamischer Schlüsselaustausch zu
erfolgen hat. Zur Erfüllung dieser Aufgaben wird ein weiteres Protokoll benötigt.
Das von der IETF hierfür vorgesehene hat den Namen Internet Key Exchange
(IKE). Das IKE-Protokoll ist im RFC 2409 beschrieben und kommt im Zusammenhang
mit IPsec immer dann zum Einsatz, wenn für ein abzusendendes Datenpaket
keine passende SA in der Security Association Database des Senders gefunden
wird und gleichzeitig im SPD-Eintrag für die Verbindung die Anwendung von
IPsec gefordert wird. Mittels IKE tauschen die Kommunikationspartner zunächst
Informationen zur Berechnung eines geheimen Schlüssels aus. Die Schlüsselberechnung
erfolgt dann nach dem Diffie-Hellman-Verfahren. Nach einer erfolgreich
abgelaufenen wechselseitigen Authentifikation und dem verschlüsselten Austausch
von Sicherheitsattributen können beide Partner die Security Association erzeugen.
IPsec ist in der vorliegenden Spezifikation in vielen Varianten, Modi und Typen
einsetzbar. Was aber auf der einen Seite eine durchaus gewünschte Flexibilität
bringt, erfordert auf der anderen Seite größte Sorgfalt bei der Implementierung
und Konfiguration von IPsec-Systemen. Besonders die vollständige, konsistente
und korrekte Formulierung der Einträge in der SPD und SAD ist keine einfache
Aufgabe. [5] In [8] untersuchen Niels Ferguson and Bruce Schneier die kryptographischen
Eigenschaften von IPsec und lassen kaum einen Zweifel daran, dass sie
nur wenig von IPsec halten. Wesentliche Kritikpunkte der beiden Autoren sind die
Komplexität, die schlechte Dokumentation und der Variantenreichtum von IPsec
und IKE. Auf Authentifizierungsheader und Transportmodus könne im Grunde
vollständig verzichtet werden, da diese jeweils durch ESP oder Tunnelmodus
abgedeckt würden.
37

Inv.-Nr.:2003-07-02/047/IN96/2253
2.6 Das DPAC Informationssystem
Das DPAC Informationssystem der Firma Häcker-Automation, welches zur Zeit
noch Gegenstand der Entwicklung ist, soll in naher Zukunft zu einer zentralen
Anlaufstelle zur Informationsgewinnung für Mitarbeiter und Kunden werden. Die
Grundlage des Informationssystems bildet die Database for Process Administration
and Controlling, die alle wichtigen Daten vom einzelnen Kundenkontakt bis
hin zum Lagerbestand erfasst. Firmenintern fasst man Entwicklungs-, Produktionsund
Lebenszyklus eines Produktes als eine Art Kette von Einzelprozessen auf. Jeder
dieser Prozesse wird zur eindeutigen Identifizierung in ein sogenanntes Sachgebiet
eingeordnet und erhält eine eigene Sachgebietsnummer. Zielstellung des DPAC Informationssystem
ist es, Informationen und Daten über und aus den einzelnen Prozessen
zentral zu erfassen, anhand der Sachgebietsnummer projektbezogen einzuordnen
und berechtigten Personen zur Verfügung zu stellen. Durch diese zentrale
Informationsgewinnung und Verteilung soll eine merkliche Entlastung der Mitarbeiter,
eine bessere Prozesssteuerung, besseres Kostenmanagement, eine Erhöhung
der Effizienz und letztendlich eine gesteigerte Produktqualität ermöglicht werden.
Die nachfolgende Liste gibt einen auszugartigen Überblick über den Anforderungsund
Aufgabenkatalog des DPAC Informationssystems:
• Der Systemzugriff für autorisierte Mitarbeiter ist direkt vom jeweiligen Arbeitsplatz
aus möglich. Von hier aus können Daten erfasst und abgerufen werden.
• Ein besonders geschützter Zugang erlaubt berechtigten Außendienstmitarbeitern
den externen Zugriff auf das System, primär, um Daten abzufragen, dennoch
weitestgehend ohne Funktionsverlust gegenüber der firmenintern verwendeten
Zugriffslösung.
• Die Integration einer speziellen Zugriffsmöglichkeit ermöglicht es Kunden
der Firma, auftragsbezogene und für sie relevante Daten abzufragen, den
Entwicklungs- und Produktionsprozess zu verfolgen (workflow) und sich
zeitnah über den aktuellen Stand des Auftrags zu informieren.
• Die graphische Benutzeroberfläche (engl. GUI: graphical user interface), die
den Zugang zum System realisiert und die Schnittstelle zwischen Benutzer
und System bildet, ist so zu implementieren, dass sie auf möglichst vielen
verschiedenen Rechnerplattformen und ohne größeren Installationsaufwand
eingesetzt werden kann. Diese Client-Software (Frontend) wird den Benutzern
an einer zentralen Stelle (Server) zur Verfügung gestellt.
• Notwendige Updates der Client-Software sollten weitestgehend automatisch
erfolgen.
• Sich zyklisch wiederholende Prozesse arbeitet das System selbsttätig ab, um
die Mitarbeiter zu entlasten.
• Im System erfolgt eine automatisierte Einordnung von Projekten in Sachgebiete
sowie eine konsistente Zuweisung und Verwaltung von Sachgebietsnummern
nach festgelegten Regeln.
38

Inv.-Nr.:2003-07-02/047/IN96/2253
3 Mobiler Code
Die Anforderungen des DPAC-Informationssystems an die Client-Software sind
vielfältig. Mobiler Code stellt insbesondere im Bezug auf die Verteilung, Plattformunabhängigkeit
und Updatefähigkeit der Software eine elegante Lösung dar.
In den nun folgenden Abschnitten sollen Konzepte erörtert werden, wie mobiler
Code im DPAC-Informationssystem Verwendung finden kann und welche Sicherheitsprobleme
in diesem Kontext entstehen können. Eine besondere Rolle soll dabei
die plattformunabhängige Programmiersprache JAVA von Sun Microsystems spielen.
Sie bietet eine Vielzahl von Sicherheitsmechanismen und stellt auf Basis ihrer
virtuellen Maschine eine Möglichkeit dar, Programmcode auf unterschiedlicher
Hardware ausführbar zu machen. Diese Tatsache der Hardwareunabhängigkeit (im
übrigen wird auch eine Unabhängigkeit vom jeweilig eingesetzten Betriebssystem
erreicht) ist von entscheidender Wichtigkeit für die breite Akzeptanz von mobilem
Code.
[5] definiert mobilen Code als einen Begriff, unter dem sich alle Programme
zusammenfassen lassen, deren Programmcode auf einem entfernten, potentiell
nicht vertrauenswürdigen Rechner generiert wurde und die auf Gastrechnern (engl.
hosts) ausgeführt werden. [22] fügt noch ergänzend hinzu, dass mobiler Code keine
variablen Daten beinhaltet und nach jeder Übertragung auf ein anderes System
im selben Zustand startet. Bei mobilem Code handelt es sich also ganz allgemein
gesagt um Programmcode, der auf einem Server zur Verfügung gestellt, über ein
Transportmedium übertragen und bei einem Client zur Anwendung kommt. Damit
unterscheidet sich das zugrundeliegende Ausführungsmodell vom herkömmlichen
Client-Server Modell zur Durchführung von verteilten Berechnungen, bei dem
Nachrichten, also Daten, über ein Medium übertragen werden. Der ausführbare Code
selber bleibt jedoch permanent auf dem Rechner, auf dem er installiert wurde. [5]
Bekannteste Beispiele für mobilen Code sind Java-Applets, ActiveX-Controls
von Microsoft oder auch mobile Agenten 40 , die mit speziellen Agentensprachen
wie Telescript programmiert werden.
3.1 Sicherheitsbedrohungen
Lässt man einmal Viren, Würmer und Trojanische Pferde, die genau genommen
auch eine Art von mobilem Code sind, außen vor und betrachtet nur solchen Programmcode,
der nicht vordringlich zum Zwecke eines Angriffs auf einen entfernten
Rechner entwickelt wurde, so bleibt dennoch eine nicht unerhebliche Menge von
Bedrohungen für die Sicherheit übrig, die an dieser Stelle besprochen werden sollen.
40 Ein mobiler Agent ist eine spezielle Ausprägung von mobilen Code, der auch zustandsbehaftet
sein kann. Er wandert von Rechnerknoten zu Rechnerknoten und bietet Dienste an.
39

Inv.-Nr.:2003-07-02/047/IN96/2253
Zur Verdeutlichung der Sichereitsproblematik im Zusammenhang mit dem Einsatz
von mobilem Code sollte man sich die folgenden Fragen vor Augen führen:
• Welche Bedrohungen existierenden für mobilen Code?
• Kann mobiler Code selbst zu einer Bedrohung für seinen Gastrechner und
damit auch für den Benutzer werden?
• Welche Möglichkeiten gibt es, um mobilen Code vor Angriffen zu schützen?
• Wie kann der Gastrechner geschützt werden, auf dem mobiler Code ausgeführt
wird?
Aus den ersten beiden Fragen lassen sich im wesentlichen drei Klassen von Sicherheitsbedrohungen
ableiten. [5] Sie betreffen sowohl den mobilen Code selbst
als auch die Ausführungsumgebung des Gastrechners. In die erste Klasse fallen die
vielfältigen Bedrohungen, denen der mobile Code ausgesetzt ist, wenn er über ein
unsicheres Transportmedium wie beispielsweise das Internet übertragen wird. Wird
er auf einem Gastrechner zur Ausführung gebracht, so ist der mobile Code Bedrohungen
seitens dieses Rechners ausgesetzt. In die dritte Klasse lassen sich Bedrohungen
einordnen, die der mobile Code möglicherweise selbst birgt und denen sich
der Gastrechner bei der Ausführung des Codes aussetzt. Hier sind beispielsweise
unautorisierte Zugriffe auf rechnereigene Ressourcen zu nennen. Abbildung 11
gibt noch einmal einen visuellen Überblick über die drei Bedrohungsbereiche, die
im Folgenden noch etwas genauer untersucht werden sollen.
Abbildung 11: Bedrohungsszenarien für mobilen Code [5]
3.1.1 Bedrohungen für den mobilen Code
Potentiellen passiven Angriffen setzt sich der mobile Code während seiner
Ausführung aber auch während des Transports über ein unsicheres Medium aus.
Denkbar ist ein Angriff, der darauf abzielt, sensible lokale Daten des Codes auszuspähen,
aber auch das Erstellen von Bewegungsprofilen von migrierendem Code
könnte Ziel eines Angreifers sein. Gerade in Bezug auf Mobile Agenten, die sich
selbständig von Rechner zu Rechner bewegen, könnte es möglicherweise für einen
40

Inv.-Nr.:2003-07-02/047/IN96/2253
Angreifer von Interesse sein, welche Rechner in einem Netzwerk die Dienste der
Agenten in Anspruch nehmen.
Aktive Angriffe, deren Ziel durch die Modifikation des mobilen Codes erreicht werden
soll, betreffen ebenfalls sowohl den Bereich des Transfers als auch den Bereich
der Ausführung auf einem Gastrechner. Ein Angreifer könnte beispielsweise versuchen,
durch gezielte Veränderung des mobilen Codes einen Virus oder ein Trojanisches
Pferd zu integrieren. Bei einem mobilen Agenten könnte er den vorgesehenen
Ausführungspfad so verändern, dass der Agent auf einen anderen Rechner umgelenkt
wird. [5]
3.1.2 Bedrohungen für den Gastrechner
Neben den beschriebenen Attacken auf den mobilen Code stellt dieser selbst auch
eine erhebliche Bedrohung für seinen Gastrechner dar. Auf Seiten des Gastrechners
lassen sich Angriffe ebenso in passive und aktive aufteilen. Durch passive Angriffe,
wie das Lesen von Dateien können Informationen über das Gastsystem gewonnen
und über eine Netzwerkverbinung an einen entfernten Rechner geschickt werden.
Klassisches Beispiel hierfür ist das Auslesen einer Passwortdatei, um einen gezielten
Passwort-Crackangriff vorzubereiten.
Mittels aktiver Angriffe kann der mobile Code versuchen, unautorisiert Zugriff auf
Dateien oder Ressourcen des Gastsystems zu erlangen, um dort Modifikationen durzuführen.
Mobiler Code könnte auch dazu eingesetzt werden, um die Verfügbarkeit
des Gastrechners zu beeinträchtigen. Bei solchen Denial-of-Service-Attacken monopolisiert
der Code dann bei der Ausführung die CPU, sodass andere Anwendungen
blockiert werden.
Als einen Maskierungsangriff bezeichnet man eine Attacke gegen einen Gastrechner,
bei der der mobile Code eine falsche Identität oder Funktionalität vortäuscht.
Auch Maßnahmen wie das Signieren des Codes, um seinen Ursprung nachzuweisen
geben keine Auskunft über die Funktionsweise, dass heißt auch signierter Code
kann bedrohliche Funktionen beinhalten. [5]
3.2 Sicherheitsmaßnahmen
3.2.1 Schutz des mobilen Codes
Der Schutz des mobilen Codes kann auf der Transportstrecke relativ einfach durch
den Einsatz von Verschlüsselungstechniken realisiert werden. Die jedoch meist
interpretative Ausführung des Codes macht es notwendig, dass die Daten der
Ausfühungsumgebung in einer unverschlüsselten Form vorliegen. Der Schutz des
Programmcodes ist somit durch kryptographische Mittel, wenn überhaupt nur beim
Transfer zu gewährleisten. Eine Lösungsmöglichkeit, den mobilen Code vor dem
Gastrechner zu schützen, besteht darin, ihn nur an Systeme zu versenden, die als
vertrauenswürdig eingestuft sind und ihre Identität korrekt nachgewiesen haben.
Von Nachteil ist jedoch, dass dieser Lösungsansatzes eine starke Einschränkung der
Flexibilität zur Folge hat, da die vertrauenswürdigen Partner von vornherein festgelegt
werden müssen. Für das Problem des Schutzes von mobilen Code bei der
41

Inv.-Nr.:2003-07-02/047/IN96/2253
Ausführung auf einem vertrauensunwürdigen Gastrechner gibt es bis heute noch
keine befriedigende Lösung, es ist immer noch Gegenstand der Forschung. [5]
3.2.2 Schutz des Gastrechners
Die beste Art, einen Gastrechner vor Bedrohungen zu schützen, die mobiler Code
birgt, ist es, Download und Ausführung gänzlich zu unterbinden. Da diese doch sehr
radikale Lösung nur in den seltensten Fällen wünschenswert ist, müssen Verfahren
zum Einsatz kommen, die ein für das Gastsystem sicheres Ausführen von mobilem
Code ermöglichen.
Eine sehr restriktive Vorgehensweise ist die sogenannte Sandbox (Sandkasten), wie
sie beispielsweise in Java realisiert ist. Ihr Prinzip beruht ganz allgemein gesagt
auf der Beschränkung von Zugriffsrechten. Sie definiert die Ausführungsumgebung
des Codes als einen isolierten Speicherbereich, innerhalb dessen der Code freien
Zugriff besitzt. Auf Systemressourcen außerhalb dieses Bereichs ist der Zugriff dagegen
kaum oder nur unter strengen Kontrollen möglich.
Die von Microsoft empfohlene und eingesetzte Authenticode-Technik dient zur eindeutigen
Identifizierung von mobilem Code und soll dadurch einen gewissen Schutz
vor bedrohlichen ActiveX-Controls gewährleisten. Dass dieser Schutz jedoch nur
sehr schwach ist, liegt an der Tatsache, dass lediglich der Ursprung der mobilen
Einheit nachgewiesen und überprüft werden kann, nicht aber die Vertrauenswürdigkeit
des Codes und die beinhaltete Funktionalität. In [5] wird diese Vorgehensweise
sogar als kontraproduktiv bezeichnet, da sie unerfahrene Benutzer in einer falschen
Sicherheit wiegt.
Die Technik des Proof-Carrying Codes (PCC) ist das dritte Verfahren, das an dieser
Stelle kurz vorgestellt werden soll. Die Grundidee von PCC ist, dass ein Gastrechner
verifizieren kann, ob mobiler Code aus einer nicht vertrauenswürdigen Quelle
einer vorher definierten Sicherheitspolitik genügt. Der Gastrechner legt dazu eine
Sicherheitsstrategie fest und veröffentlicht diese. Der ausführbare, mobile Code
wird vom Autor mit einem formalen Sicherheitsbeweis (safety proof) ausgestattet,
der beweisen soll, dass der Code die spezifizierte Sicherheitsstrategie nicht verletzt.
Anhand dieses Sicherheisbeweises kann dann der Gastrechner vor der Ausführung
des Programmcodes überprüfen, ob eine Sicherheitsstrategie-Verletzung auftreten
wird oder nicht. Eine PCC Implementierung besteht im Regelfall aus den folgenden
vier Komponenten: [2][32]
• einer formalen Spezifikationssprache, um die Sicherheitsstrategie festzulegen
• einer formalen Semantik, meist in Form einer Logik, genutzt vom nicht vertrauenswürdigen
Code
• einer Sprache, um die formalen Beweise zu repräsentieren
• einem Algorithmus, um die Beweise schnell und leicht zu validieren
Ein Hauptvorteil von PCC in der Umgebung von mobilem Code besteht darin, dass
die gesamte Beweislast hinsichtlich der Sicherheit des Codes beim Autor liegt. Dies
ist durchaus sinnvoll, da ja der Autor seinen Code viel besser kennt als der Nutzer.
42

Inv.-Nr.:2003-07-02/047/IN96/2253
Dem Gastrechner kommt dann nur noch die Aufgabe einer einfachen Beweisüberprüfung
zu. Aufwendige zur Laufzeit durchzuführende Kontrollen des Codes sind
nicht notwendig. Das größte Hindernis für den Einsatz der PCC-Technik ist die
Tatsache, dass die Erstellung von Beweisen, die die Sicherheit des mobilen Codes
betreffen, keinesfalls eine triviale Aufgabe ist. Nur in den seltensten Fällen ist
es möglich, einen solchen Beweis automatisch zu erzeugen. Auf eine breite Akzeptanz
wird diese Technik erst dann stoßen, wenn eine einfach zu handhabende
Entwicklungsumgebung für mobilen Code zur Verfügung steht, die es erlaubt, PCC
zu integrieren. [5][32]
3.3 Die Programmiersprache Java
Java wurde 1991 im Rahmen eines Forschungsprojektes in einem kleinen Team unter
der Leitung von James Gosling bei der Firma Sun entwickelt und hieß zunächst
Oak (Object Application Kernel). Ursprüngliches Ziel der Entwickler war es, eine
Steuerungsprogrammiersprache für elektronische Haushaltsgeräte zu schaffen. Erst
vier Jahre später 1995 wurde die auf andere Systeme leicht portierbare Sprache für
den Einsatz im Internet entdeckt und veröffentlicht. Nicht zuletzt wegen der engen
Verwandschaft mit der Programmiersprache C und C++ vergrößerte sich die
Java-Nutzergemeinde in den letzten 8 Jahren stetig. Die Sprache erlebt eine rasante
Verbreitung nicht nur in Forschung und Lehre sondern auch in vielen kommerziellen
Bereichen. Die Firma Sun beschreibt Java als eine einfache, objektorientierte,
verteilte, interpretierte, robuste, sichere, architektur-neutrale, portable, schnelle,
nebenläufige und dynamische Sprache [22].
Mit Java ist es gelungen, eine Programmiersprache zu konzipieren, die sich besonders
gut für den Einsatz in heterogenen, vernetzten Systemen eignet. Entscheidend
dafür ist die Portabilität von Java-Programmen, die auf der Plattformunabhängigkeit
des durch den Java-Übersetzer erzeugten maschinenunabhängigen Bytecodes
basiert. [5] Bei diesem ”neutralen” Bytecode handelt es sich nicht um prozessorabhängige
Maschinenbefehle sondern vielmehr um eine Definition plattformübergreifender
Anweisungen, die nur geringe Übereinstimmungen zu herkömmlichen
Assembler-Befehlen aufweisen.
Ein Java-Programm, welches in Bytecode übersetzt wurde, ist, isoliert gesehen,
nicht lauffähig. Da es aber keinen Sinn machen würde, Programme zu schreiben
und zu übersetzen, die später nicht ausführbar sind, liegt es auf der Hand, dass
Mechanismen existieren müssen, mit deren Hilfe Bytecode auf einem Rechner ausgeführt
werden kann. Der Just in Time Compiler (JIT) ist ein solcher Mechanismus.
Er übersetzt den Bytecode in den jeweils benötigten Maschinencode des Rechners,
auf dem das Java-Programm ausgeführt werden soll. Einen anderen Weg geht die
Java Virtual Machine (JVM). Ihr Bytecode-Interpreter führt den Bytecode wie der
Name schon sagt interpretativ aus. Die Java Virtual Machine ist praktisch ein virtueller
Rechner, der eine Schnittstelle zwischen Bytecode und realem Rechner bildet
und den Java-Programmen eine einheitliche Ausführungsumgebung zur Verfügung
stellt. Spätestens hier, bei der Ausführung des Java-Bytecodes, verliert das Konzept
von Java allerdings seine Unabhängigkeit, da weder JIT noch JVM plattformunabhängig
sind.
43

Inv.-Nr.:2003-07-02/047/IN96/2253
Alle benötigten Komponenten für die Ausführung und Entwicklung von Java-
Programmen bietet die Firma Sun auf ihrer Java-Homepage (http://java.
sun.com) zum Download an. Aus dem ursprünglich veröffentlichten Java Development
Kit (JDK) in Version 1.0 ist mittlerweile das Software Development
Kit (SDK) hervorgegangen, welches in der Java 2 Platform - Enterprise Edition
(J2EE) und Standard Edition (J2SE) eingebettet ist. Enterprise Edition und
Standard Edition unterscheiden sich lediglich im Ausstattungsumfang. So enthält
die J2EE zusätzliche Werkzeuge, wie sie beispielsweise für die Entwicklung von
Java-Beans 41 benötigt werden. Mit dem SDK erhält der Entwickler eine komplette
Systemumgebung für die Erstellung von Java-Programmen, die aus den folgenden
Hauptkomponenten besteht: [20]
• Entwicklungsumgebung mit einem Compiler, der den Java-Quellcode in systemunabhängigen
Bytecode übersetzt (javac)
• Java Core Classes (Java Kernklassen) für die Entwicklung von Applikationen
und Applets (java.lang.*, java.applet.*, java.util.*, ...)
• Eine Laufzeitumgebumg mit der JVM (java)zur Ausführung des Bytecodes
(Java Runtime Environment)
• Werkzeuge für die Konfiguration der Sicherheitsmechanismen (keytool,
jarsigner, policytool)
Im Gegensatz zum SDK, welches primär für die Entwicklung von Java-
Programmen gedacht ist, wird die Java Runtime Environment (JRE) für das
Ausführen des Bytecodes benötigt. Die JRE beinhaltet praktisch die schon angesprochene
virtuelle Maschine und kann ebenfalls über die Java-Homepage bezogen
werden.
Zum besseren Verständnis des nachfolgenden Abschnitts Sicherheitsarchitektur
und -modelle in Java sollen an dieser Stelle noch kurz die Begriffe Java-Applet,
Java-Applikation und JavaScript definiert werden.
• Java-Applets sind mobile Programme (mobiler Code), die meist auf einem
Server gespeichert und in Webseiten eingebettet sind. Ihr Bytecode wird über
das Netz geladen und kann nur in geeigneten Web-Browsern oder Applet-
Viewern ausgeführt werden. Der Abschnitt 3.4 beschäftigt sich noch eingehend
mit dem Thema Java-Applets.
• Java-Applikationen sind eigenständige Programme, deren Bytecode in einer
JVM eines beliebigen Rechners ausgeführt werden kann.
• Java darf nicht mit der Scriptsprache JavaScript verwechselt werden.
JavaScript-Programme dienen in erster Linie zur Bearbeitung von HTML-
Seiten durch den Browser des Client-Rechners. Es ist deshalb zu beachten,
dass die Sicherheitskonzepte von Java keinesfalls auf JavaScript zutreffen.
41 vergl.: Enterprise JavaBeans Technology (http://java.sun.com/products/ejb/)
44

Inv.-Nr.:2003-07-02/047/IN96/2253
3.3.1 Sicherheitsarchitektur und -modelle in Java
Das Sicherheitskonzept von Java wird oft nur mit den Begriffen Sandbox und Signierte
Applets in Zusammenhang gebracht. Zweifelsohne sind diese beiden Konzepte
sehr wichtig, aber in Java kommen noch mehr Sicherheitskomponenten und
-mechanismen zum Einsatz.
Das Sicherheitsmodell der Java-Architektur hat sich seit der Einführung von Java
bereits mehrfach geändert. Dabei wurden aber die wesentlichen Architekturkomponeten,
der Verifizierer (Bytecode-Verifier), der Klassenlader (Class Loader) und der
Sicherheitsmanager (Security Manager) im Prinzip beibehalten. Diese drei Komponenten
bilden zusammen mit dem Sprachdesign von Java das Sandkastenmodell
(sandbox model). Dieser Begriff rührt daher, dass einem Applet nur eingeschränkte
Rechte zugebilligt werden, also sein Wirken auf einen bestimmten Bereich (”Sandkasten”)
begrenzt ist. [5][20]
Sicherheitsmechanismen der Sprache Die Sprachdefinition von Java formt
selbst schon eine wichtige Sicherheitskomponente. In ihr sind gewisse Spielregeln
festgelegt, die unter anderem dafür sorgen sollen, dass ein sicherer und robuster
Programmcode entsteht. Der restriktive Compiler überwacht zur Übersetzungszeit,
ob sich der Quellcode an diese Spielregeln hält. So ist es beispielsweise notwendig,
Methoden oder Deklarationen einer Zugriffsebene (öffentlich, geschützt oder
privat) zuzuordnen und Variablen vor ihrer Verwendung explizit mit einem gültigen
Wert zu initialisieren. Darüber hinaus hat sich der Entwickler von Java-Programmen
noch an andere Richtlinien zu halten, die man in anderen Programmiersprachen
nicht unbedingt wiederfindet: [20]
• Der Gebrauch von Zeigern ist unzulässig. Java kennt keine Zeigerstrukturen
und Arithmetik, sodass ein willkürlicher und direkter Zugriff auf Speicheradressen
nicht möglich ist.
• Das Umwandeln von Datentypen zur Laufzeit ist nicht erlaubt.
• Der Zugriff auf die Elemente eines Datenfeldes kann nur innerhalb der gültigen
Grenzen erfolgen. Damit ist das Schreiben und Lesen von unerlaubten
Speicherbereichen nicht möglich.
• Instruktionen, die Speicher explizit reservieren oder freigeben, sind in Java
nicht vorhanden. Der Garbage Collector, eine Komponente des Laufzeitsystems,
sorgt für eine intelligente Verwaltung von freien Speicherfragmenten
und nicht mehr verwendeten Objekten.
Sind alle geforderten Richtlinien im Quellcode eingehalten worden, so generiert der
Compiler (javac) aus der .java-Datei eine sogenannte Klassendatei mit der Endung
.class. Diese Klassendatei enthält dann den Bytecode des Java-Programms.
Strukturierter Bytecode Die vom Compiler erzeugte Datei beinhaltet neben dem
schon erwähnten Bytecode auch wichtige Informationen über das Quellprogramm.
Diese ermöglichen es Kontrollkomponenten, hier der Bytecode-Verifier, zu einem
45

Inv.-Nr.:2003-07-02/047/IN96/2253
späteren Zeitpunkt erneut in der Lage zu sein, syntaktische und strukturelle Überprüfungen
am transformierten Code durchzuführen. Prinzipiell ist eine Klassendatei
aus sechs Bereichen aufgebaut: [32]
• Dateikopf (Dateikennung, Versionsinformationen),
• Konstantenpool,
• Klassenbeschreibung (dazu gehören der Name der Klasse, die Vaterklasse,
implementierte Interfaces, Zugriffsrechte für die Klasse),
• Array von Datenfeldern,
• Array mit Methoden (hier ist insbesondere auch der Bytecode für jede einzelne
Methode enthalten) und
• zusätzliche Informationen (sogenannte Attribute)
In den jeweiligen Bereichen findet der Bytecode-Verifier dann unter anderem Informationen
wie die Dateikennungskonstante 0xCAFEBABE , die Version des Übersetzers,
der den Code erzeugt hat, Angaben über die maximal benötigte Größe des
Laufzeit-Stacks und die benötigten Register.
Bytecode-Verifier Aufgabe des Bytecode-Verifiers ist es, auf Basis der durch den
Compiler bereits durchgeführten Analysen und generierten Kontrollinformationen
sicherzustellen, dass nur syntaktisch und strukturell korrekter Bytecode in der virtuellen
Maschine zur Ausführung kommt. [5] Der Grund für den Einsatz des Verifiers
liegt darin, dass nicht garantiert werden kann, dass der zur Erzeugung der Klassendateien
verwendete Compiler vertrauenswürdig ist, oder dass ein Angreifer den
Bytecode in mühevoller Handarbeit nicht modifiziert hat. Der Verifizierer nimmt sowohl
Laufzeittests (dynamische Tests) als auch Tests beim Linken (statische Tests)
vor. Der Verifikationsprozess besteht insgesamt aus vier Phasen, die im Folgenden
beschrieben werden: [20][32]
1. In der ersten Phase überprüft der Verifier die Einhaltung grundlegender Formate.
Dazu gehört, ob die Klassendatei mit der Dateikennung 0xCAFEBABE
beginnt, ob alle Attribute die richtige Länge besitzen und ob die Klassendatei
vollständig ist.
2. In Phase 2 wird anschließend die Integrität der Klassendaten kontrolliert. Ohne
detailliert Einsicht in den Bytecode zu nehmen, untersucht der Verifier
insbesondere ob:
• als final definierte Klassen keine Subklassen besitzen,
• als final definierte Methoden nicht überschrieben werden,
• jede Klasse mit Ausnahme von Object eine Vaterklasse besitzt und
• alle Konstantenpooleinträge korrekt sind.
46

Inv.-Nr.:2003-07-02/047/IN96/2253
3. Nachdem bis hierher noch keine Ausnahmebehandlung eingreifen musste,
erfolgt in der dritten Phase die wichtige aber auch sehr komplexe Daten- und
Kontrollflußanalyse für jede einzelne Methode. Insbesondere soll der Verifier
in dieser Phase sicherstellen, dass:
• die Methoden mit den geeigneten Parametern aufgerufen werden,
• Feldern nur Werte zugewiesen werden, die die korrekten Typen besitzen,
• Variablen vor ihrer Verwendung initialisiert worden sind und
• es zu keinen Stack-unter- oder -überläufen kommt.
4. Da nicht alle Tests beim Linken der Klassendatei durchgeführt werden, beispielsweise
können nicht alle Typkonflikte zur Linkzeit erkannt werden, erfolgt
in der vierten Phase eine Analyse des Programmverhaltens zur Laufzeit.
Dazu wird nacheinander jede Instruktion im Bytecode geprüft, zum Beispiel,
ob auf ein Feld oder eine Methode zugegriffen werden darf. Allerdings
hat diese statische Rekonstruktion des Laufzeitverhaltens ohne tatsächliche
Ausführung des Codes nur eine begrenzte Aussagekraft in Bezug auf mögliche
Sicherheitslücken zur Laufzeit. [20]
Nach erfolgreichem Abschluss der Prüfung des Bytecodes durch den Verifier übernehmen
zwei weitere Instanzen der Java-Sicherheisarchitekur die Überwachung der
korrekten Ausführung des Codes: der Class Loader und der Security Manager.
Class Loader Nachdem der Verifier seine Überprüfungen ohne Beanstandungen
durchgeführt hat, wird der Bytecode durch den Class Loader in die virtuelle Maschine
geladen. Grundsätzlich werden beim Laden von Klassen in die Laufzeitumgebung
immer erst die lokal vorliegenden Dateien herangezogen, bevor auf Code
zurückgegriffen wird, der von externen Quellen wie dem Internet geladen wurde.
Mit dieser Vorgehensweise soll sichergestellt werden, dass die Systemklassen der
Java-Laufzeitumgebung, wie beispielsweise die zur Ein- und Ausgabe von Dateien,
nicht einfach durch gleichlautende Klassen überschrieben und später ausgeführt
werden können. Man spricht hier von sogenannten Class-Spoofing-Angriffen.
Eine weitere wesentliche Aufgabe des Class Loaders ist die Bereitstellung und Verwaltung
von Namensräumen. Jedes nicht vertrauenswürdige Applet erhält einen eigenen
isolierten Namensraum und kann nur die eigenen Methoden sowie die zur
Verfügung gestellten Systemmethoden nutzen. Dadurch werden Konflikte bei gleicher
Namensgebung vermieden und Applets unterschiedlicher Herkunft ist es nicht
möglich, zu kooperieren, um möglicherweise einen gemeinsamen Angriff durchzuführen.
[5][20]
Security Manager Die zur Laufzeit durchzuführenden Kontrollen fallen in das
Aufgabengebiet des Security Managers. Er spielt als zentrales Element der Sicherheitsarchitektur
die wichtigste Rolle zur Laufzeit und wird von der JVM
bei Zugriffsversuchen auf sicherheitskritische Systemressourcen konsultiert. Seine
primäre Aufgabe besteht darin, alle als potentiell gefährlich eingestuften Operationen
von nicht vertrauenswürdigen Klassen zu überwachen und gegebenenfalls
47

Inv.-Nr.:2003-07-02/047/IN96/2253
einzuschreiten, wenn eine Verletzung der lokalen Sicherheitspolitik vorliegt. Dies
kann zum Beispiel der Fall sein beim: [20]
• Lesen oder Schreiben von lokalen Dateien
• Aufbau einer Netzwerkverbindung zu anderen Rechnern im Netzwerk
• Manipulieren des Zustands anderer Threads
• Verwenden des Druckers
Der Security Manager wird automatisch von allen gängigen Browsern für die
Ausführung von Applets aktiviert. Beim Start einer lokal installierten und als
vertrauenswürdig eingestuften Java-Applikation tritt er jedoch im allgemeinen
nicht in Aktion. Seit Java 2 (JDK Version 1.2) besteht allerdings die Möglichkeit,
den Security Manager ausdrücklich beim Start einer Applikation aufzurufen, was
zur Folge hat, dass sie den gleichen Restriktionen unterliegt, die auch für den
fremden Code gelten. Ein solcher expliziter Aufruf erfolgt beim Start der JVM mit
dem Kommandozeilenparameter -D, gefolgt vom gewünschten Security Manager
(i.d.R. java.security.manager).
Ist der Security Manager erst einmal aktiviert, so ist er eng mit den Java Core
Classes verbunden. Jeder als sicherheitskritisch betrachtete Methodenaufruf einer
Basisklasse veranlasst die Java-API 42 , mit der sogenannten check()-Methode
die Berechtigung zur Ausführung dieser Operation beim Security Manager zu
erfragen. Dieser antwortet mir einer SecurityException, falls die Operation
gegen die Sicherheitspolitik verstößt. Ist die Operation hingegen erlaubt, wird
keine Exception (dt. Ausnahme) ausgelöst. check()-Methoden existieren für
alle sensiblen Bereiche auf einem System, so zum Beispiel checkRead() oder
checkWrite() für den Zugriff auf das Dateisystem oder checkExec() beim
Ausführen von Systemkommandos.
Abbildung 12 aus [5] fasst noch einmal die beschriebenen Komponenten
(grau hinterlegt) der Sicherheitsarchitektur zusammen.
Sicherheitsmodell im JDK 1.0 Wie bereits erwähnt, unterlag das Sicherheitsmodell
von Java in den vergangenen Jahren einem ständigen Wandel. Das ursprüngliche
Modell wurde mit dem JDK 1.0 eingeführt und ist auch unter dem
Namen Sandbox-Modell bekannt. Es unterscheidet ganz einfach zwischen Bytecode,
der von einem entfernten Rechner als Applet geladen wird und lokalen Java-
Applikationen, die grundsätzlich als vertrauenswürdig betrachtet werden. Während
der lokale Code, sprich die Applikation, das Recht hat, alle Ressourcen des Systems
uneingeschränkt zu nutzen, wird das Applet in einer nur sehr eingeschränkten
Rechteumgebung, der Sandbox, ausgeführt. Im Einzelnen bedeutet das für das
Applet, dass ihm kein Zugriff auf Dateien des lokalen Dateisystems gewährt wird,
es keine beliebigen Netzwerkverbindungen zu anderen Rechnern aufbauen kann,
außer zu dem Rechner von dem es geladen wurde und, dass es ihm nicht gestattet
ist, neue Prozesse oder Kommandos zu starten. [5][20]
42 API: Application Programming Interface
48

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 12: Komponenten der Java-Sicherheitsarchitektur [5]
Sicherheitsmodell im JDK 1.1 Die beschriebenen Restriktionen in Java 1.0
machten es praktisch unmöglich, sinnvolle Applets zu entwickeln. Man stelle sich
beispielsweise einen einfachen Texteditor vor, der zwar dynamisch über das Internet
geladen werden kann, dem es aber nicht möglich ist, auf lokale Textdateien zuzugreifen,
um deren Bearbeitung durch den Anwender zu ermöglichen.
Mit der im Frühling 1997 vorgestellten Nachfolgeversion 1.1 wurde die Rechtevergabe
etwas flexibler. Die Welt der Applets wurde jetzt in zwei Lager aufgeteilt:
vertrauenswürdige und nicht vertrauenswürdige Applets. Letztere unterliegen nach
wie vor den starken Einschränkungen der Sandbox. Die als vertrauenswürdig eingestuften
Applets erhalten hingegen die gleichen Rechte wie sie auch lokalen Applikationen
eingeräumt werden. Ein Applet gilt dann als vertrauenswürdig, wenn
es mit einer digitalen Unterschrift des Autors versehen ist und der Anwender des
Applets manuell bestätigt, dass er dem Autor sein Vertrauen schenkt. Die digitale
Unterschrift (Signatur) ist dabei ein Hilfsmittel, die eine zweifelsfreie Identifikation
des Urhebers und die Integrität des Codes gewährleisten soll.
Ebenfalls eine Neuerung im JDK 1.1 war die Einführung des jar-Kommandos. Das
jar-Kommando erlaubt eine Zusammenfassung aller Klassen und Ressourcen (z.B.
Bilder) eines Applets zu sogenannten Archiven mit der Dateiendung .jar. Diese an
das ZIP-Format angelehnten Archivdateien können von ihrem Autor signiert und
mit geeigneten Web-Browsern in einer einzigen HTTP-Transaktion geladen und
anschließend automatisch entpackt werden.
Im Gegensatz zum fremden Code, dem in Java 1.1 mehr Freiraum gewährt wird,
hat sich das Sicherheitskonzept für lokal installierte Applikationen verschärft. Einen
uneingeschränkten Zugriff auf die Systemressourcen erhalten die Applikationen nur
noch dann, wenn sie aus einem Verzeichnis stammen, das in der Umgebungsvariable
mit dem Namen CLASSPATH eingetragen ist. Die CLASSPATH-Variable enthält
standardmäßig das Verzeichnis der Runtime-Klassen der JVM und kann um Ver-
49

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 13: Sicherheitsmodelle in JDK1.0 und JDK1.1 [5][20]
zeichnisse neu installierter Applikationen erweitert werden. Eine solche Erweiterung
bedeutet allerdings einen elementaren Eingriff in die lokale Sicherheitspolitik.
[5][20]
Sicherheitsmodell in Java 2 Trotz der Verbesserungen im JDK 1.1 zur ersten
Version bestand nach wie vor das Problem der wenig flexiblen Rechtevergabe.
Besonders die Tatsache, dass signierten Applets der uneingeschränkte Zugriff
auf die Systemressourcen gestattet wurde, widerspricht der Forderung nach einer
Rechtevergabe nach dem Prinzip der minimalen Rechte (vergl.: Abschnitt 2.2.3).
Zur Beseitigung dieser Inflexibilität wurde im Dezember 1998 die neue Version 1.2
des JDK, die auch unter dem Namen Java 2 SDK, Standard Edition v1.2 bekannt
ist, mit einem neuen Sicherheitsmodell eingeführt. Der wesentlichste Fortschritt
des neuen Modells besteht darin, dass nunmehr eine feingranulare Berechtigungsvergabe
und Kontrolle möglich ist. [5]
Mit der Einführung von Java 2 wurde auch die Java Cryptographic Extension
(JCE) erweitert. Die JCE ist eine Java-Bibliothek, die unter anderem Algorithmen
zur Verschlüsselung, zur Generierung von Schlüsseln und Message Authentication
Codes (MAC) bietet sowie eine Schlüssel- und Zertifikatsmanagemet umfasst.
Das Sicherheitsmodell von Java 2 beruht auf dem Prinzip, dass jedes Subjekt, sei
es lokaler oder entfernter Code, signiert oder unsigniert, einer geltenden Sicherheitspolitik
unterworfen ist. Diese Politik ist nicht mehr in der Programmlogik des
Security Managers verankert, sondern lässt sich vom Sicherheitsbeauftragten in
der Rolle des Systemadministrators für das System oder vom Benutzer in dessen
Heimatverzeichnis über ein Politik-Objekt (i.d.R. die Textdatei java.policy)
festlegen, auf das der sogenannte Access Controler zugreift. Die Sicherheitspolitik
(security policy) beschreibt, welche Berechtigungen (permissions) an den
Bytecode vergeben werden, wobei bestimmte Informationen, wie die Quelle des
Codes und/oder Signaturen, die dem Code assoziiert sind, berücksichtigt werden
können. Die Quelle des Codes ist bei Applets durch die URL festgelegt, von der der
50

Inv.-Nr.:2003-07-02/047/IN96/2253
Code geladen wurde, und der zu einem Signaturschlüssel eines signierten Applets
passende öffentliche Verifikationsschlüssel identifiziert den Signierer (i.d.R. den
Autor des Applets).
Die in Java 2 neu festgelegte, abstrakte Klasse java.security.Permissions dient
der Vergabe von Berechtigungen. Um spezifische Rechte an Systemressourcen
zu vergeben, werden von ihr Subklassen gebildet. Beispielsweise beinhaltet die
Klasse java.io.FilePermission die Rechte zur Nutzung von Dateien und
java.net.SocketPermission die Rechte für den Zugriff auf Netzwerkdienste.
Listing 1 zeigt beispielhaft den Inhalt der java.policy-Datei, in der zwei
Subklassen von java.security.Permissions wiederzufinden sind.
✞
Listing 1: java.policy
grant CodeBase "https://www.haecker-automation.com/dpac",SignedBy "Haecker"{
permission java.io.FilePermission "read,write", "/temp/*";
permission java.net.SocketPermission "connect","db.haecker-automation.com";
};
☎
grant {permission java.net.SocketPermission "localhost:1024-","listen";}
✝
Der erste Eintrag der java.policy-Datei besagt, dass eine Klasse, deren Quelle
(CodeBase) die URL https://www.haecker-automation.com/dpac ist und von
”Haecker” signiert wurde, auf alle Dateien im Verzeichnis /temp/ lesend und
schreibend zugreifen darf. Desweiteren ist sie berechtigt, eine Socket-Verbindung
zum Rechner db.haecker-automation.com aufzubauen. Der zweite und letzte
Eintrag gestattet es allen Subjekten an den Portadressen des lokalen Rechners, die
einen Wert größer oder gleich 1024 besitzen, (unprivilegierte Ports) zu lauschen,
also ankommende Nachrichten zu empfangen. [5]
Bei der Durchführung der Zugriffskontrolle wird der Security Manager in Java
2 um den bereits angesprochenen Access Controller ergänzt. Aus Gründen
der Abwärtskompatibilität kommt es nach wie vor zum Aufruf der check-
Methoden. Diese entscheidet der Security Manager jedoch nicht mehr selber,
sondern reicht sie an den Access Controller weiter. So erzeugt beispielsweise die
check read(file)-Methode ein java.io.FilePermission-Objekt für diesen
Aufruf:
✆
AccessController.checkPermission(new java.io.FilePermission(file, read))
Der Access Controller konsultiert dann das Politik-Objekt und prüft, ob das
auszuführende Subjekt bzw. dessen Schutzdomäne (siehe unten) die erforderlichen
Berechtigungen besitzt. Sollte dies nicht der Fall sein, wird wie in den vorangegangenen
Java-Versionen eine Ausnahme vom Typ SecurityException erzeugt und
der Programmablauf beendet.
Als ein weiteres wichtiges Sicherheitskonzept führt Java 2 die Schutzdomäne
(protection domain) ein. In einer Schutzdomäne ist eine Menge von Klassen
zusammengefasst, wodurch alle Instanzen (Objekte) dieser Klassen die gleichen
Berechtigungen erlangen. Die Laufzeitumgebung erzeugt Schutzdomänen dynamisch
und fasst die Klassen, die beispielsweise die gleiche Ursprungs-URL
51

Inv.-Nr.:2003-07-02/047/IN96/2253
besitzen oder mit dem gleichem Schlüssel signiert wurden, automatisch in einer
Domäne zusammen. Die Berechtigungen für den Zugriff auf Systemressourcen
werden dann an die Schutzdomäne vergeben. Eine domänenübergreifende Interaktion
ist nur über den vertrauenswürdigen Systemcode als Vermittler oder durch
eine explizite Berechtigungsvergabe der beteiligten Domänen möglich.
Ein Beispiel für Schutzdomänen sind die Domänen für nicht vertrauenswürdigen
Code (sie entspricht dem Prinzip der Sandbox) oder die Systemdomäne, die
den gesamten JDK-Code enthält und als einzige die Berechtigung hat, auf alle
Ressourcen direkt zuzugreifen. [5][20]
3.3.2 Bewertung des Java-Sicherheitskonzepts
Natürlich ist auch die Sicherheitsarchitektur von Java, so ausgeklügelt sie auch erscheinen
mag, nicht unfehlbar. [32] stellt zum Beispiel in Kapitel 4 eine Auswahl
verschiedener Java-Sicherheitslücken vor, die im Zeitraum von 1996 bis 1999 entdeckt
und mittlerweile behoben wurden. Dennoch ist sich die Literatur weitestgehend
darüber einig, dass die Sicheitsarchitektur in Java eine der fortschrittlichsten
ist. Die Kombination aus dem Java-Sprachenkonzept und den Komponenten der
Laufzeitumgebung vereint eine Vielzahl erprobter Sicherheitskonzepte. [5] nennt
hier unter anderem die Trennung zwischen der Festlegung der Sicherheitsstrategie
mittels Politik-Objekt und deren Realisierung über den Security Manager und Access
Controller sowie die Kapselung von ausführbarem Code in Schutzdomänen.
Auch das vom JCE zur Verfügung gestellte Schlüssel- und Zertifikatsmanagement
gilt als wichtiges Hilfsmittel, um signierte und/oder verschlüsselte Applets zu erzeugen.
Neben den Vorzügen der Java-Sicherheitsarchitektur findet man in [5] aber auch
einige interessante Kritikpunkte:
• Der erste Kritikpunkt beschäftigt sich mit der Vergabe von Berechtigungen
auf Grundlage der Herkunftsadresse und/oder der mit dem Urheber assoziierten
Signatur. Zu beachten ist nämlich, dass Rechte nicht an einzelne Benutzer
sondern an Java-Klassen vergeben werden, deren Identifizierung nur
über diese beiden genannten Merkmale erfolgt. Da jedoch kein Nachweis
über die Authentizität der Adresse des Quell-Rechners bzw. der zu ladenden
Klasse gefordert wird, eröffnet diese die Möglichkeit für URL-Spoofing Angriffe.
Ein Angreifer könnte versuchen, eine Herkunfts-URL vorzutäuschen,
um so seine maskierten Klassen-Dateien in ein Zielsystem einzuschleusen,
denen dann dort die Berechtigungen der maskierten Adresse eingeräumt werden.
Abhilfe könnten hier stärkere Authentifizierungsverfahren oder sichere
Übertragungsprotokolle (vergl.: 2.5.2) schaffen.
• Jeder in den Einträgen des Politik-Objekts angegebene Alias, dessen Signatur
akzeptiert wird, (im Beispiel oben ist das der Alias ”Haecker”) bezieht sich
auf einen Eintrag, der in der rechnerlokalen Schlüsseldatenbank zu finden ist.
In dieser Datenbank wird die Verknüpfung zwischen dem Alias des Signateurs
(also des Urhebers) und dessen öffentlichen Schlüssel, der zur Verifikation
benötigt wird, hergestellt. Die für die Sicherheit des lokalen Rechners
52

Inv.-Nr.:2003-07-02/047/IN96/2253
verantwortlichen Benutzer müssen diese Schlüsseldatenbank selber warten
und die Konsistenz, Integrität und Vertraulichkeit der Datensätze gewährleisten.
• Der letzte Kritikpunkt der hier aufgegriffen werden soll, bezieht sich auf das
Politik-Objekt selbst. Da es in der derzeitigen Realisierung eine Textdatei ist,
unterliegt es damit den Schutzmechanismen des zugrunde liegenden Betriebssystems.
Es ist leicht einzusehen, dass eine Modifikation des Politik-Objekts
weitreichende Konsequenzen hat, da seine Integrität das Fundament für die
Sicherheitsarchitektur bildet. Gerade offene Betriebssysteme, die nur wenig
Wert auf Zugriffsschutz legen, sind hier als äußerst problematisch anzusehen.
3.4 Java-Web-Start, eine Alternative zu Applets
In dem nun folgenden Abschnitt soll mit Java-Web-Start (kurz JWS oder WebStart)
eine konkrete Technologie vorgestellt werden, mit der die Idee des Mobilen Codes
einfach und komfortabel umgesetzt werden kann.
Die schon oft angesprochenen Applets bilden im Grunde genommen das
Fundament für die Java-Web-Start Technologie. Mit ihnen wurde bekanntlich
das Einbinden von Java-Programmen mit graphischer Oberfläche in Webseiten
ermöglicht, was maßgeblich die anfängliche Begeisterung für Java auslöste. Später
erkannte man noch einen weiteren strategischen Vorteil. Diese Programme mussten
nicht installiert werden, sondern wurden einfach aufgerufen und waren immer
up-to-date. Das brachte die Zeit in Erinnerung, als die Anwender noch an einfachen
Terminals saßen und schnell war die Idee geboren, alle benötigten Programme als
Applets zu implementieren, die bei Bedarf von einem zentralen Server geladen
werden. Laut [15] hatte man erkannt, dass in den Unternehmen ein Großteil der Kosten,
die durch Computerarbeitsplätze entstehen, gar nicht beim eigentlichen Kauf
verursacht werden, sondern erst danach. Beispielsweise durch Updates, Reparatur
und Wartung, aber auch durch Probleme, die durch nicht verfügbare, fehlerhafte
oder inkonsistente Programmversionen entstehen. Warum sich aber die aus dieser
Idee hervorgegangenen Java Workstations nicht durchsetzen konnten, darüber
lässt sich nur spekulieren. Viele Anzeichen deuten darauf hin, dass zu langsame
Netzwerkverbindungen, unzulängliche Java-Implementierungen in den Bowseren
aber auch eine gewisse Skepsis gegenüber der relativ neuen Programmiersprache
Java zu viele Probleme verursacht hat.
Ende 1999 startete Sun Microsystems noch einmal einen Versuch mit dem Produkt
Sun Ray, der den sogenannten Thin Clients zum Durchbruch verhelfen sollte
(vergl.: http://wwws.sun.com/hw/sunray/index.html).
Mit der WebStart Technologie verfolgt Sun gewissermaßen einen ähnlichen
Ansatz wie den, der oben beschrieben ist. Das Ziel von JWS ist es, die Vorteile der
Applets (u.a. Installationsfreiheit), mit denen der Applikationen (u.a. Geschwindigkeit
und Frexibilität) zu kombinieren. Java-Web-Start v1.0 Beta wurde erstmals
im Jahr 2000 vorgestellt und ist seit Java-Version 1.4 fester Bestandteil der JRE.
Die zur Zeit aktuelle WebStart-Version 1.2 wurde im Herbst 2002 freigegeben. Sie
53

Inv.-Nr.:2003-07-02/047/IN96/2253
beinhaltet neben den üblichen Fehlerkorrekturen auch einige neue Funktionsmerkmale,
die auch für den Sicherheitsbereich interessant sind.
Die nun folgenden Ausführungen sollen einen Einblick in die Funktionsweise
von WebStart geben und die eingebetteten Sicherheitsmechanismen vorstellen,
mit denen man Antworten auf die oben im Zusammenhang mit mobilen Code
gestellten Sicherheitsfragen finden kann.
3.4.1 Warum Java-Web-Start?
Warum man JWS gegenüber Applets den Vorzug geben sollte, liegt an den Nachteilen
und Problemen, die Applets mit sich bringen. Hier ein paar Beispiele:[47]
• Applets müssen innerhalb eines geeigneten Browsers oder Applet-Viewers
gestartet werden.
• Bei einem größeren Applet, dessen Download vielleicht mehrere Minuten in
Anspruch nimmt, ist es sinnvoll dieses zu cachen 43 , wenn es häufiger benötigt
wird. Leider ist man normalerweise der Gnade des jeweiligen Browsers ausgeliefert,
wenn es um das Cachen geht.
• Das ”offline” Ausführen eines Applets ist in der Regel nur über Umwege
möglich, die es unter anderem erforderlich machen, dass der Anwender weiß,
wo der Browser das Applet zwischengespeichert hat.
• Ein weiteres Problem ist, dass man bei der Entwicklung von Applets nicht
genau sagen kann, welchen Browser der Anwender benutzt und welche JVM-
Version dieser unterstützen. Manche Hersteller verweigern ihrem Browser
jegliche Java-Unterstützung, um beispielsweise eigene Lösungen besser vermarkten
zu können, andere unterstützen Java grundsätzlich aber nicht immer
in der aktuellsten Version. Von Sun werden zwar Plug-Ins angeboten, die die
jeweiligen Browser auf ein einheitliches aktuelles Niveau bringen. Eine Garantie
dafür, dass der Anwender diese Plug-Ins auch installiert hat, gibt es
jedoch nicht.
Die anschließenden Erläuterungen sollen zeigen, dass mit JWS eine Technologie
zur Verfügung steht, mit der all diese Probleme auf eine elegante Art und Weise
gelöst werden können.
Aus Sicht des Anwenders stellt WebStart die sehr einfache Möglichkeit dar,
Java-Applikationen zu ”installieren”, zu starten und zu aktualisieren. Diese
durchaus gewünschte Tatsache ergibt sich daraus, dass er zum Starten einer
Applikation lediglich auf einen speziellen Link einer Webseite klicken muss.
Dieser Link zeigt auf eine Deskriptordatei (JNLP-Datei), in der alle von WebStart
benötigten Informationen untergebracht sind. Hat der Browser die Deskriptordatei
als solche erkannt, wird von ihm Java-Web-Start aufgerufen. Daraufhin wertet
WebStart die Informationen aus dem JNLP-File aus und lädt die darin beschriebene
43 engl. cache: Zwischenspeicher
54

Inv.-Nr.:2003-07-02/047/IN96/2253
Java-Applikation via HTTP über das Netzwerk. Nachdem diese dann erfolgreich
gespeichert (gecached) wurde, wird sie vom WebStart-Applikationsmanager
gestartet und steht somit dem Anwender zur Verfügung. Dies alles geschieht ohne
weiteres Zutun des Anwenders. Nötig ist lediglich der auslösende Klick auf den
beschriebenen Link und etwas Geduld beim Download, falls die Applikation zum
ersten Mal gestartet wird.
Vom rein technischen Standpunkt aus betrachtet, bietet die Java-Web-Start
Technogie einige Vorteile:[34]
• Mit WebStart lassen sich ausschließlich Java-Applikationen verteilen, die
dem Java 2 Standard entsprechen. Diese können auf einem Web Server wie
beispielsweise dem Apache-Web-Server zur Verfügung gestellt werden, um
sie auf verschiedene Clients zu verteilen. Dabei spielt das auf den Clients
installierte Betriebssystem keine Rolle. Wichtig ist nur, dass die von der Applikation
geforderte Version der JVM auf dem Client-System präsent ist.
• Sind auf einem Client-System mehrere Versionen der Java 2 Plattform
vorhanden, werden diese von Java-Web-Start, genauer vom WebStart-
Applikationsmanager, erkannt und unterstützt. Das bedeutet, dass es möglich
ist, verschiedene Applikationen auf verschiedenen virtuellen Maschinen auszuführen,
wenn beispielsweise eine die Java-Version 1.4.1, die andere aber
nur Version 1.3.0 verlangt. Außerdem ist WebStart in der Lage, nicht vorhandene
aber benötigte Versionen der Laufzeitumgebung nachzuladen.
• Schon einmal gestartete Applikationen hat WebStart automatisch zusammen
mit der passenden Deskriptordatei auf dem jeweiligen lokalen Client-System
gespeichert. Erfolgt nun ein erneuter Aufruf der Applikation durch den Anwender,
sei es durch Klicken auf den Link der zugehörigen Webseite oder
durch Aufruf im Applikationsmanager (vergl.: Abbildung 14), versucht Web-
Start zuerst festzustellen, ob die Version der gespeicherten Applikation noch
die aktuellste ist. Sollte dies der Fall sein, wird die Applikation gestartet. Andernfalls
wird erst das verfügbare Update über das Netz geladen.
Ein besonderes Feature von WebStart ist es, auch Applikationen ”offline”, also
ohne bestehende Netzwerkverbindung auszuführen. Voraussetzung dafür
ist allerdings, dass die Applikation den offline-Betrieb explizit erlaubt. Die
Update-Funktionalität von WebStart ist im Offline-Betrieb verständlicherweise
nicht verfügbar.
• Neben der Möglichkeit, eine Java-Applikation über den Applikationsmanager
zu starten, bietet WebStart auch die Möglichkeit, Short-Cuts auf dem Desktop
und/oder im Startmenü (nur unter MS Windows) anzulegen, über die die Applikation
dann ebenfalls gestartet werden kann.
• Java-Web-Start nutzt das Sicherheitsmodell der Java 2 Plattform (vergl.: Abschnitt
3.3.1). Anwendungen unterliegen ähnlich wie Applets den Restriktionen
der Sandbox. Anwendungen, die auf alle Systemressourcen freien Zugriff
wünschen, müssen signiert sein und der Anwender muss den Zugriff explizit
erlauben.
55

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 14: Der Java-Web-Start Applikationsmanager
• Java-Web-Start ist browserunabhängig und läuft auf allen Plattformen, die
von der Java 2 Standard Edition unterstützt werden.
Der mit Java vertraute Leser hat vielleicht festgestellt, dass WebStart auch ein
Problem löst, welches im Zusammenhang mit dem Starten von lokal installierten
Applikationen auftritt. Sieht man einmal von ausführbaren jar-Archiven ab,
werden Java-Applikationen in der Regel über die Kommandozeile mit dem Befehl
java bzw. javaw plus Angabe der Klasse, die die main-Methode enthält, gestartet.
Dies ist wohl für die Mehrzahl der Anwender, die eine graphische Benutzeroberflächen
einsetzen, eine etwas befremdliche Vorgehensweise. Mit dem von
WebStart gebotenen Konzept der automatischen Erzeugung von Short-Cuts können
Java-Applikationen möglicherweise auch den Anwendern näher gebracht werden,
die vornehmlich mit der Maus arbeiten.
3.4.2 Das Java Network Launching Protokoll
Das Java Network Launching Protokoll (kurz JNLP) bildet das Fundament von
Java-Web-Start. Anders gesagt, JWS steht nicht auf eigenen Füßen, sondern basiert
auf dem Java Network Launching Protokoll und stellt praktisch eine Referenzimplementierung
für JNLP dar.
In der Spezifikationsbeschreibung ([27]) definiert Sun Microsystems das Java
Network Launching Protokoll, zu dem auch eine API gehört, als ein webzentriertes
Protokoll zur Verteilung von Softwarekomponenten sowie als eine
Anwendungsumgebung für über das Web aufgerufene Applikationen, die auf der
Java 2 Technologie basieren. Ein Programm, welches die JNLP-Spezifikationen implementiert,
wird als JNLP-Client bezeichnet. Die Hauptkonzepte der Spezifikation
sind:[27]
56

Inv.-Nr.:2003-07-02/047/IN96/2253
• Ein web-zentriertes Anwendungsmodell, in dem transparente und inkrementelle
Updates genauso unterstützt werden wie das inkrementelle Nachladen
von Programmteilen und das ohne Installationprozess auskommt.
• Ein Protokoll, dass beschreibt, wie mit einer Applikation zu verfahren ist,
die auf einem Web-Server für eine Menge von JNLP-Clients bereit gestellt
werden soll. Die Schlüsselkomponente hierbei ist die Deskriptordatei.
• Eine standardisierte Ausführungsumgebung für Applikationen.
Das Anwendungsmodell In dem vom Java Network Launching Protokoll definierten
Anwendungsmodell kann sich die Applikation, die auch als Ressource bezeichnet
wird auf einem beliebigen, erreichbaren Web-Server im Netz befinden. Der
Anwender kann dann selbst entscheiden, ob er das Programm laden und ausführen
möchte und welche Rechte es erhalten soll. Das Anwendungsmodell lässt sich wie
folgt charakterisieren:[34][27]
• Kein Installationsprozess: Der JNLP-Client (z.B. WebStart) lädt auf Anforderung
die Programme vom Web-Server und speichert sie im Lokalen Cache.
Der Anwender wird nicht mehr nach Installationsparametern gefragt.
• Inkrementeller Download: Besteht eine Applikation aus mehreren Programmteilen,
so können die, die zum Start der Applikation nicht unbedingt benötigt
werden erst einmal auf dem Server verbleiben. Sollten bestimmte Teile im
Verlauf der Programmausführung dann doch benötigt werden, so kann sie der
JNLP-Client dynamisch nachladen.
• Transparente Updates: Der JNLP-Client kann die zur Zeit lokal gespeicherte
Version einer Applikation periodisch mir der vergleichen, die auf dem Web-
Server zum Download bereit gestellt ist. Ergibt der Vergleich, dass die Version
auf dem Server aktueller ist als die lokale, so veranlasst dies den JNLP-Client,
die neuere Version automatisch für den Anwender verfügbar zu machen.
• Inkrementelle Updates: Genau wie einzelne Programmteile nachgeladen werden
können, ist es auch möglich, diese einzeln upzudaten. Der JNLP-Client
muss dann nur die Teile neu laden, die sich tatsächlich geändert haben. Das
reduziert natürlich drastisch die Downloadzeiten.
• Unterstützung für Offline-Ausführung: Ein JNLP-Client kann eine lokal gespeicherte
Applikation auch ohne aktuell bestehende Netzwerkverbindung
ausführen. Voraussetzung dafür ist aber, dass alle relevanten Teile des
Programms lokal gespeichert sind und dass die Applikation die Offline-
Verwendung gestattet.
Die Deskriptordatei Die Deskriptordatei (JNLP-Datei) ist wohl das wichtigste
Element der JNLP Technologie und steht im Mittelunkt der Protokollspezifikation.
Sie ist als XML 44 -Dokument aufgebaut und enthält alle Informationen, die der
44 XML: Extensible Markup Language, eine besonders für den systemunabhängigen Datenaustausch
geeignete Sprache, die HTML- und SGML-Konzepte übernimmt.
57

Inv.-Nr.:2003-07-02/047/IN96/2253
JNLP-Client benötigt, um eine Applikation zu laden und zu starten. Prinzipiell lässt
sich die JNLP-Datei mit einer ausführbaren Anwendung vergleichen mit dem Unterschied,
dass sie unabhängig von Betriebsystem und Hardware ist.[34]
Abbildung 15: Allgemeiner Überblick über die Elemente einer JNLP-Datei [27]
Abbildung 15 zeigt ganz allgemein, die fünf Elemente die in jeder Deskriptordatei
zu finden sind. Die einzelnen Elemente stellen praktisch eine Struktur für die
JNLP-Datei dar:
• Das jnlp- oder Wurzel-Element beinhaltet Informationen, die die Deskriptordatei
selbst spezifizieren.
• Im information-Element sind meta-Informationen über die Applikation enthalten.
Diese können beispielsweise während des Downloads angezeigt werden.
• Das security-Element wird verwendet, um festzulegen, welche Rechte die
Applikation bei der Ausführung auf dem Gastrechner benötigt.
• Im resources-Element sind alle Ressourcen aufgeführt, die Teile der Applikation
sind. Das können zum Beispiel Java-class-Dateien und native Bibliotheken
sein.
• Der letzte Teil der Deskriptordatei kann nur aus einem der vier Elemente
application-desc, applet-desc, component-desc oder installer-desc bestehen.
Eine JNLP-Datei mit den Elementen application-desc oder applet-desc wird
als Applikations-Deskriptor bezeichnet. Enthält die Datei hingegen die Elemente
component-desc oder installer-desc, so nennt man sie Erweiterungs-
Deskriptor.
Nach dieser allgemeinen Betrachtung der Struktur soll das Listing 2 ein konkretes
Beispiel für eine JNLP-Datei geben, deren Einzelheiten anknüpfend beschrieben
58

Inv.-Nr.:2003-07-02/047/IN96/2253
werden. Die beinhalteten Informationen stehen XML-typisch innerhalb bestimmter
Tags 45 .
✞
Listing 2: JNLP-Datei [40]
Demo Application
My Company, Inc.
Demo Application
Description for myApplication.
✝
Die Attribute spec, codebase und href sind am Anfang des jnlp-Elements zu
finden. spec beschreibt die der Datei zugrundeliegende Version der Spezifikation.
Das + zeigt an, dass die Deskriptordatei auch für JNLP-Clients geeignet ist, die
eine höhere als die angegebene Spezifikationsversion implementieren. Hinter dem
Attribut codebase ist die Quelle der Applikation in Form einer URL angegeben.
Diese URL dient auch gleichzeitig als Basis, wenn im weiteren Verlauf der
Deskriptordatei relative URL’s angegeben werden, beispielsweise um Ressourcen
zu kennzeichnen. Der Eintrag href zeigt auf die JNLP-Datei selbst, da der JNLP-
Client beim Starten der Applikation die Deskriptordatei eventuell erneut liest, um
sicherzustellen, dass alle Versionen noch korrekt sind.
Das information-Element beinhaltet allgemeine Informationen zur Applikation.
Im Tag steht der Name der Applikation und im Tag
der Hersteller bzw. Anbieter. enthält die URL zur Homepage der
Applikation, wo der Anwender möglicherweise weiterführende Informationen
finden kann (Online-Handbuch etc.). Im Tag kann eine kurze
Beschreibung der Applikation erfolgen. Das zugehörige Attribut kind legt fest, wie
die Beschreibung benutzt wird:
• one-line: Die Beschreibung soll in einer Zeile dargestellt werden.
• short: Die Beschreibung benötigt mehr Platz als nur eine Zeile und kann
über einen Absatz reichen.
• tooltip: Die Beschreibung wird im Tooltip angezeigt.
45 engl. Tag: Kennzeichner
☎
✆
59

Inv.-Nr.:2003-07-02/047/IN96/2253
Es kann jeweils nur ein Element der Beschreibungsart spezifiziert werden. Die
Beschreibung muss mit einfachem Text erfolgen. Formatierungsfunktionen, wie sie
beispielsweise HTML bietet, werden nicht unterstützt.
Das Tag liefert den Speicherort einer GIF- oder JPEG-Datei, die das
Icon für die Applikation enthält. Dieses Icon kann der JNLP-Client während des
Starts der Applikation und im Applikationsmanager anzeigen. Darüber hinaus
kann es für den Shortcut auf dem Desktop verwendet werden. Das optionale
Attribut kind=’’splash’’ im Zusammenhang mit einem weiteren Icon findet
dann Verwendung, wenn während des Starts der Applikation ein vom Standard
abweichender Splash-Screen angezeigt werden soll.
Ist das Tag vorhanden, so zeigt dies an, dass die Applikation
auch ohne bestehende Netzwerkverbindung ausgeführt werden kann.
Eine Besonderheit des information-Elements ist, dass es lokalisiert werden kann.
Dass heißt, eine Deskriptordatei kann mehrere information-Elemente enthalten, die
der JNLP-Client anhand des locale Attributs unterscheiden und verwenden kann.
Innerhalb des security-Elements können die Sicherheitsanforderungen für
die Applikation angegeben werden. Es kann entweder leer bleiben oder eins von
zwei möglichen Tags enthalten. Ist gesetzt, so fordert die
Applikation vollen Zugriff auf alle Systemressourcen des Gastrechners. Das Tag
sollte eingefügt werden, wenn die
Applikation die gleichen Berechtigungen wie ein J2EE-Anwendungs-Client 46
benötigt. Bleibt das security-Element hingegen leer, dann führt der JNLP-Client
die Applikation in der abgeschirmten Sandbox aus.
Mit dem resources-Element können alle Ressourcen die zur Applikation gehören,
spezifiziert werden. Dazu gehören JAR-Dateien, native Bibliotheken, erforderliche
Erweiterungen, Systemeigenschaften und JDK-Versionen. Mit Hilfe der Attribute
os, arch oder lokale können Ressourcen die auf bestimmte Betriebssysteme,
Systemarchitekturen oder Lokalisierungen zugeschnitten sind gekennzeichnet
werden. Der JNLP-Client erkennt das ihm zugrundeliegende System und ist damit
in der Lage, die jeweilig passenden Ressourcen einzusetzen.
Das resources-Element kann sechs verschiedene Unterelemente enthalten:
• Im jar-Element wird eine JAR-Datei angegeben, die zur Applikation gehört
und die Java-Klassen, aber auch Bilder oder Konfigurationsdateien enthalten
kann. Das zugehörige Attribut href wird dazu benötigt, um den Speicherort
der JAR-Datei zu nennen. Weitere optionale Attribute sind version,
download und main. Mit version kann eine bestimmte Version der JAR-
Datei spezifiziert werden, die vom JNLP-Client geladen werden soll. Diese
Versionierung erfordert allerdings zusätzliche Funktionen auf Seiten des
Webservers, die mit Hilfe von CGI-Scripts oder Servlets realisiert werden
können. Standardmäßig werden JAR-Dateien vor dem Start der Applikation
übertragen. Ist jedoch download=’’lazy’’ gesetzt, so ist dies der Hinweis
46 Ein J2EE-Anwendungs-Client ist ein eigenständiges Programm, welches über die Kommandozeile
oder den Desktop gestartet werden kann und typischerweise auf Enterprise JavaBean Programme
eines J2EE-Anwendungs-Servers zugreift.
60

Inv.-Nr.:2003-07-02/047/IN96/2253
für den JNLP-Client, dass die JAR-Datei erst dann geladen werden muss,
wenn sie im Verlauf der Ausführung der Applikation tatsächlich benötigt
wird. Das auf true gesetzte Attribut main zeigt dem JNLP-Client an, dass
die entsprechende JAR-Datei die Hauptklasse der Applikation enthält.
• Im j2se-Element kann eine bestimmte Java2-Runtime-Environment-Version
angegeben werden, die zur Ausführung der Applikation benötigt wird. Sind
mehrere j2se-Element mit unterschiedlichen Versionen vorhanden, so besagt
dies, dass die Applikation mehrere JRE-Versionen unterstützt.
• Das nativelib-Element beschreibt native Bibliotheken, die auf die gleiche
Art wir JAR-Dateien geladen werden können. Nativelib Einträge sind in
der Regel in resources Einträge gekapselt, da sie systemspezifisch sind.
• Im property-Element können Systemeigenschaften für die Applikation
definiert werden, die über die Methoden System.getProperty und
System.getProperties zur Verfügung stehen. Das Element besitzt die zwei
Attribute name und value.
• Das package-Element kann dazu verwendet werden, dem JNLP-Client mitzuteilen,
welche Pakete 47 in welche JAR-Dateien eingebettet sind.
• Im extension-Element kann eine Erweiterung angegeben werden, die im Zusammenhang
mit der Applikation benötigt wird. Eine Erweiterung könnte
beispielsweise eine Installationsroutine sein, die native Bibliotheken vor einem
ersten Start der eigentlichen Applikation auf dem Gastsystem installiert.
Soll die JNLP-Datei als Applikations-Deskriptor Verwendung finden, so muss sie
entweder das application-desc-Element oder das applet-desc-Element enthalten.
Das application-desc-Element besagt, dass über die JNLP-Datei eine Applikation
gestartet wird. Es beinhaltet das Attribut main-class, um auf die Java-Klasse der
Applikation zu zeigen, die die main-Methode enthält sowie das Attribut argument,
mit dem Startparameter an die Applikation übergeben werden können.
Ein JNLP-Client unterstützt auch das Starten von Applets. Dazu dient dann das
applet-desc-Element, das alle benötigten Attribute und Parameter beinhaltet.
Enthält eine JNLP-Datei das component-desc-Element oder das installer-desc-
Element so wird sie als Erweiterungs-Deskriptor bezeichnet. Das componentdesc-Element
wird verwendet, um allgemeine Komponenten zu repräsentieren, die
von Applikationen gemeinsam genutzt werden können. Im installer-desc-Element
sind solche Anwendungen näher spezifiziert, die nur einmal auf dem Gastsystem
47 Pakete dienen in Java zur Organisation von Java-Klassen. Jede Klasse in Java ist Bestandteil
eines Pakets.
61

Inv.-Nr.:2003-07-02/047/IN96/2253
ausgeführt werden. Das geschieht genau dann, wenn die JNLP-Datei zum ersten
Mal aufgerufen wird.
Die JNLP-API Ein weiterer durchaus interessanter Punkt der JNLP-Spezifikation
ist die JNLP-API. Sie stellt zusätzliche Dienste zur Verfügung, die es einer gestarteten
Applikation ermöglichen, über den JNLP-Client mit der Systemumgebung zu
interagieren. Das ist besonders dann wichtig, wenn die Applikation über gar keinen
oder nur eingeschränkten Zugriff auf die Ressourcen des Gastsystems verfügt. In
der JNLP-API sind die folgenden Dienste definiert:[27][34]
• BasicService: Über diesen Dienst, der ähnlich dem AppletContext ist, kann
die Applikation mit der Laufzeitumgebung kommunizieren und bestimmte
Informationen abfragen.
• DownloadService: Der DownloadService erlaubt der Applikation eine gewisse
Kontrolle über die eigenen auf dem Gastrechner gespeicherten Ressourcen.
Mit seiner Hilfe können beispielsweise Ressourcen nachgeladen und
auch lokal gelöscht werden.
• FileOpenService: Der FileOpenService stellt Methoden zur Verfügung, die
es erlauben, Dateien zu lesen, die sich auf einem lokalen Datenträger befinden.
• FileSaveService: Das Pendant zum FileOpenService ist der FileSaveService.
Mit ihm können Daten in Form von Dateien auf einem lokalen Datenträger
gespeichert werden.
• ClipboardService: Der ClipboardService ermöglicht einer Applikation den
Zugang zur systemweiten Zwischenablage, um dort Daten zu lesen und zu
schreiben.
• PrintService: Über diesen Dienst können Druckaufträge an den JNLP-Client
geschickt werden, der sie dann an das System weiterreicht.
• PersistenceService: Der PersistenceService bietet Methoden, mit denen der
jeweilige Zustand einer Applikation persistent auf dem lokalen Gastsystem
gespeichert werden kann. Das dazu verwendete Verfahren ist vergleichbar mit
den Cookies, die bei HTML zum Einsatz kommen. Über den PersistenceService
können Applikationen vom gleichen Anbieter auch untereinander kommunizieren,
dazu werden sie über ihre Herkunfts-URL identifiziert.
• ExtensionInstallerService: Dieser letzte in der JNLP-API definierte Dienst
steht nur solchen Applikationen zur Verfügung, die als sogenannte Extension-
Installer gekennzeichnet sind. Als Extension-Installer kann man Anwendungen
bezeichen, die ein Gastsystem um systemspezifische Ressourcen erweitert
welche von einer anderer Applikation benötigt werden, um korrekt
zu funktionieren. Über den ExtensionInstallerService kann man beispielsweise
das Standard-Speicher-Verzeichnis für Erweiterungen abfragen (i.d.R.
${java.home}/lib/ext) und den Anwender über den Fortschritt der Installation
informieren.
62

Inv.-Nr.:2003-07-02/047/IN96/2253
Für den Anwendungsentwickler gestaltet sich die Einbindung dieser Dienste bei
der Programmierung relativ einfach. Die Lokalisierung eines Dienstes erfolgt über
die lookup-Methode der Klasse ServiceManager unter Angabe des Namens des
gewünschten Dienstes. Danach können die in der JNLP-API definierten Methoden
des jeweiligen Dienstes aufgerufen werden.
3.4.3 Sicherheitsmechanismen und -werkzeuge
Java-Web-Start unterstützt grundsätzlich das Java 2 Sichherheitsmodell. Dass heißt
alle mit WebStart gestarteten Applikationen, die als nicht vertrauenswürdig betrachtet
werden, haben praktisch den selben Status wie Applets und unterliegen damit
den bekannten Restriktionen der Sandbox. Da diese die Funktionalität einer Applikation
jedoch deutlich beeinflussen können, bietet WebStart verschiedene Möglichkeiten,
die es erlauben, einzelne Restriktionen gezielt zu umgehen oder der Applikation
volle Zugriffsrechte auf alle Systemressourcen einzuräumen.
Politik-Objekt Die erste Möglichkeit setzt voraus, dass der Anwender einer Applikation
genau weiß, welche geschützten Systemressourcen diese benötigt und in
welcher Form sie darauf zugreifen möchte. Ist ihm dies bekannt, so kann er die
Rechte, die er der Applikation zubilligen möchte in das Politik-Objekt eintragen
(vergl.: Abschnitt 3.3.1 - Das Java 2 Sicherheitsmodell). Wie bereits beschrieben,
findet üblicherweise als Politik-Objekt die Textdatei .java.policy Verwendung
die sich im Heimatverzeichnis des jeweiligen Benutzers befindet und beim Start der
virtuellen Maschine gelesen wird. Die .java.policy-Datei kann vom Anwender
im Grunde mit jedem beliebigen Texteditor bearbeitet werden. Voraussetzung ist
nur, dass er die von der Java-Laufzeitumgebung geforderte Syntax einhält (vergl.:
Listing 1). Da man aber nicht davon ausgehen kann, dass jeder Anwender gewillt
ist, sich in diese Syntax einzuarbeiten, bietet Sun mit dem Policy Tool ein Werkzeug
an, welches den Anwender bei der Erstellung der eigenen Sicherheitspolitik
unterstützen soll.
Das Policy Tool ist ein Bestandteil der JRE. Nach dem Aufruf mit dem Kommando
policytool erscheint ein graphisches Frontend, das dem Benutzer das aktuelle
Regelwerk anzeigt (vergl.: Abbildung 16). Nach einem Klick auf den Button
Richtlinieneintrag hinzufügen öffnet sich ein Dialogfenster, in dem die Herkunft
(Code-Basis:) und der Unterzeichner (Signiert von:) der Applikation eingetragen
werden können. Durch einen weiteren Klick, diesmal auf den Button Berechtigung
hinzufügen und dem Eintragen der gewünschten Optionen im erscheinenden
Dialog, kann das Regelwerk um eine neue Berechtigung ergänzt werden.
Das Policy Tool generiert danach automatisch den syntaktisch exakten Eintrag für
die .java.policy-Datei. Durch ähnliche Vorgehensweisen können Berechtigungen
auch verändert oder gelöscht werden.
Der Vorteil dieser expliziten Berechtigungsvergabe ist klar. Der Anwender kann
einer Applikation ganz gezielt den Zugriff auf bestimmte Systemressourchen erlauben
den die Restriktionen der Sandbox ohne Modifikation des Politik-Objekts sonst
verhindert hätte. Die folgenden Nachteile liegen jedoch auch auf der Hand:
• Der Autor einer Applikation muss den Anwendern mitteilen, welche sicher-
63

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 16: Frontend des Java-Policy-Tools
heitskritischen Berechtigungen diese auf dem Gastrechner benötigt und wie
sich eine Zurückweisung dieser Berechtigungen auf die Funktionalität der
Applikation auswirken würde.
• Der Anwender muss selbst entscheiden, inwieweit er einer Applikation bzw.
dessen Autor sein Vertrauen schenkt und welche Art von Zugriffen auf
geschützte Systemressourcen gestattet werden. Dies setzt jedoch ein gewisses
Verständnis für die Bedeutung und Wirkungsweise der unterschiedlichen
Berechtigungen voraus.
• Erhöht sich die Anzahl der Applikationen, die Zugriff auf geschützte Systemressourcen
benötigen und über WebStart geladen und ausgeführt werden,
so erhöht sich auch der Administrationsaufwand für das lokale Politik-Objekt.
Der Anwender hat dafür Sorge zu tragen, dass das Politik-Objekt immer in
einer aktuellen und konsistenten Form vorliegt, um keine Sicherheitslücken
entstehen zu lassen.
Dienste der JNLP-API Einen anderen Weg als den oben beschriebenen geht der
Ansatz, bei dem der Autor einer Applikation versucht, sicherheitskritische Zugriffe
auf Systemressourcen an den JNLP-Client (in diesem Fall WebStart) zu delegieren.
Diese Vorgehensweise wird durch die Verwendung der in der JNLP-API definierten
Dienste und durch die Tatsache möglich, dass WebStart vollen Zugriff auf alle
Ressourcen des Systems besitzt. Kommt es nun durch die Applikation zu einem
Zugriffsversuch auf eine geschützte Ressource, so warnt Java-Web-Start den Anwender
und fragt, ob es den Zugriff gestatten soll oder nicht. WebStart öffnet dazu
ein Dialogfenster, in dem die Art des Zugriffs näher beschrieben ist und der Anwender
gefragt wird, ob er den Zugriff erlauben möchte. Abbildung 17 zeigt einen
solchen Sicherheitshinweis.
Der Vorteil dieses Ansatzes ist es, dass der Benutzer praktisch kurz vor der Verlet-
64

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 17: WebStart Sicherheitshinweis
zung der Sicherheitspolitik gewarnt wird und durch einen einfachen Klick auf einen
Button entscheiden kann, ob er den Zugriff auf die Ressource gestatten möchte oder
nicht. Nachteilig wirkt sich aus, dass noch nicht für alle Restriktionen, die die Sandbox
aufgibt Dienste aus der JNPL-API zur Verfügung stehen. So ist es beispielsweise
noch nicht möglich, über den JNLP-Client eine Netzwerkverbindung zu einem
fremden Rechner aufzubauen. Dies ist ja bekanntlich auch eine Restriktion, die die
Sandbox einer Applikation auferlegt. Ein weiterer Nachteil besteht darin, dass es
zwar möglich ist, das WebStart eine einmal durch den Anwender getroffene Entscheidung
bezüglich des Zugriffs auf eine lokale Ressource speichert (die Checkbox
im Dialogfenster wurde aktiviert), nach der Beendigung der Applikation wird
diese Entscheidung aber wieder ”vergessen”. Für den Anwender heißt dies letztendlich,
dass er jedes Mal nach einem Neustart der Applikation die Zugriffserlaubnis
neu erteilen oder verwehren muss, was durchaus als lästig empfunden werden kann.
JNLP-Datei Die letzte hier vorgestellte Möglichkeit, einer über WebStart gestarteten
Applikation mehr Freiräume auf dem Gastsystem einzuräumen, besteht
darin, in der Deskriptordatei uneingeschränkten Zugriff auf alle Ressourcen des
Gastrechners zu fordern. Dies kann der Entwickler einer Applikation ganz einfach
durch den Tag erreichen, den er in das Security-Element der
JNLP-Datei einfügen muss. Der Tag zeigt WebStart an, dass
die Applikation die selben Berechtigungen wie eine lokal installierte Anwendung
wünscht und damit keinen Restriktionen mehr ausgesetzt ist.
Damit einem Angreifer der Versuch erschwert wird, diese Vorgehensweise auszunutzen,
um ”bösartigen” Code einzuschleusen, der gänzlich ohne Restriktionen ausgeführt
wird, fordert WebStart, dass alle JAR-Dateien aus denen eine Applikation
besteht, vom Applikationshersteller digital signiert sind. Eine Signatur des Hashwerts
einer JAR-Datei mit dem privaten Schlüssel des Applikationsherstellers versetzt
WebStart in die Lage, zwei Dinge zu überprüfen:
• Die Quelle der Applikation. Vor dem Start der Applikation prüft WebStart alle
aus der Signatur stammenden Informationen zur Herkunft der Applikation
und zeigt diese in einem Hinweisfenster an (vergl.: Abbildung 18). Zur Verifi-
65

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 18: WebStart Sicherheitswarnung
kation der Signatur benötigt WebStart den enthaltenen öffentlichen Schlüssel
des Applikationsherstellers, der von einer vertrauenswürdigen Instanz zertifiziert
sein sollte.
• Die Unversehrtheit der Applikation. Durch erfolgreiche Überprüfung der digitalen
Signatur ist gewährleistet, dass die JAR-Dateien der Applikation seit
ihrer Signierung nicht verändert wurde. Sollte diese Überprüfung fehlschlagen,
so wird die Applikation nicht gestartet.
Nach erfolgreicher Überprüfung der Signatur durch WebStart kann der Anwender
entscheiden, ob er dem Hersteller der Applikation vertraut oder nicht. Über den in
Abbildung 18 dargestellten Hinweisdialog kann er WebStart seine Entscheidung
mitteilen. Vertraut der Anwender dem Applikationshersteller so klickt er auf den
”Starten”-Button und die Applikation startet mit den selben Berechtigungen wie
eine lokal installierte Anwendung. Ein Klick auf den ”Beenden”-Button zeigt
WebStart das Misstrauen des Anwenders an, was dazu führt, dass die Applikation
nicht ausgeführt wird.
Auch an dieser Stelle sei noch einmal darauf hingewiesen, dass mit einer Signatur
nicht der Funktionsumfang oder die Semantik eines Programms geprüft werden
kann. Es soll mit ihr vielmehr ein Ersatz für das Vertrauen geschaffen werden, das
ein Händler seinen Kunden dadurch bietet, dass er Software in einer geschlossenen
Verpackung zum Verkauf anbietet (Unversehrtheit des Inhalts) und garantiert, dass
diese Software vom Originalhersteller stammt [30].
Die bis hierher gemachten Aussagen zum Thema Sicherheit in Java-Web-Start betrafen
hauptsächlich den Bereich: Schutz des Gastrechners vor dem mobilen Code.
In den nun folgenden Ausführungen sollen Sicherheitsmechanismen vorgestellt
werden, mit denen der mobile Code selbst geschützt werden kann.
Bis zur Einführung der Web-Start-Version 1.2 im Herbst 2002 war das Signieren
der JAR-Dateien die einzige Möglichkeit, eine Applikation zu schützen.
Da Signaturen aber nur die Integrität des Programmcodes sicherstellen können
nicht aber die Vertraulichkeit, wurde der Ruf der Anwender nach Techniken
laut, die es erlauben Applikationen während des Downloads zu ver-
66

Inv.-Nr.:2003-07-02/047/IN96/2253
schlüsseln. Durchsucht man genau zu diesem Thema die WebStart-FAQ 48
(http://java.sun.com/products/javawebstart/faq.html) so findet man
eine Frage, die sich mit dem verschlüsselten Laden von JAR-Dateien beschäftigt.
Die Antwort der WebStart-Entwickler darauf könnte man als etwas zweideutig
auffassen. Auf der einen Seite wird darauf hingewiesen, wie wichtig ein geschützter
Datenaustausch zwischen Client und Server ist. Auf der anderen betrachtet man
ein verschlüsseltes Laden von JAR-Dateien nicht unbedingt als erforderlich, da
diese clientseitig wieder entschlüsselt und gespeichert werden müssen, um der
virtuellen Maschine den Zugriff auf die beinhalteten Klassen zu ermöglichen.
Sicherlich ist diese Tatsache auch richtig, wenn man davon ausgeht, dass alle
Applikationen auf frei zugänglichen Webservern zur Verfügung gestellt werden.
Eine sichere Übertragung würde dann keinen Sinn machen, da sich jeder die
Applikationen downloaden könnte. Ist der Zugang zum Webserver aber geschützt
und nur bestimmten Personen erlaubt, so kann eine sichere Übertragung des
Programmcodes eine wichtige Rolle spielen. Dies ist möglicherweise auch ein
Grund, warum die Entwickler von Java-Web-Start in Version 1.2 den Wünschen der
Anwender entsprochen haben und mit der Unterstützung von HTTPS (respektive
SSL) die geschützte Übertragung von JAR-Dateien erlauben.
HTTP über SSL (HTTPS) Da das Hypertext Transfer Protokoll (HTTP)
während der Übertragung von Daten keine Verschlüsselung unterstützt, ist es für
sicherheitskritische Anwendungen ungeeignet. Diese Unsicherheit von HTTP war
historisch gesehen der Grund, warum das kryptographische Protokoll SSL (vergl.:
Abschnitt 2.5.2) entwickelt wurde. SSL kann durch seine Lage zwischen TCP
und einem Protokoll der Anwendungsschicht sehr gut im Zusammenspiel mit
HTTP verwendet werden. Vorteilhaft ist auch, dass SSL mit dem ApplicationData-
Protokoll einen Bestandteil hat, der auf das darüber liegende Protokoll (in diesem
Fall HTTP) abgestimmt werden kann. Alle gängigen Web-Browser und -Server
unterstützen daher nicht nur HTTP sondern liefern das darunter liegende SSL
gleich mit. Wird HTTP zusammen mit SSL eingesetzt, so nennt man dieses
Protokollpaar HTTPS. HTTPS verfügt über alle die Sicherheitsmerkmale, die SSL
auch bietet.
Will ein Anwender HTTPS einsetzen, dann muss die in den Browser eingegebene
URL mit ”https” beginnen. Ist dies der Fall, dann versucht der Browser, eine
SSL-Verbindung aufzubauen. Unterstützt der Webserver ebenfalls SSL, so kann
die folgende Kommunikation mit SSL geschützt werden.
Soll WebStart die Ressourcen einer Applikation über HTTPS laden, muss
dies in der JNLP-Datei angegeben werden. Beginnt die URL hinter dem Attribut
”codebase” im JNLP-Element mit ”https” so versucht WebStart eine sichere
Verbindung zum Webserver aufzubauen um darüber den Download durchzuführen.
Damit der Verbindungsaufbau gelingt, muss der entsprechende Webserver seinerseits
ebenfalls HTTPS unterstützen.
Mit der Veröffentlichung der JRE-Version 1.4.2-Beta im Frühjahr 2003 unterstützt
WebStart auch das dynamische Einbinden von SSL-Webserver-Zertifikaten wie
48 FAQ: Frequently Asked Questions - häufig gestellte Fragen
67

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 19: WebStart HTTPS-Sicherheitswarnung
man es auch von den meisten Browsern her kennt. Abbildung 19 zeigt einen Dialog
in dem WebStart den Anwender fragt, ob er dem SSL-Zertifikat des Webservers
vertrauen möchte. Dieser Sicherheitsdialog erscheint immer dann, wenn WebStart
die zertifizierende Instanz nicht kennt bzw. als nicht vertrauenswürdig erachtet. Der
Anwender kann WebStart durch einen Klick auf den Button ”Ja” bzw. ”Immer”
mitteilen, dass er dem Serverzertifikat vertraut und die Ressourcen der Applikation
geladen werden sollen. Ein Klick auf den ”Nein”-Button veranlasst WebStart,
die Verbindung zum Webserver zu beenden. Hinter dem Button ”Mehr Details”
verbirgt sich ein Fenster das mehr Informationen über das SSL-Zertifikat beinhaltet,
unter anderen auch den Zertifizierungspfad.
Durch den Einsatz von HTTPS bzw. SSL wird nicht nur das geschützte Laden von
Ressourcen ermöglicht sondern auch die weiter oben angesprochene Forderung
nach einem starken Authentifizierungsverfahren erfüllt (vergl.: Abschnitt 3.3.2).
Mit den Funktionen, die SSL zur Verfügung stellt, ist es möglich, einen Nachweis
über die Authentizität der Adresse des Webservers (Quell-Rechners) zu erbringen.
Somit kann der Anwender sicher sein, dass er die Applikation vom ”richtigen”
WebServer lädt.
3.4.4 Bewertung von Java-Web-Start und Verbesserungsvorschläge
Mit Java-Web-Start oder spezieller dem Java Network Launching Protokoll steht
eine Technologie zur Verfügung, in der die Idee, die hinter Java-Applets steht
konsequent weiterentwickelt und verbessert wurde. WebStart ermöglicht es dem
Anwender, dessen Rechner an einem Netzwerk angeschlossen ist, auf einfache
und bequeme Weise Java-Applikationen zu nutzen, ohne sich darum kümmern zu
müssen, wie die Applikation installiert wird oder wie ein Update durchzuführen
ist. In Bezug auf die Anwenderfreundlichkeit von Java-Applikationen wurde mit
WebStart ein Schritt in die richtige Richtung gemacht.
Für Software-Hersteller eröffnet WebStart zumindest für kleinere Anwendungen
neue Wege für deren Distribution. Bei der heute jedoch weit verbreiteten
68

Inv.-Nr.:2003-07-02/047/IN96/2253
DSL 49 -Technologie und Programmen, die auch in der nicht installierten Form
mehrere hundert Megabyte umfassen, ist die Download-Zeit über ein Netzwerk
leider noch viel zu lang. Es wäre also vermessen, zu behaupten, dass WebStart
die klassischen Distributionsmittel, wie Diskette, CD und DVD in naher Zukunft
ablösen wird. Dennoch für große Netzwerke, wie beispielsweise Firmennetze, in
denen möglicherweise sogar schon Gigabit-Ethernet-Technik zum Einsatz kommt,
stellt WebStart mit Sicherheit eine interessante Alternative zur herkömmlichen
Verteilung von Software dar. Nicht zuletzt, weil zeitaufwendige Installationsund
Wartungsprozesse der Software auf einer Vielzahl von Einzelplatzsystemen
entfallen.
In Bezug auf die Benutzerakzeptanz wäre es wünschenswert, wenn Java-Web-Start
oder ähnliche Ansätze ihren Weg in die Betriebssysteme finden würden, so dass
diese Technologien schon nach der Installation des Betriebssystems zur Verfügung
stehen. Allerdings ist das wohl in naher Zukunft nicht zu erwarten.
Mit der Unterstützung von SSL in der WebStart-Version 1.2 ist zum einen
ein deutlich verbesserter Schutz des mobilen Codes während der Übertragung
möglich. Zum anderen kann mit Hilfe von SSL auch der Webserver authentifiziert
werden. Aber auch der Schutz des Gastrechners spielt ganz allgemein in Java und
insbesondere bei WebStart eine wichtige Rolle.
Das Java Network Launching Protokoll bietet mit der zugehörigen API praktisch
ein erweitertes Sandkastenmodell. Durch die Dienste, die die API zur Verfügung
stellt, können einige sicherheitskritische Zugriffe auch Ressourcen des Gastrechners
durchgeführt werden, die normalerweise die Sandbox verhindern würde.
Da die Zugriffe einzeln vom Anwender erlaubt werden müssen, kommt diese
Vorgehensweise der Forderung nach minimalen Zugriffsrechten für Applikationen
ziemlich nahe. Wünschenswert wäre nur, dass sich WebStart die Entscheidungen
des Anwenders auch über einen Neustart der Applikationen hinaus merken könnte
und dass die WebStart-Entwickler noch weitere Dienste zu der jetzt schon bestehenden
Menge hinzufügen.
Der Autor dieser Arbeit könnte sich auch vorstellen, dass die Berechtigungen, die
eine Applikation auf einem Gastsystem benötigt, im security-Element der Deskriptordatei
festgehalten werden. Dort kann der Entwickler, der die Anforderung seiner
Applikation genau kennt, die gewünschten Berechtigungen eintragen. Listing 3
zeigt beispielhaft wie die Einträge des security-Elements der Deskriptordatei
aussehen könnten.
49 DSL: Digital Subscriber Line
69

Inv.-Nr.:2003-07-02/047/IN96/2253
✞
Listing 3: Fiktives security-Element
☎
...
...
✝
✆
WebStart bzw. der JNLP-Client könnte das security-Element auslesen und die geforderten
Berechtigungen in einem Dialogfenster, wie es in Abbildung 20 zu sehen
ist, dem Anwender darstellen. Dieser kann dann vor dem Start der Applikati-
Abbildung 20: Möglicher WebStart Sicherheitshinweis
on entscheiden, welche Zugriffe er auf lokale Systemressourcen gestatten möchte.
Durch Java-Web-Start ist danach sicherzustellen, dass die Applikation auch nur genau
die als sicherheitskritisch betrachteten Berechtigungen zugebilligt bekommt,
die im security-Element gefordert und vom Anwender genehmigt wurden. Sollte
sich der Anwender dazu entschließen, eine oder mehrere Berechtigungen nicht zu
erteilen, so müsste WebStart ihn darüber informieren, welche Konsequenzen dies
für die Funktionalität der Applikation hat (vergl.: Listing 3 - deny-hint).
70

Inv.-Nr.:2003-07-02/047/IN96/2253
4 Sichere Kommunikation zwischen Front- und
Backend
Im vorangegangenen Abschnitt wurde mit Java-Web-Start eine Technologie vorgestellt,
die es erlaubt, das Frontend des DPAC-Informationssystems sicher in einem
Netzwerk zu verteilen. Der nun folgende Abschnitt betrifft den Bereich der Kommunikationssicherheit
(vergl.: Abschnitt 2.5) und beschäftigt sich mit der Frage:
Wie kann eine sichere Kommunikation zwischen Front- und Backend realisiert werden?
Bevor diese Frage jedoch konkret beantwortet wird, soll zunächst die Client-
/Server-Architektur des DPAC-Informationssystems kurz vorgestellt werden. Eine
ausführlichere Betrachtung wird dann später im Abschnitt 5.1 vorgenommen.
Wie Abbildung 21 verdeutlicht, kommuniziert das DPAC-Frontend nicht direkt mit
dem Backendsystem. Vielmehr ist ein sogenannter Anwendungsserver als eine Art
Vermittler zwischengeschaltet, in dem die Geschäftslogik des Systems verankert ist.
Da die Kommunikation zwischen Anwendungsserver und Backendsystem in der
Regel über ein privates nach ”außen” abgeschirmtes Netzwerk (Intranet) erfolgt,
soll das Hauptaugenmerk dieses Abschnitts in der Sicherung der Verbindung zwischen
Client (Frontend) und Anwendungsserver liegen. Grund hierfür ist, dass zum
Herstellen dieser Verbindung auch öffentliche Netzwerke genutzt werden könnten
(Stichwort Außendienstmitarbeiter).
Abbildung 21: Eine 3-tier-Architektur
Für die Kommunikation zwischen den Clients und dem Anwendungsserver
soll im DPAC-Informationssystem Java’s Remote Method Invocation (kurz RMI)
zum Einsatz kommen. Diese speziell für Java-Programme konzipierte Middleware-
Technologie eignet sich besonders für das DPAC-Informationssystem, da sie relativ
einfach zu integrieren ist und es sich sowohl beim Anwendungsserver als auch
beim Client um eine Java-Applikation handelt. Nach einer kurzen Einführung in die
RMI-Technologie sollen im weiteren Verlauf dieses Abschnittes Sicherheitsmechanismen
vorgestellt werden, mit denen eine RMI-Kommunikation geschützt werden
kann.
71

Inv.-Nr.:2003-07-02/047/IN96/2253
4.1 Java RMI
4.1.1 Einführenden Erläuterungen
Da eine detaillierte Beschreibung von RMI im Rahmen dieser Arbeit zu weit
führen würde, soll an dieser Stelle nur eine kurze Einführung in das Thema
gegeben werden.
Durch Remote Method Invocation können Java-Objekte in verschiedenen virtuellen
Maschinen über ganz normale Methoden-Aufrufe so miteinander kommunizieren,
als wären sie in der selben virtuellen Maschine allokiert.
Im Grunde genommen, sind es immer drei Parteien, die an einer RMI-Konferenz
beteiligt sind: Ein Server, ein Client und ein Verzeichnisdienst, die sogenannte
Registry. Der Server bietet Dienstleistungen an, die von einem Client, der auf einer
anderen virtuellen Maschine - remote - ausgeführt wird, in Anspruch genommen
werden können. Eine Dienstleistung besteht aus einem Remote-Objekt, dass auf
dem Server zu Hause ist und spezielle Methoden enthält, die vom Client aufgerufen
werden können. Die Registry hilft dem Client bei der Suche nach einem Server
und seinem Remote-Objekt. Voraussetzung hierfür ist, dass der Server vorher
sein Remote-Objekt bei der Registry unter Verwendung eines Aliases angemeldet
hat. Ganz allgemein dargestellt, sieht der Ablauf für den Aufruf einer entfernten
Methode via RMI wie folgt aus:[48]
• Der Client-Stub 50 stellt eine Verbindung mit der virtuellen Maschine her, die
das entfernte Objekt enthält. Die Objektreferenz erhält der Client vom Verzeichnisdienst
(Registry) unter Angabe des assozierten Namens (Alias).
• Die zu übertragenden Methoden-Argumente werden verpackt (Marshalling)
und per Serialisierung 51 an die entfernte VM versandt.
• Der Client wartet, bis der Server die aufgerufene Methode des Remote-
Objekts abgearbeitet hat und die Resultate zum Client überträgt.
• Auf der Serverseite:
– Die Argumente, die der Client übertragen hat, werden vom Server ausgepackt
(Unmarshalling).
– Der Server führt die gewünschte Methode mit den vom Client erhaltenen
Argumenten aus.
– Das Resultat oder eine Ausnahme wird verpackt (Marshalling) und an
den aufrufenden Client per Serialisierung übertragen.
50 Der Stub ist ein clientseitiger Stellvertreter für das auf dem Server befindliche Remote-Objekt.
51 Unter Serialisierung wird die Fähigkeit verstanden, ein Objekt, das im Hauptspeicher der Anwendung
existiert, in ein Format zu konvertieren, das es erlaubt, das Objekt in eine Datei zu schreiben
oder über eine Netzwerkverbindung zu transportieren. Dabei wird natürlich auch den umgekehrten
Weg eingeschlossen, also das Rekonstruieren eines in serialisierter Form vorliegenden Objekts
in das interne Format der laufenden Java-Maschine.
72

Inv.-Nr.:2003-07-02/047/IN96/2253
• Der Client-Stub packt den Rückgabewert - oder die auf Serverseite ausgelöste
Ausnahme - aus (Unmarshalling).
• Der ermittelte Wert wird an die Aufrufstelle des Clients weitergereicht.
Die gesamte RMI-Netzwerk-Kommunikation zwischen Client, Server und Registry
wird über Java-Sockets 52 abgewickelt. Das verwendete Protokoll ist in der Anwendungsschicht
angesiedelt und trägt den Namen Java Remote Method Protocol 53
(kurz JRMP).
4.1.2 Sicherheit in RMI
Java RMI stellt einen relativ einfachen Weg dar, um eine verteilte Java-Anwendung
zu entwickeln. Aus sicherheitstechnischer Sicht weist RMI jedoch einige Probleme
auf:[18]
• RMI ist ein einfacher Ansatz, um eine Kommunikation zwischen Client und
Server zu ermöglichen. Objekte werden serialisiert und über ein Netzwerk
übertragen. Dabei findet keine Verschlüsselung der Objekte statt, so dass jeder
im Netzwerk die übertragenen Daten mitlesen könnte.
• Es existieren im RMI weder für den Client noch für den Server entsprechende
Authentifizierungsmechanismen.
• Es gibt keine Zugriffskontrollmöglichkeiten für serverseitige Remote-
Objekte. Somit ist es praktisch jedem (RMI-) Client erlaubt, die Remote-
Objekte des Servers zu nutzen.
• Durch fehlende Sicherheitskontrollen im Verzeichnisdienst Registry ist es im
Grunde jedem Aufrufer möglich, Anfragen über Remote-Objekte zu stellen.
• Netzwerk- und Serverfehler lösen Ausnahmen aus. Die Anwendung, die RMI
nutzt, muss darauf vorbereitet sein, diese zu verarbeiten.
Mal abgesehen vom Security-Manager, der gestartet werden muss, bevor eine entfernte
Klasse geladen werden kann, bietet RMI wie die obigen Ausführungen zeigen
keine nennenswerten Sicherheitsmechanismen. Insbesondere ist es mit dem ”reinen”
RMI nicht möglich, die Vertraulichkeit, Integrität und Authentizität der übertragenen
Daten zu gewährleisten. Die Verwendung des Ausdrucks ”reines” RMI
ergibt sich aus der Tatsache, dass 1999 ein Entwurf für eine Erweiterung (Java RMI
Security Extension) vorgestellt wurde, welche RMI um einige Sicherheitsmechanismen
ergänzt. Leider hat diese Erweiterung, mit der unter anderem das gegenseitige
Autenifizieren von Client und Server sowie eine Verschlüsselung der Kommunikation
unterstützt werden sollte, ihren Weg in das Java-Software-Developer-Kit noch
nicht gefunden. Wie dennoch eine RMI-Kommunikation abgesichert werden kann,
wird im Folgenden beschrieben.
52 Ein Socket (Kommunikationsendpunkt) ist eine Schnittstelle zum Netzwerk. Er ist durch die
IP-Adresse eines Rechners zusammen mit einer Portnummer eindeutig identifizierbar.
53 JRMP ist ein proprietäres Protokoll für den Aufruf entfernter Methoden in einem System verteilter
Java-Objekte.
73

Inv.-Nr.:2003-07-02/047/IN96/2253
4.1.3 Sicherung der RMI-Kommunikation
Im wesentlichen gibt es, in Bezug auf die Verwendung von Mechanismen die Java
zur Verfügung stellt, zwei grundlegende Ansätze, um die Kommunikation zwischen
den beteiligten RMI-Partnern zu schützen. Der erste Ansatz verfolgt die Sicherung
der Kommunikation auf Anwendungsebene. Dass heißt, innerhalb der RMInutzenden
Anwendungen (Client- und Serverprogramm) werden geeignete Verfahren
angewandt, um die Vertraulichkeit, Integrität und Authentizität der übertragenen
Daten zu gewährleisten. Die Java Cryptography Extension (kurz JCE) beispielsweise
stellt solche geeigneten Verfahren zur Verfügung.
JCE Mit Erscheinen des JDK 1.2 wurde eine Erweiterung für die Java Cryptography
Architecture (JCA), die JCE vorgestellt. Historisch gesehen, war die Entwicklung
der JCE deshalb notwendig geworden, weil restriktive Exportbestimmungen
der USA die Ausfuhr gewisser kryptographischer Software untersagten. Sun entschied
sich deshalb dafür, jene Klassen, die nicht von dieser Regelung betroffen
sind, in der JCA und die restlichen in der JCE zusammenzufassen. [16] Mittlerweile
sind diese Exportbestimmungen aber gelockert worden und die JCE ist fester
Bestandteil des SDKs (ab Version 1.4). Die JCE erweitert die bereits vorhandenen
Sicherheits-APIs der JCA mit den folgenden Funktionen:[38]
• Symmetrische Verschlüsselung für Blockchiffren (DES, 3DES, AES 54 )
• Symmetrische Verschlüsselung für Stromchiffren (RC4)
• Asymmetrische Verschlüsselung (RSA)
• Password Based Encryption (PBE)
• Schlüsselgenerierung symmetrischer Schlüssel
• Schlüsselvereinbarung (-austausch)
• Message Authentication Code (MAC)
• Verschlüsselung von serialisierbaren Objekten
Mit Hilfe der JCE ist es also möglich, die Anwendungsdaten, die zwischen RMI-
Client und -Server ausgetauscht werden zu schützen. Der Anwendungsentwickler
kann dazu die oben angeführten Funktionen einsetzten. Zu bedenken ist, dass
bei diesem Ansatz nur die Anwendungsdaten geschützt werden, nicht aber die
Informationen die vom JRMP hinzugefügt und ausgetauscht werden.
Der zweite Ansatz, eine RMI-Kommunikation zu schützen, der hier beschrieben
werden soll, setzt auf die Verwendung von sicheren Übertragungsprotokollen.
Aufgrund der Tatsache, dass RMI mit Sockets arbeitet und dass JRMP auf der
Anwendungsebene angesiedelt ist, erscheint der Einsatz eines Protokolls wie SSL
oder TLS (vergl.: Abschnitt 2.5.2) durchaus als sinnvoll und praktikabel. Um SSL
in Java nutzen zu können, bietet Sun mit der Java Secure Socket Extension (kurz
JSSE) eine eigens dafür konzipierte API an.
54 Ab Java 2 SDK 1.4.2
74

Inv.-Nr.:2003-07-02/047/IN96/2253
JSSE Die Java Secure Socket Extension wurde von Sun als Standard-API für
die Verwendung von SSL bzw. TLS in Java definiert. Sie geht von der Klasse
java.net.Socket aus und leitet diese ab, wodurch SSL-Sockets überall da eingesetzt
werden können, wo ”normale” Sockets Verwendung finden, also auch bei
RMI. Die JSSE ist aber nicht nur Standard-API sondern auch gleichzeitig eine
dazu passende Referenzimplementierung von Sun, die wie die JCE in das Java
2 SDK ab Version 1.4 integriert ist. Die Eigenschaften und Funktionen die
die JSSE-Referenzimplementierung bietet, lassen sich mit folgenden Stichpunkten
beschreiben:[39]
• Hundertprozentige Java-Implementierung
• Unterstützung von SSL v3
• Unterstützung von TLS v1.0
• Bereitstellung von Werkzeugen für das Schlüssel- und Zertifikatsmanagement
• Bereitstellung der Klassen SSLSocket und SSLServerSocket mit denen der
Aufbau sicherer Kanäle realisiert werden kann
• Unterstützung von HTTPS
• Verwaltung von SSL-Sitzungen
• Unterstützung der Client-/Server-Authentifizierung, als Teil des SSL-
Handshakes
• Unterstützung verschiedenster kryptographischer Verfahren
(vergl.: Tabelle 1)
Kryptographisches Verfahren
max. Schlüssellänge (Bits) a
RSA (Authentifizierung) 2048
RSA (Schlüsselaustausch) 2048
AES b (Blockverschlüsselung) 256
RC4 (Blockverschlüsselung) 128
DES (Blockverschlüsselung)
64 (56 effektiv)
Triple DES (Blockverschlüsselung) 192 (108 effektiv)
Diffie-Hellman (Schlüsselvereinbarung) 1024
DSA (Authentifizierung) 1024
a Die aufgeführten maximalen Schüssellängen sind die, die von der JSSE unterstützt werden.
Durch die in machen Ländern geltenden Ex- und Importbeschränkungen für kryptographische Produkte
kann es hier zu Veränderungen kommen.
b Ab Java 2 SDK v1.4.2
Tabelle 1: Unterstützte kryptographische Verfahren der JSSE
75

Inv.-Nr.:2003-07-02/047/IN96/2253
Alle Klassen der JSSE-Implementierung sind im Paket javax.net.ssl enthalten.
Dabei zählen die Klassen SSLContext, SSLSocket, SSLSession, TrustManager
und KeyManager wohl zu den wichtigsten, die benötigt werden, um eine SSL-
Verbindung aufzubauen.
Die Klasse SSLContext ist die Kernklasse für die JSSE-Implementierung.
Sie repräsentiert eine Implementation eines Protokolls, beispielsweise SSL
oder TLS und ist in der Lage, SSL-Socket-Factories 55 zu erzeugen, welche
ihrerseits wiederum zur Erzeugung von SSLSockets benötigt werden. SSL-
Context unterstützt das Provider-Interface, dass es Fremdanbietern (Provider)
ermöglicht, ihre eigenen Implementierungen in das JSSE-System zu integrieren.
Durch den Aufruf SSLContext.getInstance und der Angabe des gewünschten
Protokolls sowie wahlweise des Providernamens wird ein Objekt erzeugt,
welches das angegebene Protokoll implementiert. Ein anschließender Aufruf
der Methode getSocketFactory bzw. getServerSocketFactory liefert ein
SSLSocketFactory- bzw. SSLServerSocketFactory-Objekt, mit dem SSLSockets
bzw. SSLServerSockets erzeugt werden können, über die dann ein sicherer Datenaustausch
stattfinden kann. [16]
Auf der Seite des Clients kommen Objekte der Klasse SSLSocket zum Einsatz, die
wie bereits beschrieben von einer SSLSocketFactory erzeugt werden. Neben den
typischen Funktionen, über die jedes Socket-Objekt verfügt, bietet es zusätzlich
noch Möglichkeiten, um das Verhalten der SSL-Implementation zu steuern. Den
SSLSocket für den Server liefert die accept()-Methode des SSLServerSocket-
Objekts.
Ein Objekt der Klasse SSLSession enthält die Informationen über den Sicherheits-
Zustand einer Verbindung zwischen einem SSL-Client und -Server. Diese
Informationen können über mehrere Verbindungen hinweg verwendet werden, um
beispielsweise das SSL-Handshake-Verfahren zu verkürzen, da im SSLSession-
Objekt unter anderem kryptographische Verfahren und verwendete Schlüssel von
den vorangegangenen SSL-Sitzungen (Sessions) gespeichet sind und somit nicht
neu ausgehandelt werden müssen. Ein SSLSession-Objekt erhält man über die
Methode getSession() des entsprechenden SSLSockets.
Mit Hilfe der Klasse TrustManager können die vom Kommunikationspartner
gelieferten Authentifizierungsinformationen überprüft werden. Bei diesen Informationen
handelt es sich zumeist um X.509 Zertifikate (vergl.: Abschnitt 2.4.5).
Es können aber auch andere Verfahren eingesetzt werden. Ein Objekt der Klasse
TrustManager kann mittels der TrustManagerFactory-Klasse erzeugt werden.
Um sich dem Kommunikationspartner gegenüber zu authentifizieren, benötigt ein
SSL-Context einen geeigneten KeyManager. Die Klasse KeyManagerFactory kann
ein solches benötigtes KeyManger-Objekt erzeugen. Für jede Authentifizierungsmethode,
die man verwenden möchte, bedarf es jeweils eines KeyManagers. [16]
55 Eine Factory ist ein Hilfsmittel zum Erzeugen von Objekten. Sie wird verwendet, wenn das Instanzieren
eines Objekts mit dem new-Operator allein nicht möglich oder sinnvoll ist - etwa weil das
Objekt schwierig zu konstruieren ist oder aufwendig konfiguriert werden muss, bevor es verwendet
werden kann [15].
76

Inv.-Nr.:2003-07-02/047/IN96/2253
Das nachfolgende Listing 4 zeigt beispielhaft wie ein SSLSocket-Objekt für
eine Client-Anwendung erzeugt werden kann und verdeutlicht das Zusammenspiel
der oben genannten Klassen.
✞
Listing 4: SSL-Client
import javax.net.ssl.*;
import java.security.SecureRandom;
import java.security.KeyStore;
import java.io.FileInputStream;
☎
public class SSLClient {
public SSLClient(){
SecureRandom secureRandom;
KeyStore clientKeyStore;
KeyStore serverKeyStore;
TrustManagerFactory tmf;
KeyManagerFactory kmf;
SSLContext sslContext;
SSLSocketFactory sf;
SSLSocket sec_socket;
char[] passphrase;
/*KeyStore-Kennwort*/
passphrase = "Passwort".toCharArray();
/*Erzeugen ein kryptographischen Zufallszahl*/
secureRandom = new SecureRandom();
secureRandom.nextInt();
try {
/*Privaten Schluessel des SSL-Clients laden, dieser wird
*spaeter zur Authentifizierung, vom SSLContext benoetigt*/
clientKeyStore = KeyStore.getInstance("JKS");
clientKeyStore.load(new FileInputStream("/client.private"),passphrase);
/*Oeffentlichen Schluessel der SSL-Server laden um empfangene
* Authentifizierungsinformationen ueberpruefen zu koennen*/
serverKeyStore = KeyStore.getInstance("JKS");
serverKeyStore.load(new FileInputStream("/server.public"),passphrase);
/*Erzeugen einer KeyManagerFactory die den KeyManager liefert*/
kmf = KeyManagerFactory.getInstance("SUNX509");
kmf.init(clientKeyStore,passphrase);
/*Erzeugen einer TrustManagerFactory die den TrustManager liefert*/
tmf = TrustManagerFactory.getInstance("SUNX509");
tmf.init(serverKeyStore);
/*Erzeugung eines SSLContext-Objekts welches TLS implementiert und
*mit dem KeyManager,TrustManager der secureRandom inizialisiert wird*/
sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(),tmf.getTrustManagers(),secureRandom);
/*Der SSLContext liefert die SSLSocketFactory, die ihrerseits
*den SSLSocket liefert*/
sf = sslContext.getSocketFactory();
sec_socket = (SSLSocket)sf.createSocket("db.haecker-automation.com", 9335);
/*Ab hier kann der SSLSocket dann weiter verwendet werden
.....
*/
} catch (Exception e) {
e.printStackTrace();
}
}
}
✝
✆
77

Inv.-Nr.:2003-07-02/047/IN96/2253
Auf der Seite des SSL-Servers gestaltet sich die Generierung eines SSL-
Sockets ähnlich wie beim Client. Unterschiede bestehen lediglich darin, dass
der KeyManagerFactory der private Schlüssel des Servers zur Verfügung stehen
muss und dass, wenn eine Client-Authentifizerung durchgeführt werden soll
(SSLServerSocket.setNeedClientAuth(true)), der TrustManagerFactory die
öffentlichen Schlüssel der Clients bekannt sind. Beim Client ist es, wie Listing 4
zeigt, verständlicherweise genau umgekehrt. Auch in Bezug auf die SSLSocketFactory
gibt es einen Unterschied. Der Server benötigt im Gegensatz zum Client eine
SSLServerSocketFactory, die ein SSLServerSocket-Objekt erzeugen kann. Den eigentlichen
SSLSocket über den dann die Kommunikation mit dem Client stattfindet,
liefert die accept()-Methode des SSLServerSocket-Objekts. In Listing 5 sind die
Unterschiede zum Client bei der Erzeugung eines SSLSockets auf Serverseite noch
einmal dargestellt.
✞
public class SSLServer {
Listing 5: SSL-Server
☎
public SSLServer(){
SSLServerSocketFactory ssf;
SSLServerSocket sec_serv_socket;
/*... Wie beim Client (vergl.: Listing 4) ...*/
try {
/*Privaten Schluessel des SSL-Servers laden, dieser wird
*spaeter zur Authentifizierung, vom SSLContext benoetigt*/
serverKeyStore = KeyStore.getInstance("JKS");
serverKeyStore.load(new FileInputStream("/server.private"),passphrase);
/*Oeffentliche Schluessel der SSL-Clients laden um empfangene
* Authentifizierungsinformationen ueberpruefen zu koennen*/
clientKeyStore = KeyStore.getInstance("JKS");
clientKeyStore.load(new FileInputStream("/client.public"),passphrase);
/*Erzeugen einer KeyManagerFactory die den KeyManager liefert*/
kmf = KeyManagerFactory.getInstance("SUNX509");
kmf.init(serverKeyStore,passphrase);
/*Erzeugen einer TrustManagerFactory die den TrustManager liefert*/
tmf = TrustManagerFactory.getInstance("SUNX509");
tmf.init(clientKeyStore);
/*... Wie beim Client (vergl.: Listing 4) ...*/
/*Der SSLContext liefert die SSLServerSocketFactory, die ihrerseits
*den SSLServerSocket liefert*/
ssf = sslContext.getServerSocketFactory();
sec_serv_socket = (SSLServerSocket)ssf.createServerSocket(9335);
/*Client Authentifizierung einschalten*/
sec_serv_socket.setNeedClientAuth(true);
/*Warten auf einen Verbindungswunsch*/
sev_socket = sec_serv_socket.accept();
/*Ab hier kann der SSLSocket dann weiter verwendet werden
.....
*/
} catch (Exception e) {
e.printStackTrace();
}
}
}
✝
✆
78

Inv.-Nr.:2003-07-02/047/IN96/2253
Die Listings 4 und 5 machen deutlich, dass sich die Java Secure Socket Extension
relativ einfach einsetzen lässt. Mit der JSSE-Referenzimplementierung von Sun ist
es praktisch möglich, nahezu jede Kommunikation, die über Sockets stattfindet,
durch SSL bzw. TLS zu schützen.
Neben der JSSE-Referenzimplementierung von Sun bieten auch andere Hersteller
eigene SSL-Implementierungen für Java an. Nennenswert ist hier zum Beispiel die
Implementierung iSaSiLk des Instituts für Angewandte Informationsverarbeitung
und Kommunikationstechnologie (IAIK) der Technischen Universität Graz. iSaSiLk
bietet gegenüber der JSSE eine ganze Menge mehr Cipher-Suites sowie Einstellungsmöglichkeiten
und damit eine verbesserte Flexibilität. Weitere Informationen
zur iSaSiLk und anderen kryptographischen Produkten (z.B. IAIK-JCE) findet man
auf der Webseite des IAIK [12]. Von dort können auch kostenlose Evaluationskopien
der Produkte bezogen werden.
Für den speziellen Fall der RMI-Kommunikation zwischen DPAC-Client und
-Server bietet der Einsatz einer JSSE-Implementierung unter anderem die
folgenden Vorteile:
• Einfache Integrationsmöglichkeit Die JSSE lässt sich relativ einfach in Anwendungen
integrieren die RMI nutzen. Das liegt nicht zuletzt daran, dass die
RMI-Architektur so konzipiert ist, dass nie unmittelbar auf Sockets zugegriffen
wird, sondern immer dann, wenn ein Socket oder ServerSocket benötigt
wird, diesen eine sogenannte RMISocketFactory bereitstellt. [16] Durch die
Entwicklung einer eigenen RMISocketFactory kann man, die jeweiligen Anforderungen
(z.B. Sicherheit) die an den Socket bzw. ServerSocket gestellt
werden berücksichtigen. Ein Beispiel für eine solche RMISocketFactory wird
im Abschnitt 5.5.1 gegeben.
• Zuverlässige Protokolle Mit SSL und TLS kommen kryptographische Protokolle
zur Anwendung, die sich schon oft bewährt haben und als sicher gelten.
• Client/Server Authentifizierung DPAC-Client und -Server können sich gegenseitig
authentifizieren.
• Aktualität Die JSSE-Implementierungen wie beispielsweise die von Sun
oder die des IAIK wurden in den letzten Jahren ständig weiterentwickelt,
angepasst und verbessert. Dies ist ein besonders wichtiger Punkt, denn nur
so kann sichergestellt werden, dass neue Erkenntnisse aus der Kryptoanalyse
zeitnah in ein kryptographisches Produkt wie es die JSSE ist, einfließen und
damit die Sicherheit erhöhen.
Neben der JSSE und JCE existieren natürlich auch noch andere nicht Java-basierte
Verfahren mit denen die Kommunikation zwischen Client und Server geschützt werden
kann. Hier wäre beispielsweise das Virtual Private Network (VPN) (virtuelles
privates Netzwerk) zu nennen, in dem unter anderem IPsec (vergl.: Abschnitt 2.5.2)
zum Einsatz kommen kann. Auf die Technik der VPNs wird im Abschnitt 4.2 kurz
eingegangen.
79

Inv.-Nr.:2003-07-02/047/IN96/2253
4.1.4 Probleme beim Einsatz von RMI
Probleme beim Einsatz von RMI treten häufig dann auf, wenn Client oder Server
hinter einer Firewall betrieben werden, die keine RMI-Zugriffe (JRMP) zulässt. Eine
Firewall erzeugt einen Schutzwall zwischen dem Intranet eines Unternehmens
und dem rechtlichen Internet. Sie hat die Aufgabe, die Ressourcen aller Rechner
innerhalb eines Unternehmens vor unberechtigten Zugriffen durch externe Benutzer
oder Prozesse zu schützen und die Verwendung von Ressourcen außerhalb des
Intranets durch Benutzer im Unternehmen zu steuern.
Verbietet eine Firewall die Nutzung von RMI, beispielsweise durch eine Sperrung
des Ports 1099, über den im allgemeinen die Kommunikation zwischen Client und
Verzeichnisdienst stattfindet, so kann der RMI-Client nicht auf die vom RMI-Server
angebotenen Remote-Objekte zugreifen. Es gibt prinzipiell drei Möglichkeiten, das
Problem zu umgehen: [10][13][18]
• Die wohl einfachste Vorgehensweise ist es, die Firewall so zu konfigurieren,
dass Netzwerkverbindungen zum RMI-Server erlaubt sind. Allerdings wird
meist das Öffnen eines oder gar mehrerer Ports vom Sicherheitsbeauftragten
einer Firma nicht unbedingt toleriert.
• Ein anderer Lösungsweg nutzt die Tatsache aus, dass die meisten Firewalls
Netzwerkverbindungen zulassen, bei denen der Datenaustausch mittels HTTP
erfolgt. Ist dies der Fall, so ist es möglich, die JRMP-Daten über HTTP zu
tunneln, um so Zugriff auf den RMI-Server zu erhalten. Dieser Zugriff kann
entweder direkt oder indirekt stattfinden. Das Konzept des HTTP-Tunnels
basiert auf der Einbettung einer JRMP-Nachricht in einen HTTP-Request.
Wenn der RMI-Client erkennt, dass er keine direkte Verbindung zum Server
herstellen kann, so generiert er eine HTTP-POST-Anfrage, in die er
die JRMP-Daten einbettet und schickt diese direkt an den RMI-Server (z.B.
http://rmi.server:1099/), der an einem bestimmten Port ”lauscht”. Der
RMI-Server nimmt dann aus der POST-Anfrage die Daten heraus und interpretiert
sie. Die Antwort des Servers wird als HTTP-Response zurück an
den Client geschickt. Dieses direkte Senden der Anfrage an den Server ist
allerdings nur dann möglich, wenn sich nur der Client hinter einer Firewall
befindet und diese zusätzlich noch einen HTTP-Verbindungsaufbau zu einem
anderen Port als den normalerweise üblichen (Port 80) gestattet. Ist dies nicht
der Fall, dass heist auch der RMI-Server ist hinter einer Firewall oder die
Client-Firewall lässt nur HTTP-Verbindungen zu Port 80 zu, so versucht der
RMI-Client seine Anfrage über den Port 80 des Servers zu stellen. Auf Serverseite
muss dann aber ein Webserver-Prozess installiert sein, der mit Hilfe
eines CGI-Scripts oder Servlets die Anfrage an den RMI-Server weiterreicht
(indirekter Zugriff). Der RMI-Server schickt seine Antwort zurück an den
Webserver der den HTTP-Header hinzufügt und die Antwort an den anfragenden
Client zurücksendet.
• Die dritte Möglichkeit besteht in der Verwendung von Sockets, deren Eigenschaften
auf bestimmte Bedürfnisse zugeschnitten sind. Beispielsweise ist es
80

Inv.-Nr.:2003-07-02/047/IN96/2253
auf Seiten des RMI-Servers möglich, mit Hilfe von selbst definierten RMI-
SocketFactories dem Socket des Remote-Objekts einen ganz bestimmten Port
zuzuweisen 56 . Die Firewall müsste dann so konfiguriert werden, dass sie die
RMI-Kommunikation über diesen einen Port gestattet.
Aus den drei oben beschriebenen Lösungsansätzen kann der jeweiligen Situation
entsprechend einer ausgewählt werden um das Problem ”Firewall” zu umgehen.
Dabei muss die Nutzung eines HTTP-Tunnels nicht explizit eingerichtet werden,
vielmehr ist RMI so konzipiert, dass der RMI-Client automatisch versucht, seine
Anfragen via HTTP zu versenden, sollte ein ”normaler” Verbindungsaufbau zum
RMI-Server nicht gelingen. Soll dieses Verhalten ausdrücklich verboten werden, so
ist die Eigenschaft java.rmi.server.disableHttp auf true zu setzen. Die Nutzung
eines HTTP-Tunnels bringt allerdings auch einige Nachteile mit sich. Zum
einen ist ein HTTP-basiertes RMI-JRMP durch das zusätzliche Verpacken und dem
eventuellen Aufruf des CGI-Skripts erheblich langsamer als das binäre Protokoll
(direkte Socketverbindung). Zum anderen eröffnet sich durch den indirekten Zugriff
ein nicht zu vernachlässigendes Sicherheitsloch auf Seiten des Servers, aufgrund der
Tatsache, dass das CGI-Script praktisch jede Anfrage egal ob von einem RMI-Client
oder nicht, weiterleitet. Die automatische Verwendung von HTTPS wird leider nicht
unterstützt.
4.2 Virtual Private Networks (VPNs)
Wenn es darum geht Außendienstmitarbeiter, externe Geschäftspartner oder Firmenfilialen
an das Intranet eines Unternehmens anzubinden, kommen immer häufiger
Virtuelle Private Netzwerke zur Anwendung. VPNs wurden entwickelt, um getrennte
lokale Netzwerke miteinander zu koppeln. Ihr Vorteil ist, dass sie viel kostengünstiger
eingesetzt werden können als eine exklusiv angemietete Standleitung
eines Telekommunikationsanbieters, da sie öffentliche Infrastrukturen, wie das Internet
nutzen. Sender und Empfänger tragen gewöhnlich nur die Leitungskosten bis
zu einem lokal agierenden Internet Service Provider (ISP), der sie mit dem Internet
verbindet. VNPs stellen allerdings im Gegensatz zu Standleitungen keine garantierte
Bandbreite zur Verfügung. Außerdem ist es in den meisten Fällen notwendig,
die Daten vor unberechtigten Zugriffen zu schützen, da sie ja über ein öffentliches
Netz transportiert werden. Man spricht deshalb auch oft von einem VPN-Tunnel,
der zwischen zwei Kommunikationsendpunkten eingerichtet wird und durch den
Nachrichten (Daten-Pakete) geschützt vor Zugriffen Dritter ausgetauscht werden
(vergl.: Abbildung 22). Die Anbindung von lokalen Netzwerken oder mobilen Außendienstmitarbeitern
erfolgt meist auf den Ebenen zwei (Layer-2 VPNs) oder drei
(Layer-3 VPNs) des OSI-Referenzmodells. [20][25] Technologie sowie Vor- und
Nachteile beider Varianten werden im Folgenden besprochen.
56 Im Normalfall, dass heißt ohne die Verwendung von selbst definierten RMISocketFactories,
wird dem Socket des Remote-Objekts ein zufälliger, im System noch freier Port zugewiesen.
81

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 22: Kommunikationspartner in einem VPN
4.2.1 Layer-2 VPNs
Auf der Datensicherungsschicht (Ebene zwei des OSI-Referenzmodells) hat sich
das Layer 2 Tunneling Protocol (L2TP) und das Point-to-Point Tunneling Protokoll
(PPTP) als Standardmechanismus für den Transport von beliebigen Netzwerkprotokollen
in VPNs durchgesetzt. [20]
L2TP Das nach RFC 2661 standardisierte Layer 2 Tunneling Protocol tunnelt
das in der Datensicherungsschicht angesiedelte Point-to-Point Protocol (kurz PPP).
Durch den Tunnel wird erreicht, dass die normalerweise am Einwahlknoten des
Internet Service Providers terminierende PPP-Verbindung bis zum Übergang zwischen
Internet und Unternehmensnetzwerk erweitert wird.
Bietet der ISP von sich aus spezielle Mechanismen zum Aufbau einer L2TP-
Verbindung an, so muss sich der mobile Außendienstmitarbeiter lediglich wie
gewohnt über PPP mit seinem Modem oder seiner ISDN-Karte beim Provider
einwählen. Dieser richtet ihm nach erfolgreicher Authentifizierung (z.B. über
CHAP 57 ) eine L2TP-Verbindung ein. Dazu muss der ISP eine Datenbank führen,
in der den mobilen Mitarbeitern die Endpunkte bzw. Zieladressen der L2TP-Tunnel
(L2TP Network Server, LNS) zugeordnet werden. Der beim ISP betriebene L2TP
Access Concentrator (kurz LAC) tunnelt dann die PPP-Pakete mit L2TP. Für den
Transport der L2TP-Pakete zwischen LAC und LNS über das Internet bzw. IP
kommt UDP als Transportprotokoll zum Einsatz. Die zum Versand vorbereiteten
Pakete schickt der LAC als IP-Datagramm an den UDP-Port 1701 des LNS. Dort
angekommen, werden die L2TP-Pakete wieder entpackt und die getunnelten PPP-
Daten wie am Ende einer normalen PPP-Verbindung an den Protokollstack weitergereicht.
In Bezug auf das Anbinden von mobilen Mitarbeitern hat die Verwendung von
57 Das Challenge Handshake Authentication Protocol (vergl.: RFC1994) ist ein kryptographisches
Protokoll zur Authenfizierung. Bei CHAP wird das geheime Passwort nicht im Klartext zur Gegenstelle
gesandt.
82

Inv.-Nr.:2003-07-02/047/IN96/2253
L2TP gegenüber einer normalerweise beim ISP endenden PPP-Verbindung mehrere
Vorteile: [20]
• PPP bietet einen von der Netzwerkschicht unabhängigen Transportmechanismus,
so dass in den getunnelten Paketen nicht nur TCP/IP, sondern auch andere
Protokolle wie IPX/SPX oder NetBEUI über die virtuelle Verbindung
transportiert werden können.
• Die Vergabe von IP-Adressen an den mobilen Mitarbeiter kann aus einem
zentral verwalteten Pool im Unternehmen erfolgen.
• Der Zugang zu Diensten im Internet kann über den zentralen Gateway des Unternehmens
erfolgen, wodurch die im Unternehmen geltenden Beschränkungen
und Sicherheitspolitiken eingehalten werden.
• Es können weitere, vom ISP nicht angebotene Authentifzierungsmechanismen
aus dem Unternehmensnetzwerk eingesetzt werden.
Wird der L2TP-Tunnel vom LAC beim ISP initiiert, so sind keine besonderen technischen
Voraussetzungen vom Client zu erfüllen, da heutzutage nahezu jedes Betriebssystem
PPP-Verbindungen aufbauen kann. Steht hingegen beim Provider kein
LAC zur Verfügung, so muss der Tunnel durch den mobilen Client selbst aufgebaut
werden. Für diesen Fall muss auf den Rechner des mobilen Mitarbeiters der
L2PT-Code installiert sein. Einige Betriebssysteme wie Microsoft Windows-2000
oder -XP haben den L2TP-Standard bereits integriert.
L2PT setzt selbst keine Authentifizierungs-, Integritäts- und Verschlüsselungsmechanismen
zum Schutz der getunnelten Pakete voraus. Im RFC wird diesbezüglich
auf den IPsec-Standard (vergl.: Abschnitt 2.5.2) hingewiesen. Da normale IP-
Datagramme den L2TP-Tunnel umschließen, sind AH, ESP und IKE problemlos
einsetzbar. Aus diesem Grund finden bei VPN-Lösungen für mobile Außendienstmitarbeiter
meist Kombinationen aus L2TP und IPsec Verwendung. [20]
PPTP Das unter der Federführung Microsofts von mehreren Firmen entwickelte
Point-to-Point Tunneling Protocol stellt eine Erweiterung von PPP zum Aufbau
von VPN’s dar. Mit PPTP werden PPP-Pakete mit der im RFC 2784 beschriebenen
Generic Routing Encapsulation (kurz GRE) gekapselt und anschließend in
IP-Datagrammen zur Gegenstelle getunnelt. GRE kann weitestgehend mit TCP-
Segmenten verglichen werden, da sich der Tunnelzusatz ebenfalls Sequenz- und
Bestätigungsnummern sowie Mechanismen zur Flußsteuerung bedient. Im Gegensatz
zum L2TP kann der Aufbau eines Tunnels nicht an den ISP delegiert werden.
Der bereits mit dem Internet verbundene PPTP-Client muss eigenständig eine
Punkt-zu-Punkt-Verbindung zum gewünschten PPTP-Server des Unternehmens
aufbauen. Neben dem eigentlichen Tunnel benötigt PPTP zusätzlich eine separate
TCP-Verbindung vom Client zum PPTP-Server über Port 1723 zur Steuerung des
Tunnles (z.B. Verbindungsauf- und abbau). Ein weiterer Unterschied zu L2TP besteht
darin, dass nicht beliebige Netzwerkprotokolle im PPP-Rahmen transportiert
werden können, sondern sich PPTP auf IP, IPX und NetBEUI beschränkt. [20]
83

Inv.-Nr.:2003-07-02/047/IN96/2253
Die Authentifizierung eines PPTP-Clients beim PPTP-Server erfolgt über ein geheimes
Passwort, welches nur dem Server und dem Client bekannt sein darf. Damit
das Passwort nicht im Klartext zum Server gesendet werden muss, findet das Microsoft
Challenge Handshake Authentication Protocol (kurz MSCHAP) Verwendung,
welches an CHAP angelehnt ist. Hierbei sollte allerdings unbedingt darauf
geachtet werden, dass die aktuelle Version MSCHAPv2 eingesetzt wird, da die
Vorgängerversion zum Teil gravierende Sicherheitsmängel aufweist. [29][25][30]
Die Verschlüsselung des Datentransfers übernimmt bei PPTP ein zusätzliches
Kompressions-Modul names Microsoft Point-to-Point Encryption (kurz MPPE).
MPPE bedient sich eines RC4-Algorithmus und arbeitet wahlweise mit 128 oder
40 Bit langen Schlüsseln, die aus dem Authentifizierungs-Passwort abgeleitet werden.
Für den Einsatz von 128 Bit langen Schlüsseln ist unter Umständen ein Update
zu installieren, begründet durch frühere US-Exportbeschränkungen.
Microsofts PPTP-Implementierung erfuhr schon öfter intensive Kritik durch
Kryptographie-Experten. So kritisieren beispielsweise Schneier und Mudge in [29]
vor allem die Verwendung von Passwörten zur Authentifizierung und Schlüsselerzeugung.
[25] empfiehlt, dass diese Passwörter aus mindestens zwölf zufälligen Zeichen
bestehen sollten, um eine einigermaßen akzeptable Sicherheit zu erreichen.
PPTP spielt beim Aufbau von VPNs durch die weite Verbreitung von Windows-95,
-98 und -ME immer noch eine wichtige Rolle. Dennoch lässt sich durch die Integration
von L2TP und IPsec in Windows-2000 und -XP ein Strategiewechsel bei
Microsoft erkennen. [20] Schneier kommt in seiner Analyse zu dem Schluss, dass
die Verwendung von PPTP in dem Maße abnimmt, wie sich IPsec weiter durchsetzt.
[25][29]
4.2.2 Layer-3 VPNs
Als Alternative bzw. Ergänzung zu PPTP und L2TP beim Aufbau eines VPN bietet
sich auch IPsec (vergl.: Abschnitt 2.5.2) an. Mit AH, ESP und IKE stehen geeignete
Mechanismen zur Verfügung, um abhörsichere Tunnel über das Internet einzurichten.
Der sendende VPN-Gateway, der IPsec unterstützt, kapselt zum Beispiel
die von internen Workstations empfangenen Datagramme in der chiffrierten ESP-
Nutzlast (Tunnel Modus) und versieht den Klartext-IP-Header mit der Adresse der
VPN-Gateways beim Empfänger. Am Zielort angekommen, werden die IP-Pakete
entschlüsselt und der Absender identifiziert, bevor sie an den eigentlichen Adressaten
weitergereicht werden. Falls ein solches Paket unterwegs abgefangen wird,
kann einzig und allein die Adresse des VPN-Gateways ausgelesen werden. Interne
IP-Adressen und die transportierten Daten sind verschlüsselt und bleiben dadurch
verborgen.[20]
Wie das Beispiel zeigt, kommt IPsec klassischerweise dann zum Einsatz, wenn
entfernte Netzwerke sicher über das Internet verbunden werden sollen. Aufgrund
seiner Komplexität ist es für spontane Fernzugriffs-Szenarien nicht ganz einfach
zu handhaben. Gerade in diesem Bereich haben die Entwickler von IPsec-
Implementierungen (beispielsweise FreeS/WAN 58 ) in den letzten Jahren jedoch ei-
58 FreeS/WAN ist eine frei erhältliche IPsec-Implementierung für Linux (vergl.: http://www.
freeswan.org).
84

Inv.-Nr.:2003-07-02/047/IN96/2253
niges verbessert. [25]
4.2.3 VPNs und das DPAC-Informationssystem
Virtuelle Private Netzwerke bieten eine ganze Reihe von Vorteilen, die durchaus
auch für das DPAC-Informationssystem von Interesse sind. So können insbesondere
Außendienstmitarbeiter, denen in der Regel ein eigener mobiler Rechner zur
Verfügung steht, eine gesicherte Verbindung zum firmeneigenen Intranet und damit
auch zum DPAC-System aufbauen. Nach erfolgreichem Verbindungsaufbau kann
der mobile Mitarbeiter dann nicht nur das Angebot des DPAC-Informationssystems
nutzen, sondern auch weitere Dienste, die nur im Intranet verfügbar sind. Außerdem
kann der Authentifizierungsmechanismus, den der jeweilige VPN-Ansatz anbietet,
zusätzlich zu dem angewandt werden, der im DPAC-System genutzt wird.
Einziges Mako dieser VPN-basierten Zugriffslösung ist, dass eine gewisse Infrastruktur
zur Verfügung stehen muss, um mit VPNs arbeiten zu können. So muss
auf Seiten des firmeneigenen Intranets ein geeigneter VPN-Gateway eingerichtet
werden, über den die gesicherte Kommunikation stattfindet (vergl.: Abbildung 22).
Diese Aufgabe kann entweder ein eigenständiger Rechner oder eine in den meisten
Firmen schon vorhandene Firewall übernehmen, die mit zusätzlicher VPN-
Funktionalität ausgestattet ist. Wie man beispielsweise einen IPsec-Gateway relativ
einfach und kostengünstig einrichten kann, wird in [26] sehr anschaulich erläutert.
Aber nicht nur auf der Seite des Unternehmensnetzwerkes sind Maßnahmen zu
treffen, um den Einsatz von VPNs zu ermöglichen. Auch auf den Clientrechnern
muss eine geeignete VPN-Software installiert sein. Zwar haben die meisten
heutzutage verfügbaren Betriebssysteme bereits VPN-Funktionalitäten von Hause
aus integriert. Diese müssen aber in der Regel vor ihrer Verwendung konfiguriert
und an spezielle Bedingungen angepasst werden. Für den Außendienstmitarbeiter
mit eigenem mobilen Rechner stellt diese Tatsache sicher kein unüberwindliches
Problem dar. Der Rechner wird einmal vom zuständigen Systemadministrator
der Firma konfiguriert und sollte dann einsatzbereit sein. Von Kunden,
Lieferanten oder Geschäftspartnern der Firma Häcker-Automation, die das DPAC-
Informationssystem nutzen wollen, kann man jedoch nicht verlangen, dass die notwendige
Software und das Know How zur Installation und Konfiguration eines
VPN-Clients vorhanden ist. Es würde auch wenig Sinn machen, ein DPAC-Frontend
anzubieten, das sich praktisch ohne Installation sehr benutzerfreundlich einsetzen
lässt und dann die Einrichtung einer VPN-Verbindung zum firmeneigenen Gateway
zu verlangen, die möglicherweise erst aufwendig konfiguriert werden muss.
Außerdem ist es sicherlich nur in den seltensten Fällen erwünscht, dass Kunden,
Lieferanten oder Geschäftspartner Zugriff auf das Intranet der Firma erhalten.
Der Einsatz eines Virtuellen Privaten Netzwerkes im Zusammenhang mit dem
DPAC-Informationssystem bietet sich also dann an, wenn es darum geht, die Rechner
von Außendienstmitarbeitern in das Intranet einzubinden. Für Kunden, Lieferanten
oder Geschäftspartner ist der Einsatz von VPNs möglicherweise mit einem
zu hohen Konfigurationsaufand verbunden.
85

Inv.-Nr.:2003-07-02/047/IN96/2253
5 Das DPAC-Informationssystem
In diesem letzten Abschnitt der Arbeit sollen die bis hierher getroffenen Aussagen
und erarbeiteten Ergebnisse aus den Bereichen Grundlagen, Mobiler Code
und Sichere Kommunikation in einem Konzept zur sicheren Integration des
DPAC-Backendsystems zusammenfließen sowie der hieraus entstandene DPAC-
Prototyp vorgestellt werden. Eine Grundlage für die Entwicklung dieses Konzeptes
bilden die in Abschnitt 2.6 bereits vorgestellten Anforderungen an das DPAC-
Informationssystem, die sich wie folgt für das Integartionskonzept konkretisieren
lassen:
1. Die DPAC-Client-Anwendung (kurz DPAC-Client oder DPAC-Frontend) soll
unabhängig von der jeweils beim Anwender eingesetzten Plattform betrieben
werden können.
2. Die DPAC-Client-Anwendung soll an einer zentralen Stelle (Server)
verfügbar gemacht werden, sodass sie berechtigte Nutzer praktisch ”on demand
59 ” über das Intra- bzw. Internet auf den jeweiligen Arbeitsplatzrechner
laden können.
3. Nach dem Laden kann die DPAC-Client-Anwendung ohne weitere Installationsmaßnahmen
betrieben werden.
4. Notwendige Updates an der Client-Software sollen automatisch erfolgen.
5. Die DPAC-Client-Software ist vor Manipulationen und Verlust der Vertraulichkeit
gegenüber Dritten während des Transports über möglicherweise
öffentliche Netze zu schützen. Ebenso ist der Schutz der Client-Software an
der Quelle (Server) sicherzustellen.
6. Die Kommunikation zwischen DPAC-Client und -Backendsystem ist so abzusichern,
dass zu jedem Zeitpunkt die Vertraulichkeit, die Integrität und die
Authentizität der übertragenen Daten gewährleistet ist.
7. Berechtigte Benutzer des DPAC-Informationssystems, die sich am System
eindeutig identifiziert und authentifiziert haben, erhalten auf Grundlage ihrer
Rolle (Außendienstmitarbeiter, Kunde, Geschäftspartner, Lieferant, usw.)
bestimmte Berechtigungen im System.
Unter Einbeziehung dieser Anforderungen soll im weiteren ein Konzept entwickelt
werden, das als ein Fundament verstanden werden kann, auf dem sich das DPAC-
System in Zukunft weiter ausbauen lässt. Außerdem soll an dieser Stelle die Arbeitsweise
des auf dem Konzept basierenden DPAC-Prototypen erläutert werden.
In ihm finden die in den vorangegangenen Abschnitten ausschließlich theoretisch
betrachteten Techniken und Mechanismen eine konkrete Anwendung.
Ein weiteres Ziel dieses Teils der Arbeit ist es, auf das Zusammenspiel der einzelnen
Teile des DPAC-Informationssystems (DPAC-Client, DPAC-Anwendungsserver
und Datenbank) näher einzugehen.
59 engl. on demand: auf Verlangen / auf Wunsch
86

Inv.-Nr.:2003-07-02/047/IN96/2253
5.1 Entwicklungs- und Testumgebung
Für die Entwicklung des DPAC-Prototypen stellte die Firma Häcker-Automation
Schwarzhausen eine eigens dafür erworbene Entwicklungs- und Testumgebung zur
Verfügung, die aus den folgenden Komponenten bestand:
• einem Entwicklungs- und Testrechner AMD 1800 mit dem Betriebssystem
MS Windows 2000
• einem Industrie-PC (Pentium III 800) mit dem Betriebssystem Linux (redhat-
Distribution v7.1) für den Einsatz als Web-, Anwendungs und Datenbank-
Server
• einem Hardlock Evaluation-Kit der Firma Aladdin
• einer Umgebung für die Entwicklung leistungsfähiger Java -Anwendungen –
Borland JBuilder 6 Professionell
• einer relationalen Datenbank – Borland InterBase 6.1
• einem Webserver (v1.3) der Apache Software Foundation
• dem J2SE SDK von Sun Microsystems Version 1.4.0 später v1.4.1 und
v1.4.2-Beta
5.2 Architektur
Wie schon im Abschnitt 4 kurz angesprochen, ist die Client-/Server- Architektur des
DPAC-Informationssystems dreistufig (3-tier architecture). Dass heißt, das DPAC-
Frontend, welches auf dem Client-Rechner des Anwenders zum Einsatz kommt,
kommuniziert nicht direkt mit dem Backendsystem, sondern mit einem Anwendungsserver,
der als eine Art Zwischenschicht fungiert. Die drei Stufen werden in
Abbildung 23 illustriert und können wie folgt beschrieben werden:
• In der ersten Stufe ist der DPAC-Client (Frontend) angesiedelt. Er kommuniziert
über eine Middleware mit dem Anwendungsserver.
• Der Anwendungsserver in der zweiten bzw. mittleren Stufe stellt die
Geschäftslogik für den DPAC-Client bereit. Die Schnittstellen zum Client bestehen
aus einer Menge von Anwendungsdiensten. In Richtung des Backends
kommuniziert der Anwendungsserver über ein proprietäres Protokoll, das
vom Hersteller des Backendsystems spezifiziert ist.
• Die Datenbestände für den Anwendungsserver werden in der dritten Stufe
vom Backend des DPAC-Informationssystems gehalten. Als Backend kommt
die InterBase-Datenbank von Borland zum Einsatz.
Die Gründe für die Wahl einer solchen Architektur ergeben sich unter anderem
aus den Punkten 2,6 und 7 des Anforderungskataloges (siehe oben). Die 3-tier-
Architektur hat im Gegensatz zu einer 2-tier-Architektur, bei der der Client direkt
87

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 23: 3-tier-Architektur des DPAC-Informationssystems
mit dem Backend über ein proprietäres Protokoll kommuniziert, beispielsweise den
Vorteil, dass die Anwendungsdienste in der mittleren Stufe bereit gestellt werden
und so der Client einfach gehalten werden kann. In ihm ist praktisch nur noch
die Präsentationslogik realisiert, wodurch eine einfachere Wartung und Verteilung
der Software erreicht wird. Der DPAC-Client ist somit als sogenannter ”Thin
Client” ausgelegt, was in Bezug auf die Verteilung in einem Netzwerk (Punkt 2 des
Anforderungskataloges) besonders dann wichtig ist, wenn nur geringe Bandbreiten
für den Download vom Server zur Verfügung stehen. Ein weiterer Vorteil der 3-tier-
Architektur ergibt sich daraus, dass für die Kommunikation zwischen Client und
Anwendungsserver eine Vielzahl von Protokollen zur Verfügung stehen. Aus dieser
Menge von Protokollen kann das für die Situation am besten geeignete ausgewählt
werden und man ist somit an dieser Stelle nicht auf das herstellerspezifische
Protokoll des Backendsystems angewiesen. Insbesondere ist es dadurch möglich,
die Kommunikation, wie im Punkt 6 des Anforderungskataloges vorgegeben,
verschlüsselt stattfinden zu lassen.
Durch den Einsatz eines Anwendungsservers ist es desweiteren auch möglich,
spezielle Mechanismen zur Nutzerauthentifikation zu integrieren, die unabhängig
von denen des Backendsystems sind (Punkt 7 des Anforderungskataloges).
Wie Abbildung 23 zeigt, gibt es prinzipiell zwei Verbindungsarten, die geschützt
werden müssen. Auf der einen Seite die Verbindung zwischen dem jeweiligen Client
und dem Anwendungsserver, auf der anderen die zwischen Anwendungsserver
und Datenbankserver. Der Schutz der Kommunikationsverbindungen zwischen
Anwendungs- und Datenbankserver wird im allgemeinen dadurch gewährleistet,
dass beide über ein Rechnernetzwerk verbunden sind, das von ”außerhalb” nicht
erreichbar ist (firmeneigenes Intranet). Desweiteren sollten sich beide Server
in einem speziell abgeschirmten Raum befinden, zu dem nur bestimmte vertrauenswürdige
Personen Zutritt haben (bauliche Schutzmaßnahmen). Da die
88

Inv.-Nr.:2003-07-02/047/IN96/2253
Kommunikation zwischen einem DPAC-Client und dem Anwendungsserver nicht
nur über das firmeneigene Intranet, sondern auch über das öffentliche Internet
(Stichwort: Außendienstmitarbeiter) erfolgen kann, gestaltet sich der Schutz dieser
Kommunikation vor etwaigen Angriffen etwas aufwendiger. Ziel muss es sein,
dass zu jedem Zeitpunkt die Vertraulichkeit, die Integrität und die Authentizität der
übertragenen Daten gewährleistet ist.
Ein weiterer, ebenfalls wichtiger Punkt ist die Absicherung des Anwendungsservers,
da dieser mit seiner Anbindung an ein öffentliches Kommunikationsnetzwerk
praktisch die Schnittstelle zur ”Außenwelt” darstellt und damit den verschiedensten
Bedrohungen (vergl.: Abschnitt 2.3) ausgesetzt ist. Zum Schutz des Anwendungsservers
sollten die Sicherheitsdienste des dort installierten Betriebssystems
verwendet werden.
5.3 Das DPAC-Frontend
Die graphische Client-Anwendung, sprich das Frontend des DPAC-
Informationssystems, ist eine Java-Applikation und kann somit wie unter
Punkt 1 der Anforderungen beschrieben, praktisch unabhängig von der zu Grunde
liegenden Plattform (Hardware, Betriebssystem usw.) eingesetzt werden. Einzige
Voraussetzung ist, dass für die Ausführung auf dem Client-Rechner eine geeignete
Java-Laufzeitumgebung (JRE) zur Verfügung steht.
Die primäre Aufgabe des zur Zeit existierenden Frontend-Prototypen besteht darin,
die im DPAC-System gehaltenen Daten über den Anwendungsserver zu beziehen,
graphisch aufzubereiten und berechtigten Benutzer darzustellen. Desweiteren bietet
er benutzerfreundliche Mechanismen an, mit denen neue Daten hinzugefügt oder
bestehende verändert werden können. Abbildung 24 zeigt, wie sich das Frontend
für den Benutzer darstellt, wenn dieser den Bereich Kontaktverwaltung gewählt
hat.
Die benötigten Daten bezieht die Client-Anwendung über Dienste, die vom DPAC-
Anwendungssever zur Verfügung gestellt werden, sodass clientseitig praktisch nur
die sogenannte Präsentationslogik implementiert sein muss (vergl.: Abschnitt 5.2).
Die Kommunikation zwischen DPAC-Client und -Server erfolgt mittels Java-RMI.
Da aber die RMI-Technologie von Hause aus keine Mechanismen zur Sicherung
der Kommunikation zwischen Client und Server bietet (vergl.: Abschnitt 4.1.2),
dies aber im Anforderungskatalog (Punkt 6) verlangt wird, finden im Prototypen
des DAPC-Frontends Secure Sockets Verwendung (vergl.: Abschnitt 4.1), über die
eine geschützte Kommunikation stattfinden kann.
Auf Grund der Tatsache, dass es sich bei der Client-Anwendung um eine Java-
Applikation handelt, kommen für die Verteilung der DPAC-Client-Software im
Intra- bzw. Internet (Anforderungspunkt 2) prinzipiell zwei Technologien in Frage.
Java-Applets oder Java-Web-Start. Generell erlauben es zwar beide Technologien,
die Anforderungspunkte 2, 3, 4 und 5 zu erfüllen, dennoch wird im Prototypen des
DPAC-Informationssystems Java-Web-Start der Vorzug gegeben. Anlass hierfür
sind die im Abschnitt 3.4 beschriebenen Vorteile gegenüber Applets.
89

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 24: Frontend zur Kontaktverwaltung im DPAC-System
5.3.1 WebStart
Bevor das DPAC-Frontend mit Hilfe von Java-WebStart sicher verteilt werden kann,
ist es notwendig, die folgenden vorbereitenden Schritte durchzuführen:
• Alle von der Client-Anwendung benötigten Klassen und Ressourcen müssen
in einem oder mehreren Java-Archiven (JAR) zusammengefasst werden.
• Die Java-Archive müssen nach ihrer Erstellung signiert werden. Zum einen,
um unberechtigte Modifikationen an der Software zu erkennen (Anforderungspunkt
5), zum anderen damit, dass der Client-Anwendung auf dem Gastrechner
die benötigten Zugriffsrechte eingeräumt werden können (vergl.: Abschnitte
3.3.1 und 3.4.3).
• Als nächster Schritt muss eine Deskriptor-Datei (JNLP-Datei, vergl.: Abschnitt
3.4.2) erzeugt werden, die alle von WebStart benötigten Informationen
enthalten muss.
• Mit der Erstellung einer Webseite, die einen Link auf die entsprechende
Deskriptor-Datei enthält, wird es einem Benutzer ermöglicht, die DPAC-
Client-Anwendung zu laden und anschließend zu starten.
• Java-Archive, JNLP-Datei und Webseite müssen unter Verwendung eines geeigneten
Webservers und unter Beachtung der geltenden Sicherheitsrichtlinien
verfügbar gemacht werden.
90

Inv.-Nr.:2003-07-02/047/IN96/2253
Java-Archive Durch die Verwendung eines Java-Archivs lassen sich alle von
der DPAC-Client-Anwendung benötigten Klassen-, Bibliothek- und Ressource-
Dateien in einer einzigen 60 JAR-Datei zusammenfassen. Zum Erstellen einer
solchen JAR-Datei gibt es die unterschiedlichsten Möglichkeiten. Bei Java-
Entwicklungsumgebungen, wie beispielsweise dem JBuilder, reicht in der Regel ein
einfacher Klick auf einen entsprechenden Menüpunkt aus, um die gewünschten Dateien
eines Software-Projekts in einem Archiv zusammenzufassen. Die JAR-Datei
wird dann nach der Angabe das Names, den sie tragen soll automatisch erzeugt.
Für solche Entwickler, die keine Java-Entwicklungsumgebung einsetzen, beinhaltetet
das Java 2 SDK ein kleines Programm, das sogenannte jar-Tool. Dieses lässt sich
zwar nicht ganz so komfortabel bedienen, wie die graphisch unterstützten Werkzeuge
einer Entwicklungsumgebung, sein Einsatz aber führt dennoch zum gleichen
Ergebnis. Das jar-Tool wird über die Befehlszeile aufgerufen und gesteuert. Der
Befehl zum Erzeugen (Option c) einer JAR-Datei (Option f), die die vom DPAC-
Client benötigten Klassen, Ressourcen und Bibliotheken enthält, könnte zum Beispiel
wie folgt lauten:
jar cf DPAC Client.jar input-file(s)
In diesem Beispiel werden alle Dateien, die anstelle des Platzhalters ”input-file(s)”
aufgelistet sind in der Archiv-Datei ”DPAC Client.jar” zusammengefasst. Anstatt
mit einer Liste von Dateien zu arbeiten, kann man auch ganze Verzeichnisse
anstelle von ”input-file(s)” angegeben. Deren Inhalte werden dann rekursiv der
Archiv-Datei hinzugefügt. Auch die Anwendung von Wildcard-Zeichen (z.B. *)
ist möglich. [35]
Code Signieren Nachdem alle benötigten Dateien der Client-Anwendung in
einem Java-Archiv zusammengefasst wurden, ist es nunmehr möglich, die entstandene
JAR-Datei zu signieren. Wie bereits erwähnt, gewährleistet die Signatur,
dass nachträglich durchgeführte Veränderungen an den Dateien des Java-Archivs
erkannt werden. Diese Tatsache ist für das DPAC-Informationssystem besonders
wichtig, da es sich bei der Client-Anwendung um mobilen Code handelt, der
auch über öffentlich zugängliche Netzwerke verteilt werden kann und damit
potentiellen Angriffen ausgesetzt ist. Ein weiterer ebenfalls schon angesprochener
Vorteil der Signatur ist, dass mit Hilfe des angewandten Publik-Key-Verfahrens
der Signateur der Archiv-Datei (im speziellen Fall ist hier der Signateur die Firma
Häcker-Automation als eine Institution) authentifiziert werden kann. Voraussetzung
hierfür ist natürlich, dass der öffentliche Schlüssel des Signateurs von einer
vertrauenswürdigen Instanz zertifiziert ist.
Um eine JAR-Datei signieren zu können, benötigt man im wesentlichen drei
60 Aufgrund der Tatsache, dass die Anzahl der Klassen-, Bibliothek- und Ressource-Dateien des
Prototypen für die Client-Anwendung relativ überschaubar ist, wurde darauf verzichtet, die Anwendung
in mehrere Bereiche zu untergliedern, um dann für jeden dieser Bereiche eine separate
JAR-Datei zu erzeugen. Für den späteren Einsatz sollte allerdings die Verwendung von mehreren
JAR-Dateien in Betracht gezogen werden, um u. a. eine bessere Wartbarkeit der Software zu erreichen.
91

Inv.-Nr.:2003-07-02/047/IN96/2253
Komponenten: Einen Schlüsselgenerator, der ein Schlüsselpaar bestehend aus
einem privaten und einem öffentlichen Schlüssel erzeugt, eine vertrauenswürdige
Institution, die die Authentizität des öffentlichen Schlüssels bestätigt und
schließlich ein Werkzeug, welches den eigentlichen Signaturvorgang durchführt.
Zwei dieser Komponenten, nämlich der Schlüsselgenerator (keytool) und das
Signatur-Werkzeug (jarsigner) werden von Sun Microsystems als Bestandteil des
Java 2 SDK bereit gestellt.
Das keytool als einen reinen Schlüsselgenerator zu bezeichnen, ist im Grunde
genommen falsch, es bietet viel mehr Funktionalitäten. Sun bezeichnet es als ein
Werkzeug zur Schlüssel- und Zertifikats-Verwaltung. Dennoch kann das keytool
auch dazu genutzt werden, um Schlüsselpaare zu erzeugen, die zum Signieren von
JAR-Dateien geeignet sind. Die Schlüsselpaare und eventuelle Zusatzinformationen
werden in einer sogenannten keystore-Datei gespeichert, die, falls noch nicht im
lokalen Heimatverzeichnis des Benutzers vorhanden, automatisch erzeugt wird.
Die keystore-Datei kann als eine Art kleine Datenbank aufgefasst werden, in der
Informationen wie privater/öffentlicher Schlüssel und zugehörige Zertifikate als
Datensatz unter einem identifizierenden Alias verschlüsselt gespeichert werden.
Der Zugang zu diesen Informationen erfolgt über ein geheimes Passwort, welches
nur berechtigten Benutzer bekannt sein darf.
Der Aufruf und die Bedienung des keytools erfolgt, wie bei den meisten Werkzeugen,
die Sun im Java 2 SDK zur Verfügung stellt, über die Kommandozeile.
Der folgende Befehl erzeugt zwei zusammengehörige Schlüssel (privat/öffentlich)
für das kryptographische Verfahren RSA (vergl.: Abschnitt 2.5.1), deren Länge
jeweils 2048 Bit beträgt und die in der keystore-Datei unter dem Alias ”haecker”
abgespeichert werden:
keytool -genkey -alias haecker -keyalg RSA -keysize 2048
Nach der Bestätigung des Befehls fordert keytool den Benutzer auf, das Passwort
für den keystore einzugeben. Hier ist Vorsicht geboten, da die Eingabe im Klartext
auf dem Bildschirm zu lesen ist. Nachdem das korrekte keystore-Passwort eingegeben
wurde, werden vom Benutzer noch einige persönliche Daten abgefragt
(Name, Firma, Abteilung usw.), die für die Erstellung eines Test-Zertifikats
benötigt werden. Nach der abschließenden Eingabe eines neuen Passworts für
den zu generierenden privaten Schlüssel wird das Schüsselpaar berechnet und
abgespeichert.
Damit ein späterer Benutzer des DPAC-Clients auch wirklich sicher sein
kann, dass er zur Verifizierung der Signatur des mobilen Codes den richtigen
öffentlichen Schlüssel der Firma Häcker-Automation verwendet, sollte dieser von
einer allgemein als vertrauenswürdig angesehenen Institution zertifiziert sein. Das
keytool bietet dazu mit dem Befehl -certreq die Möglichkeit, einen sogenannten
Certificate Signing Request (kurz CSR) zu erstellen und in eine Datei zu schreiben.
Der CSR enthält unter anderem den vom keytool erzeugten öffentlichen Schlüssel.
keytool -certreq -alias haecker -file haeckerCSR.csr
92

Inv.-Nr.:2003-07-02/047/IN96/2253
Die CSR-Datei kann dann an eine auf Zertifizierung spezialisierte Institution, wie
es beispielsweise VeriSign 61 oder Thawte 62 , geschickt werden, um ein Zertifikat
zu erwerben. Die Institution überprüft in der Regel offline, ob der Antragsteller
rechtmäßiger Besitzer des öffentlichen Schüssels ist. War die Überprüfung erfolgreich,
so wird auf Grundlage des CSR ein entsprechendes Zertifikat erteilt und zum
Antragsteller versandt. Das erworbene Zertifikat kann dann mittels keytool im keystore
unter dem entsprechenden Alias gespeichert werden.
keytool -import -alias haecker -file haeckerCER.cer
Das Programm jarsigner ist das Signatur- und Verifikations-Werkzeug im Java 2
SDK. Es dient sowohl zum Signieren von JAR-Dateien als auch zum Verifizieren
von Signatur und Integrität. Der Jarsigner wird unter Angabe der zu signierenden
JAR-Datei und des Aliases, der das gewünschte Schlüsselpaar im keystore repräsentiert,
aufgerufen:
jarsigner DPAC Clinet.jar haecker
Nach der richtigen Eingabe des keystore-Passworts wird der Signaturvorgang gestartet.
Dabei werden die im JAR-Archiv vorhandenen Dateien unverändert beibehalten.
Es kommen mit der signature-Datei und der signature-block-Datei lediglich
zwei hinzu. Die signature-Datei beinhaltet die Namen und zugehörigen
Hashwerte aller Dateien des Archivs. In der signature-block-Datei sind der öffentliche
Schlüssel des Singnateurs, das zugehörige Zertifikat und der Hashwert der
signature-Datei gespeichert. Der Hashwert der signature-Datei ist mit dem entsprechenden
privaten Schlüssel des Signateurs verschlüsselt. Durch dieses Konstrukt
wird erreicht, dass eine noch so kleine Veränderung an den Dateien des
Java-Archivs erkannt werden kann. Denn verändert man eine Datei, so ändert sich
auch deren Hashwert. Durch einen Vergleich mit dem entsprechenden Hashwert in
der signature-Datei kann die Modifikation erkannt werden. Kommt es zudem noch
zu Veränderungen an der signature-Datei, beispielsweise durch Manipulation eines
Hashwertes einer zuvor geänderten Datei des Archives, so führt dies ebenfalls zu einer
Erkennung. Hierzu wird der Hashwert der signature-Datei mit dem verglichen,
der in der signature-block-Datei gespeichert ist. Dieser kann ohne Kenntnis des privaten
Schlüssels des Signateurs nicht erfolgreich manipuliert werden. [36][37]
Deskriptor-Datei Funktion und Syntax der WebStart-Deskriptor-Datei (JNLP-
Datei) wurde bereits im Abschnitt 3.4.2 ausführlich erläutert. Aus diesem Grund
soll an dieser Stelle nur kurz auf die JNLP-Datei eingegangen werden, die im Prototypen
Verwendung findet. Das Listing 6 zeigt den Inhalt der JNLP-Datei. Besondere
Aufmerksamkeit ist dem Attribut codebase zu schenken. Durch den Einsatz
von HTTPS wird erreicht, dass die Übertragung der DPAC-Client-Software zwischen
Webserver und Client-Rechner, verschlüsselt stattfindet. Somit ist, wie im
Punkt 5 des Anforderungskataloges verlangt wird, neben der Integrität der Client-
Anwendung (durch die Signatur) auch die Vertraulichkeit gegenüber Dritten sichergestellt.
Desweiteren kann der Benutzer der Client-Anwendung durch die Verwendung
von HTTPS den Webserver zweifelsfrei identifizieren. Voraussetzung hierfür
61 http://www.verisign.com
62 http://www.thawte.com
93

Inv.-Nr.:2003-07-02/047/IN96/2253
ist natürlich, dass ein gültiges SSL-Serverzertifikat vorliegt, das von einer vertrauenswürdigen
Institution ausgestellt wurde.
✞
Listing 6: DPAC-JNLP-Datei
Frontend fuer das DPAC-Informationssystem
Haecker-Automation Schwarzhausen
Prototyp des DPAC-Clients
✝
☎
✆
Webseite Die Webseite des DPAC-Informationssystems bildet praktisch eine
zentrale Anlaufstelle für diejenigen Benutzer, bei denen sich die DPAC-Client-
Software noch nicht im lokalen WebStart-Cache befindet. Die primäre Aufgabe der
Webseite ist es, einen Link zur Verfügung zu stellen, der auf die Deskriptor-Datei
(DPAC.jnlp) zeigt.
Bitte hier klicken um die
DPAC-Client-Anwendung zu Laden/Starten.
Durch einen Klick auf diesen Link wird die JNLP-Datei zum Client-Rechner
übertragen, wo sie dann von WebStart ausgewertet wird (vergl.: Abschnitt 3.4.2).
Mit Hilfe der Webseite können aber auch noch andere Aufgaben erfüllt werden.
Beispielsweise ist es durch den Einsatz von Scriptsprachen (z.B. Java- oder
VB-Script) möglich, zu testen, ob auf dem Client-Rechner eine geeignete JRE und
WebStart installiert sind. Sollte der Test negativ ausfallen, so kann automatisch ein
Link zu einer Webseite angeboten werden, von wo die gewünschte JRE geladen
werden kann (z.B. http://www.java.com). Ein Beispiel für ein solches Java- bzw.
VB-Script ist unter [40] im Bereich ”Developer/Documentation” zu finden.
Der Punkt 2 des Anforderungskataloges schreibt vor, dass die DPAC-Client-
Anwendung nur von berechtigten Benutzern geladen werden darf. Mit dieser
durchaus sinnvollen Forderung soll erreicht werden, dass die DPAC-Client-
Software nicht in falsche Hände gelangt. Wie in Abschnitt 2.3.4 beschrieben, sieht
ein Angriffszyklus in der Regel so aus, dass der Angreifer zuerst einmal versucht,
an so viel wie möglich Informationen über das anzugreifende System zu gelangen.
Eine Analyse der DPAC-Client-Software würde ihn mit Sicherheit ein ganzes
Stück näher an sein fragwürdiges Ziel bringen.
94

Inv.-Nr.:2003-07-02/047/IN96/2253
WebStart bietet allerdings keine dokumentierten Funktionen an, mit denen man
einen berechtigten Anwender vor dem eigentlichem Download der Applikation
authentifizieren kann. Abhilfe für dieses Problem schaffen zwei Lösungen, die
HTTP im Zusammenhang mit der Nutzerauthentfizierung bereit hält. Die Basic
Authentication für HTTP und die Digest Access Authentication für HTTP. Diese
beiden Mechanismen können zwar nicht dazu eingesetzt werden, den Download
der Client-Anwendung durch WebStart direkt zu beeinflussen, ihre Anwendung
ermöglicht aber die Durchführung einer Zugriffskontrolle für die Webseite, die den
Link zum Laden der Anwendung beinhaltet.
Mit Hilfe von Basic- und Digest-Authentication lässt sich ein Zugriffsschutz
mittels Benutzername/Passwort für bestimmte Dokumente und Verzeichnisse eines
Webservers realisieren. Dabei ist die Methode Basic Authentication, wie der Name
schon sagt nur eine Basismethode, die lediglich vor völlig unerfahrenen Angreifern
schützt. Der Grund hierfür liegt in der Tatsache, dass sowohl Passwort als auch die
Daten selbst unverschlüsselt über das Netzwerk übertragen werden. [30]
Die im Zusammenhang mit den Arbeiten zu HTTP v1.1 spezifizierte Digest
Access Authentication versucht, die offensichtlichsten Sicherheitsmängel von
Basic zu beseitigen. Dazu wurde in RFC 2617 ein einfaches Challenge-and-
Response-Protokoll definiert und in den HTTP-Rahmen eingepasst. Wichtigstes
Merkmal der Digest-Authentication ist, dass das Passwort niemals im Klartext
übertragen wird. Vielmehr schickt der Client als Antwort (Response) auf die
Challenge-Nachricht des Servers einen Hashwert (typischerweise MD5), der unter
anderem aus Benutzername, Passwort, Zufallszahl aus der Challenge-Nachricht
des Servers und URL des angeforderten Dokuments berechnet wird. Der Server
berechnet seinerseits ebenfalls diesen Hashwert und vergleicht ihn mit dem, den
er vom Client als Response erhalten hat. Sind beide gleich, wird das angeforderte
Dokument zum Client gesandt, andernfalls erhält der Client eine Fehlermeldung.
Die Digest Access Authentication wird von den meisten heutzutage verwendeten
Webserver und -browsern unterstützt. [30][6]
Genau wie beim Download der DAPC-Client-Software ist auch beim Aufruf
der Webseite die Anwendung von HTTPS dringend anzuraten, insbesondere dann,
wenn nur eine Basic Authentication eingesetzt werden soll. Durch den Einsatz
von HTTPS wird zum einen erreicht, dass die Deskriptor-Datei geschützt vor den
Zugriffen Dritter zum Client-Rechner übertragen wird. Zum anderen kann der Benutzer
mit Hilfe des SSL-Serverzertifikats die Webseite zweifelsfrei identifizieren.
Um den Schutz der Webseite vor unberechtigten Zugriffen noch etwas zu
erhöhen, ist auch die Anwendung eines serverseitigen Scriptes denkbar, welches
nach erfolgreich durchgeführter Authentifizierung und Aktivierung des
”JNLP-Links” noch eine gewisse Zeit wartet und danach die entsprechende
Benutzername/Passwort-Kombination auf Seiten des Servers löscht und damit
ungültig macht. Somit ist es praktisch möglich, den Zugriff auf die Webseite,
beispielsweise durch Kunden, Lieferanten usw. nur einmal zu erlauben. Gelangen
dann Benutzername und Passwort eines berechtigten Anwenders in die Hände
95

Inv.-Nr.:2003-07-02/047/IN96/2253
eines unberechtigten Anwenders, sei es durch Diebstahl oder Weitergabe, so könnte
dieser die Webseite und damit die Deskriptor-Datei nicht aufrufen.
5.3.2 Webserver
Ein zentraler Bestandteil des WebStart-Konzeptes ist der Webserver. Er stellt praktisch
die Quelle für die DPAC-Webseite, -Deskriptor-Datei und -Client-Anwendung
dar. Bevor der Webserver im DPAC-Informationssystem eingesetzt werden kann,
sind in der Regel jedoch noch einige Einstellungen bezüglich WebStart- und
SSL-Unterstützung vorzunehmen.
Einmalig muss der Webserver so konfiguriert werden, dass dieser Deskriptor-
Dateien an ihrer Extension .jnlp erkennt und zum Client-Browser den korrekten
Mime-Typ 63 application/x-java-jnlp-file überträgt. Der Browser erkennt am
Mime-Typ, dass es sich bei der empfangenen Datei um eine JNLP-Datei handelt
und übergibt diese automatisch an Java-Web-Start. Bei dem für den Prototypen
eingesetzten Webserver der Apache Software Foundation erfolgt die Konfiguration
des Mime-Typs durch einfaches Hinzufügen der Zeile
application/x-java-jnlp-file JNLP
in die Datei .mime.types. Soll ein anderer Webserver zum Einsatz kommen, ist
dessen Dokumentation zu konsultieren.
Ein weiterer Konfigurationspunkt betrifft die Sicherheit des Webservers. Wie
bereits erwähnt, soll sowohl die Übertragung der Webseite als auch die Übertragung
der Deskriptor-Datei und eigentlichen DPAC-Client-Software über HTTPS
erfolgen. Dazu ist es notwendig, den Webserver so einzurichten, dass dieser SSL
unterstützt. Beim Apache-Webserver erfolgt die Einbindung der SSL-Funktionen
über das Modul mod ssl, welches installiert und konfiguriert werden muss. mod ssl
ist genau wie der Apache-Webserver frei verfügbar. Das SSL-Modul implementiert
jedoch das SSL-Protokoll nicht selbst, sondern es handelt sich hierbei um eine
Schnittstelle zwischen dem Webserver und einer entsprechenden SSL-Bibliothek.
Eine solche Bibliothek wird beispielsweise von OpenSSL 64 zur Verfügung gestellt.
OpenSSL beinhaltet aber nicht nur eine SSL-Bibliothek, vielmehr ist es
ein vollständiges Kryptographiepaket, das alle notwendigen Programme enthält,
um Schlüssel und Zertifikate zu erstellen. Eine ausführliche Beschreibung und
Konfigurationsanleitung von mod ssl und OpenSSL ist in [6] im Kapitel 13 zu
finden.
Ein letzter wichtiger Punkt, der im Zusammenhang mit dem Webserver angesprochen
werden soll, betrifft das SSL-Serverzertifikat. Ein gültiges, auf die
Firma Häcker-Automation Schwarzhausen ausgestelltes Serverzertifikat ist aus
63 Mime-Typen sind der Internet-Standard zur Klassifizierung und Typisierung von Dateien, beispielsweise,
um Anlagen in E-Mails auf netzweit einheitliche Weise mit dem Typ des Inhalts beschriften
zu können [45].
64 http://www.openssl.org/
96

Inv.-Nr.:2003-07-02/047/IN96/2253
dem Grund so wichtig für das DPAC-Informationssystem, weil es dem Anwender
erlaubt, den Webserver zweifelsfrei zu identifizieren. Somit kann er sicher sein, dass
sowohl die DPAC-Webseite als auch die zu ladende DPAC-Client-Software von der
Firma Häcker-Automation stammen. SSL-Serverzertifikate werden beispielsweise
von den im Zusammenhang mit der Code-Signierung bereits angesprochenen
Firmen VeriSign und Thawte angeboten. Sie können mit den Werkzeugen, die
OpenSSL zur Verfügung stellt, eingebunden werden.
Aber nicht nur die Verwendung eines gültigen SSL-Serverzertifikats ist wichtig,
auch sollte der allgemeine Schutz des als Webserver genutzten Rechners nicht
außer Acht gelassen werden. Da dieser Rechner an das öffentliche Internet
angebunden sein muss, ist er auch einer Vielzahl von Bedrohungen ausgesetzt.
Sinnvoll ist es, auf diesem Rechner so wenig Dienste wie möglich zur Verfügung zu
stellen, die aus dem Internet erreichbar sind, um somit die Angriffsfläche so gering
wie möglich zu halten. Außerdem sollte der Webserver-Dienst möglichst keine
Schreibrechte auf dem System erhalten, um zu verhindern, dass es einem Angreifer
möglicherweise gelingt, ”bösartige” Software in das System einzuschleusen. Neben
den Schreibrechten sollten auch die Leserechte des Webserver-Prozesses auf die
benötigten Verzeichnisse und Dokumente beschränkt werden. Zu den Aufgaben
des für den Webserver verantwortlichen Sicherheitsbeauftragten gehört es, sich
über neu entdeckte Sicherheitslücken der Webserver-Software zu informieren und
möglichst zeitnah geeignete Sicherheits-Updates zu installieren.
5.4 Der DPAC-Anwendungsserver
Der DPAC-Anwendungsserver arbeitet wie Abbildung 23 zeigt als eine Art Vermittler
zwischen den Clients und dem Backendsystem. Seine primären Aufgaben
bestehen darin, die Client-Anwendungen und den jeweiligen Benutzer zu authentifizieren,
Anfragen der Clients entgegenzunehmen, diese an das Backendsystem
aufbereitet weiterzugeben und Resultate, die das Backendsystem liefert, verpackt an
den Client zurückzusenden. Der prototypische DPAC-Anwendungsserver ist genau
wie das DPAC-Frontend eine Java-Applikation, die allerdings nur über die Befehlszeile
aufgerufen und gesteuert wird. Aufbau und Arbeitsweise des Servers sollen an
dieser Stelle beschrieben werden.
5.4.1 Arbeitsweise des Servers
Der DPAC-Anwendungsserver besteht im wesentlichen aus sechs Komponenten
(Klassen): Setup, LogFileWriter, JDBC-Treiber (InterClient), ConnectionDistributor,
ObjectAdmin und DBQuest. Jede dieser Komponenten beinhaltet ganz bestimmte
Funktionen, die im DAPC-Informationssystem benötigt werden. Das Schema
des DAPC-Anwendungsservers, welches in Abbildung 25 dargestellt ist, setzt
die einzelnen Komponenten visuell in Beziehung zueinander.
Setup Die Setup-Klasse hat, wie der Name schon vermuten lässt, die Aufgabe,
den Anwendungsserver zu initialisieren und zu starten. In ihr ist die main-Methode
implementiert, die von der JVM als erste aufgerufen wird. Nachdem Setup die RMI-
97

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 25: Schema des DPAC-Anwendungsservers
Registry gestartet hat, wird ein Objekt der Klasse ObjectAdmin erzeugt und bei der
Registry unter dem Namen ”ObjectAdmin” angemeldet. Dieses Remote-Objekt ist
dann später der erste Anlaufpunkt für die DPAC-Clients. Ihre Pflicht hat die Setup-
Komponente dann erfüllt, wenn sie neben dem ObjectAdmin-Objekt auch noch eine
Instanz der Klasse LogFileWriter erzeugt hat.
LogFileWriter In der Klasse LogFileWriter sind spezielle Methoden implementiert,
die es den anderen Komponenten erlauben, bestimmte Ereignisse in einer oder
mehreren Dateien zu protokollieren. Solche Ereignisse können zum Beispiel das
Anmelden eines Clients, ein Zugriff auf das Backendsystem oder eine ausgelöste
Ausnahme sein. Der LogFileWriter ist somit die Komponente des Anwendungsservers,
die für die Nachweisführung (vergl.: Abschnitt 2.2.5) zuständig ist. Es
sei jedoch erwähnt, dass der LogFileWriter des hier vorgestellten Prototypen zur
Zeit noch nicht alle die Funktionen beinhaltet, die unter Umständen benötigt werden.
Zwar ist es bereits möglich, sicherheitsrelevante Daten und Aktionen, wie IP-
Adressen der DAPC-Clients oder Zugriffe auf die Datenbank zu protokollieren, dies
ist aber bei weitem nicht ausreichend. Besonders wichtig ist beispielsweise die Einbindung
von Mechanismen, die missglückte Zugriffsversuche auf das System analysieren,
protokollieren und gegebenenfalls zeitnah den Administrator oder Sicherheitsbeauftragten
informieren.
InterClient Der von Borland zusammen mit der Datenbank InterBase ausgelieferte
JDBC 65 -Treiber InterClient Version 2.5 bildet die Schnittstelle zwischen Anwendungsserver
und Datenbank. Der Treiber ist vollständig in Java programmiert
und kommuniziert direkt mit dem Datenbankserver (Typ 4 Treiber).
Während der Tests, die mit dem Treiber durchgeführt wurden, traten immer wieder
Probleme beim Verbinden mit dem Datenbankserver auf. Eine Anfrage bei Borland
ergab, dass der InterClient v2.5 und die auf Seiten der Datenbank eingesetzte Li-
65 JDBC: Java Database Connectivity Interface
98

Inv.-Nr.:2003-07-02/047/IN96/2253
nux Distribution v7.1 der Firma redhat nicht richtig zusammenarbeiten. Nach einem
Downgrade des Treibers auf Version 2.01 arbeitete das System wie gewünscht.
ConnectionDistributor Die Klasse ConnectionDistributor verwaltet die drei zur
Verfügung stehenden Verbindungen zum Backendsystem in einem Pool. Nach dem
Start des Servers werden drei Connection-Objekte erzeugt, die jeweils eine Verbindung
zur Datenbank repräsentieren. Die Connection-Objekte werden in einem
sogenannten Stack 66 -Objekt gespeichert. Jedes Mal, wenn eine Komponente des
Anwendungsservers eine Verbindung zur Datenbank benötigt, wird ein Connection-
Objekt aus dem Stack-Objekt gelöst und an die Komponente übergeben. Sind die
Arbeiten an der Datenbank beendet so wird das Connection-Objekt wieder in das
Stack-Objekt zurückgeschrieben und kann wiederverwendet werden. Der Vorteil
dieser Vorgehensweise ist, dass ständig drei offene Verbindungen zur Datenbank
bestehen und nicht erst zeitraubend für jede Anfrage auf- und abgebaut werden
müssen.
ObjectAdmin Die Klasse ObjektAdmin ist eine von zwei Klassen des Anwendungsservers,
deren Methoden auch von Objekten aufgerufen werden können, die
in entfernten virtuellen Maschinen existieren. Anders gesagt, stellt die von Setup
erzeugte Instanz der Klasse ObjektAdmin ihre Methoden den DPAC-Clients
zur Verfügung. Diese können die Methoden über die Remote Method Invocation
(vergl.: Abschnitt 4.1) aufrufen. Die Hauptaufgaben der Komponente ObjektAdmin
sind die Authentifizierung der DPAC-Client-Anwendungen und deren Benutzer, die
Rechteverwaltung sowie die Erzeugung, Verwaltung und Zuteilung von DBQuest-
Objekten.
Ziel eines jeden DPAC-Clients ist es, eine Referenz auf ein Remote-Objekt der
Klasse DBQuest zu erlangen. Der Weg dahin führt über die von Setup erzeugte
Instanz der Klasse ObjektAdmin. Hier meldet sich der DPAC-Client durch den
Aufruf einer bestimmten login-Methode an. Das ObjektAdmin-Objekt überprüft
zunächst, ob der Benutzername des Anwenders in der Tabelle users der Datenbank
zu finden ist und ob das gesendete Passwort mit dem gespeicherten übereinstimmt
(vergl.: Abschnitt 5.5 Nutzerauthentifikation). War die Authentifikation des Anwenders
erfolgreich, wird die Datenbank ein zweites Mal konsultiert, um aus der Tabelle
user rights die Berechtigungen zu erfragen, die der entsprechende Anwender im
DPAC-Informationssystem hat. Auf Grundlage des Ergebnisses dieser Anfrage wird
ein neues DBQuest-Objekt erzeugt und bei der RMI-Registry unter einem zufällig
gewählten Namen angemeldet. Dieser Name wird zusammen mit den Rechten des
Anwenders an den DPAC-Client als Rückgabewert der login-Methode übermittelt.
Mit Hilfe der übermittelten Informationen und der auf dem Anwendungsserver laufenden
RMI-Registry ist es dem Client möglich, eine Referenz auf das für ihn bestimmte
DBQuest-Objekt zu erlangen. Die ebenfalls übertragenen Berechtigungen
des Anwenders werden clientseitig dazu genutzt, um bestimmte Funktionalitäten
ein- bzw. auszuschalten. Der Benutzer des DPAC-Clients hat nunmehr die Möglichkeit,
auf die ihm zugänglichen Informationen, die das DPAC-Informationssystem
66 Ein Stack ist eine Liste, bei der nur das erste (= oberste) Element gelesen werden kann. Mit den
Methoden push und pop können entweder Elemente hinzugefügt oder entfernt werden.
99

Inv.-Nr.:2003-07-02/047/IN96/2253
bereit hält, zuzugreifen.
Hat ein Anwender seine Arbeit beendet und schließt aus diesem Grund die DPAC-
Client-Anwendung, so informiert der Client den ObjectAdmin durch den Aufruf
einer bestimmten Methode, dass er sein DBQuest-Objekt nicht mehr benötigt. Der
ObjectAdmin meldet daraufhin das entsprechende DBQuest-Objekt bei der RMI-
Registry ab, sodass es, wenn es lokal nicht mehr referenziert ist, vom Garbage Collector
gelöscht und der Speicherplatz wieder freigegeben werden kann.
Die Vorteile dieser hier erläuterter Vorgehensweise lassen sich wie folgt beschreiben:
• Ein DBQuest-Objekt, welches Methoden für den Zugriff auf die Datenbank
bereitstellt, ist immer nur dann auf dem Server verfügbar, wenn ein berechtigter
Client (Anwender) es explizit anfordert und damit arbeitet. Somit wird die
Angriffsfläche bezüglich serverseitig ”lauschender” Sockets möglichst gering
gehalten.
• Die Funktionalität des DBQuest-Objekts kann auf Grundlage der Berechtigungen
des jeweiligen Nutzers modifiziert werden. Meldet sich beispielsweise
ein Nutzer beim DPAC-System an, der in die Rolle ”Kunde” einzuordnen
ist und damit nur Leserechte für bestimmte Tabellen oder Views besitzt, so
kann das DBQuest-Objekt so initialisiert werden, dass Funktionen, die das
Ändern, Einfügen oder Löschen von Datensätzen erlauben serverseitig deaktiviert
sind.
• Auf Grund der Tatsache, dass zu jedem berechtigten Client dynamisch ein
zugehöriges DBQuest-Objekt erzeugt wird, kann die Anzahl der gleichzeitig
auf das System zugreifenden Clients beschränkt werden. Anders gesagt, im
ObjectAdmin ist ein Zähler integriert, der jedes Mal um den Wert eins erhöht
bzw. verringert wird, wenn ein Client ein DBQuest-Objekt anfordert bzw.
nicht mehr benötigt. Durch die Angabe eines Maximalwertes von parallel
existierenden DBQuest-Objekten kann somit auch die Anzahl der gleichzeitig
im DPAC-System vorhandenen Clients bestimmt werden.
Der Prototyp gestattet den gleichzeitigen Systemzugriff von bis zu 10 Clients.
DBQuest Objekte dieser Klasse bilden das eigentliche Verbindungsstück zwischen
DPAC-Client-Anwendung und Datenbank. Einige Methoden dieser Klasse
sind genau wie beim ObjectAdmin so implementiert, dass sie von entfernten Clients
via RMI aufgerufen werden können. Sie erlauben unter anderem, Datensätze
abzufragen, zu modifizieren oder neu anzulegen. DBQuest-Objekte können auf der
Grundlage von Nutzer-Berechtigungen so initialisiert werden, dass für den jeweiligen
Client nur bestimmte Methoden aktiviert sind.
5.5 Absicherung der Kommunikation
Die in Punkt 6 des Anforderungskataloges beschriebenen Sicherheitsansprüche, die
an die Kommunikation zwischen DPAC-Client und -Anwendungsserver gestellt
100

Inv.-Nr.:2003-07-02/047/IN96/2253
werden, kann (wie in Abschnitt 4.1.2 beschrieben) RMI allein nicht gewährleisten.
Deshalb bedarf es einer Art Erweiterung, die es erlaubt, Vertraulichkeit, Integrität
und Authentizität der übertragenen Daten sicherzustellen. Im Prototypen
des DPAC-Informationssystems kommt die Java Secure Socket Extension (vergl.:
Abschnitt 4.1.3) als eine solche Erweiterung zum Einsatz. Die Gründe hierfür liegen
zum einen in der RMI-Architektur (Kommunikation über Sockets), zum anderen in
den Vorteilen, die die JSSE gegenüber den anderen vorgestellten Verfahren hat.
Möglich wird die Verwendung der JSSE aufgrund der Tatsache, dass RMI nie unmittelbar
auf Standard-Sockets zugreift, sondern Sockets immer über eine RMI-
Socket-Factory bezieht.
5.5.1 RMI-Socket-Factory
Die Hauptaufgabe der RMI-Socket-Factory besteht darin Socket- und ServerSocket-
Objekt für die Netzwerk-Kommunikation zur Verfügung zu stellen. Die Erstellung
und Einbindung einer eigenen RMI-Socket-Factory ist im Prinzip einfach und kann
relativ frei gestaltet werden. Die einzige Anforderung, die an die RMI-Socket-
Factory gestellt wird, ist, dass sie entweder das Interface RMIServerSocketFactory
mit der zugehörigen Methode createServerSocket(int port) oder das Interface
RMIClientSocketFactory mit der Methode createSocket(String host,int
port) implementiert. Diese Methoden stellen praktisch eine definierte Schnittstelle
zum umgebenden RMI-System dar. Die Methode createSocket liefert auf Anforderung
des RMI-Systems ein Socket-Objekt, welches eine Socket-Verbindung zu
der übergebenen Host-Adresse und dem Port repräsentiert. Dieses Socket-Objekt
wird dann in der Regel vom Client verwendet. Auf Seiten des Servers wird ein
ServerSocket-Objekt benötigt, welches auf einem bestimmten Port ”lauscht”.
Hierfür ist die Methode createServerSocket zuständig.
Die Besonderheit der beiden im Prototypen des DPAC-Systems eingesetzten RMI-
Socket-Factories ist, dass sie keine Standard (Server)Socket-Objekte zurückliefern,
sondern Secure (Server)Socket-Objekte, die mit Hilfe der JSSE erzeugt wurden.
Die Listings 7 und 8 zeigen zur Veranschaulichung jeweils einen Auszug aus
der Klasse DPACSecureServerSocketFactory bzw. der Klasse DPACSecureClient-
SocketFactory.
✞
Listing 7: DPACSecureServerSocketFactory
public class DPACSecureServerSocketFactory
implements RMIServerSocketFactory{
☎
}
✝
ServerSocket createSecureServerSocket(int port){
/*... wie in Listing 5 ...*/
return sec_serv_socket;
}
public ServerSocket createServerSocket(int port){
return createSecureServerSocket(port);
}
✆
101

Inv.-Nr.:2003-07-02/047/IN96/2253
✞
Listing 8: DPACSecureClientSocketFactory
public class DPACSecureClientSocketFactory
implements RMIClientSocketFactory{
☎
}
✝
Socket createSecureSocket(String host, int port){
/*... wie in Listing 4 ...*/
return sec_socket;
}
public Socket createSocket(String host, int port)
throws IOException{
return createSecureSocket(host, port);
}
✆
In beiden Listings wurde aus Gründen der Übersichtlichkeit auf die Darstellung
des Programmteils, in dem die eigentliche Erzeugung des Secure Socket- bzw.
Secure ServerSocket-Objekts erfolgt, verzichtet. Eine ausführliche Beschreibung
über die Erzeugung von Secure (Server)Sockets ist im Abschnitt 4.1.3 (JSSE) und
im Anhang A.2 zu finden.
Nachdem die beiden RMI-Socket-Factories erstellt wurden, müssen sie noch
beim RMI-System registriert werden. Dies erfolgt in der Regel durch den Aufruf
des Konstruktors der Vaterklasse (UnicastRemoteObject)
super(port, DPACSecureClientSocketFactory,
DPACSecureServerSocketFactory);
innerhalb der Klassen, deren Methoden via RMI aufgerufen werden sollen.
An dieser Stelle sei noch erwähnt, dass auch die Kommunikation zwischen
DPAC-Client und der RMI-Registry mit Hilfe der vorgestellten Socket-Factories
geschützt werden kann. Dazu startet das Setup-Objekt des Anwendungsservers die
Registry unter Angabe der zu verwendenden Factories
Registry registry = LocateRegistry.createRegistry (port,
DPACSecureClientSocketFactory, DPACSecureServerSocketFactory);
5.6 Nutzerauthentifikation
Im DPAC-Informationssystem kommen vom Download der Client-Anwendung
bis hin zur eigentlichen Nutzung eine ganze Reihe von Authentifikationsverfahren
zur Anwendung. Einige von diesen Verfahren erfordern die Interaktion mit dem
Nutzer, andere laufen im Hintergrund automatisch ab. Bereits angesprochen
wurde die Nutzerauthentifikation am Webserver, mit der erreicht werden soll, dass
die DPAC-Client-Anwendung nur von berechtigten Nutzern geladen wird. Eine
weitere Authentifikation findet statt, wenn zwischen DPAC-Client und -Server eine
Verbindung über Secure Sockets aufgebaut wird. Hier authentifizieren sich Client
und Server gegenseitig ohne Zutun des Anwenders mit Hilfe der Funktionen, die
das SSL-Protokoll bietet. Was noch fehlt und an dieser Stelle besprochen werden
soll, ist ein Authentifikationsverfahren, mit dem ein Anwender beim Start der
102

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildung 26: USB- und Parallel-Port Hardlock
DPAC-Client-Anwendung seine Identität eindeutig nachweisen kann. Auf Basis
dieser Identität wird dem Anwender eine bestimmte Rolle (Außendienstmitarbeiter,
Lieferant, Kunde etc.) zugewiesen und er bekommt die zur Rolle passende
Zugriffsberechtigung eingeräumt. Sollte die Identität dem DPAC-System nicht
bekannt sein (keine Referenzdaten vorhanden) oder deren Nachweis fehlschlagen
(keine Übereinstimmung mit den Referenzdaten), so wird der Zugang zum System
verweigert.
Prinzipiell gibt es drei Verfahren zur Authentifikation, die hier zum Einsatz
kommen können: Authentifikation durch Wissen, Authentifikation durch Besitz und
Authentifikation durch Körpermerkmale (vergl.: Abschnitt 2.2.2). Denkbar sind
aber auch Mehrfachanwendungen und Kombinationen aus diesen drei Verfahren.
Leider lastet solchen Kombinationen (Mehrfachanwendungen) meist an, dass sie
zwar die Sicherheit erhöhen, jedoch auf Kosten der Benutzerfreundlichkeit. Für
die Nutzerauthentifikation im Prototypen des DPAC-Informationssystems wurde
deshalb nach einer Lösung gesucht, die praktisch einen Kompromiss in Bezug auf
Sicherheit und Benutzerfreundlichkeit darstellt. Die Entscheidung fiel letztendlich
auf eine Kombination der beiden Verfahren Authentifikation durch Wissen und
Authentifikation durch Besitz. Nicht zuletzt, weil beide Verfahren heutzutage
durchaus weit verbreitet und die meisten Nutzer mit dem Umgang vertraut sind.
Auf die Anwendung eines biometrischen Verfahrens (Authentifikation durch
Körpermerkmale) wurde verzichtet, da die erforderliche Hardware zur Erkennung
von Körpermerkmalen entweder zu kostenintensiv oder, wie in [43] gezeigt wird,
noch nicht genügend ausgereift ist.
Das klassische Authentifikationsverfahren durch Wissen basiert im DPAC-
System wie bei vielen anderen Systemen auch auf einer Nutzer-Kennung und
einem zugehörigen geheimen Passwort. Kennung und Passwort werden vom
System-Administrator für jeden neuen Benutzer erzeugt, in der Tabelle users der
103

Inv.-Nr.:2003-07-02/047/IN96/2253
Datenbank als Referenzdaten abgespeichert und dem neuen Benutzer übergeben.
Dieser hat später die Möglichkeit, mit Hilfe einer Funktion der DPAC-Client-
Anwendung sein vom Administrator erzeugtes Passwort zu ändern. Das System
überprüft dabei, ob das Passwort bestimmten Kiriterien entspricht. Beispielsweise
wird geprüft, ob das neue Passwort eine bestimmte Länge hat (≥ 8 Zeichen) und
mindestens drei Sonderzeichen oder Zahlen enthält. Diese Regeln zur Erzeugung
von Passwörtern sollen verhindern, dass es einem Angreifer gelingt, durch eine
Wörterbuchattacke oder einfaches Erraten des Passworts Zugang zum System
zu erlangen. Der MD5-Hashwert (vergl.: Abschnitt 2.4.3) des regelkonformen
Passworts wird dann in der Datenbank abgespeichert (Referenzwert). Somit ist
sichergestellt, dass in der Tabelle users keine Passwörter im Klartext gespeichert
sind.
Das zweite im DPAC-Informationssystem eingesetzte Verfahren zur Nutzerauthentifikation
basiert auf dem Besitz eines Hardware-Moduls. Dass heißt, ein
Benutzer des DPAC-Informationssystems benötigt zur Authentifikation nicht nur
das Wissen über sein ansonsten geheimes Passwort, sondern zusätzlich noch ein
Hardware-Modul. Hardware-Module sind in der Regel spezielle Speicherchips,
die kryptographische Informationen beinhalten und über bestimmte Schnittstellen
mit dem Rechner verbunden werden. Abbildung 26 zeigt zwei Hardware-Module
der Firma Aladdin (genannt Hardlock) für den USB- bzw. Parallel-Port, die im
Prototypen des DPAC-Systems Verwendung finden.
Prinzipiell bieten beide in Abbildung 26 dargestellten Hardlock-Module die
gleiche Funktionalität. Dennoch ist aufgrund der Größe und der mittlerweile
weiten Verbreitung der USB-Schnittstelle die Anwendung des USB-Hardlocks
vorzuziehen. Das Hardlock-Modul wird vor der Übergabe an seinen Benutzer mit
Hilfe einer speziellen Crypto-Programmer-Card oder eines USB-Master-Hardlocks
vom System-Administrator mit einer Kodierung programmiert. Das Vorhandensein
eines Hardlock-Moduls mit dieser Kodierung wird später von der DPAC-Client-
Anwendung über die Methode Login() der Klasse Hardlock 67 abgefragt.
Neben der Kodierung bietet das Hardlock-Modul zusätzlich die Möglichkeit,
einen 96 Byte großen, nichtflüchtigen Speicher (EEPROM) mit nutzerspezifischen
Informationen zu beschreiben. Dieser Speicher kann nur bei der Kodierung mit
der Crypto-Programmer-Card bzw. dem USB-Master-Hardlocks beschrieben
werden. Im DPAC-System wir er dazu verwendet, die Nutzer-Kennung seines
Benutzers zu speichern. Diese kann später von der Client-Anwendung mit Hilfe der
Hardlock-Methode Read() gelesen und verwendet werden. Aufgrund der Tatsache,
dass es in der DPAC-Client-Anwendung für den Benutzer keine Möglichkeit gibt,
seine Kennung über einen Dialog mitzuteilen (lediglich das geheime Passwort wird
abgefragt), entsteht somit eine direkte Verbindung zum angesprochenen Authentifikationsverfahren
durch Wissen. Desweiteren ist es durch die Speicherung der
Nutzer-Kennung auf dem Hardlock-Modul möglich, das Vorhandensein des Moduls
auch serverseitig zu überprüfen, da sowohl das Passwort (MD5-Hashwert) als
auch die Nutzer-Kennung zum Server geschickt werden. Ist das Hardlock-Modul
67 Die Klasse Hardlock wurde von der Firma Aladdin zur Einbindung ihrer Hardlock-Module in
Java-Programme entwickelt.
104

Inv.-Nr.:2003-07-02/047/IN96/2253
nicht verfügbar, so fehlt auch die entsprechende Nutzer-Kennung.
Der Ablauf der Nutzerauthentifikation im DPAC-Informationssystem lässt
sich wie folgt zusammenfassen:
• Vorbereitend muss der DAPC-Nutzer sein Hardlock-Modul mit dem Rechner
verbinden.
• Nach dem Start der DPAC-Client-Anwendung wird zunächst überprüft, ob
ein Hardlock-Modul mit der entsprechenden Kodierung vorhanden ist. Wenn
dies der Fall ist, wird die Nutzer-Kennung ausgelesen. Danach wird der Nutzer
aufgefordert sein geheimes Passwort einzugeben. Sollte der Nutzer die
Anwendung zum ersten Mal starten, so ist an dieser Stelle das vom System-
Administrator erzeugte Passwort zu verwenden.
Ist das Hardlock-Modul nicht verfügbar, beendet sich die Client-Anwendung
mit einer Fehlermeldung.
• Vom eingegebenen Passwort wird ein MD5-Hashwert errechnet. Dieser wird
anschließend zusammen mit der Nutzer-Kennung zum Server versandt.
• Der Server vergleicht die erhaltenen Informationen mit den Referenzdaten
aus der Datenbank. Stimmen diese überein, so teilt er dem Client den Namen
mit, unter dem er sein DBQuest-Objekt (vergl.: Abbschnitt 5.4.1) bei der
RMI-Registry angemeldet (gebunden) hat. Sollte es keine Übereinstimmung
gegeben haben, so erhält der Client eine Fehlermeldung.
• Die vom Server gesendeten Informationen verwendet der Client entweder,
um eine Referenz auf sein DBQuest-Objekt zu erhalten oder beim Empfang
einer Fehlermeldung, um den Nutzer aufzufordern, sein Passwort erneut einzugeben.
Sollte der Nutzer dreimal hintereinander sein Passwort falsch eingegeben haben,
oder die Nutzer-Kennung nicht bekannt sein, so wird dies als Angriff gewertet. Der
Anwendungsserver erzeugt einen entsprechenden Eintrag mit der IP-Adresse des
Clients in die Log-Datei und die DPAC-Client-Anwendung beendet sich mit einer
Fehlermeldung. An dieser Stelle wäre es auch durchaus denkbar, eine Funktion zu
integrieren, die beim Eintreten eines solchen Ereignisses umgehend den System-
Administrator beispielsweise über E-Mail informiert und die IP-Adresse des betroffenen
Clients in eine sogenannte Black-List einträgt. Eine solche Black-List ist
eine Liste, in der alle die IP-Adressen von Clients zu finden sind, denen der Systemzugriff
unbedingt zu verweigern ist.
105

Inv.-Nr.:2003-07-02/047/IN96/2253
6 Zusammenfassung und Ausblick
Moderne Unternehmensstrukturen und neue Arbeitsformen wie Telearbeit und
Mobile Computing benötigen immer mehr anpassungsfähige Informationstechnologien,
die sich auf unterschiedlichste Kommunikationsanforderungen einstellen
müssen. Diese Informationstechnologien ermöglichen es, dem klassischen Aufbau
einer Firmenstruktur mehr Flexibilität zu geben, sodass auch dezentral angesiedelte
Mitarbeiter an einem oder mehreren Projekten zusammen arbeiten können.
Die meisten Firmen haben erkannt, dass sich mit Hilfe des Mediums Internet
nicht nur Waren verkaufen lassen, sondern vielmehr hohe Kosten durch die
produktivitätssteigernde Nutzung des Mediums zur Kommunikation mit Kunden,
Geschäftspartnern, Lieferanten und Außendienstmitarbeitern eingespart werden
können. Neben den Kosten spielt aber auch die Sicherheit eine überaus wichtige
Rolle. Die Ursachen sind darin zu finden, dass viele Informationen, die über
öffentliche Netze transportiert werden schon lange nicht mehr nur allgemeinen
Charakter haben (z.B. Webseiten), sondern auch als sensibel und vertraulich
eingestuft werden müssen.
Ziel dieser Arbeit war es, ein Integrationskonzept für das Backendsystem der
Firma Häcker-Automation zu entwickeln und vorzustellen, das aufzeigt, wie
die im Backendsystem gehaltenen Informationen berechtigten Anwendern zur
Verfügung gestellt werden können. Dabei wurde den Aspekten dynamische
Verteilung einer Client-Anwendung, die den Zugriff auf das Backendsystem über
einen Anwendungsserver ermöglicht, Nutzerfreundlichkeit und Sicherheit eine
besondere Bedeutung eingeräumt.
Mit Java-Web-Start wurde eine Technologie vorgestellt, mit der sich eigenständige
Java-Applikationen über Rechnernetzwerke wie das Internet verteilen lassen.
WebStart stellt damit eine echte Alternative zu Java-Applets dar, in der die meisten
Nachteile von Applets durch gezielte Verbesserungen aus dem Weg geräumt
worden sind. Diese Verbesserungen und das Sicherheitskonzept von WebStart
(Schutz der übertragenen Java-Applikation und Schutz des Gastrechners) haben
unter anderem dazu beigetragen, WebStart für die Verteilung der DPAC-Client-
Anwendung einzusetzen. Für eine bessere Akzeptanz beim Anwender wäre es
allerdings wünschenswert, wenn Java und damit auch WebStart zusammen mit
den gängigen Betriebssystemen ausgeliefert würde, sodass eine möglicherweise
als lästig empfundene Nachinstallation der Java Virtual Machine (JVM) nicht
mehr notwendig ist. Leider hat einer der bedeutendsten Betriebssystem-Hersteller
Microsoft angekündigt, ab dem Jahr 2004 keine eigene JVM mehr auszuliefern,
was angesichts der weltweit immer größer werdenden Zahl von Java-Nutzern
nicht unbedingt nachvollziehbar ist. Erfreulich hingegen ist, dass Sun zwei der
wichtigsten PC-Lieferanten, hp und DELL, gewinnen konnte, ihre Rechner ab
Ende 2003 mit vorinstallierter JVM auszuliefern. [41]
Neben der Verteilung der Client-Anwendung lag ein weiterer Schwerpunkt der
Arbeit in der Sicherung der RMI-Kommunikation zwischen der Client-Anwendung
106

Inv.-Nr.:2003-07-02/047/IN96/2253
und dem Anwendungsserver. Auf der Suche nach Lösungsmöglichkeiten für dieses
Problem wurden neben der Java Cryptography Extension (JCE) und Java Secure
Socket Extension (JSSE) auch Virtuell Private Networks (VPNs) betrachtet. Dabei
hat sich herauskristallisiert, dass sich die auf Basis des SSL-Protokolls arbeitende
JSSE am besten in die RMI-Architektur integrieren lässt.
Den Grad an Sicherheit, den die JSSE bietet, wird zum einen von der internen
Umsetzung des SSL-Protokolls, zum anderen von den zur Verfügung stehenden
kryptographischen Verfahren und der eingesetzten Schlüssellängen bestimmt. Es
ist leicht einzusehen, dass beispielsweise eine Verschlüsselung mit DES (Data
Encryption Standard) heutzutage keinen ausreichenden Schutz mehr gewährleisten
kann. Einfach aufgrund der Tatsache, dass schon vor einigen Jahren erfolgreiche
Angriffe auf DES durchgeführt wurden. Dennoch wird DES vermutlich aus
Kompatibilitätsgründen immer noch von vielen kryptographischen Werkzeugen
unterstützt. So auch von der JSSE und JCE. Für kryptographische Produkte und
Werkzeuge ist es von besonderer Wichtigkeit, immer am Puls der Zeit zu bleiben,
um aktuelle Erkenntnisse aus der Kryptoanalyse und neue kryptographische
Verfahren einfließen zu lassen. Dass Sun Microsystems diesen Weg geht, zeigt
die Integration des Advanced Encryption Standard (AES) in die JSSE und JCE
Implementationen. Der Advanced Encryption Standard unterstützt Schlüssellängen
bis zu 256 Bit und ist ab der Version 1.4.2 des J2SE SDK verfügbar.
Allerdings ist auch das Image des AES, der als Nachfolger von DES gilt, schon
ein klein wenig angekratzt. In [46] werden einige Methoden vorgestellt, die von
den konventionellen Verfahren der Kryptoanalyse abweichen und AES mittelfristig
in Bedrängnis bringen könnten. Dennoch darf AES vorerst mit ruhigem Gewissen
benutzt werden. Nur 20 Jahre AES-Lebenserwartung, ähnlich wie bei DES sind
wohl nicht zu erwarten. [46]
Wie in der Arbeit erläutert, haftet RMI der Nachteil an, dass die Kommunikation
einen offenen Port erfordert, der durch den weit verbreiteten Einsatz von
Firewalls nicht immer zur Verfügung steht. Genau an diesem Punkt setzt das zur
Zeit im Zusammenhang mit WebServices viel diskutierte Simple Object Access
Protocol (SOAP) an. SOAP bietet einen einfachen Zugriff auf Server-Ressourcen
mit Hilfe der etablierten Web-Standards HTTP und XML. Dabei beschreibt SOAP
selbst nur die Art und Weise, wie Inhalte (Serialisierung) und die XML-Daten
übertragen werden. Mit der Übertragung selbst hat SOAP aber eigentlich nichts
zu tun, denn dafür wurden andere Protokolle definiert. Idealerweise findet HTTP
als Transportprotokoll Verwendung, denn in der Regel beschränken Firewalls die
Nutzung von HTTP nicht. Der XML-basierende Aufruf einer entfernten Routine
sieht ganz allgemein betrachtet wie folgt aus: Zunächst wird der Aufruf in eine
XML-Datenstruktur verpackt und via HTTP-Request (in der Regel auf dem
Standardport 80) vom Client an den Server übertragen. Nach Abarbeitung der
Routine verpackt der Server die Rückgabewerte ebenfalls in eine XML-Struktur
und sendet diese per HTTP-Response zurück.
Der Einsatz von SOAP bringt aber nicht nur Vorteile. So wird die zu übertragende
Datenmenge durch die XML-Repräsentation vergrößert und sowohl server- als
auch des clientseitig ist ein möglicherweise zeitaufwendiges Parsen der Parameter
107

Inv.-Nr.:2003-07-02/047/IN96/2253
bzw. Ergebnissen erforderlich. In Umgebungen, die performante Übertragung
fordern, wird sich SOAP deshalb wohl nicht so schnell durchsetzen. [45]
Der letzte Teil der Arbeit beschäftigte sich mit der Entwicklung und Vorstellung
eines Konzeptes zur Integration des DPAC-Backendsystems. Dabei wurden
sowohl die von der Firma Häcker-Automation gestellten Anforderungen, als auch
die vom Autor gezogenen Schlussfolgerungen, die sich während der Untersuchungen
der Bereiche Grundlagen, Mobiler Code und Sichere Kommunikation ergaben,
bei der Konzeption berücksichtigt.
Das erarbeitete Integrationskonzept und der darauf aufbauende Prototyp bilden
eine Grundlage, auf der sich das DPAC-Informationssystem der Firma Häcker-
Automation in Zukunft weiter ausbauen und mit weiteren Funktionen versehen
lässt.
108

Inv.-Nr.:2003-07-02/047/IN96/2253
A
Anhang
A.1 Thesen dieser Arbeit
• Da mobiler Code während des Transports über ein unsicheres Medium den
unterschiedlichsten Bedrohungen ausgesetzt ist, muss er zu diesem Zeitpunkt
durch geeignete Mechanismen geschützt werden.
• Für den Schutz der Vertraulichkeit des mobilen Codes ist der Advanced Encryption
Standard (AES) einzusetzen, da sein Vorgänger DES (Data Encryption
Standard) diesbezüglich keine Sicherheit mehr gewährleisten kann.
• Zukünftige Java-Web-Start-Versionen gilt es dahingehend zu verbessern, dass
die vom Anwender getroffenen Entscheidungen bezüglich der Berechtigungen,
die eine Applikation auf dem lokalen System hat, gespeichert werden,
da ansonsten Akzeptanzprobleme auftreten.
• Die Sicherheitserweiterung für Javas Remote Method Invocation (RMI Security
Extension) hat bis heute das Entwurfsstadium noch nicht verlassen und
kann zur Sicherung der RMI-Kommunikation nicht eingesetzt werden.
• Da RMI nie unmittelbar auf Sockets zugreift, können mit Hilfe von RMI-
Socket-Factories benutzerspezifische Sockets implementiert werden die insbesondere
die Einrichtung einer sicheren Kommunikationsverbindung zwischen
Client und Server erlauben.
• Da die RMI-Kommunikation einen offenen Port erfordert, kommt es zu Problemen,
wenn RMI-Client oder RMI-Server hinter einer Firewall (Packetfilter)
betrieben werden.
• Der spontane Aufbau einer sicheren Kommunikationsverbindung mit Hilfe
eines Virtuel Private Networks (VPN) ist nur dann möglich, wenn bereits eine
entsprechende Infrastruktur zur Verfügung steht.
• Die Client/Server-Architektur des DPAC-Informationssystems ist so konzipiert,
dass auf Seiten des Clients nur die Präsentationslogik implementiert
werden muss.
• Ein Dienst zum Manipulieren und Abfragen der Daten im Backendsystem
existiert auf dem DPAC-Anwendungsserver nur dann, wenn er von einem berechtigen
DPAC-Client/Nutzer angefordert wurde und dieser damit arbeitet.
Schwarzhausen, 01.07.2003
Christian Stötzer
I

Inv.-Nr.:2003-07-02/047/IN96/2253
A.2 Erstellen von Secure Sockets mit Hilfe der JSSE
A.2.1
Clientseitig
An dieser Stelle soll die Erzeugung eines Secure-Socket-Objekts auf Seiten des
Clients schrittweise beschrieben werden. Es wird vorausgesetzt, dass der zur
Authentifizierung benötigte öffentliche Schlüssel des Servers in Form der Datei
sever public.key bereits vorliegt.
Vorbereitung
1. Erzeugen eines Schlüsselpaars (öffentlich/privat) mit Hilfe des keytools.
keytool -genkey -alias clientprivate -keystore client.private
-keyalg rsa -keysize 1024
Dieses Kommando erzeugt nach der Eingabe eines neuen keystore-Passworts
sowie einiger Daten, die für das Testzertifikat benötigt werden, einen privaten
und einen öffentlichen Schlüssel der Länge 1024 Bit für das RSA-Verfahren.
Beide Schlüssel werden in der keystore-Datei client.private unter dem
Alias clientprivate gespeichert.
2. Export des öffentlichen Client-Schlüssels mittels keytool, um ihn für den Server
verfügbar zu machen.
keytool -export -alias clientprivate -keystore client.private
-file client public.key
Dieser Befehl schreibt nach Eingabe des keystore-Passworts eine Kopie des
öffentlichen Client-Schlüssels in die Datei client public.key.
3. Import des öffentlichen Server-Schlüssels für die spätere Authentifizierung
des Servers.
keytool -import -noprompt -alias severpublic -keystore
server.public -file sever public.key
Dieser Befehl importiert nach der Eingabe eines neuen keystore-Passworts
den öffentlichen Schlüssel des Servers in eine neue keystore-Datei namens
server.public. Zur Identifizierung bekommt der Schlüssel den Alias
serverpublic zugewiesen.
Programmierung
4. Erzeugen eines SecureRandom-Objekts, das durch den Aufruf der Methode
nextInt() eine kryptographische Pseudo-Zufallszahl berechnet.
SecureRandom secureRandom = new SecureRandom();
secureRandom.nextInt();
II

Inv.-Nr.:2003-07-02/047/IN96/2253
5. Erzeugung eines leeren KeyStore-Objekts vom Typ ”JKS” und anschließende
Initialisierung mit Hilfe der load()-Methode sowie der keystore-Datei
client.private.
KeyStore clientKeyStore = KeyStore.getInstance("JKS");
clientKeyStore.load(new FileInputStream("client.private"),
"keystore-Passwort".toCharArray());
6. Erzeugen eines zweiten KeyStore-Objekts, welches den öffentlichen
Schlüssel des Servers aufnimmt.
KeyStore serverKeyStore = KeyStore.getInstance("JKS");
serverKeyStore.load(new FileInputStream("server.public"),
"keystore-Passwort".toCharArray());
7. Erzeugen eines TrustManagerFactory-Objekts und anschließende Initialisierung
mit dem serverKeyStore-Objekt. Das TrustManagerFactory-Objekt hat
somit Zugriff auf den öffentlichen Schlüssel des Servers.
TrustManagerFactory tmf =
TrustManagerFactory.getInstance("SUNX509");
tmf.init(serverKeyStore);
Die TrustManagerFactory liefert später den TrustManager, der für die Authentifizierung
des Servers benötigt wird.
8. Erzeugen eines KeyManagerFactory-Objekts und anschließende Initialisierung
mit dem clientKeyStore-Objekt. Das KeyManagerFactory-Objekt hat
somit Zugriff auf den privaten Schlüssel des Clients.
KeyManagerFactory kmf =
KeyManagerFactory.getInstance("SUNX509");
kmf.init(clientKeyStore,"keystore-Passwort".toCharArray());
Die KeyManagerFactory liefert später den KeyManager, der für die Verwaltung
der Schlüssel des Clients zuständig ist.
9. Erzeugen eines SSLContext-Objekts, das eine Implementierung des Transport
Layer Security Protokolls (TLS) repräsentiert. Anschließend wird es mit
dem KeyManager, den die KeyManagerFactory liefert, dem TrustManager
von der TrustManagerFactory und dem zu Beginn erzeugten SecureRandom-
Objekt initialisiert.
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(),
tmf.getTrustManagers(),secureRandom);
10. Die Methode getSocketFactory() des SSLContext-Objekts liefert ein
SSLSocketFactory-Objekt, mit dessen Hilfe dann ein Secure-Socket-Objekt
erzeugt wird.
SSLSocketFactory sf = sslContext.getSocketFactory();
SSLSocket socket = (SSLSocket)sf.createSocket(host,port);
III

Inv.-Nr.:2003-07-02/047/IN96/2253
A.2.2
Serverseitig
Die notwendigen Schritte zur Generierung eines Secure-Server-Socket-Objekts auf
Seiten des Servers ähneln denen, die clientseitig durchzuführen sind, um ein Secure-
Socket-Objekt zu erzeugen. Soll der Server den Client authentifizieren, so muss auf
Seiten des Server der öffentliche Schlüssel des Clients verfügbar sein. Im weiteren
wird davon ausgegangen, dass die Datei client public.key den öffentlichen
Schlüssel des Clients enthält und für den Server verfügbar ist.
Vorbereitung
1. Erzeugen eines Schlüsselpaars (öffentlich/privat) mit Hilfe des keytools.
keytool -genkey -alias serverprivate -keystore server.private
-keyalg rsa -keysize 1024
Dieses Kommando erzeugt nach der Eingabe eines neuen keystore-Passworts
sowie einiger Daten, die für das Testzertifikat benötigt werden, einen privaten
und einen öffentlichen Schlüssel der Länge 1024 Bit für das RSA-Verfahren.
Beide Schlüssel werden in der keystore-Datei server.private unter dem
Alias serverprivate gespeichert.
2. Export des öffentlichen Server-Schlüssels mittels keytool, um ihn für den Client
verfügbar zu machen.
keytool -export -alias serverprivate -keystore server.private
-file server public.key
Dieser Befehl schreibt nach Eingabe des keystore-Passworts eine Kopie des
öffentlichen Server-Schlüssels in die Datei server public.key.
3. Import des öffentlichen Client-Schlüssels für die spätere Authentifizierung
des Clients.
keytool -import -noprompt -alias clientpublic -keystore
client.public -file client public.key
Dieser Befehl importiert nach der Eingabe eines neuen keystore-Passworts
den öffentlichen Schlüssel des Clients in eine neue keystore-Datei namens
client.public. Zur Identifizierung bekommt der Schlüssel den Alias
clientpublic zugewiesen.
Programmierung
4. Erzeugen eines SecureRandom-Objekts, das durch den Aufruf der Methode
nextInt() eine kryptographische Pseudo-Zufallszahl berechnet.
SecureRandom secureRandom = new SecureRandom();
secureRandom.nextInt();
IV

Inv.-Nr.:2003-07-02/047/IN96/2253
5. Erzeugung eines leeren KeyStore-Objekts vom Typ ”JKS” und anschließende
Initialisierung mit Hilfe der load()-Methode sowie der keystore-Datei
server.private.
KeyStore serverKeyStore = KeyStore.getInstance("JKS");
serverKeyStore.load(new FileInputStream("server.private"),
"keystore-Passwort".toCharArray());
6. Erzeugen eines zweiten KeyStore-Objekts, welches den öffentlichen
Schlüssel des Clients aufnimmt.
KeyStore clientKeyStore = KeyStore.getInstance("JKS");
clientKeyStore.load(new FileInputStream("client.public"),
"keystore-Passwort".toCharArray());
7. Erzeugen eines TrustManagerFactory-Objekts und anschließende Initialisierung
mit dem clientKeyStore-Objekt. Das TrustManagerFactory-Objekt hat
somit Zugriff auf den öffentlichen Schlüssel des Clients.
TrustManagerFactory tmf =
TrustManagerFactory.getInstance("SUNX509");
tmf.init(clientKeyStore);
Die TrustManagerFactory liefert später den TrustManager, der für die Authentifizierung
des Clients benötigt wird.
8. Erzeugen eines KeyManagerFactory-Objekts und anschließende Initialisierung
mit dem serverKeyStore-Objekt. Das KeyManagerFactory-Objekt hat
somit Zugriff auf den privaten Schlüssel des Servers.
KeyManagerFactory kmf =
KeyManagerFactory.getInstance("SUNX509");
kmf.init(serverKeyStore,"keystore-Passwort".toCharArray());
Die KeyManagerFactory liefert später den KeyManager, der für die Verwaltung
der Schlüssel des Servers zuständig ist.
9. Erzeugen eines SSLContext-Objekts, das eine Implementierung des Transport
Layer Security Protokolls (TLS) repräsentiert. Anschließend wird es mit
dem KeyManager, den die KeyManagerFactory liefert, dem TrustManager
von der TrustManagerFactory und dem zu Beginn erzeugten SecureRandom-
Objekt initialisiert.
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(),
tmf.getTrustManagers(),secureRandom);
10. Die Methode getServerSocketFactory() des SSLContext-Objekts liefert ein
SSLServerSocketFactory-Objekt, mit dessen Hilfe dann ein Secure-Server-
Socket-Objekt erzeugt wird.
V

Inv.-Nr.:2003-07-02/047/IN96/2253
SSLServerSocketFactory ssf = sslContext.getSocketFactory();
SSLServerSocket servs =
(SSLServerSocket)ssf.createServerSocket(port);
servs.setNeedClientAuth(true);
VI

Inv.-Nr.:2003-07-02/047/IN96/2253
Abbildungsverzeichnis
1 Kosten / Nutzen Verhältnis für Sicherheitsvorkehrungen . . . . . . . 2
2 Sicherheits-Grundfunktionen . . . . . . . . . . . . . . . . . . . . . 5
3 Beispiel einer Zugriffsmatrix [19] . . . . . . . . . . . . . . . . . . 9
4 Angriffszyklus [20] . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Komponenten eines Kryptosystems [5] . . . . . . . . . . . . . . . . 19
6 Funktionsweise des DES [24] . . . . . . . . . . . . . . . . . . . . . 26
7 Triple-DES [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8 Die Teilschichten des SSL-Protokolls im TCP/IP Modell [42][24] . 32
9 Das SSL-Record-Protokoll [4] . . . . . . . . . . . . . . . . . . . . 34
10 Anwendung von IPsec auf IP-Pakete [14] . . . . . . . . . . . . . . 36
11 Bedrohungsszenarien für mobilen Code [5] . . . . . . . . . . . . . 40
12 Komponenten der Java-Sicherheitsarchitektur [5] . . . . . . . . . . 49
13 Sicherheitsmodelle in JDK1.0 und JDK1.1 [5][20] . . . . . . . . . . 50
14 Der Java-Web-Start Applikationsmanager . . . . . . . . . . . . . . 56
15 Allgemeiner Überblick über die Elemente einer JNLP-Datei [27] . . 58
16 Frontend des Java-Policy-Tools . . . . . . . . . . . . . . . . . . . . 64
17 WebStart Sicherheitshinweis . . . . . . . . . . . . . . . . . . . . . 65
18 WebStart Sicherheitswarnung . . . . . . . . . . . . . . . . . . . . . 66
19 WebStart HTTPS-Sicherheitswarnung . . . . . . . . . . . . . . . . 68
20 Möglicher WebStart Sicherheitshinweis . . . . . . . . . . . . . . . 70
21 Eine 3-tier-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 71
22 Kommunikationspartner in einem VPN . . . . . . . . . . . . . . . 82
23 3-tier-Architektur des DPAC-Informationssystems . . . . . . . . . . 88
24 Frontend zur Kontaktverwaltung im DPAC-System . . . . . . . . . 90
25 Schema des DPAC-Anwendungsservers . . . . . . . . . . . . . . . 98
26 USB- und Parallel-Port Hardlock . . . . . . . . . . . . . . . . . . . 103
VII

Inv.-Nr.:2003-07-02/047/IN96/2253
Literatur
[1] ALADDIN KNOWLEDGE SYSTEMS GERMANY: Hardlock - Technical Documentation.
Aladdin, 2001.
[2] BRACZEK, MARK: Mobilität und IT-Sicherheit - Eine Einführung. Technische
Universität Ilmenau, 2000.
[3] BSI: IT-Grundschutzhandbuch. Bundesamtes für Sicherheit in der Informationstechnik,
2002.
[4] COULOURIS, GEORGE, JEAN DOLLIMORE und TIM KINDBERG: Verteilte
Systeme - Konzepte und Design. Addison-Wesley, 3. Auflage, 2002.
[5] ECKERT, CLAUDIA: IT-Sicherheit. Oldenbourg Verlag, 2001.
[6] EILEBRECHT, LARS: Apache Web-Server. mitp, 2000.
[7] ENGELKE, MARTINA: Datenschutz und Datensicherheit Vorlesungsskript.
Otto-von-Guericke-Universität Magdeburg, 2001.
[8] FERGUSON, NIELS und BRUCE SCHNEIER: A Cryptographic Evaluation
of IPsec. Counterpane Internet Security, Inc., 1998. http://www.
counterpane.com.
[9] GOOSSENS, MICHEL, FRANK MITTELBACH und ALEXANDER SAMARIN:
Der L A TEX Begleiter. Addison-Wesley, 1998.
[10] HAAS, ROLAND und ULRICH SCHREINER: Java-Technologien für Unternehmensanwendungen.
Hanser, 2003.
[11] HUNGENBERG, THOMAS: Online-Lexikon der Informationssicherheit. Webseite,
2000. http://www.demonium.de/th/home/sicherheit/
lexikon/index.phtml.
[12] INSTITUTS FÜR ANGEWANDTE INFORMATIONSVERARBEITUNG UND
KOMMUNIKATIONSTECHNOLOGIE: iaik’s java crypto products. Webseite,
2003. http://jce.iaik.tugraz.at/products/index.php.
[13] JGURU: Fundamentals of RMI - Short Course. Webseite, 2003. http:
//developer.java.sun.com/developer/onlineTraining/
rmi/RMI.html.
[14] KOWALK, W.: Rechnernetze. Webseite, 2002. http://einstein.
informatik.uni-oldenburg.de/rechnernetze/Default.
htm.
[15] KRÜGER, GUIDO: Handbuch der Java-Programmierung. Addison-Wesley, 3.
Auflage, 2002.
VIII

Inv.-Nr.:2003-07-02/047/IN96/2253
[16] LIPP, PETER, DIETER BRATKO, JOHANNES FARMER, WOLFGANG PLAT-
ZER und ANDREAS STERBENZ: Sicherheit und Kryptographie in Java. Addison
Wesley, 2000.
[17] MCGRAW, GARY und EDWARD E. FELTEN: Securing Java: Getting Down to
Business with Mobile Code. Wiley Computer Publishing, 1999.
[18] PISTOIA, MARCO, DUANE F. RELLER, DEEPAK GUPTA, MILIND NAGURA
und ASHOK K. RAMANI: Java2 Network Security. Prentice Hall PTR, 1999.
[19] POHL, HARTMUT, GERHARD WECK und (HERAUSGEBER): Einführung in
die Informationssicherheit. Oldenbourg Verlag München Wien, 1993.
[20] RAEPPLE, MARTIN: Sicherheitskonzepte für das Internet. dpunkt.verlag, 2.
Auflage, 2001.
[21] REIF, HOLGER: Sicherheit in Rechnernetzen Vorlesungsskript. Technische
Universität Ilmenau, Fakultät für Informatik und Automatisierung, Institut für
Praktische Informatik und Medieninformatik, 1999.
[22] REISER, HELMUT: Sicherheitsarchitektur für ein Managementsystem auf der
Basis Mobiler Agenten. Herbert Utz Verlag, 2001.
[23] RÜTSCHLIN, JOCHEN: Sicherheitsverwaltung in einer Umgebung heterogener
Datenbanken im Intranet. Diplomarbeit, Universität Ulm, 1999.
[24] SCHMEH, KLAUS: Kryptografie und Public-Key-Infrastrukturen im Internet.
dpunkt.verlag, 2. aktualisierte Auflage, 2001.
[25] SCHMIDT, JÜRGEN: Das private Internet. c’t, 10, 2003.
[26] SCHMIDT, JÜRGEN: Der Pförtner zum Netz. c’t, 10, 2003.
[27] SCHMIDT, RENÉ W.: JSR-56 - Java T M Network Launching Protocol and API
Specification v1.0.1. Sun Microsystems, Inc., 2001.
[28] SCHNEIER, BRUCE: Angewandte Kryptographie. Addison-Wesley, 1996.
[29] SCHNEIER, BRUCE und MUDGE: Cryptanalysis of Microsoft’s PPTP Authentication
Extensions (MS-CHAPv2). Webseite, 1999. http://www.
counterpane.com/pptpv2-paper.html.
[30] SCHWENK, JÖRG: Sicherheit und Kryptographie im Internet. vieweg, 2002.
[31] SCOTT, CHARLIE, PAUL WOLFE und MIKE ERWIN: Virtuelle Private Netzwerke.
O’Reilly, 1999.
[32] SOHR, KARSTEN: Die Sicherheitsaspekte von mobilem Code. Doktorarbeit,
Philipps-Universität Marburg, 2001.
[33] SOSNA, DIETER: Datenschutz und Datensicherheit Vorlesungsskript. Universität
Leipzig, 1999.
IX

Inv.-Nr.:2003-07-02/047/IN96/2253
[34] STEHLI, MARCEL: Java Web Start Technologie. Technische Universität Ilmenau,
2001.
[35] SUN MICROSYSTEMS: jar - The Java Archive Tool. Webseite, 2001.
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/
jar.html.
[36] SUN MICROSYSTEMS: jarsigner - JAR Signing and Verification Tool. Webseite,
2001. http://java.sun.com/products/jdk/1.2/docs/
tooldocs/solaris/jarsigner.ht%ml.
[37] SUN MICROSYSTEMS: keytool - Key and Certificate Management Tool. Webseite,
2001. http://java.sun.com/products/jdk/1.2/docs/
tooldocs/solaris/keytool.html%.
[38] SUN MICROSYSTEMS: Java Cryptography Extension. Webseite, 2003.
http://java.sun.com/products/jce/.
[39] SUN MICROSYSTEMS: Java Secure Socket Extension. Webseite, 2003.
http://java.sun.com/products/jsse/.
[40] SUN MICROSYSTEMS: Java Web Start. Webseite, 2003. http://java.
sun.com/products/javawebstart/.
[41] SUN MICROSYSTEMS: JavaOne conference Online. Webseite, 2003. http:
//javaoneonline.mentorware.net.
[42] TANENBAUM, ANDREW S.: Computernetzwerke. Prentice Hall, 3. revidierte
Auflage, 1998.
[43] THALHEIM, LISA, JAN KRISSLER und PETER-MICHAEL ZIEGLER: Körperkontrolle.
c’t, 11, 2002.
[44] THOMAS, STEPHEN A.: SSL and TLS Essentials. Wiley Computer Publishing,
2000.
[45] ULLENBOOM, CHRISTIAN: Java ist auch eine Insel. Galileo Computing,
2002.
[46] WOBST, REINHARD: Angekratzt - Kryptanalyse von AES schreitet voran. iX,
12, 2002.
[47] WUTKA, MARK: J2EE Developer’s Guide. Markt und Technik, 2002.
[48] ZIMMERMANN, JÜRGEN und GERD BENEKEN: Verteilte Komponenten und
Datenbankanbindung. Addison-Wesley, 2000.
X