Sichere Mediation mit mobilem Code | Implementierung und

Transcription

Lena Wiese
Sichere Mediation
mit mobilem Code
|
Implementierung und
Sicherheitsanalyse
Diplomarbeit
13. Oktober 2004
betreut und begutachtet durch
Prof. Dr. Joachim Biskup und
Dr. Barbara Sprick
Arbeitsgruppe ISSI
(Informationssysteme und Sicherheit)
Lehrstuhl VI
Fachbereich Informatik
Universitat Dortmund
Die Informatik ist eine junge Wissenschaft und trotzdem schon vielfach in
"Anwendung.
Dies ist Gunst und Last zugleich.
[...]
Deshalb gilt in der Informatik mehr noch als in anderen Wissenschaften das
Prinzip der standigen kritischen Hinterfragung der Inhalte und das Bewutsein der Beschranktheit und Relativitat der erlangten Erkenntnisse.\
Manfred Broy
i
Vorwort
Vorwort und Danksagung
Dieser Text wurde als Diplomarbeit am Informatik-Lehrstuhl 6 der Universitat Dortmund in
der Arbeitsgruppe "Informationssysteme und Sicherheit\ (ISSI) verfasst; ISSI bearbeitet unter
vielen anderen Projekten das Thema sichere Mediation. Die Diplomarbeit besteht aus funf
Teilen. Der erste Teil umfasst einfuhrende Angaben zum Thema Mediation und die Aufgabenstellung. Teil II beginnt mit einer technischen Diskussion des mobilen Codes und geht dann
uber zu Sicherheitsrisiken durch mobilen Code. Teil III beschreibt die Implementierung des
Programms, das zu dieser Diplomarbeit entwickelt wurde, und Teil IV fugt die Diskussion und
die Implementierung zweier Erweiterungen hinzu. Teil V enthalt einige abschlieende Bemerkungen. Das Glossar auf Seite 124 erklart die wichtigsten Begrie. Der Index ab Seite 126 hilft
bei der Suche nach Schlagwortern. Auf den letzten Seiten dieser Arbeit (ab Seite 132) bendet
sich ein vollstandiges Inhaltsverzeichnis. Die CD in Anhang G auf Seite 121 enthalt Bedienungsanleitungen fur alle drei Programmmodule, die Programme selbst und den Quellcode.
Die unverzichtbaren Hinweise von Peter Rechenberg (siehe [Rec03]) zu einem guten Schreibstil
in technischen Texten waren mir eine groe Hilfe beim Verfassen dieser Arbeit. Insbesondere
habe ich, soweit es ging, Anglizismen vermieden, da ich der Ansicht bin, dass das Deutsche auch
im Bereich der Informatik als Fachsprache verwendet werden kann. Eine Ausnahme bilden die
Begrie Client, Server und Interface (Interface nur, sofern es sich auf eine Java-Klasse bezieht),
sowie einige wenige andere Begrie; eine U bersetzung dieser Begrie wurde im jeweiligen Zusammenhang eventuell zu Missverstandnissen fuhren.
Die Benennung der Klassen meines Programms ist mit Bedacht und mit Hilfe eines EnglischWorterbuchs geschehen. Ich habe mich bemuht, im gesamten Text die "neue\ deutsche Rechtschreibung zu verwenden. Das gilt ganz besonders fur die Kommasetzung
und die Gro- und
Kleinschreibung. In Bezug auf die Getrennt- und Zusammenschreibung ziehe ich es jedoch vor,
adjektivische Wendungen zusammenzuschreiben (wie es der Duden 2004 auch wieder zulasst),
da die Getrenntschreibung oft den Sinn der Aussage verdreht.
Warenzeichen werden im Text nicht ausdrucklich gekennzeichnet. Alle Warenzeichen und eingetragenen Warenzeichen sind Eigentum ihrer jeweiligen Inhaber. Meine Arbeit hat von einigen
Projekten freier oder oener Software protiert. Als Erstes zu nennen ist hier die Eclipse Plattform (siehe [ECL]), die mich bei der Entwicklung mit Java sehr unterstutzt hat. Das
Gleiche gilt fur OpenOce (siehe [OPE]) und The Gimp (siehe [GIM]) fur die Graphikerstellung. Mein Programm kommt nicht ohne die Funktionalitat der Formatted Dataset API (siehe
[FDS]) und den Algorithmenreichtum der Bouncy Castle Crypto API (siehe [BCP]) aus.
Ich danke Joachim Biskup und Barbara Sprick fur die fachlich und menschlich sehr gute Betreuung. Ebenso danke ich Jan-Hendrik Lochner fur die enge Zusammenarbeit. Ich bin allen
weiteren Mitarbeitern des Lehrstuhls 6, die mir zum praktischen Einsatz meines Programms
im Rechnernetz des Lehrstuhls Tipps und Beistand geben konnten, fur ihre Hilfe dankbar.
Ein herzliches "thank you\ geht an Mike Amling, der mir einen Algorithmus zu mehrfachen
RSA-Verschlusselung vorgeschlagen hat. Ich danke T. R. und A. R. fur die unnachahmliche
Unterstutzung und fur alles, was sie fur mich getan haben.
ii
Zusammenfassung
iii
Zusammenfassung
Das Konzept des Multimediamediators umfasst ein Verfahren zur sicheren Mediation zwischen
informationssuchenden Kunden und verteilten Datenquellen. Ein Mediator erstellt aus der Gesamtanfrage eines Kunden Teilanfragen und leitet sie an die Datenquellen weiter. Er fasst
danach die Teilantworten der Datenquellen zu einer Gesamtantwort zusammen. Das Hauptanliegen dieser Diplomarbeit ist es, das Konzept des Multimediamediators um einen entscheidenden Punkt zu erweitern: die Verheimlichung der Antwortdaten vor dem Mediator. Jede
Datenquelle verschlusselt dazu ihre Teilantwort mit einem oentlichen Schlussel des Kunden.
Der Mediator kann auf den verschlusselten Teilantworten keine Gesamtantwort berechnen. Er
erstellt mobilen Code, der zusatzlich zu den verschlusselten Teilantworten die Rechenoperationen bereitstellt, um aus den unverschlusselten Teilantworten die Gesamtantwort zu berechnen.
Diesen mobilen Code schickt er an den Kunden. Der Kunde entschlusselt die Teilantworten,
fuhrt danach den Code aus und erhalt so die Gesamtantwort.
Das Ausfuhren des mobilen Codes bringt fur den Kunden Sicherheitsrisiken mit sich. Der Kunde stellt Code, dessen Hersteller er nicht kennt oder dem er nicht vertraut, die Ressourcen
seines Rechners zur Verfugung. Der mobile Code selbst mochte gegenuber dem Kunden seinen
Programmcode geheimhalten. In dieser Arbeit werden die Sicherheitsanforderungen aller Beteiligten und Manahmen gegen mogliche Angrie theoretisch erortert.
Das Multimediamediator-System mit mobilem Code wurde in der Programmiersprache Java
umgesetzt. Es wird untersucht, inwieweit Java Mechanismen bereitstellt, um den Kundenrechner vor Angrien des mobilen Codes und den Code vor Ausspahung durch den Kunden zu
schutzen.
Als Erweiterungen werden der Einsatz von mehreren Verschlusselungsschlusseln und die Hierarchisierung von Mediatoren theoretisch und praktisch behandelt.
Abstract
The concept of the Multimediamediator comprises a technique for secure mediation between
clients searching for information and distributed data sources. A mediator constructs partial
queries out of a client's global query and forwards them to the data sources. Subsequently
the mediator combines the partial responses to a global response. The main objective of this
diploma thesis is to add the following crucial extension to the Multimediamediator-concept:
concealing the response data from the mediator. To achieve this, each data source encrypts its
partial query with a public key belonging to the client. The mediator is not able to calculate the
global response from the encrypted partial responses. It constructs mobile code that in addition
to the encrypted partial responses contains operations to calculate the global response from
the decrypted partial responses. Thereafter it sends this mobile code to the client. The client
decrypts the partial responses, executes the code and thereby obtains the global response.
Executing mobile code holds security risks for the client. The client leaves computational resources to code whose producer is unknown to him and whom he doesn't put trust in. The mobile code itself wants to keep its program code a secret to the client. The security requirements
of all participants and countermeasures against potential attacks are analysed theoretically.
In this thesis the Multimediamediator-system with mobile code was implemented in the Java
programming language. It is examined what kind of mechanisms Java oers to prevent the
mobile code from attacking the client computer and the client from spying the mobile code.
As extensions, the usage of multiple encryption keys and the employment of a hierarchy of
mediators are covered theoretically and practically.
iv
v
Inhaltsubersicht
Inhaltsubersicht
Zusammenfassung . . . .
Abstract . . . . . . . . .
Inhaltsubersicht . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
iii
iii
v
I Einleitung
1 Das Konzept der Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Berechnungen des Mediators auf den Teilantworten . . . . . . . . . . . . . . . .
1
2
7
8
II Diskussion
19
4 Kommunikationsschemata fur den Multimediamediator . . . . . . . . . . . . . . 20
5 Vor- und Nachteile von mobilem Code . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Sicherheitsrisiken durch mobilen Code . . . . . . . . . . . . . . . . . . . . . . . . 34
III Implementierung
55
7 Eingesetzte Java-Mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8 Umsetzung des Multimediamediators mit mobilem Code . . . . . . . . . . . . . 66
9 Mogliche Angrie auf das Mediatorsystem . . . . . . . . . . . . . . . . . . . . . 85
IV
10
11
12
13
Erweiterungen
Auswirkungen einer Mediatorhierarchie . . .
Umsetzung der Mediatorhierarchie . . . . . .
Auswahl mehrerer Eigenschaftsnachweise . .
Umsetzung der Auswahl mehrerer Zertikate
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
96
100
104
105
V Resumee und Vorschlage fur die Zukunft
109
14 Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
15 Vorschlage fur die Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
vi
Inhaltsubersicht
VI
A
B
C
D
E
F
G
Anhang
U bersicht der Pakete . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Kunde) . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Mediator und Datenquelle) . . . . . . . .
Sequenzdiagramm erweitert (Kunde) . . . . . . . . . . . . . . . . . .
Sequenzdiagramm erweitert (Mediator und Datenquelle) . . . . . .
Verwendete Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Datentrager mit Bedienungsanleitung, Programmen und Quellcode .
Abbildungsverzeichnis
Tabellenverzeichnis .
Glossar . . . . . . . .
Index . . . . . . . . .
Literaturverzeichnis .
Inhaltsverzeichnis . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
. 115
. 116
. 117
. 118
. 119
. 120
. 121
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
123
124
126
126
132
1
I.
Einleitung
Inhalt
1 Das Konzept der Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Der Multimediamediator . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Berechnungen des Mediators auf den Teilantworten . . . . . . . . .
3.1 Berechnungen auf verschlusselten Daten . . . . . . . . . . . . . . . . . .
3.2 Auswertung von SQL-Ausdrucken auf verschlusselten Tabellen . . . . .
3.3 Eingeschranktes Verfahren fur Berechnungen des Multimediamediators .
3.4 Datensatzverschlusselung mit Teilschlusseln . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3
7
8
8
11
12
14
Mediation ist die Einschaltung eines (meist) neutralen und unpar"teiischen
Dritten im Konikt, der Parteien bei ihren Verhandlungsund Losungsversuchen unterstutzt, jedoch uber keine eigene
(Konikt-)Entscheidungskompetenz verfugt.\
Stephan Breidenbach [Bre95]
2
1 Das Konzept der Mediation
Mit der zunehmenden Digitalisierung von Informationen wachst die Zahl von Informationssystemen. Gleichzeitig gibt es immer mehr vernetzte Recher, die es ermoglichen, jederzeit und von
jedem Ort aus auf diese Informationen zuzugreifen. Einfache Anfragen an einzelne Datenbanken sind von einem Kunden eines Informationssystems { also einem Menschen auf Informationssuche { noch von Hand durchzufuhren; schwierig wird es, wenn die Daten in verschiedenen
Datenbanken gespeichert sind. Diese Datenbanken konnen zudem unabhangig voneinander sein
und unterschiedlich aufbereitete Daten bereit halten; eventuell sind sie nur temporar verfugbar.
Zusammenfassend lasst sich sagen, dass sich ein verteiltes Datenbanksystem durch Autonomie,
Heterogenitat und Dynamik der Datenquellen auszeichnet.
Ein Kunde muss nicht nur eine Auswahl unter den erreichbaren Datenbanken treen; aus der
puren Menge an Daten, die ihm zur Verfugung gestellt werden, muss er die Informationen
heraussuchen, die ihn interessieren (vgl. [Wie99], Seite 1). Wiederhold und Genesereth (siehe
[WG97] und [Wie99]) fuhren das Konzept der Mediation ein, um Kunden beim Finden von
relevanten Informationen in einer groen Menge von heterogenen Daten zu unterstutzen. Ein
Kunde stellt eine Anfrage anstatt an mehrere Datenbanken idealerweise an eine einzige Kontaktstelle, den sogenannten Mediator. Der Mediator ruft Daten von verschiedenen Datenbanken
ab, ubertragt die Daten der einzelnen Datenquellen in eine einheitliche Datenreprasentation,
fugt die Daten zusammen und erhoht die Informationsdichte des Ergebnisses durch Abstraktion
oder Zusammenfassung der Einzeldaten (vgl. [WG97], Seite 38). Fur eine Datenbankanfrage
bedeutet das explizit, dass der Mediator die Anfrage aufspaltet, Teilanfragen an Datenquellen stellt, aus den Teilantworten die Gesamtantwort berechnet und die Gesamtantwort an den
Kunden zuruckzuschickt.
Fur Teilnehmer an einem Mediatorsystem kann man drei verschiedene Rollen identizieren:
einen oder mehrere Kunden, einen Mediator und eine oder mehrere Datenquellen. Dieses Modell kann durch eine Hierarchie von Mediatoren erweitert werden: Ein Mediator kann eine
Teilanfrage an einen anderen Mediator weiterleiten. Dieser zweite Mediator tritt dann als Datenquelle auf.
Kunde 2
Kunde 3
Gesam
ta
nfrag e e
frag
mtan
Gesa
Mediator 1
Mediator 2
Gesamtanfrage
Teilanfrage
Teil
anfrage
Kunde 1
Quelle 1
Quelle 2
rag e
Tei lanf
Teilanfrage
Quelle 3
Abbildung 1: Schema eines Mediatorsystems
Die Begrie "Kunde\, "Mediator\ und "Datenquelle\ umfassen sowohl Menschen als auch Rechner beziehungsweise Programme: Kunde meint sowohl das Programm zum Ausfuhren einer
Anfrage als auch dessen Benutzer(in) und der Rechner auf dem es lauft; Mediatoren und Datenquellen meinen sowohl die Rechner, auf denen die Programme zur Bearbeitung der Anfrage
laufen, als auch der oder die Administrator(in) des jeweiligen Systems. Nur wenn im jeweiligen Zusammenhang eine Unterscheidung zwischen Mensch, Maschine und Programm notig ist,
werden sie explizit benannt.
1.1 Der Multimediamediator
3
Das Basismodell der Mediation nach Wiederhold und Genesereth berucksichtigt noch keine
sicherheitsrelevanten Aspekte. Alle Beteiligten konnen aber Sicherheitsforderungen an das System stellen. Datenquellen mochten ihre Angaben nur an berechtigte Kunden weiterleiten. Dabei
mochten sie durch den Mediator insofern abgeschirmt werden, dass die Kunden nichts uber die
Datenverteilung und die Identitat der Quellen erfahren. Kunden mochten, dass ihre Anfragen
und die Antworten vertraulich behandelt werden. Sie mochten, dass dem Mediator der Inhalt
der Antworten verborgen bleibt und dass die Kommunikation mit dem Mediator nicht korrumpiert werden kann. Eventuell mochten sie gegenuber dem Mediator und den Datenquellen auch
anonym bleiben. Die zentralen Sicherheitsziele sind demnach:
1. Vertraulichkeit der Daten gegenuber dem Mediator, gegenuber Kunden, die nicht berechtigt sind die Daten zu sehen, und gegenuber Dritten (zumindest wahrend der U bertragung
der Daten)
2. Anonymitat der Quellen gegenuber den Kunden
3. Vertraulichkeit der Anfrage gegenuber nicht berechtigten Kunden, Dritten und eventuell
sogar gegenuber dem Mediator
4. Unbeobachtbarkeit der Kommunikation durch nicht berechtigte Kunden und Dritte
5. Datenintegritat auf dem gesamten Kommunikationsweg
6. Anonymitat der Kunden gegenuber den Datenquellen
Die Arbeitsgruppe "Informationssysteme und Sicherheit\ am Lehrstuhl 6 des Fachbereichs Informatik der Universitat Dortmund hat ein Verfahren zur sicheren Mediation vorgestellt (siehe [ABFK03] und die darin enthaltenen Referenzen). Ihr System heit Multimediamediator
(MMM).
Im Konzept des Multimediamediator pruft eine Datenquelle anhand von Nachweisen (engl.
credentials), ob ein Kunde berechtigt ist, die Daten zu erhalten, die er angefordert hat. Die
Nachweise mussen von einer allgemein anerkannten Zertizierungsstelle ausgestellt sein: ein
Kunde sollte sich die Nachweise nur von einer Zertizierungsstelle mit einem guten Ruf austellen lassen, da eine Datenquelle Nachweise nur akzeptieren wird, wenn sie der ausstellenden Zertizerungsstelle vertraut. Es gibt zum einen Identitatsnachweise, die einen oentlichen
Schlussel an die Identitat eines Kunden knupfen, und zum anderen Eigenschaftsnachweise,
die einen oentlichen Schlussel an Eigenschaften des Kunden knupfen. Fur einen oentlichen
Schlussel kpub , eine Identitat id und eine Eigenschaft r ist I = (kpub ; id) ein Identitatsnachweis
und R = (kpub ; r) ein dazugehoriger Eigenschaftsnachweis. Mediator und Datenquellen sehen
nur die Eigenschaftsnachweise und vertrauen der Zertizierungsstelle, dass diese die Identitat
und die zertizierten Eigenschaften des Kunden gepruft hat. Die Geheimhaltung der Identitatsnachweise ermoglicht es so, die Identitat des Kunden vor dem Mediator und den Datenquellen
zu verbergen und sichert damit seine Anonymitat.
Der Kunde stellt seine Anfrage zusammen mit einer Menge von Eigenschaftsnachweisen. Der
Multimediamediator wahlt die fur eine Teilanfrage notwendige Teilmenge an Eigenschaftsnachweisen aus und leitet sie mit der jeweiligen Teilanfrage an die Datenquellen weiter. Er vereinfacht dem Kunden die Anfrage dadurch, dass er die relevanten Datenquellen selbst identizieren
und lokalisieren kann. Er verfugt uber eine abstrakte Datenbeschreibung { das sogenannte Anwendungsschema, das die Datenbankschemata der angeschlossenen Datenquellen verknupft. So
uberblickt der Multimediamediator die verfugbaren Daten und kann die Anfragen entsprechend
aufspalten. Das Mediatorsystem ist dynamisch. Kunden und Datenquellen konnen zur Laufzeit
das System betreten und wieder verlassen. Daher ist nur ein Entwurf auf einer hohen Abstraktionsebene moglich, bei dem die Datenquellen mit dem Mediator ihr Datenangebot vertraglich
4
k pub
r
Zertifizierungs
stelle
k pub
r
k pub
id
Kunde
Mediator
k pub: öffentlicher Schlüssel des Kunden
r: Eigenschaften
id: Identität des Kunden
Abbildung 2: Identitats- und Eigenschaftsnachweise
festlegen (siehe top-down design paradigm in [ABFK03], Seite 369). Wird eine neue Datenquelle an den Multimediamediator angeschlossen, muss der Teil des Anwendungsschemas, der sich
auf die von der Datenquelle angebotenen Informationen bezieht, in das Datenquellenschema
eingebettet werden.
Datenquellen konnen allerdings fur semantisch gleiche Eintrage unterschiedliche Datentypen
benutzen. Beispielsweise kann eine Datenbank zur Speicherung eines Zeitintervalls Ganzzahlen
und eine andere Fliekommazahlen benutzen. Um in einem solchen Fall Typkonikte zu vermeiden, muss der Multimediamediator uber eine Umwandlungsfunktion zwischen den Daten
aus verschiedenen Datenquellen verfugen. Zwischen Mediator und Datenquellen fuhren sogenannte Datenhullen (engl. wrappers) diese Umwandlung durch.
Die Datenquellen haben die Entscheidungsfreiheit einen Eigenschaftsnachweis anhand von Zugrisregeln, die sie im Voraus denieren, zu akzeptieren oder abzulehnen.Der Multimediamediator kann die Kunden daruber informieren, welche Eigenschaftsnachweise die Datenquellen verlangen. Jedoch tut er das nur, wenn der Kunde diese Metainformation erhalten darf. Der
Mediator kann selbst Zugrisregeln denieren und abhangig von diesen Regeln den Kunden
verschiedene Sichten auf die Daten zur Verfugung stellen.
Eigenschaften des Kunden liegen in den Eigenschaftsnachweisen als sogenannte Autorisierungsattribute vor. Ein solches Autorisierungsattribut besagt zum Beispiel "Die Person, deren Identitat mit dem oentlichen Schlussel kpub verknupft ist, ist Studentin der Universitat Dortmund\.
Innerhalb eines Eigenschaftsnachweises konnen mehrere Autorisierungsattribute mit boolschen
Operatoren verknupft werden. Liegen mehrere boolsche Ausdrucke uber Autorisierungsattributen vor (etwa aus mehreren Eigenschaftsnachweisen), werden sie konjugiert.
Die Datenquelle deniert Regeln fur den Zugri auf ihre Daten, indem sie ein Privileg mit einem boolschen Ausdruck uber Autorisierungsattributen verknupft. Ein Privileg p gibt an, mit
welcher Methode m auf ein Datenobjekt o zugegrien werden darf: p = (o; m). Die Zugrisregel "Eine Person hat Lesezugri auf die Mathematikdatenbank matdat, wenn sie Student(in)
UND in NRW eingeschrieben ist\ verknupft das Privileg p ="Lesezugri auf die Mathematikdatenbank matdat\ mit der Konjunktion von Autorisierungsattributen a ="Eine Person ist
Student(in) UND in NRW eingeschrieben\. Die Datenbank erlaubt dem Kunden
den Zugri
(das heit sie gewahrt ihm Privileg p), wenn die zertizierten Eigenschaften r des Kunden die
mit dem Privileg verknupften Autorisierungsattribute a implizieren. Im Beispiel gilt diese Implikation, da eine Studentin der Universitat Dortmund Studentin und in NRW eingeschrieben
ist.
Wenn die Autorisierung erfolgreich war, berechnet die Datenquelle ihre Teilantwort und verschlusselt sie mit den oentlichen Schlusseln aus allen Eigenschaftsnachweisen, die fur den Zugri auf die Daten notwendig waren. Dies stellt sicher, dass nur die Person die Daten entschlusseln kann, die ihre Berechtigung mit den Eigenschaftsnachweisen dargelegt hat und die privaten
Entschlusselungschlussel besitzt. So gelangen sie zumindest nicht auf dem U bertragungsweg in
falsche Hande. Insbesondere gegenuber dem Mediator, anderen Kunden und anderen Daten-
5
quellen werden die Antworten also wahrend der U bertragung geheim gehalten. Im Idealfall
berechnet der Multimediamediator aus den verschlusselten Teilantworten die Gesamtantwort
und leitet sie an den Kunden weiter, ohne selbst den Inhalt entschlusseln zu konnen. Das ist
leider nicht problemlos moglich. In dieser Diplomarbeit mochte ich daher ein Verfahren entwickeln, mit dem der Kunde dennoch die Gesamtantwort erhalten kann, ohne die oben genannten
Sicherheitsziele zu verletzen.
Zunachst mochte ich aber noch kurz darauf eingehen, welche grundlegenden Verhaltensweisen
fur ein faires Mediatorsystem, in dem kein Teilnehmer einen anderen angreift, vorausgesetzt
werden:
Kunden mussen sich darauf verlassen konnen,
{ dass die Datenquellen korrekte Antworten liefern.
{ dass der Mediator die Anfragen korrekt aufspaltet.
{ dass der Mediator die Teilanfragen korrekt weiterleitet und die Teilantworten nicht
verandert.
{ dass der Mediator und die Datenquellen die Eigenschaftsnachweise nicht veruntreuen
und keine Daten sammeln.
Datenquellen mussen sich darauf verlassen konnen, dass die Kunden die gelieferten Daten
nicht weiterverbreiten.
Kunden und Datenquellen mussen darauf vertrauen, dass die Zertikatsaussteller korrekt arbeiten, Zertikate nicht gefalscht werden konnen und die Schlusselinfrastruktur
funktioniert.
Mediatoren mussen sicher sein, dass kein anderer Teilnehmer ihre Betriebsgeheimnisse, wie den Algorithmus zur Aufspaltung der Anfrage, ihr Anwendungsschema oder die
Identitat ihrer Geschaftspartner (das sind Datenquellen oder andere Mediatoren), in Erfahrung bringen kann.
Zusatzlich kann man die Eigentumer der Daten als eigenstandige Rolle betrachten (siehe
[ABFK03], Seite 374). Sie stellen ihre Daten uber die Datenquellen den Kunden zur Verfugung.
Die Dateneigentumer mussen darauf vertrauen, dass die Datenquellen die Zugrisuberprufungen korrekt durchfuhren und Daten nur an berechtigte Kunden weitergeben.
Die Dynamik und Anonymitat, die das Multimediamediator-System auszeichnen, sind mit
Grunde fur niedriges Vertrauen zwischen den Teilnehmern. Die Basis fur das Vertrauen, dass
die anderen Teilnehmer fair handeln, ist nicht gegeben. Vielmehr kann ein Teilnehmer versuchen, eigene Interessen gegen die anderen durchzusetzen oder zum eigenen Vorteil den anderen
zu schaden. Fur einige solcher Angrie gegen die Sicherheitsinteressen der anderen Teilnehmer
schlagen die Autoren von [ABFK03] folgende Gegenmanahmen vor:
Benutzt ein Kunde immer denselben oentlichen Schlussel, kann eine Datenquelle leicht
ein Prol des Kunden erstellen. Sie kann dann versuchen von den zertizierten Eigenschaften auf die Identitat des Kunden zu schlieen oder ihre Antworten von diesem Prol
abhagig zu machen. Um das zu verhindern sollte ein Kunde moglichst fur verschiedene
Anfragen unterschiedliche Schlussel benutzen.
Schon bei der U bertragung der verschlusselten Antworten lauert das erste Angrisrisiko. Wenn ein Angreifer die gleichen Eigenschaften wie ein Kunde nachweisen kann, die
Anfrage des Kunden kennt und die verschlusselte Antwort abfangt, kann er dieselbe Anfrage stellen und so an die Klartext-Antwort gelangen. Mit diesen Informationen kann er
versuchen, den privaten Schlussel des Kunden zu ermitteln. Abhilfe bietet ein hybrides
6
Verschlusselungsverfahren (also ein Verfahren mit einem symmetrischen Sitzungschlussel, der mit dem asymmetrischen Schlussel verschlusselt wird) oder das Einbringen von
Zufallstext in die Antwort.
Die Menge der ubertragenen Daten, also die Groe des Datensatzes, kann eine interessante Information fur Angreifer sein. Antworten mussen als Gegenmanahme entweder
aufgeblaht oder gestuckelt werden, um immer gleich groe Datensatze zu ubertragen.
Ein Angreifer kann einen Eigenschaftsnachweis eines Kunden missbrauchen, indem er mit
diesem Ausweis eine Anfrage stellt. So gelangt er an die verschlusselte Antwort, die er
zwar nicht lesen kann, aber ihm vielleicht zu anderen Informationen verhilft. Als Urheber
der Anfrage wird dennoch der Kunde vermutet. Er kann sich gegen Falschanschuldigen
nur wehren, wenn jede Anfrage zusatzlich signiert wird.
Datenquellen, die Kunden verbieten, die empfangenen Daten weiterzugeben, konnen diese
Weiterverbreitung nicht verhindern. Sie konnen ihr Eigentumsrecht nur durch Wasserzeichen kenntlich machen.
Die Darstellung des Multimediamediators in diesem Abschnitt soll nur einen einfuhrenden
U berblick geben. Weitere Details des Konzepts { zum Beispiel zu Regeln fur den Zugri auf
die verwendeten Schemata { sind im Originaltext und in der Dissertation [Kar02] zu nden.
7
2 Aufgabenstellung
geschrieben von Barbara Sprick
Mediation ist ein Leitbild zur Bildung hochleistungsfahiger Informationssysteme, die fur einen
Benutzer zielgerichtet Daten aus verteilten, autonomen und heterogenen Quellen aunden und
zur verlangten Information zusammenfuhren und aufbereiten.
Im Rahmen eines Projektes des Landes Nordrhein Westfalen wurde in der Gruppe ISSI am
Lehrstuhl 6, des Fachbereichs Informatik der Universitat Dortmund ein Verfahren zur sicheren
Mediation entwickelt [ABFK03, ABK01]. Im einfachen, unsicheren Fall senden Kunden SQLAnfragen an den Mediator, der diese in kleine Teilanfragen zerlegt und an die entsprechenden
Quellen weiterleitet. Die Quellen berechnen die entsprechenden Teilantworten und schicken diese zuruck an den Mediator, der hieraus dann die vom Kunden gestellte SQL-Anfrage auswertet
und die Antwort dem Kunden zurucksendet.
In dem Verfahren fur sichere Mediaton sendet der Mediator nicht nur die entsprechenden Teilanfragen an die Quellen, sondern zusatzlich noch einen (von einer TTP zertizierten) oentlichen
Schlussel des Kunden. Nun verschlusseln die Quellen ihre Teilantworten mit dem oentlichen
Schlussel des Kunden und senden die verschlusselten Antworten an den Mediator zuruck.
Ohne die Antworten entschlusseln zu konnen, kann der Mediator nur sehr beschrankt mit diesen
verschlusselten Teilantworten rechnen und die vom Kunden gestellte SQL-Anfrage auswerten.
Um dieses Problem zu losen, wird ein eingeschrankter Teil von SQL identiziert, der leicht in
Ausdrucke der relationalen Algebra ubersetzt werden kann. Jeder solche Ausdruck entspricht
einem Syntaxbaum, dessen Blatter mit den verschlusselten Teilanfragen beschriftet sind und
dessen innere Knoten mit den (wenigen verschiedenen) Operatoren der Algebra beschriftet
sind.
Ziel dieser Diplomarbeit ist, ein Java-Tool zu erstellen, das fur eine gegebene SQL-Anfrage und
fur gegebene verschlusselte Teilantworten mobilen Code erzeugt. In der geschutzten Umgebung
des Kunden soll dieser Code unter Eingabe des geheimen Schlussels des Kunden die Teilantworten decodieren und die SQL-Anfrage anhand der decodierten Teilantworten auswerten.
Da mobiler Code auf den Rechnern der Kunden ausgefuhrt wird, birgt die Anwendung mobilen Codes selbst wieder Sicherheitsprobleme [MF99, GMPS97]. In dieser Diplomarbeit sollen
von Java vorgesehene Sicherheitsmechanismen zur Reduzierung dieser Risiken (bspw. digitale
Zertikate, das Ausfuhren des Codes in einer Sandbox, etc.) verwendet und analysiert werden.
Zusatzlich zu der Hauptaufgabe werden alternativ folgende Erweiterungen bearbeitet:
1. Wird in einer ersten Version die Verwendung eines Schlussels pro Anfrage angenommen,
so kann diese Annahme spater gelockert werden: Hat ein Benutzer mehrere Schlussel, so
konnen unterschiedliche Quellen ihre Antworten auch mit unterschiedlichen oentlichen
Schlusseln verschlusseln. In diesem Fall bedarf es auch unterschiedlicher Schlussel zum
Entschlusseln der Teilantworten, wobei der vom Mediator erstellte mobile Code die Zuordnung der entsprechenden Schlussel zu den jeweiligen Teilantworten sicherstellen muss.
Diese Verwaltung zu implementieren ist eine mogliche Erweiterung der Hauptaufgabe.
2. In der ersten Version wird angenommen, dass die Quellen dem Mediator ihre Daten
als verschlusselte Antworten auf SQL-Anfragen schicken. In dem Mediatorkonzept in
[ABFK03] kann jedoch auch ein Mediator als Quelle agieren. In diesem Fall wurde die
Quelle nicht direkt eine verschlusselte Antwort zurucksenden, sondern selbst wieder mobilen Code zur Berechnung der Antwort erstellen. Eine weitere mogliche Erweiterung der
Hauptaufgabe ist, den Einuss von mobilem Code eingebettet in anderen mobilen Code auf die Sicherheitsanforderungen, die Sicherheitsprobleme und die zuvor analysierten
Losungen zu untersuchen.
8
3 Berechnungen des Mediators auf den Teilantworten
Der Mediator nimmt dem anfragenden Kunden die Aufteilung der Gesamtanfrage in Teilanfragen und die Suche nach den richtigen Datenquellen ab. Als Anfragesprache benutzt der Kunde
(in diesem Falle der menschliche Benutzer oder auch ein anderes Programm auf dem Kundenrechner, das Datenbankanfragen erzeugt) eine Teilmenge der Structured Query Language
(SQL), die sich als relationale Algebra darstellen lasst. Der Mediator erstellt aus einer Anfrage einen Algebrabaum; in diesem Baum benden sich algebraische Operatoren in den inneren
Knoten und Teilanfragen in den Blattern. Als Denitionsgrundlage der Algebra habe ich die
algebraischen Basisoperatoren nach Kemper und Eickler ([KE96]) benutzt. Ein algebraischer
Operator ist demnach ein Element aus der Menge fVereinigung, Kreuzprodukt, Mengendierenz, Projektion, Selektion, Umbenennung von Attributen g. Eine Teilanfrage an einem Blatt ist
eine SQL-Anfrage, die von einer Datenquelle unabhangig von anderen Datenquellen beantwortet werden kann. Die Datenquellen verschlusseln ihre Teilantwort auf die Teilanfragen mit den
oentlichen Schlusseln des Kunden. Die Forderung nach Verschlusselung der Teilantworten ist
unabdingbar, da vertrauliche Daten nicht einmal dem Mediator bekanntgegeben werden sollen.
Idealerweise sollte der Mediator auf die verschlusselten Teilantworten die Operatoren im Algebrabaum anwenden und so eine verschlusselte Gesamtantwort berechnen. Er schickt die verschlusselte Gesamtantwort an den Kunden, der sie entschlusseln und die Daten lesen kann.
Diese Vorgehen bietet folgende Vorteile:
Der Kunde erhalt nur die minimale Datenmenge als Antwort und muss sie (auer der
Entschlusselung) nicht weiter bearbeiten.
Die Datenquellen geben ihre verschlusselten Teilantworten nur an den Mediator weiter.
Die Teilantworten gelangen nicht in die Hande des Kunden, der zwar die Berechtigung
hat, die Daten zu lesen, aber vielleicht gar nicht wei, wie er danach fragen soll.
Berechnungen auf verschlusselten Daten (engl. computing with encrypted data, CED) sind aber
nur eingeschrankt moglich. Das Problem der Berechnungen auf Schlusseldaten ist wohl schon
so alt wie die Kryptographie selbst. Welche theoretischen Ansatze es fur Berechnungen auf verschlusselten Daten gibt, mochte ich im folgenden Abschnitt vorstellen. Abschnitt 3.2 behandelt
danach ein Verfahren fur die teilweise Auswertung von SQL-Ausdrucken auf verschlusselten
Tabellen. Alternativ zu einer Berechnung auf vollstandig verschlusselten Daten kann dem Mediator die Moglichkeit gegeben werden, Relationen teilweise zu entschlusseln. Dazu stelle ich
die Datensatzverschlusselung mit Teilschlusseln in Abschnitt 3.4 vor.
3.1 Berechnungen auf verschlusselten Daten
Theoretische Modelle fur eine verteilte Berechnung auf verschlusselten Daten gehen in der
Regel von zwei Teilnehmern aus; sie werden haug als Alice und Bob bezeichnet. Alice hat
einen Eingabewert x und Bob eine Funktion f ; Alice mochte den Funktionswert f (x) zu ihrer
Eingabe erhalten. Dabei darf Bob den Funktionswert nicht herausbekommen und Alice nichts
Entscheidendes uber die Funktion f erfahren. Bob ist auf polynomielle Rechenzeit beschrankt,
wahrend Alice unbeschrankte Rechenzeit zur Verfugung hat. Ein Optimierungsziel ist, die Zahl
der Kommunikationsrunden zwischen Alice und Bob moglichst gering zu halten; optimal ist also
eine Kommunikationsrunde: Alice schickt ihre Klartexteingabe x (die sie vorher verschlusselt)
an Bob und Bob sendet f (x) (ebenfalls in verschlusselter Form) an Alice. Ein Protokoll mit
nur einer Kommunikationsrunde heit auch nichtinteraktiv\. Daneben gibt es zwei Modelle fur
mogliche Angrie. In dem einen Modell ist "der Angreifer "ehrlich aber neugierig\; er halt sich
an das vereinbarte Kommunikationsprotokoll aber versucht, seinen Opfern passiv zu schaden,
3.1 Berechnungen auf verschlusselten Daten
9
indem er vertrauliche Informationen abfangt (diese Informationen kann er dann aber an andere
weitergeben, die einen aktiven Angri durchfuhren). In dem anderen Modell ist der Angreifer
bosartig\ und versucht aktiv (etwa durch falsche oder zu lange Berechnungen) einen korrekten
"Abauf
des Protokolls zu verhindern.
Fur Berechnungen auf verschlusselten Zahlen aus einer Gruppe Z=N Z (fur N 2 N) haben Sander, Young und Yung (siehe [SYY99]) ein nichtinteraktives Protokoll entwickelt, mit dem mit
einer Funktion f aus der Komplexitatsklasse1 NC 1 zu einer verschlusselten Eingabe e(x) der
Funktionswert f (e(x)) berechnet werden kann; Bob muss die Eingabe nicht entschlusseln, um
die Funktion f auf e(x) auszuwerten2 . Alice kann mit der entsprechenden Entschlusselungsfunktion aus f (e(x)) ezient den Wert f (x) berechnen; sie kann jedoch aus dem Ergebnis keine
Ruckschlusse auf die Funktion f ziehen. Sie verwenden ein probabilistisches Verschlusselungsschema e, bei dem ein Eingabebit auf mehrere Schlusselreprasentationen abgebildet wird.
Fur die Halbgruppe Z=2Z geben Sander et al. ein UND-homomorphes Verschlusselungsschema
e0 an: sie entwerfen einen Operator , so dass fur zwei Klartexteingaben x1 ; x2 2 Z=2Z gilt:
e0 (x1 ) e0 (x2 ) = e0 (x1 UND x2 ).
Bisher wurden nur wenige solcher Verschlusselungsschemata entwickelt. Ein allgemeines algebraisches homomorphes Verschlusselungsschema fur Z=2Z, fur das man einen additiven Operator und einen mulitplikativen Operator benotigt, wurde unter der Annahme, dass man
aus dem Ergebnis einer Multiplikation oder Addition die Eingabewerte nicht ableiten kann, beliebige Berechnungen auf verschlusselten Daten ermoglichen (siehe [SYY99], Seite 556). Young
und Yung merken als generelles Problem solcher Verschlusselungsschemata jedoch an, dass die
Eingabewerte durch die Verschlusselung groer und die Operatoren komplexer werden (vgl.
[YY04], Seite 143).
Eng verwandt mit Berechnungen auf verschlusselten Daten ist die sichere Funktionsauswertung (engl. secure function evaluation). Die beiden Teilnehmer Alice und Bob stellen Eingaben
fur eine gemeinsame Funktion bereit. Beide sollen das Endergebnis erhalten, ohne dass sie die
Eingabe des anderen Teilnehmers in Erfahrung bringen (vgl dazu auch [YY04], Seite 145).
Cachin et al. (siehe [CCKM00]) betrachten sichere Funktionsauswertung und fordern zusatzlich, dass Bob den Funktionswert nicht erfahrt. Sie zeigen, dass mit "beschrankter Alice\ und
unbeschranktem Bob\ ein nichtinteraktives Protokoll zur sicheren Berechnung von Funktionen
"existiert,
die durch Schaltkreise polynomieller Groe berechnet werden konnen. Jedoch mussen
alle Eingaben zum gleichen Zeitpunkt erfolgen.
Goldreich (siehe [Gol04], Seite 693) betrachtet verteilte Berechnung mit mehreren Teilnehmern.
Er beschreibt ein sicheres Protokoll (in dem kein Teilnehmer die Eingabe der anderen Teilnehmer erfahrt) fur beliebige Funktionen, die sich durch Schaltkreise darstellen lassen. Er zeigt,
wieviele Teilnehmer maximal das Protokoll aktiv angreifen durfen, damit das Protokoll sicher
bleibt. Fur jeden Eingabebaustein des Schaltkreises ist allerdings eine "vergessliche U bertragung\ (engl. oblivious transfer; siehe [CCKM00], Seite 516) notig (vgl. dazu auch [AMP04],
Seite 41).
Nachdem lange Zeit nur Berechnungen auf verschlusselten naturlichen Zahlen moglich waren,
haben Stern, Foque und Wackers (siehe [FSW03] in [Bla03]) ein homomorphes Kryptosystem
fur beschrankte rationale Zahlen entworfen: in ihm sind Multiplikation und Addition auf einer verschlusselten Darstellung von rationalen Zahlen durchfuhrbar. Sie bauen dafur auf dem
Paillier-Kryptosystem fur Berechnungen auf verschlusselten naturlichen Zahlen auf (siehe dazu
[Pai99]).
Neben den Versuchen, allgemeine homomorphe Verschlusselungsschemata zu nden, wird die
Nick's class\ NC 1 umfasst alle Folgen boolscher Funktionen, die durch Schaltkreise logarithmischer Tiefe
"und
polynomieller Groe berechnet werden konnen; vgl. etwa [Weg96], Seite 18.
2 Ein Schaltkreis, der die Funktion f berechnet, besteht aus ODER- und NICHT-Gattern. UND-Gatter werden
nach den DeMorgan-Regeln ersetzt.
1
10
Auswertung einzelner Operatoren auf verschlusselten Daten untersucht. Freedman, Nissim und
Pinkas (siehe [FNP04]) betrachten den Fall, in dem Alice und Bob jeweils eine Menge mit
mehreren Elementen haben und die Elemente in der Schnittmenge berechnen wollen, ohne
dass dem jeweils anderen die restlichen Elemente bekannt gegeben werden. Sie berechnen die
Schnittmenge mit Hilfe eines Polynoms P , dessen Nullstellen die ka Elemente x1 ; : : : ; xka von
Alice sind:
P (y) = (x1 y) (xka
y) =
X y
ka
u=0
u
u
Die Koezienten u des Polynoms werden homomorph mit einer Erweiterung des PaillierKryptosystems e00 verschlusselt. Alice erstellt dieses Polynom, berechnet die Koezienten durch
Interpolation, verschlusselt sie und sendet sie an Bob. Bob wertet das verschlusselte Polynom
auf jedem seiner Elemente y1 ; : : : ykb aus und multipliziert das Ergebnis mit einer jeweils neuen
Zufallszahl rj ; schlielich verschlusselt er das Element und addiert es hinzu:
yj0 = e00 (rj P (yj ) + yj ) fur j = 1; : : : kb :
Freedman et al. verringern den Berechnungsaufwand fur das Polynom durch verschiedene Verfahren. Bob permutiert die Ergebnisse und schickt sie an Alice. Alice entschlusselt sie und
erhalt als Schnittmenge fxi jxi = e00 1 (yj0 ); i = 1; : : : ka ; j = 1; : : : kb g (e00 1 sei die passende
Entschlusselungsfunktion). Fur alle anderen Elemente von Bob erhalt sie Zufallszahlen. Freedman et al. zeigen, dass ihr Verfahren sicher gegen bosartige Alice und bosartigen Bob ist. In
dem Fall benotigen sie jedoch mindestens funf Kommunikationsrunden. Schlielich erweitern
sie ihr Protokoll auf mehrere Teilnehmer.
A hnliches zeigen Aggarwal, Mishra und Pinkas (siehe [AMP04]) fur die Berechnung des kkleinsten Elements der Vereinigung von zwei Mengen. Sie benotigen O(k) Kommunikationsrunden.
In einem folgenden Artikel beschreiben Malkhi et. al (siehe [MNPS04]) die praktische Umsetzung einer sicheren Funktionsauswertung mit zwei Teilnehmern. Sie entwarfen eine Programmiersprache und ein U bersetzungsprogramm, das ein Programm dieser Sprache in einen
Schaltkreis umwandelt. Die Ausdrucksfahigkeit der Sprache ist begrenzt. Es durfen zum Beispiel keine Rekursionen benutzt werden, damit aus dem Schaltkreis keine Informationen uber
den Kontrolluss abgeleitet werden konnen. Bei der Auswertung des Schaltkreises muss einer der Teilnehmer fur jeden Eingabebaustein seine verschlusselte Eingabe an den anderen
Teilnehmer senden.
Man kann das Multimediamediator-System als Sonderform der sicheren Funktionsauswertung
betrachten. Allerdings sollen die Teilnehmer, die die Eingaben liefern { also die Datenquellen,
das Funktionsergebnis nicht erfahren, sondern der Kunde. Fur den Multimediamediator ware eine nichtinteraktive Berechnung auf den verschlusselten Teilantworten optimal. Das heit,
dass die Datenquellen dem Mediator die verschlusselten Tabellen ubergeben und der Mediator
auf den verschlusselten Tabellen die verschlusselte Gesamtantwort berechnet, ohne nochmals
mit den Datenquellen oder jemand anderem kommunizieren zu mussen. Der Mediator leitet die
verschlusselte Gesamtantwort dann an den Kunden weiter. An der Berechnung nehmen nicht
nur zwei Teilnehmer teil, sondern viele Datenquellen und Mediatoren konnen zum Ergebnis
beitragen. Da die bisher bekannten Verschlusselungsschemata nur mit einem eingeschrankten
Operatorensatz arbeiten, ist eine allgemeine Ausfuhrung von Programmen auf verschlusselten Daten nicht moglich. Ein zusatzliches ungelostes Problem ist, dass die Datenquellen die
Teilantworten eventuell sogar mit verschiedenen Schlusseln und mehrfach verschlusseln sollen.
Mir sind keine Ansatze bekannt, die auf derart verschlusselten Daten rechnen konnten.
11
3.2 Auswertung von SQL-Ausdrucken auf verschlusselten Tabellen
3.2 Auswertung von SQL-Ausdrucken auf verschlusselten Tabellen
Es gibt Bemuhungen, die Auswertung von SQL-Ausdrucken auf verschlusselten Tabellendaten
zu ermoglichen. Hacgumus, Iyer, Li und Mehrota (siehe [HILM02]) benutzen Partitionierungen
von Wertebereichen, auf denen die Berechungen durchgefuhrt werden. Leider lasst sich dieser
Ansatz nicht auf den Multimediamediator ubertragen, da sein Anwendungsbereich anders gelagert ist. Hacgumus et al. schlagen den Einsatz von relationalen Operatoren auf verschlusselten
Tabellen vor, um Datenbanksysteme zu entlasten: ein Datenbanksystem bekommt eine Anfrage
eines Kunden und mochte einen Teil der Auswertungsarbeit von einem anderen Rechner ausfuhren lassen, der seine Rechenzeit anbietet. Dieser Rechenanbieter soll die Daten aber nicht
transformierte Tabelle
und Anfrage
Anfrage
Datenbank
Kunde
Ergebnis
Berechnung auf entschlüsselten Daten
Rechen
anbieter
Obermenge des
Ergebnisses
Berechnung auf verschlüsselten Daten
Abbildung 3: Rechenanbieter fur Datenbanksysteme
lesen konnen. Er bekommt von dem Datenbanksystem daher eine verschlusselte Tabelle und
berechnet mit seinen relationalen Operatoren eine Teilmenge der Zeilen3 . Diese Zeilen werden
an das Datenbanksystem zuruckgeschickt. Es entschlusselt die Zeilen und berechnet auf den
entschlusselten Zeilen das wirkliche Ergebnis. Fur das Datenbanksystem sinkt damit der Rechenaufwand.
Allerdings muss das Datenbanksystem die Tabelle nicht nur verschlusseln sondern dem Rechenanbieter zusatzliche Angaben machen, damit er seine Teilauswertung durchfuhren kann.
Das Datenbanksystem partitioniert den Wertebereich jedes Attributs in disjunkte Teilbereiche und nummeriert diese Teilbereiche durch. Die Tabelle wird zeilenweise verschlusselt und
danach durch weitere Attribute erganzt. Fur jedes Attribut A erhalt die Tabelle eine neues
Attribut AS . Fur den Wert jedes Attributs in einer Zeile wird die unverschlusselte Nummer
des Teilbereichs angegeben, in dem sich der Wert bendet: Fur ein Attribut A und den Wert
vi dieses Attributes in der Zeile i wird in der neuen Spalte AS der Wert num(vi ) eingetragen
(es sei num die Funktion, die einem Wert die Nummer des Teilbereiches zuweist, in dem der
Wert sich bendet).
Da der Rechenanbieter die Partitionierungsfunktion (und die Nummerierung), die das Datenbanksystem benutzt, nicht kennt, erhalt er dadurch zunachst keine vertraulichen Informationen.
Ein Beispiel fur diese Partitionierung bendet sich im Originaltext [HILM02]. Wenn die Teilbereiche zusammenhangend sind, kann die Nummerierung der Teilbereiche ordnungserhaltend
sein (so denn der Wertbereich des Attributs eine Ordnung aufweist). Das bedeutet, dass fur
ein Attribut A und dessen Wertebereich (A) gilt: wenn vi ; vj 2 (A) und vi < vj , dann
gilt num(vi ) num(vj ). Damit wird aber auch dem Rechenanbieter die Ordnung unter den
Teilbereichen bekannt gemacht.
Nach der Verschlusselung und Erganzung der Tabelle wird die Anfrage so umgeformt, dass sie
vom Rechenanbieter ausgefuhrt werden kann. Dazu mussen zunachst einmal die Bedingungen,
die in der Anfrage vorkommen, geandert werden. Fur den ordnungserhaltenden Fall sieht das
so aus:

Rechenanbieter kann verschlusselte Tabellen auch dauerhaft speichern, um das Ubertragen
einer Tabelle
in jeder Anfrage einzusparen.
3 Der
12
Bei Test auf Gleichheit von Attributen mit einer Konstanten wird statt der Konstante
die Nummer des Teilbereichs eingesetzt, in der sich die Konstante bendet. Also aus der
Bedingung "A = 4\ wird die neue Bedingung "AS = num(4)\.
Bei einem Kleinervergleich wird muss zusatzlich die Gleichheit mit aufgenommen werden,
da Attributwert und Vergleichskonstante im selben Teilbereich liegen konnen: aus der
Bedingung "A < 4\ wird die neue Bedingung "AS num(4)\.
Groervergleiche werden analog zu Kleinervergleichen umgesetzt.
Die Nummerierung der Teilbereiche muss nicht ordnungerhaltend sein. So erfahrt der Rechenanbieter nicht einmal die Reihenfolge der Werte in der Tabelle. Allerdings gestaltet sich die
Umformung der Anfrage schwieriger. Bei Groer- und Kleinervergleichen wird dann die Vergleichskonstante durch eine Menge von Teilbereichsnummern ersetzt. Weitere Umformungen
von Bedingungen (insbesondere der Vergleich zweier Attributwerte und die boolsche Verknupfung von Bedingungen) mochte ich hier nicht auuhren; sie sind im Originaltext zu nden.
Hacgumus et al. beschreiben abschlieend die Funktionsweise ihrer relationalen Operatoren
fur den Rechenanbieter. Jeder Operator rechnet auf den Teilbereichsnummern. Das Ergebnis
der anbieterseitigen Auswertung ist daher eine Obermenge des wirklichen Ergebnisses. Das Datenbanksystem entschlusselt das Ergebnis des Anbieters und fuhrt dann eine Nachbearbeitung
durch, um das wirkliche Ergebnis zu erhalten, das sie an den Kunden zurucksendet.
Diese Verfahren zur Berechnung von SQL-Ausdrucken auf verschlusselten Tabellen verschleiert
die Werte innerhalb der Tabelle. Die Struktur der Tabelle (also die Anzahl der Zeilen und Spalten) wird dem Rechenanbieter dennoch bekannt gemacht. Eine endgultige Auswertung ndet
wieder auf den unverschlusselten Daten statt.
Der Ansatz von Hacgumus et al. lasst sich nicht auf den Multimediamediator ubertragen. Alle
Datenbanksysteme mussten eine gemeinsame Partitionierungs- und Nummerierungsfunktion
benutzen, damit der Mediator zumindest teilweise die Ausfuhrung durchfuhren konnte. Das
Endergebnis kann er jedoch nicht selbst berechnen, sondern nur eine Obermenge dessselben.
Aus dieser Obermenge musste dann das wirkliche Endergebnis ermittelt werden; dazu kommt
als Einziger der Kunde in Frage, da nur er berechtigt ist, das Endergebnis zu erhalten. Es mussten ihm die von allen Datenbanken verwendete Partitionierungs- und Nummerierungsfunktion
bekannt gegeben werden, die sich nach im Ansatz von Hacgumus et al. jedoch nicht andern
soll, um standige Neuberechnungen zu vermeiden. Eine verschlusselte Tabelle ist deshalb weder vor den anderen Datenbanksystemen noch vor Kunden geschutzt, die bereits eine Antwort
erhalten haben. Wenn sich die Funktionen mit jeder Anfrage andern, mussten alle beteiligten Datenbanksysteme bei einer Anfrage auf die neuen Funktionen einigen, ihre Tabellen neu
verschlusseln und sie dem Rechenanbieter zukommen lassen.
3.3 Eingeschranktes Verfahren fur Berechnungen des Multimediamediators
Damit ein Mediator nichtinteraktiv eine Gesamtantwort mit relationalen Operatoren aus verschlusselten Teilantworten berechnen kann, sind starke Einschrankungen des Verschlusselungsverfahrens und der Funktionalitat notig: Relationale Operatoren betrachten einzelne Attributwerte und mussen auf Tabellen arbeiten, deren Struktur (die Spalten- und Zeilenanzahl) sie
kennen; alle Teilantworten mussen mit demselben Schlussel verschlusselt werden, um Vergleich
auf Schlusseldaten und das Zusammensetzen von Tabellen zu ermoglichen, und als Vergleichsoperator fur Selektionspradikate sind nur = und 6= zugelassen. Um die Tabellenstruktur zu
erhalten, muss die Datenquelle jede Zelle der Tabelle (auch die Attributnamen) einzeln mit
dem oentlichen Schlussel des Kunden verschlusseln und die Tabelle mit den verschlusselten
Eintragen zuruckliefern. Die Operatoren Vereinigung und Kreuzprodukt konnen auf den verschlusselten Tabellen wie auf unverschlusselten arbeiten, da sie die Tabellen nur aneinander
hangen; ebenso die Mengendierenz, da sie nur die Gleichheit von Eintragen uberpruft. Den
13
Operatoren Selektion und Projektion, die die Angabe eines Selektionspradikates beziehungsweise einer Menge von Projektionsattributen benotigen, mussen diese Eingaben verschlusselt
ubergeben werden. Fur ein Selektionspradikat "Name = 'Muller'\ mussten "Name\ und "Muller\ zu den Schlusseltexten crypt("Name\) und crypt("Muller\) verschlusselt werden und in der
verschlusselten Tabelle die Spalte crypt("Name\) nach Eintragen mit dem Wert crypt("Muller\)
durchsucht werden. Der Operator zur Umbenennung
von Attributen benotigt als Eingabe den
verschlusselten Namen des Attributs und den verschlusselten neuen Wert. Auf Schlusseltexten
sind im Allgemeinen bisher nur Gleichheits- beziehungsweise Ungleichheitsvergleiche moglich;
Vergleiche auf Gleichheit von Zelleninhalten konnen auf Schlusseltexten ohne weitere Angabe durchgefuhrt werden unter der Voraussetzung, dass alle Werte mit demselben Schlussel
verschlusselt wurden. Groer- und Kleinervergleiche konnen nicht ausgewertet werden, da die
Verschlusselung die Ordnung auf den Daten zerstort. Tritt in einem Selektionspradikat aber
zum Beispiel ein auf, kann von der Datenquelle eine partielle Ordnung auf den verschlusselten Daten des betreenden Attributs mitgeliefert werden. Diese bleibt dann solange gultig, wie
der Spalte keine neuen Eintrage hinzugefugt werden (zum Beispiel durch eine Vereinigung).
Dieses Verfahren der Berechnung auf verschlusselten Tabellenzellen umfat nicht den vollen
Funktionsumfang, den der Multimediamediator bieten soll. Damit die Schlusseltexte uberhaupt
vergleichbar sind, muss das Verschlusselungsverfahren folgende Eigenschaften haben:
alle Teilantworten mussen mit demselben Schlussel verschlusselt werden
gleiche Klartexte mussen in gleiche Schlusseltexte umgewandelt werden
das Verschlusselungsverfahren muss kollisionsfrei sein; ein Schlusseltext darf nicht zu
mehreren Klartexten gehoren
Die Vertraulichkeit der Daten ist mit diesem Verfahren aus mehreren Grunden nicht gewahrleistet. Da dem Mediator nicht nur das Schema, sondern auch die Zeilenanzahl der Tabelle bekannt
gemacht wird, kennt er die Anzahl der Zeilen und Spalten und die Anordnung der Schlusseldaten in der Tabelle. Er kann Schlusseldaten dadurch thematisch gruppieren. Er bekommt eine
groe Anzahl kurzer Schlusseltexte zu sehen, die alle mit demselben Schlussel verschlusselt
wurden, und hat daher die Moglichkeit eventuell einzelne Klartexte aus dem Kontext zu raten.
Ohne die Klartexte zu kennen kann er auf den Schlusseltexten die prozentualen Anteile gleicher
Eintrage ermitteln. Beispielsweise lasst sich fur eine Spalte "Geschlecht\ mit Werten 2 fmannlich, weiblichg schon eine entscheidende Information (namlich das Frauen-Manner-Verhaltnis)
mit ein wenig Vorwissen aus den Schlusseltexten ermitteln. Wenn dem Mediator beispielweise
bekannt ist, dass er eine Tabelle mit Daten von Informatikstudierenden bearbeitet, wird eine
Spalte mit nur zwei Werten die Spalte sein, die das Geschlecht angibt; die kleinere Anzahl wird
davon in der Regel der Frauenanteil, die groere Anzahl der Manneranteil sein. Der Mediator
kann auerdem selbst einen Teil der Tabelle von der Datenquelle abfragen, fur den er eine
Berechtigung besitzt. Er kann mit der Antwort einen Klartextangri auf die mit dem Kundenschlussel verschlusselte Tabelle durchfuhren. Eventuell reicht es sogar, die verschlusselten
mit den entschlusselten Daten in Beziehung zu setzen. Denning ([Den82], S. 148) beschreibt
als Beispiel eine Gehaltstabelle, in der anhand der verschlusselten Gehalter und der nichtverschlusselten Namen herausgefunden werden kann, welche Personen dasselbe verdienen.
Wie oben schon erwahnt, ist der Multimediamediator bei der Berechnung auf verschlusselten
Tabellen auf Gleichheitsvergleiche eingeschrankt. Groer- und Kleinervergleiche sind nur auf
Relationen der Teilantworten moglich aber nicht mehr in zusammengefugten Relationen; die
Angabe und Prufung der partiellen Ordnung auf den Teilantworten ist ein groer zusatzlicher
Aufwand. Durch die partielle Ordnung erhalt der Mediator zudem wieder Zugri auf vertrauliche Informationen: in der Gehaltstabelle kann er beispielsweise herausnden, welche Person
das meiste verdient. Der Mediator kann nicht nur geheime Daten ausspionieren. Da jede Tabellenzelle einzeln verschlusselt ist, kann er die Inhalte Tabellenzellen austauschen, indem er
zum Beispiel Werte aus anderen Zellen kopiert. So kann er die Gesamtantwort falschen, ohne
14
Daten entschlusseln zu mussen.
Einen Vorteil bietet das Verfahren mit verschlusselten Tabellenzellen jedoch: die Anfrage kann
vom Kunden schon teilweise verschlusselt werden. Als Selektionspradikat kann er beispielweise
sofort "crypt("Name\) = 'crypt("Muller\)'\ angeben. Der Mediator kennt dann die Attributnamen und die Vergleichskonstanten nicht. Wenn in Teilanfragen Selektionen oder Projektionen
vorkommen, muss die Datenquelle sie auf der mit demselben Schlussel wie die Anfrage verschlusselten Tabelle durchfuhren.
3.4 Datensatzverschlusselung mit Teilschlusseln
Wenn der Mediator nicht auf vollstandig verschlusselten Daten rechnen kann, kann man ihm
einen Teil der Daten entschlusselt zur Verfugung stellen. Er kann dann mit diesen Daten rechnen, wahrend der Rest der Daten ihm weiterhin unbekannt ist. Im Folgenden mochte ich theoretisch prufen, ob eine solche Methode fur den Multimediamediator verwendbar ist. Das Verfahren, das ich als Grundlage nutze, ist die "Datensatzverschlusselung mit Teilschlusseln\ von
Davida, Wells und Kam (siehe [DWK81]).
Davida et al. gehen von einer Menge von t Datensatzen aus, die jeweils die gleiche Anzahl n
von Feldern mit den Inhalten fij (fur i = 1 : : : t; j = 1 : : : n) besitzen. Man benotigt insgesamt n Schlussel zum Verschlusseln (die "Schreibschlussel\) und n korrespondierende Schlussel
zum Entschlusseln (die "Leseschlussel\). Es wird immer ein Datensatz als Ganzes verschlusselt.
Jedes Feld innerhalb eines
Datensatzes wird mit einem Schreibschlussel verschlusselt und die
n Verschlusselungsergebnisse werden aufsummiert. Aus dem verschlusselten Datensatz kann
ein Feld nur mit dem korrespondierenden Leseschlussel entschlusselt werden. Die Leseschlussel
werden auch "Teilschlussel\ genannt, da sie einzeln nie den gesamten Datensatz sondern nur
einen Teil (namlich das jeweilige Feld) entschlusseln.
Umgesetzt auf den Multimediamediator ergibt sich folgendes Bild: Eine Tabelle mit t Zeilen
und n Spalten ist eine Menge von t Datensatzen, namlich den t Zeilen der Tabelle. Die n Felder eines Datensatzes sind die n Zellen der Zeile. Fur jede Spalte der Tabelle gibt es einen
Leseschlussel zum Entschlusseln (fur die j -te Spalte sei dies dj ) und einen Schreibschlussel zum
Verschlusseln (dies sei ej ).
Die Leseschlussel sind beliebige verschiedene Primzahlen; allerdings muss dj groer sein als die
Daten, die spater mit ej verschlusselt werden. Zur Berechnung der Schreibschlussel wird das
Produkt aller Leseschlussel benotigt: D := nj dj . Die Schreibschlussel ej berechnen sich dann
aus den dj und D wie folgt: Zunachst berechnet man eine multiplikative Inverse bj zu dDj in Zdj ,
so dass also gilt dDj bj = 1 mod dj . Mit als der Eulerschen Totientenfunktion ist eine mogliche
Inverse bj = ( dDj ) dj mod dj . Da dj prim ist und fur eine Primzahl p gilt (p) = p 1,
kann man noch vereinfachen: bj = ( dDj )dj mod dj . Fur Davida et al. ist das die kanonische
Darstellung der Inversen. Der Schreibschlussel ej ergeben sich dann als: ej = ( dDj )bj .
Jede Tabellenzelle fij wird mit einer Zufallszahl xj konkateniert, bevor sie verschlusselt wird
(jj sei der Konkatenationsoperator). Die Zufallszahl xj soll eine Kryptoanalyse zu erschweren,
die die Berechnung eines groten gemeinsamen Teilers auf zwei Datensatzen versucht.
Eine Tabelle wird von einer Datenquelle zeilenweise verschlusselt, wobei sich der Schlusseltext
Ci der Zeile i nach der folgenden Formel ergibt:
=1
(
)
1
2
Ci =
X e (x jjf ) mod D
n
j =1
j
j
ij
fur i = 1 : : : t
Nach dem chinesischen Restklassensatz (vgl. etwa [Weg96], Seite 105) gilt, dass Ci eine Losung des Gleichungssystems der Form Ci = (xj jjfij ) mod dj fur j = 1 : : : n ist. Diese Losung
ist eindeutig in ZD . Demnach kann (xj jjfij ) mit dem Schlussel dj ausgelesen werden, indem
15
Ci mod dj berechnet wird. Davida, Wells und Kam stellen auerdem eine Art randomisier-
tes Signaturverfahren vor, um die Authentizitat von Datensatzen nachprufen zu konnen. Ein
groes logistisches Problem bei diesem Ansatz ist meiner Meinung nach die groe Menge an
Schlusseln, die benotigt wird. Jede Teilantwort hat so viele Teilschlussel, wie sie Spalten besitzt.
3.4.1 Umsetzung auf den Multimediamediator
Der Mediator kann aus den verschlusselten Teilantworten die verschlusselte Gesamtantwort berechnen, ohne die Gesamtantwort vollstandig lesen zu konnen, wenn er nur die Tabellenzellen
entschlusseln darf, die er fur die Ausfuhrung der Operatoren im Algebrabaum benotigt. Dazu
muss er bei den Datenqellen die Leseschlussel (die jeweils fur eine Spalte gelten) beantragen. Die
Datenbank kann dann entscheiden, ob es sicher ist, dem Mediator den Schlussel zu geben, oder
ob der dadurch schon zu viele Kenntnisse uber die Gesamtantwort erhalt. Die Beantragung und
U bertragung der Schlussel sind als Extra-Kommunikationsrunden zu sehen, so dass hier nur
ein interaktives Protokoll moglich ist. Es muss sichergestellt werden, dass der Mediator nicht
alle dj eines Datensatzes erhalt. Er kann sonst D und alle ej ausrechnen. Abgesehen davon,
dass der Mediator den vollstandigen Datensatz zu sehen bekommt, konnte er damit die Tabellendaten verandern und erneut verschlusseln, ohne dass es dem Kunden auallt. Dagegen gibt
es ein Mittel: Eine Datenquelle kann Fullspalten, die keine relevanten Daten enthalten, in ihre
Teilantworten einfugen. Die Leseschlussel fur diese Fullspalten halt sie in jedem Fall geheim.
Dem Kunden mussen zur Entschlusselung die Leseschlussel fur Nicht-Fullspalten zuganglich
gemacht werden. Sie werden mit den oentlichen Schlusseln aus den Eigenschaftsnachweisen
verschlusselt und in einem "Schlusselbund\ zusammengefasst. Nur berechtigte Kunden konnen
also die Leseschlussel entschlusseln und damit die Gesamtantwort erhalten.
In folgenden Abschnitt diskutiere ich, wie die algebraischen Operatoren "Umbenennung von
Attributen\, "Selektion\, "Projektion\, "Vereinigung\, "Mengendierenz\ und "Kreuzprodukt\
fur die Datensatzverschlusselung umgesetzt werden konnen und welche Auswirkungen das auf
die Geheimhaltung der Tabellen hat.
3.4.2 Umsetzung der algebraischen Operatoren
Ich gehe vereinfachend davon aus, dass die Metadaten der Tabelle (also die Attributnamen)
unverschlusselt sind. Da das Konzept des Multimediamediators ein Anwendungsschema fur
den Mediator vorsieht, das die Metadaten der Datenquellen vereint, bringen unverschlusselte
Metadaten keine neuen Erkenntnisse fur ihn. Zunachst betrachte ich die unaren Operatoren
"Umbenennung von Attributen\, "Selektion\ und "Projektion\:
Die Umbenennung ist auf den unverschlusselten Metadaten problemlos moglich. Es wird
der alte Attributname durch den neuen ersetzt.
Bei einer Selektion mussen die Selektionsspalten entschlusselt werden. Fur die Selektionsspalten k1 ; k2 : : : kl beantragt der Mediator bei der Datenquelle die Schlussel dk1 ; dk2 : : : dkl .
Damit entschlusselt er diese Spalten. Danach wertet der Mediator das Selektionspradikat
aus. Erfolgt die Selektion fur ein Attribut durch den Vergleich mit einer Konstante, wird
fur jede Zeile der Wert des Attributs mit der Konstante verglichen. Erfolgt die Selektion
fur ein Attribut durch den Vergleich mit einem Vergleichsattribut, muss zusatzlich diese
Vergleichsspalte entschlusselt werden. In das Endergebnis werden alle Ci ubernommen,
fur die das Selektionspradikat erfullt ist.
Fur eine rechnerische Ausfuhrung einer Projektion musste der Mediator alle Spalten
einer Tabelle entschlusseln konnen, denn durch eine Herausnahme von Spalten k1 ; k2 : : : kl
verfallen die Schlussel dk1 ; dk2 : : : dkl ; sie ieen nicht mehr in die Berechnung von D ein.
Mit einer A nderung des Wertes D andern sich aber samtliche Schreibschlussel und damit
die Verschlusselungsergebnisse fur die Zeilen.
16
Eine Neuverschlusselung der Tabelle fur die Projektion ist jedoch gar nicht notwendig:
Man kann die Projektionsspalten k1 ; k2 : : : kl auch einfach in Fullspalten umdenieren
und die Schlussel dk1 ; dk2 : : : dkl (beziehungsweise ihre verschlusselte Darstellung) aus
dem Schlusselbund entfernen. An der verschlusselten Tabelle andert sich dadurch nichts.
Die binaren Operatoren "Vereinigung\, "Mengendierenz\ und "Kreuzprodukt\ bergen groere
Probleme bei der Umsetzung. Es werden zwei Tabellen zusammengesetzt, die in der Regel
mit verschiedenen Schreibschlusseln verschlusselt wurden. Dabei gehe ich davon aus, dass die
jeweiligen Tabellen operationsvertraglich sind. Zunachst einmal will der Mediator Tabellen
verschlusseln, die er direkt als Teilantworten von den Datenquellen erhalten hat und die noch
nicht weiter bearbeitet wurden.
Eine Vereinigung von zwei Tabellen kann ausgefuhrt werden, ohne die Tabelleninhalte zu kennen. Die Aufgabe besteht darin, dafur zu sorgen, dass alle Datensatze mit
denselben Schreibschlusseln verschlusselt wurden. Dafur kann er die Leseschlussel (fur
Nicht-Fullspalten) der einen Tabelle und die Schreibschlussel und den Wert D der anderen beantragen. Er entschlusselt die eine Tabelle und verschlusselt sie erneut mit den
Schreibschlusseln der anderen.
Der Mediator kann bei der Neuverschlusselung einer Tabelle alternativ auch die Datenquellen um Mithilfe bitten: Bei einer Vereinigung von zwei Tabellen, deren Spalten mit
unterschiedlichen ej verschlusselt wurden, kann der Mediator eine Datenquelle nach ihren
Schreibschlusseln fur Nicht-Fullspalten und dem Wert D fragen. Dann bittet er die zweite
Datenquelle, ihre Tabelle mit diesen Schreibschlusseln und diesem D zu verschlusseln.
In beiden Fallen konnte die ersten Datenquelle die neu verschlusselten Daten der zweiten
Datenquelle entschlusseln, da sie im Besitz der Leseschlussel ist.
Wenn die zweite Tabelle von der ersten subtrahiert werden soll und die Schnittmenge
zwischen beiden Tabellen nicht leer ist, muss der Mediator auf jeden Fall alle Leseschlussel
der Nicht-Fullspalten der beiden Tabellen haben. Sonst kann er die Zeilen, die gleich
sind, nicht herausnden. Die Datenquellen konnten ihm die Schlussel aber schrittweise
zur Verfugung stellen. Wenn der Mediator anhand weniger entschlusselter Spalten bereits
sieht, dass es keine gleichen Zeilen in den Tabellen gibt, braucht er die weiteren Schlussel
nicht zu beantragen.
Um das Kreuzprodukt auszurechnen, braucht der Mediator die Kenntnis aller Tabelleninhalte, da er jeweils einen Datensatz aus der ersten Tabelle mit einem Datensatz aus
der zweiten Tabelle addieren muss. Dazu muss er alle Spalten entschlusseln und neu
verschlusseln. Es muss sichergestellt sein, dass alle Leseschlussel verschieden sind, da andernfalls der chinesische Restklassensatz nicht mehr gilt.
Allerdings kann der Mediator auch wieder auf die Mithilfe der Datenquellen zuruckgreifen. Die erste Datenquelle muss Leseschlussel d1j1 und die zweite Datenquelle d2j2 benutzen,
die paarweise verschieden sind (mit j1 = 1 : : : n + k1 und j2 = 1 : : : n + k2 fur die n NichtFullspalten und die k1 Fullspalten der ersten und die k2 Fullspalten der zweiten Datenquelle); es muss also gelten dlj1 6= dlj2 fur l 2 f1; 2g, j1 = 1 : : : n + k1 und j2 = 1 : : : n + k2 .
Wenn die beiden Datenquellen sich auf entsprechende Schlussel geeinigt und D berechnet
haben (mit einem Verfahren wie zum Beispiel "vergessliche U bertragung\ (engl. oblivious
transfer; siehe [CCKM00], Seite 516), konnen sie ihre Schreibschlussel berechnen und ihre
Daten verschlusseln. (Oder der Mediator berechnet aus den Teilprodukten jn1+=1k1 d1j1 und
nj2+=1k2 d2j2 den Wert D.) Danach kann der Mediator die beiden Teildatensatze modulo D
addieren. Wenn die Datenquellen sich auf die Leseschlussel einigen konnten, ohne deren
Werte wirklich auszutauschen, dann kann auch keine aus den verschlusselten Tabellen die
Daten der anderen Datenquelle herauslesen.
17
Die Weiterverarbeitung solcher Tabellen innerhalb des Algebrabaums ist schwierig; der Mediator muss die U bersicht uber die verwendeten Schlussel behalten und wissen, bei wem er die
entsprechenden Schlussel beantragen muss.
Es konnte ein zusatzlicher Teilnehmer am Multimediamediator-System eingefuhrt werden. Eine Instanz, die die Entschlusselung und Neuverschlusselung von Datensatzen vornimmt, wenn
es zu Konikten in den binaren Operatoren kommt. Dieser Teilnehmer sieht dann zwar die
entschlusselten Datensatze, wei aber nicht, durch welche Operatoren sie zusammengesetzt
werden.
18
19
II.
Diskussion
Inhalt
4 Kommunikationsschemata fur den Multimediamediator . . . . . . . . . . .
4.1 Anforderungen und Nachteile . . . . . . . . . . . . .
4.2 Aufteilung von Entschlusselung und Berechnung . .
4.3 Kommunikation zwischen Mediator und Kunde . . .
5 Vor- und Nachteile von mobilem Code . . . . . . .
5.1 Verringerung der ubertragenen Datenmenge . . . . .
5.2 Unabhangigkeit von der Netzverbindung . . . . . . .
5.3 Vermeidung eines verteilten Berechnungszustands . .
5.4 Lokalitat von Ressourcen . . . . . . . . . . . . . . .
5.5 Einfachheit des Empfangersystems . . . . . . . . . .
5.6 Erweiterbarkeit des Empfangersystems . . . . . . . .
6 Sicherheitsrisiken durch mobilen Code . . . . . . .
6.1 Angrie des mobilen Codes gegen den Kunden . . .
6.2 Schutz des Kunden vor Angrien des mobilen Codes
6.3 Angrie des Mediators gegen den Kunden . . . . . .
6.4 Schutz des Kunden vor Angrien des Mediators . . .
6.5 Schutz der Teilantworten auf dem Mediator . . . . .
6.6 Schutz des mobilen Codes bei der U bertragung . . .
6.7 Schutz des mobilen Codes auf dem Kundenrechner .
6.8 Verhinderbarkeit von Angrien mit Java . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
21
23
28
28
29
30
30
31
31
34
35
38
43
45
46
47
48
53
Vertrauen ist die emotionale Sicherheit, einem anderen Menschen
"und
dem eigenen Dasein oen gegenubertreten und sich hingeben
zu konnen. Vertrauen ist die Grundlage jeglicher nahen zwischenmenschlichen Beziehung, aber auch der Begegnung mit Freunden
sowie fur jedes Gesprach.\
Brockhaus
20
4 Kommunikationsschemata fur den Multimediamediator
Die Einschrankungen der Berechnung auf verschlusselten Tabellenzellen und der Berechnung
mit Teilschlusseln sollen fur den Multimediamediator nicht hingenommen werden: man mochte
es den Datenquellen ermoglichen, unterschiedliche Schlussel zur Verschlusselung der Teilantworten zu verwenden, und dem Mediator die genaue Struktur (zumindest die Zeilenanzahl)
einer Teilantwort verheimlichen. Auerdem soll der Mediator moglichst wenig mit den anderen Teilnehmern kommunizieren. Um Vergleiche zwischen Tabellen durchfuhren zu konnen,
die mit unterschiedlichen Schlusseln verschlusselt wurden, mussen entschlusselte Daten ausgewertet werden. Der Mediator soll die Daten aber nicht zu Gesicht bekommen. Daher muss
die Entschlusselung auf dem Kundenrechner stattnden. Um die Vertraulichkeit der Teilantworten zu wahren, durfen die entschlusselten Daten den Kundenrechner nicht mehr verlassen.
Das bedeutet jedoch, dass der Kundenrechner zusatzlich die Funktionalitat bereitstellen muss,
die Gesamtantwort zu berechnen. Welche Moglichkeiten es gibt, um das alles zu gewahrleisten,
mochte ich im Abschnitt 4.2 erlautern und in dem dann folgenden Abschnitt 4.3 mogliche Schemata fur die Kommunikation zwischen Mediator und Kunde diskutieren. Zunachst mochte ich
aber noch kurz auf allgemeine Anforderungen an den Multimediamediator und auf generelle
Nachteile im Konzept der Mediation eingehen.
4.1 Anforderungen und Nachteile
Es gibt einige grundsatzliche Anforderungen an das Multimediamediator-System, die es mit
anderen verteilten Anwendungen gemein hat. Ich mochte folgende Mechanismen in dieser Diplomarbeit als gegeben voraussetzen:
Zertikatsausstellung: Bevor ein Kunde auf geschutzte Daten zugreifen kann, muss er
sich die entsprechenden Zertikate von dritter Stelle ausstellen lassen. Die Datenquellen
mussen zur Zugriskontrolle die Moglichkeit haben, die Authentizitat der Zertikate zu
uberprufen.
Schlusselverteilung: Wenn der Kunde sicher sein will, dass eine Antwort vom richtigen
Mediator kommt, muss der Mediator die Antwort signieren und der Kunde mit dessen
oentlichem Schlussel die Signatur uberprufen; dazu muss der Kunde aber zunachst auf
sicherem Wege den Schlussel des Mediators erhalten und das nicht nur fur einen, sondern
fur alle Mediatoren, die er benutzen mochte.
Korrektheit und Vollstandigkeit der Antwort: Die Korrektheit einer Antwort kann nicht
immer sichergestellt werden. Falls beispielsweise eine Datenquelle zeitweise nicht zur Verfugung steht, kann es vorkommen, dass die Antwort nicht vollstandig ist und relevante
Daten fehlen. Der Mediator muss in diesem Falle zum Zeitpunkt der Anfrage Ersatzdatenquellen nden.
Durch die Nutzung eines Mediators erleichtert sich der Kunde die Anfrage. Er nimmt damit
aber auch Nachteile in Kauf, die dem Konzept der Mediation inharent sind. Als die zwei
Hauptprobleme sehe ich die folgenden an:
Unverschlusselte Anfrage: Der Mediator bekommt die Anfrage als Klartext, da er sonst die
Aufspaltung der Anfrage nicht durchfuhren kann. Damit erfahrt der Mediator zumindest
das Themeninteresse des Kunden und die Anfrage gibt ihm Vorwissen uber die Antwort,
so dass er vom Schlusseltext auf den Klartext der Antwort schlieen konnte.
Kontrolle der Datenquellen: Die Abkapselung der Datenquellen von den Kunden fuhrt
dazu, dass die Kunden keinerlei Metainformationen uber die Datenquellen erhalten; sie
4.2 Aufteilung von Entschlusselung und Berechnung
21
konnen Glaubwurdigkeit, Qualitat, Kontext und Aktualitat der Quellen nicht uberprufen,
sondern mussen dem Mediator vertrauen, dass er zuverlassige Quellen benutzt. Das ist
speziell ein Problem, wenn zusatzlich eine Monopolisierung stattndet und ein einziger
Mediator die Anfragen nahezu aller Kunden beantwortet.
4.2 Aufteilung von Entschlusselung und Berechnung
Die Aufspaltung der Anfrage fuhrt dazu, dass die Teilantworten zu einer Gesamtantwort zusammengesetzt werden mussen. Aus der Verschlusselung der Teilantworten folgt, dass die Daten
wieder entschlusselt werden mussen. Diese beiden Aufgaben konnen auf verschiedene Arten
zwischen Multimediamediator und Kunde aufgeteilt werden. Dabei mochte man den Kunden
moglichst entlasten, aber gleichzeitig die Vertraulichkeit von zu schutzenden Daten und geheimen Schlusseln gewahrleisten.
Grundsatzlich kann man feststellen, dass die Verschlusselung der Teilantworten dazu fuhrt, dass
zum Kunden sehr viel mehr Daten ubertragen werden, als er fur die Gesamtantwort eigentlich
braucht; dies wird in Abschnitt 5.1 weiter erlautert. Zu beachten ist hierbei, dass der Kunde
trotzdem nur Daten von den Datenquellen bekommt, die er zu sehen berechtigt ist. Falls die
Datenquelle eine Anfrage nach einer Relation bekommt, von der der Anfrager nur einen Teil
sehen darf, dann schickt die Datenquelle auch nur diesen Teil zuruck. Den Teil der Relation,
den der Anfrager nicht sehen darf, behalt sie weiterhin fur sich.
Die Datenquellen verschlusseln zunachst einmal ihre Teilantworten mit den oentlichen Schlusseln des Kunden. Da die Berechnung auf verschlusselten Daten { wie oben erlautert { nicht
praktikabel ist, ergeben sich fur die Aufteilung von Entschlusselung und Berechnung vier Moglichkeiten:
Szenario A: Der Mediator entschlusselt die Teilantworten und berechnet aus den entschlusselten Teilantworten die Gesamtantwort, die er dann (eventuell in verschlusselter Form) an den
Kunden sendet. Dieses Szenario hat zwei Nachteile:
Der Mediator bekommt auf jeden Fall die Teilantworten zu sehen, da er mit den entschlusselten Daten rechnet.
Zusatzlich muss der Kunde dem Mediator aber auch seine privaten Entschlusselungschlussel zuganglich machen, damit der Mediator die Entschlusselung der Teilantworten
durchfuhren kann.
Wenn es eine Moglichkeit gabe, den Mediator die Daten so entschlusseln zu lassen, dass er den
Schlussel weder sehen und kopieren, noch mehrfach verwenden kann, wurde der zweite Nachteil
wegfallen. Die Wunschvorstellung ist also, dass der Kunde den Schlussel in einer "schwarzen
Kiste\ sendet. Der Mediator kann die Kiste nicht einsehen; das heit, er bekommt den Schlussel
nicht zu Gesicht. Aber er kann einmal eine verschlusselte Teilantwort in die Kiste eingeben und
bekommt die entschlusselten Daten heraus. Als Hardwarelosung ware es moglich, den Schlussel auf einer Chipkarte dem Mediator zu senden und die Entschlusselung auf der Chipkarte
durchzufuhren. Dies ware aber (sowohl fur Kunden als auch Mediatoren) ein sehr groer Aufwand. Eine reine Softwarelosung fur die Entschlusselung unter Geheimhaltung des Schlussels ist
zur Zeit nicht realisierbar. Wenn der Kunde seinen Schlussel namlich kryptographisch schutzt,
musste der Mediator eine Moglichkeit haben, mit dem verschlusselten Schlussel andere Daten
zu entschlusseln. Er musste also mit dem verschlusselten Schlussel rechnen konnen. Dass das
nicht generell moglich ist, habe ich im Abschnitt 3.1 dargestellt. Der Kunde musste also dem
Mediator Zugri auf seinen Schlussel im Klartext erlauben.
Allerdings gibt es auch fur Berechnungen mit Schlusseln auf fremden Rechnern theoretische
Ansatze; Sander und Tschudin (siehe [ST98]) geben ein Signierschema an, bei dem durch
Komposition einer Berechnungsfunktion mit einer Signierfunktion nur Fuktionswerte der Berechnungsfunktion signiert werden konnen; deshalb kann die Signierung auf einem beliebigen
22
Rechner durchgefuhrt werden. Eine solche Komposition musste auch fur die Entschlusselungsfunktion des Kunden moglich sein. Allerdings musste dann der Kunde seine Entschlusselungsfunktion mit der Berechnungsfunktion des Mediators komponieren; der Mediator musste dem
Kunden also seine Berechnungsfunktion bekannt geben. Andernfalls konnte der Mediator auch
andere Daten entschlusseln, die mit dem Schlussel verschlusselt wurden, wenn er erst einmal
im Besitz des Entschlusselungsschlussels ware. Der Kunde konnte daher nicht kontrollieren,
was der Mediator mit seinem Schlussel machte.
Der Kunde hat in diesem Szenario die wenigste Arbeit: Er muss mit der Anfrage nur seine Entschlusselungsschlussel mitschicken und eventuell die Gesamtantwort entschlusseln, wenn der
Mediator sie in verschlusselter Form zurucksendet.
Szenario B: Der Mediator sendet die verschlusselten Teilantworten an den Kunden. Der Kunde
entschlusselt die Teilantworten, um nachzuweisen, dass er im Besitz der Entschlusselungschlussel ist. Danach sendet er die entschlusselten Teilantworten an den Mediator, der daraus die
Gesamtantwort berechnet. Der Nachteil, dass der Mediator die entschlusselten Teilantworten
zu sehen bekommt, bleibt bestehen.Der Kunde behalt aber seine privaten Schlussel fur sich, da
er die Entschlusselung durchfuhrt. Dieses Szenario entspricht einer Client-Server-Architektur,
wie sie Holger Peine ([Pei02], Seite 2) in seiner Dissertation als traditionelles, synchrones Kommunikationsschema in Rechnernetzen vorstellt: Ein Client sendet Anfragen an einen Server und
der Server Antworten an den Client. Charakteristisch fur eine Client-Server-Kommunikation
sind nach Peine:
1. ein hauger Datenverkehr uber eine logische Verbindung, die auf einer sehr zuverlassigen
und performanten physischen Verbindung aufbaut
2. ein im Vorhinein festgelegtes Protokoll, uber das der Anfrage-Antwort-Dialog gefuhrt
wird
3. eine dauerhaft bestehende Verbindung.
In der Denition von Peine werden keine ausfuhrbaren Programme verschickt, sondern der
Server verarbeitet die Anfrage und sendet die Antwortdaten und der Client verarbeitet die
Antwortdaten.
Der Dialog des Kunden mit dem Multimediamediator sieht wie folgt aus: Der Kunde sendet
als erste Anfrage seine Suchanfrage. Er bekommt als erste Antwort die verschlusselten Teilantworten. Er sendet als zweite Anfrage die entschlusselten Teilantworten und bekommt als zweite
Antwort die Gesamtantwort. Der Kunde hat durch die Entschlusselungsarbeit mehr zu tun als
in Szenario A; die Berechnung der Gesamtantwort nimmt der Mediator dem Kunden jedoch
ab.
Szenario C: Der Kunde ubernimmt sowohl das Entschlusseln der Teilantworten als auch das
Berechnen der Gesamtantwort. Er bekommt dazu vom Mediator einen Algebrabaum mit den
verschlusselten Teilantworten in den Blattern. Er entschlusselt zunachst die Teilantworten und
berechnet dann auf den entschlusselten Daten die Gesamtantwort. Der Mediator hat damit weder Zugri auf entschlusselte Teilantworten noch auf private Schlussel des Kunden. Allerdings
benotigt der Kunde ein Programm, dass die Berechnung der Gesamtantwort vornimmt. Der
Kunde hat in diesem Szenario die meiste Arbeit.
Szenario D: Im letzten Fall kann der Mediator die Entschlusselung aber nicht die Berechnung
vornehmen. Er entschlusselt die Teilantworten mit dem Schlussel des Kunden; dafur gibt es
dieselben Moglichkeiten wie in Szenario A. Er schickt dann einen Algebrabaum mit den entschlusselten Teilantworten an den Kunden. Der Kunde berechnet aus dem Algebrabaum die
Gesamtantwort. Diese Variante vereint alle Nachteile der anderen Szenarien in sich.
23
4.3 Kommunikation zwischen Mediator und Kunde
Szenario
Szenario A
Vorgehensweise
Nachteile
Mediator entschlusselt private Schlussel werden
und berechnet
freigegeben und Mediator
kann Daten lesen
Szenario B
Kunde entschlusselt Mediator kann Daten lesen
und Mediator berechnet
Szenario C
Kunde entschlusselt Kunde muss Programm zur
und berechnet
Berechnung besitzen
Szenario D
Mediator entschlusselt private Schlussel werden
und Kunde berechnet freigegeben, Mediator kann
Daten lesen und Kunde muss Programm zur
Berechnung besitzen
Tabelle 1: Aufteilung von Entschlusselung und Berechnung zwischen Kunde und Mediator
In Tabelle 1 werden die vier Szenarien noch einmal aufgelistet. Dem Mediator soll im Multimediamediator-Konzept moglichst wenig Vertrauen entgegengebracht werden. Er soll zwar
aus der Anfrage einen Algebrabaum erstellen, die Teilanfragen an Datenquellen senden und
die verschlusselten Teilantworten in den Algebrabaum einsetzen. Er soll aber nicht mit dem
Entschlusselungsschlussel des Kunden rechnen und die Teilantworten nicht entschlusselt zu
Gesicht bekommen. Nur Szenario C erfullt diese Anforderungen. Dem Kunden muss daher die
Mehrarbeit zu Berechnung der Gesamtantwort aufgeburdet werden.
Es stellt sich die Frage, in welcher Form der Multimediamediator die Antwort an den Kunden sendet. Der Kunde ist nur an der Gesamtantwort interessiert und nicht an den einzelnen
Teilantworten der Datenquellen; das Konzept der Mediation sieht gerade vor, dass dem Kunden
nur die relevanten Daten geliefert werden. Er sollte als zusatzliche Angabe hochstens den (oder
die) Entschlusselungsschlussel auswahlen mussen, damit im Vergleich zu einer Anfrage ohne
Verschlusselung die Benutzung nicht zu umstandlich wird. Aufgabe des Kundenprogramms ist
es, aus der Antwort des Mediators die Gesamtantwort zu berechnen und dem Benutzer zu
prasentieren. Fur die Auslieferung und Berechnung der Gesamtantwort gibt es drei Kommunikationsschemata, die den Rechenaufwand unterschiedlich auf die Teilnehmer verteilen: mobile
Daten, mobiler Code und mobile Agenten. Auf den ersten Blick scheint der Begri "mobiler Code\ intuitiv verstandlich { es handelt sich um ein Softwaremodul, das auf einem Rechner erstellt
und auf einem anderen Rechner ausgefuhrt wird. Eine eindeutige Denition ist jedoch nicht
trivial und eine Abgrenzung zu den Begrien "mobile Daten\ und "mobile Agenten\ schwierig.
In diesem Abschnitt werden daher diese drei Konzepte zunachst beschrieben und dann auf den
Multimediamediator ubertragen.
Zunachst aber noch eine Begrisklarung: Auf Bitebene der Netzverbindung zwischen zwei Rechnern gibt es keinen Unterschied zwischen Daten und Code; Daten werden nur dann zu Code,
wenn ein Prozessor sie als Programmanweisungen interpretieren kann. Peine ([Pei02], Seite 9)
schreibt dazu: "Eine Menge von Daten wird allein dadurch zu Code, dass ein Prozessor sie sich
ansieht und Aktionen durchfuhrt, wie er sie in diesem Code beschrieben sieht\4 . Ich mochte
Daten und Code auf der Prozessor- und nicht der Bitebene betrachten.
4 Ubersetzt

aus dem Englischen; Originaltext: "A piece of data becomes code only by some processor looking
at it and performing actions as it sees described
in that code.\
24
Basierend auf [Pei02], [Vig98] und [Bau00] stelle ich fur diese Diplomarbeit die folgenden Denitionen auf:
Mobile Daten, Bearbeitungsprogramm:
Beim Konzept der mobilen Daten gibt es einen Kunden, der Informationen anfragt, und
einen Anbieter, der diese Informationen bereithalt. Die Kommunikation zwischen Kunde und Anbieter ist reiner Datenaustausch ohne Programmanweisungen; die Berechnung
oder Datenverarbeitung der Daten auf dem Kundenrechner erfolgt durch ein Programm,
das bereits vorher auf dem Kundenrechner vorhanden war, ein sogenanntes Bearbeitungsprogramm. Mobile Daten sind unabhangig von fest vorgegebenen Bearbeitungsprogrammen (sie sind sogar unabhangig von der Programmiersprache eines Bearbeitungsprogramms) { es konnen auf Kundenseite andere benutzt werden als auf Anbieterseite.
Mobile Daten werden aber immer in einem fest vereinbarten Format zwischen Kunde
und Anbieter ubertragen. Die Kontrolle des Datenverkehrs obliegt allein dem Kunden
und dem Anbieter; das heit, die U bertragung wird explizit vom Kunden angefordert
und dann vom Anbieter durchgefuhrt.
Mobiler Code, Ausfuhrungsumgebung, Code auf Nachfrage, Fernauswertung:
Mobiler Code besteht aus einer festkodierten Anweisungsfolge, die von einem Prozessor
ausgefuhrt werden kann. Eventuell gehort auch ein Satz Daten dazu, auf dem der Code
arbeitet. Eine Instanz eines mobilen Codes wird an nur einen Empfangerrechner geschickt
und nur auf ihm ausgefuhrt. Eine Installation des Codes ist dazu nicht notwendig, sondern
die Ausfuhrung kann sofort gestartet werden. Um dem Empfanger Kontrolle uber den
Ablauf des mobilen Codes zu geben, sollte der Code in einer Ausfuhrungsumgebung
laufen, einem Programm, das das darunterliegenden Betriebssystem vom mobilen Code
abschirmt. Der Empfanger kann dem Code mit der Ausfuhrungsumgebung sicherheitsrelevante Aktionen verbieten (Naheres dazu folgt im Abschnitt 6.2). Fong ([Fon98], Seite 4)
unterscheidet mobilen Code noch darin, ob der Empfanger oder der Sender die Kommunikation zwischen Sender und Empfanger initiiert. Beginnt der Empfanger, handelt es
sich um Code auf Nachfrage: der Sender verlagert mit dem Code Rechenaufgaben, die
eigentlich in seinem Aufgabenbereich liegen, auf den Empfanger; ein Beispiel dafur sind
Applets. Beginnt der Sender die U bertragung, handelt es sich um Fernauswertung: ein
Datenanbieter kann mit mobilem Code, den er als Anfrage vom Kunden bekommt, auch
die Datenverarbeitung durchfuhren, die sonst der Kunde durchfuhren wurde; der Kunde
ist der Anbieter des mobilen Codes. Im Gegensatz zu mobilen Daten verschieben sich
also bei mobilem Code die Rollen Kunde und Anbieter { man kann stattdessen besser
von Empfanger und Sender des Codes sprechen. Ein eindeutiges Datenformat muss nicht
mehr festgelegt werden. Allerdings muss der Code dem Empfangersystem eine oentliche
Schnittstelle fur die Ausfuhrung bieten. Die U bertragung und Ausfuhrung des Code konnen aber mussen nicht der Kontrolle des Empfangers unterliegen. Computerviren sind ein
Beispiel fur nichtkontrollierbaren mobilen Code ohne Ausfuhrungsumgebung und ohne
Kontrolle der U bertragung.
mobile Agenten, starke und schwache Migration, Agentensystem:
Der Begri mobile Agenten wurde zuerst im Bereich der Kunstlichen Intelligenz eingefuhrt. Unabhangig davon hat aber auch die Programmiersprache Telescript diesen Begri
fur ihre Programmmodule verwendet; sie wird heute als das erste Agentensystem bezeichnet. Von einer hohen Abstraktionsebene aus betrachtet, handelt der mobile Agent in der
virtuellen Welt im Auftrag eines realen Individuums. Ein mobiler Agent besteht { wie
mobiler Code { aus Daten und Code. Eine Instanz eines mobilen Agenten fuhrt verteilte
Berechnungen auf mehreren Rechnern aus. Die Berechnungen verandern die Daten. Eine
Installation des Agenten-Codes ist nicht notwendig. Werden zwischen zwei Wirtsrechnern nur der Code und die Daten ubertragen und beginnt die Ausfuhrung jedesmal an
25
demselben Startpunkt im Agentenprogramm, spricht man von schwacher Migration.
Wird auerdem auch noch der aktuelle Prozesszustand ubertragen und setzt der Agent
seine Berechnungen an der Stelle fort, an der er sie unterbrochen hatte, spricht man
von starker Migration5 . Die Wirtsrechner bilden ein Netzwerk aus gleichberechtigten
Partnern. Auf jedem von ihnen lauft der Agent in einer Ausfuhrungsumgebung { hier ein
sogenanntes Agentensystem. Ein Agent bendet sich meist auf dem Rechner, der die
Ressourcen hat, die er gerade benotigt. Der Aufenthaltsort kann aber auch abhangig von
der Auslastung des Netzwerks und der einzelnen Rechner gewechselt werden. Ein Agent
kann mit anderen Agenten oder mit anderen Wirtsrechnern uber das Netz kommunizieren. Ein mobiler Agent kann seinen Aufenthaltsort wechseln, ohne dass sein Wirtsrechner
Kontrolle daruber hat. Auch er muss dem Agentensystem aber eine Schnittstelle fur die
Ausfuhrung bereitstellen.
Die Grenzen zwischen den drei Typen verteilter Berechnung sind ieend und in der Literatur
ist keine eindeutige Denition zu nden. Fur den Multimediamediator sehe ich die folgenden
Moglichkeiten, die Kommunikationsschemata einzusetzen.
Eine Umsetzung des Multimediamediators mit mobilen Daten verlangt, dass Kunden und
Mediatoren sich auf ein Datenformat einigen { beziehungsweise ein Mediator seinen Kunden ein Datenformat vorgibt. Das Datenformat bildet den Algebrabaum ab; dazu lasst
sich zum Beispiel XML (Extensible Markup Language) benutzen. Der Kunde bekommt
vom Mediator auf seine Anfrage eine Datei mit dem entsprechenden Algebrabaum. Um die
Gesamtantwort zu erhalten, benutzt er ein Bearbeitungsprogramm, das die verschlusselten Teile in dieser Datei entschlusselt, die Datei einliest und den Algebrabaum berechnet
{ allerdings mit Operatoren, deren Programmcode im Bearbeitungsprogramm enthalten
und damit bereits auf dem Kundenrechner installiert sind. Wenn im Laufe der Zeit der
Mediator sein Datenformat andert (zum Beispiel neue Operatoren einfugt oder ein anderes Format fur die Teilantworten benutzt) oder bessere Algorithmen fur die Operatoren
gefunden werden, bedeutet das fur den Kunden, dass er sein Bearbeitungsprogramm aktualisieren muss; er hat damit zusatzlichen Installationsaufwand. Zudem muss das Bearbeitungsprogramm auf eine groe Menge von Datenformaten und passenden Operatoren
vorbereitet sein. Es muss dazu eine Vielzahl von Bibliotheken bereithalten, auch wenn
die Formate vielleicht nie benutzt werden.
Eine Umsetzung des Multimediamediators mit mobilem Code bedeutet, dass der Mediator dem Kunden den Algebrabaum als ausfuhrbares Programm schickt. Fur eine objektorientierte Programmiersprache sieht das so aus, dass Operatoren-Objekte die inneren
Knoten und Teilantwort-Objekte die Blatter des Baumes bilden. Die Operatoren-Objekte
haben eine Methode, die auf dem Kind oder den Kindern die gewunschte Berechnung
durchfuhrt. Als Antwort auf eine Kundenanfrage erstellt der Mediator die entsprechende
Instanz eines solchen Algebrabaums und schickt sie an den Kunden. In Java heit das
insbesondere, dass die Instanz des Baums und zusatzlich der Binarcode der Operatoren
und der Datenformate des Baums und der Teilantworten mitgeschickt wird. Mediator
und Kunden mit mobilem Code sind damit im Gegensatz zu Mediator und Kunden mit
mobilen Daten erweiterbar. Die Schnittstelle zwischen mobilem Code und Kundenrechner
sollte besonders allgemein und klein gehalten werden, damit A nderungen an Datenformat
und Operatoren keine Neuinstallation auf dem Kundenrechner verursachen. Im mobilen
Code sind nur die Bibliotheken enthalten, die der Code fur seine Ausfuhrung benotigt.
Der Kunde macht sich damit jedoch insofern abhangig von der Programmiersprache des
5 Man
kann den Prozesszustand dann im Gegensatz zu den (Last-)Daten, auf denen die Berechnungen des
Agenten durchgefuhrt werden, als eigentstandigen Satz von Ausfuhrungsdaten betrachten.
26
mobilen Codes, dass er eine Laufzeitumgebung fur die Programmiersprache bereitstellen
muss.
Mobile Agenten lassen sich in der Kommunikationsrichtung Mediator zu Kunde nicht
einsetzen, denn jede Antwort wird zu nur einem Kunden geschickt und nicht zu mehreren
Rechnern. Das Agenten-Konzept konnte vielmehr das Mediator-Konzept sogar ersetzen,
indem der Kunde einen Agenten mit einer Anfrage erstellt und dieser Agent selbststandig
bei den Datenquellen die Antwort zusammensucht. Agenten konnten das Mediatorsytem
aber auch erganzen, indem der Kunde einen Agenten mit einer Anfrage an den Mediator
sendet, der Mediator die Anfrage aufspaltet und die Datenquellen vorgibt, die der Agent
zu Beantwortung der Anfrage aufsucht, bevor er zum Kunden zuruckkehrt.
mobile Daten
Mediator sendet Algebrabaum in festgelegtem Format; Kunde hat Bearbeitungsprogramm, das die Gesamtantwort berechnet
mobiler Code
Mediator sendet Algebrabaum als ausfuhrbares Programm, das die Gesamtantwort berechnet; Kunde
bindet dazu Bibliotheken zur Laufzeit ein
mobile Agenten nicht fur Kommunikationsrichtung Mediator zu
Kunde; aber als Erweiterung der Kommunikation
des Mediators mit den Datenquellen denkbar
Tabelle 2: Schemata der Kommunikation des Mediators mit dem Kunden
Tabelle 2 stellt die drei Konzepte fur den Multimediamediator noch einmal gegenuber. Wenn
Sicherheitseinstellungen auf dem Kundenrechner vorgenommen werden sollen, ist bei allen drei
Ansatzen ein Kundenmodul notwendig, namlich bei mobilen Daten ein Bearbeitungsprogramm,
bei mobilem Code eine Ausfuhrungsumgebung und bei mobilen Agenten ein Agentensystem.
Solch ein Kundenmodul muss fur alle drei Ansatze aus vertrauenswurdiger Quelle stammen
oder aber einmal bei der Installation auf seine Unbedenklichkeit gepruft werden.
Da Kunden und Datenquellen das Multimediamediator-System dynamisch betreten und verlassen konnen, bietet mobiler Code den Vorteil, dass beliebige Antwortformate durch mitgelieferte
Programmmodule verarbeitet werden konnen. Ein starres Bearbeitungsprogramm auf Kundenseite { wie bei mobilen Daten vorhanden { kann zu schnell an Aktualitat verlieren und muss
dann neu installiert werden. Die Neuinstallation muss aktiv vom Kunden durchgefuhrt werden,
wahrend die Programmmodule des mobilen Codes immer aktuell und sofort lauahig sind, ohne dass der Kunde etwas tun muss.
Unter der Annahme, dass sich die Antwortformate nur selten andern, ist der groe Vorteil der
mobilen Daten, dass sie nur das Bearbeitungsprogramm benotigen. Dieses Programm muss nur
einmal gepruft werden. Wenn das Bearbeitungsprogramm zertiziert wurde und der Hersteller
dem Kunden vertraglich eine korrekte und schadensfreie Ausfuhrung zusichert, muss dieses
Zertikat nur einmal vor der Installation gepruft und der Vertrag nur einmal mit dem Hersteller abgeschlossen werden. Bei mobilem Code musste jeder einzelne Code zertiziert werden;
der Kunde geht fur jeden Code ein neues Vertragsverhaltnis mit dem Codehersteller ein (siehe
dazu auch 6.2.2 auf Seite 40).
Unter der Annahme, dass sich die Antwortformate haug andern, musste auch fur jede Aktualisierung und Neuinstallation des Bearbeitunsprogramms ein Zertikat uberpruft und ein
Vertrag akzeptiert werden.
Ein Bearbeitungsprogramm fur mobile Daten ist zudem umfangreicher als die Ausfuhrungsumgebung fur mobilen Code, da es fur alle moglichen Antwortformate Berarbeitungsroutinen
bereithalten muss. Die Ausfuhrungsumgebung des mobilen Codes dagegen enthalt nur grundlegende Routinen, mit denen der Code ausgefuhrt werden soll. Im mobilen Code selbst werden
nur die aktuell benotigten Routinen mitgeschickt, so dass der Code nicht so umfangreich ist wie
27
ein ganzes Bearbeitungsprogramm. Auf weitere Vor- und Nachteile von mobilem Code mochte
ich in den folgenden Abschnitten eingehen. Da es immer ein Risiko birgt, Code aus unbekannter
Quelle auszufuhren, muss eine Ausfuhrungsumgebung fur mobilen Code Vorkehrungen treen,
um Angrie des Codes zu vermeiden. In Abschnitt 6 auf Seite 34 wird mobiler Code unter
Sicherheitsaspekten betrachtet.
28
5 Vor- und Nachteile von mobilem Code
Mobiler muss sich dem Vergleich mit anderen Ansatzen stellen konnen. Sein funktional starkster
Konkurrent sind mobile Daten. Im Folgenden benutze ich externe Methodenaufrufe (engl. remote procedure calls, RPCs) als Beispiel fur eine Kommunikation mit mobilen Daten. Das Konzept der externen Methodenaufrufe sieht wie folgt aus: Ein Methodenanbieter (der sogenannte
RPC-Server) stellt die zu einer Methode gehorende Schnittstelle nach auen zur Verfugung. Er
publiziert eine Beschreibung der Methodenfunktionalitat mittels einer Beschreibungssprache
(einer Sprache zur Denition der Schnittstelle, engl.interface denition language, IDL); dies
ist im einfachsten Fall die Signatur der Methode. Der Kunde (RPC-Client) kann die externe
Methode uber sogenannte Methodenstumpfe aufrufen. Der Methodenaufruf und die U bergabe
der Parameter als Anfrage und die Ruckgabe des Funktionswertes als Antwort erfolgen synchron uber eine Netzverbindung. Der Methodenname, die Parameter und die Ruckgabewerte
sind die mobilen Daten. Das Hauptprogramm und die Methodenstumpfe auf Kundenseite und
die Methodenimplementierung auf Anbieterseite sind die Datenbearbeitungsprogramme.
Die Funktionalitat eines Programms mit mobilem Code ist auch mit mobilen Daten umsetzbar,
solange alle benotigten Schnittstellen von auen zugreifbar gemacht werden konnen. Dies betonen [HCK95] und [Pei02]. Man verspricht sich durch mobilen Code aber eine schnellere oder
zuverlassigere Ausfuhrung einer Berechnung; Fong (siehe [Fon98]) und Peine (siehe [Pei02])
zeigen die Vorteile des mobilen Codes anhand von sechs Eckdaten auf. Ob diese Vorteile auch
fur den Multimediamediator zutreen oder ob man auch Nachteile durch mobilen Code in Kauf
nehmen muss, mochte ich in den folgenden sechs Abschnitten untersuchen. Tabelle 3 stellt mobilen Code im Vergleich zu mobilen Daten im allgemeinen Fall dem mobilen Code im speziellen
Fall des Multimediamediators noch einmal gegenuber.
5.1 Verringerung der ubertragenen Datenmenge
Bei mobilen Daten kann die ubertragene Datenmenge im Vergleich zu mobilen Daten reduziert
werden, wenn der Kunde seine Datenbearbeitungsmethoden in mobilem Code "verpackt\ und
an den Anbieter (im Sinne der mobilen Daten; siehe Abschnitt 4.3, Seite 24) schickt. Hierbei
handelt es sich um eine Fernauswertung, die im selben Abschnitt beschrieben wurde. Die gesamte Berechnung kann dann auf dem Anbieter ausgefuhrt werden und nur die Gesamtantwort
wird an den Kunden ubermittelt. Aber auch vom Anbieter kann Code an den Kunden gesendet
werden: bei einem externen Methodenaufruf kann der Algorithmus, der hinter der externen Methode steckt, vom Methodenanbieter auf den Kundenrechner ubertragen werden. Der Aufruf
kann dann lokal durchgefuhrt werden und muss nicht uber das Netz geschickt werden. Dies
ware Code auf Nachfrage, der der Fernauswertung in Abschnitt 4.3 gegenubergestellt wurde.
Peine ([Pei02], Seite 3) schreibt, dass mobiler Code potenziell die ubertragene Datenmenge
reduziert. Meiner Ansicht nach hat der Einsatz von mobilem Code jedoch in der Regel zur
Folge, dass zusatzlich Daten ubertragen werden mussen (allgemein durch die Versendung des
Programmcodes und in Java zusatzlich durch fehlende Klassendenitionen); das gesamte ubertragene Datenaufkommen pro Anfrage wird nur dann verringert, wenn andernfalls ein hauger
Datenaustausch zwischen Kunde und Anbieter stattnden wurde oder eine groe Menge an
Parametern ubertragen werden musste.
Allerdings kann man auch das Datenbearbeitungsprogramm in diese Rechnung miteinbeziehen.
Im Bearbeitungsprogramm mussen, wie im letzten Abschnitt bereits erwahnt, eine Vielzahl von
Bibliotheken bereits vorhanden sein, die ja zunachst einmal auf dem Kundenrechner gelangen
mussen. Auch Aktualisierungen der Bibliotheken mussen an den Kunden ubertragen werden.
Der mobile Code enthalt dagegen nur die geringe Anzahl von Bibliotheken, die er fur seine
aktuelle Ausfuhrung benotigt. In der Gesamtbilanz kann mobiler Code daher besser dastehen.
5.2 Unabhangigkeit von der Netzverbindung
29
Bei dem in dieser Arbeit entwickelten mobilen Code ist es so, dass nicht nur zusatzliche Bibliotheken ubertragen werden, sondern dass sogar die Nutzdaten unnotig aufgeblaht werden, da
mehr Daten ubertragen werden, als fur die eigentliche Berechnung notig sind. Die Aufblahung
der Datenmengen ist jedoch eine Folge der Verschlusselung: da die Teilantworten verschlusselt
werden und der Mediator sie vollstandig an den Kunden weiterleiten muss, ist die Datenmenge
im Vergleich zu einer unverschlusselten Gesamtantwort sehr hoch. Dies ware aber auch mit
mobilen Daten der Fall. Mogliche Optimierungen mochte ich im Folgenden kurz vorstellen.
5.1.1 Optimierungen der Teilanfragen
Derzeit wird die Gesamtanfrage vollstandig in atomare Ausdrucke zerlegt; eine genauere Beschreibung folgt in Abschnitt 8.2.2 auf Seite 72. Durch eine geschicktere Aufspaltung der Anfrage, konnte der Mediator ezientere Teilanfragen stellen. Der Mediator konnte den Datenquellen
etwa mitteilen, welche Attribute einer Relation er fur die Berechnung der Gesamtantwort tatsachlich benotigt. Das kann er erreichen, indem er in die Teilanfragen Projektionen auf die
in der Anfrage vorkommenden Attribute einfugt (auch die, die implizit in Verbunden vorkommen). Die Datenquelle braucht dann nur die betrachteten Spalten zuruckzuschicken. Die
Anfrage konnte auch nur soweit aufgespalten werden, bis Teilanfragen existieren, die sich auf
jeweils eine Datenquelle beziehen; diese komplexeren Teilanfragen konnte dann vollstandig von
der jeweiligen Datenquelle beantwortet werden, ohne dass die Anfrage weiter zerlegt werden
muss. Dadurch wird der Algebrabaum kleiner; das heit, er enthalt weniger Operatoren und
damit auch weniger Ebenen. Das verkurzt die Berechnungsdauer auf dem Kundenrechner.
Mit den in 3.2 (Seite 11) dargelegten Einschrankungen kann der Ansatz von Hacgumus et
al. genutzt werden, um weniger Daten an den Kunden zu ubertragen. Er kann Daten aus den
Teilantwort herausrechnen, die auf jeden Fall nicht in der Gesamtantwort vorkommen und die
verbleibenden dann an den Kunden ubertragen.
Eine Weitergabe von Selektionen an Datenquellen kann es dem Mediator in einigen Fallen
auch erlauben, auf den verschlusselten Teilantworten die Gesamtantwort zu berechen (zumindest wenn die Teilantworten mit demselben Schlussel verschlusselt wurden). Fur ein Beispiel
siehe [ABFK03], Seite 390f.
Da solcherlei Optimierungen aber nicht Thema dieser Arbeit sind, werde ich sie ihm praktischen Teil nicht umsetzen. Dass eine U bertragung von unnotigen Daten im Gegenteil sogar
Vorteile fur die Geheimhaltung der Daten liefert, werde ich in Abschnitt 6.5 (siehe Seite 46)
darlegen.
5.2 Unabhangigkeit von der Netzverbindung
Bei Kommunikation mit mobilen Daten kann es vorkommen, dass zur Berechnung eines Ergebnisses mehrfach Verbindungen vom Kunden zum Anbieter aufgebaut werden und Verbindungen
uber einen langen Zeitraum aufrecht erhalten werden. Mehrfache Verbindungen sind beispielsweise notwendig, wenn vom Kunden mehrere externe Methoden nacheinander aufgerufen werden. Eine Verbindung zum Anbieter muss lange gehalten werden, wenn die Berechnung des
Ruckgabewertes einer externen Methode viel Zeit beansprucht. Mit mobilem Code kann eine
Berechnung unabhangig von einer standigen Verbindung der Kommunikationspartner durchgefuhrt werden. Im Idealfall wird nur eine temporare Verbindung und eine einmalige U bertragung
des mobilen Codes benotigt. Danach ist eine vollig autarke Berechnung des Endergebnisses moglich. Dies ist in dynamischen Netzen ein groer Vorteil, da eine einmalige Datenubertragung
weniger anfallig gegenuber Verbindungsabbruchen ist als eine langanhaltende Kommunikation.
So wird zwar nicht die qualitative aber die quantitative Robustheit erhoht: Verbindungsabbruche konnen immer noch auftauchen, richten aber keinen so groen Schaden an (vgl. dazu auch
Peine [Pei02], Seite 17).
Im Vergleich zum Mediatorsystem mit mobilen Daten bietet der mobile Code in diesem Punkt
30
pro Anfrage keinen Vorteil, da der Mediator die Bundelung der Antworten schon ubernimmt.
Eine mehrfache Netzverbindung ist daher auch mit mobilen Daten nicht notwendig. Im Gegenteil ist ein Multimediamediator mit mobilem Code durch die hohere ubertragene Datenmenge
noch eher durch Verbindungsabbruche gefahrdet als mit mobilen Daten.
Wenn man auch hier das Bearbeitungsprogramm der mobilen Daten in die Betrachtungen mit
einbezieht, muss man neben den mobilen Daten auch die Aktualisierungen des Bearbeitungsprogramms ubertragen und braucht auch dafur Netzverbindungen; da das Bearbeitungsprogramm und die Aktualisierungen umfangreicher sind als ein einzelner mobiler Code, mussen
diese Verbindungen stabiler sein, als fur eine U bertragung eines mobilen Codes.
5.3 Vermeidung eines verteilten Berechnungszustands
Bei einer Client-Server-Kommunikation (siehe Abschnitt 4.2) mussen die Daten sowohl auf der
Server- als auch auf der Client-Seite bearbeitet werden. Der Zustand einer Berechnung ist daher
verteilt zwischen beiden Parteien. Dieser Berechnungszustand kann inkonsistent werden, wenn
die Teilzustande auf beiden Seiten parallel bearbeitet und unabhangig voneinander verandert
werden. Es muss beispielsweise darauf geachtet werden, dass der Client nicht schon vor dem
Ende einer Anfrage an den Server mit Daten weiterrechnet, in die zunachst noch der Ruckgabewert eingerechnet werden muss (die Daten sich also durch den Ruckgabewert noch andern).
Wenn eine Berechnung auf zwei Parteien verteilt ist, aber eine Partei die (Teil-)Berechnung der
anderen Partei ubernehmen kann, bietet mobiler Code den Vorteil, dass die gesamte Berechnung lokal durchgefuhrt werden kann. Die Ausfuhrung ndet dann in einem Ausfuhrungsstrang
lokal statt und wird nicht durch einen inkonsistenten verteilten Berechnungszustand gefahrdet.
Das Konzept der Mediation sieht die Verteilung einer Berechnung auf mehrere Parteien vor.
Beim Multimediamediator wird eine Anfrage vom Kunden uber einen primaren Mediator auf
mehrere Datenquellen und eventuell auf weitere Mediatoren verteilt. Mediatoren nehmen dabei
aber Aufgaben wahr, die nicht auf den Kunden ubertragen werden konnen; dies sind insbesondere die Aufspaltung der Anfrage und die Erstellung des mobilen Codes. Die Datenquellen
sind fur die Erstellung der Teilantworten zustandig. Die Berechnung muss also auf alle Parteien verteilt bleiben. Das gilt sowohl fur eine Umsetzung mit mobilem Code als auch fur eine
Umsetzung mit mobilen Daten.
Aus den folgenden Grunden kann es jedoch nicht passieren, dass der verteilte Berechnungszustand im Mediatorsystem inkosistent wird, auch wenn aus Optimierungsgrunden die Teilanfragen an die betroenen Datenquellen parallel gestellt werden: Zum Einen sind die Datenquellen
in der Beantwortung der Teilanfragen unabhangig und der Mediator bearbeitet die Teilantworten nicht weiter; Inkonsistenzen beim Aufbau des Antwortbaumes sind daher zu verhindern .
Zum Anderen ndet die Kommunikation zwischen Kunde und Mediator innerhalb einer Anfrage nur seriell statt; wenn die Anfrage des Kunden synchron an den Mediator gestellt wird,
muss der Kunde auf die Ruckantwort des Mediators warten, bevor er die Berechnung der Gesamtantwort beginnen oder eine neue Anfrage starten kann.
6
5.4 Lokalitat von Ressourcen
Mobiler Code kann dort sein, wo sich die ortsgebundene Ressource bendet, auf die er zugreift.
Dadurch ist eine Echtzeitbenutzung der Ressource moglich, ohne dass eine Netzverzogerung
die Berechnung beeinut. Eine solche Ressource ist zum Beispiel der Bildschirm; JavaScript
als mobiler Code kann die Anzeige einer Webseite dynamisch andern, ohne dass dafur eine
HTTP-Anfrage an den Server der Webseite gestellt werden muss.
6 Bei
einer seriellen, synchronen Versendung der Teilanfragen muss der Mediator auf die Teilantwort der Datenquelle warten. Bei einer parallelen, asynchronen Versendung kann der Mediator die Teilanfragen durchnummerieren und die Teilantworten an der entsprechenden Stelle in den Algebrabaum einsetzen.
5.5 Einfachheit des Empfangersystems
31
Betrachtet man beim Multimediamediator den privaten Entschlusselungsschlussel des Kunden
als Ressource, ist der Aufenthalt des mobilen Codes an dem Ort an dem sich diese Ressource bendet { namlich auf dem Kundenrechner { nicht allein eine Option sondern sogar notwendig.
Der mobile Code kann den privaten Schlussel nur auf dem Kundenrechner benutzen (beziehungsweise der Kunde den Code entschlusseln). Eine Veroentlichung des Schlussels oder ein
Zugri auf den Schlussel durch den Mediator macht das System hinfallig.
Auch mobile Daten konnen zum Standort der Ressource gesendet werden. Sie sind dort allerdings auf jeden Fall auf ein Bearbeitungsprogramm angewiesen, das die Methoden zur Benutzung der Ressource bereithalt. Mobiler Code kann im Gegensatz dazu im Zusammenspiel mit
der Eigenschaft "Erweiterbarkeit des Empfangersystems\ (siehe Abschnitt 5.6) die ortsgebundene Ressource exibel benutzen, indem der Code die benotigten Methoden mitbringt.
5.5 Einfachheit des Empfangersystems
Das Konzept der mobilen Daten sieht sowohl fur Kunden- als auch fur Anbieterseite Programme zur Bearbeitung von Daten vor. Bei externen Methodenaufrufen etwa sind das auf
Kundenseite das Hauptprogramm und die sogenannten Methodenstumpfe, die auch eine Parameterumwandlung durchfuhren konnen, und auf Anbieterseite die eigentliche Methode selbst.
Die Idealvorstellung fur mobilen Code ist es dagegen, dass nur der Sender ein Programm hat,
das den mobilen Code erstellt und ihn an den Empfanger schickt. Auf Empfangerseite wird der
Code ohne weitere Hilfsprogramme innerhalb des Betriebssystems ausgefuhrt.
Die Empfanger sind allerdings meist keine homogene Gruppe, sondern benutzen unterschiedliche Betriebssysteme. Der mobile Code braucht dann auch auf der Empfangerseite ein Programm: eine Ausfuhrungsumgebung, die von der zugrundeliegenden Plattform abstrahiert. Diese Ausfuhrungsumgebung gibt dem Empfanger auch die Moglichkeit, die Ausfuhrung des Codes
zu kontrollieren. Meiner Ansicht nach ist eine Ausfuhrungsumgebung unabdingbar, wenn fur
den mobilen Code Sicherheitseinstellungen vorgenommen werden sollen, da nur ein vertrauenswurdiges Modul auf Kundenseite diese Aufgabe sicher durchfuhren kann. Der mobile Code
selbst darf keine Sicherheitseinstellungen auf dem Kundenrechner vornehmen; er muss hochstens nachweisen, dass er bestimmte Sicherheitsregeln einhalt. Ein Verfahren dazu stelle ich in
Abschnitt 6.2.3 auf Seite 41 vor. Auerdem schirmt die Ausfuhrungsumgebung das Betriebssystem vom mobilen Code ab. Wie oben schon erwahnt muss die Ausfuhrungsumgebung ein
unbedenkliches Programm sein und eventuell bei der Installation uberpruft werden.
Zentrales Ziel eines Systems mit mobilem Code sollte es sein, die Ausfuhrungsumgebung moglichst klein zu halten. Mobiler Code bietet den Vorteil, dass die Ausfuhrungsumgebung im
Vergleich zum Bearbeitungsprogamm mobiler Daten wenig Speicherplatz und Rechenzeit verbraucht; jeder Code bringt eine geringe Anzahl dynamischer Bibliotheken mit, die auch nur
wahrend der Ausfuhrung des Codes auf dem Rechner vorhanden sein mussen.
Im Fall des Multimediamediators erscheint es mir zudem wichtig, dass die gesamte Anfragedauer nicht wesentlich groer ist als die Anfragedauer ohne Verschlusselung und Schutzmechanismen. Bei Suchanfragen sind Benutzer (im Gegensatz zu beispielsweise Programminstallationen)
meist sehr ungeduldig und verzichten im dem Fall, dass die Suche zu lange dauert, lieber auf
Verschlusselung. Die Handhabbarkeit sollte durch verschlusselte Antworten auch nicht verschlechtert werden. Der Kunde muss ein Passwort fur den Zugri auf die privaten Schlussel
angeben; viel mehr sollte er aber nicht zusatzlich tun mussen, da sonst die Akzeptanz fur ein
solches Anfrageprogramm wieder sinkt. Das muss aber auch fur das Bearbeitungsprogramm
von mobilen Daten gelten.
5.6 Erweiterbarkeit des Empfangersystems
Wahrend bei mobilen Daten die Teilnehmer selbst fur die Aktualisierung ihrer Programme
zustandig sind, kann ein Sender von mobilem Code die jeweils aktuelle Version oder einen
32
Vergleichswert
allgemein Multimediamediator
Verringerung der ubertragenen Datenmenge
-/0/+
-/0
Unabhangigkeit von der Netzverbindung
+
0
Vermeidung eines verteilten Berechnungszustands
+
0
Lokalitat von Ressourcen
+
+
Einfachheit des Empfangersystems
+
+
Erweiterbarkeit des Empfangersystems
+
+
Tabelle 3: Vergleich des mobilen Codes mit mobilen Daten.
+: besser als mobile Daten; 0: kein Unterschied; -: schlechter als mobile Daten
Korrekturcode schicken; der Empfanger muss sich nicht mit der Aktualisierung seines Systems befassen. Das ist der grote Vorteil von mobilem Code gegenuber mobilen Daten. Fong
([Fon98], Seite 6) nennt als Beispiel erweiterbare Betriebssysteme. Peine ([Pei02], Seite 3f)
weist auerdem darauf hin, dass mobiler Code leistungsfahiger und funktionsreicher sein kann
als traditionelle Protokolle, da ihm unter Umstande die gesamte Softwareschnittstelle des Empfangerrechners zu Verfugung steht und er nicht nur auf Schnittstellen zugreifen kann, die ubers
Netz veroentlicht werden. Meiner Ansicht nach ist eine Moglichkeit zur Erweiterung des Empfangersystems sogar unabdingbar, denn mobiler Code benotigt oft zusatzliche Bibliotheken oder
Klassendateien. Die Bibliotheken mussen entweder vorher auf allen potenziellen Empfangern
verteilt werden, immer mit dem Code mitgeschickt werden oder vom Empfanger nachbestellt
werden. Alle drei Varianten bringen unterschiedliche Nachteile mit sich:
Die Verteilung im Voraus erhoht den Administrationsaufwand auf Empfangerseite und
die groere Menge an Bibliotheken belegt mehr Speicherplatz, obwohl viele Bibliotheken
eventuell gar nicht benutzt werden. Entscheidend fur die Ausfuhrung des mobilen Codes
ist auerdem die Versionskontrolle: greift der mobile Code auf neue Bibliotheken zu,
mussen diese auch bei allen potenziellen Empfangern aktualisiert werden.
Das sofortige Mitschicken der Bibliotheken vergroert die Menge der zu ubertragenden
Daten erheblich und ist nutzlos, wenn die Bibliothek auf Empfangerseite schon vorhanden war. Versionskonikte konnen jedoch nicht auftreten, da eine Aktualisierung der
Bibliotheken nur von der sendenden Stelle vorgenommen werden muss.
Eine Nachbestellung von Bibliotheken kann entweder statisch vor Ausfuhren des Codes
oder dynamisch zur Laufzeit des Codes durchgefuhrt werden. Im ersten Fall muss der
mobile Code eine Moglichkeit bieten, den Typ und die Version der benotigten Bibliotheken herauszunden; diese mussen dann mit denen auf dem Empfangersystem abgeglichen
werden. Im zweiten Fall muss das Empfangersystem Fehler behandeln, die durch nichtvorhandene Bibliotheken zur Laufzeit auftreten, diese in Bestellungen umsetzen und nach
Erhalt der Bibliothek das Programm an der unterbrochenen Stelle wieder aufnehmen.
Die Nachbestellung von Bibliotheken widerspricht dem Konzept des mobilen Codes darin, dass eine einzelne Verbindung mit dem Sender nicht ausreicht und eventuell mehrere
Verbindungen aufgenommen werden mussen. Die Nachbestellung erhoht dadurch zudem
die Laufzeit des mobilen Codes. Bei Aktualisierung der Bibliotheken reicht aber auch hier
die A nderung an der zentralen Stelle.
Im Falle des Multimediamediators habe ich mich fur das sofortige Mitschicken der Bibliotheken
entschieden. Vor folgendem Hintergrund erscheint mir das sinnvoll:
Ein Kunde spricht viele wechselnde Mediatoren an (und der Mediator wiederum verschiedene Datenquellen) und bekommt daher eventuell Antworten in sehr unterschiedlichen
Datenformaten, die jeweils andere Operatoren benotigen.
5.6 Erweiterbarkeit des Empfangersystems
33
Ein Mediator bekommt Anfragen von vielen verschiedenen Kunden und kann nicht sicherstellen, dass auf jedem von ihnen die Bibliotheken im Voraus vorhanden sind.
Ein Kunde loscht schon vorhandene Bibliotheken eventuell im Laufe der Zeit.
Ein Verteilen der Bibliotheken im Voraus ist wegen der Dynamik des Systems kaum moglich.
Da eine Nachbestellung zusatzliche Zeit in Anspruch nimmt, ist sie fur ein Anfragesystem auch
eher ungeeignet.
34
6 Sicherheitsrisiken durch mobilen Code
In einem dynamischen System mit vielen wechselnden Teilnehmern, deren Identitat unbekannt
ist, ist die Basis fur gegenseitiges Vertrauen gering. Jeder Teilnehmer bildet einen eigenen
Schutzbereich, den er durch geeignete Manahmen (z. B. benutzerbasierte Authentizierung
oder Firewalls) von der Umwelt abschirmen kann. Um die Funktionalitat von mobilem Code
nutzen zu konnen, muss ein Teilnehmer nichtvertrauenswurdigen Code in seinen Schutzbereich
hereinlassen. Auch wenn der Empfanger dem Sender des Codes vertraut, ist die ursprungliche
Herkunft des Codes oft unbekannt. Email-Viren, die Adressbucher kompromittieren, nutzen
dieses Vertrauen des Empfangers gegenuber dem Sender zur Verbreitung aus.
Als Prinzipale - also sicherheitsrelevante Individuen oder Programme - fur mobile Agenten
benennen Berkovits, Guttman und Swarup ([BGS98], Seite 121) den Codehersteller, den Sender,
das Programm innerhalb des Agenten, den Agenten selbst (Programm und Daten) und einen
oder mehrere Wirtsrechner. Dies lasst sich auf mobilen Code ubertragen, wobei der mobile
Code aber nur einen Wirtsrechner { den sogenannten "Kundenrechner\ { besucht. Die Person,
die hinter dem Kundenrechner steht und eigentlich die Sicherheitsforderungen stellt, ist der
oder die menschliche Besitzer(in) des Rechners. Der Codehersteller und Sender stimmen im
Szenario des Multimediamediators uberein; beides ist der Mediator. Im Modell von Berkovits
et al. produziert der Codehersteller auch die Daten des mobilen Agenten. Dies ist beim mobilen
Codes des Multimediamediator nicht der Fall: die Daten, die der mobile Code enthalt, werden
von den Datenquellen bereitgestellt. Fur das Multimediamediator-System betrachte ich daher
die folgenden Prinzipale:
den Mediator (als Codehersteller und Sender)
die Datenquellen (als Datenlieferanten)
den mobilen Code als Ganzes
den Programmcode innerhalb des mobilen Codes
die Daten innerhalb des mobilen Codes
der Kunde (der Begri "Kunde\ bezeichnet weiterhin den/die Besitzer(in), den Kundenrechner und die Ausfuhrungsumgebung als Gesamtheit)
Die folgenden Abschnitte sollen einen U berblick daruber geben, welche Prinizipale durch den
Einsatz von mobilem Code Opfer von Angrien werden konnen. Der Kunde kann vom Mediator
direkt angegrien werden; damit beschaftigt sich Abschnitt 6.4. Indirekt kann der Mediator (in
der Funktion als Codehersteller) den Kunden mittels des mobilen Codes angreifen; das ist das
Thema des Abschnitts 6.1. Die Daten des mobilen Codes konnen vom Mediator angegrien
werden (siehe Abschnitt 6.5). Der mobile Code ist wahrend der U bertragung zum Kunden Angrien Dritter ausgesetzt (siehe Abschnitt 6.6). Auf dem Kundenrechner kann mobiler Code
vom Kunden selbst und von anderen mobilen Codes angegrien werden; beide Falle behandelt Abschnitt 6.7. Zu den verschiedenen Angrien stelle ich Gegenmanahmen vor. Einige
dieser Manahmen bauen auf asymmetrischen Verschlusselungsverfahren zur Signierung oder
Geheimhaltung von Nachrichten auf. Die korrekte Verteilung der oentlichen Schlussel auf die
wechselnden Teilnehmer bleibt dabei weiterhin ein Problem, das von keinem der vorgestellten
Verfahren gelost wird, und daher in einem zusatzlichen Schritt im Voraus geregelt werden muss.
Abschnitt 6.8 (Seite 53) gibt eine U bersicht daruber, ob und wie die hier besprochenen Angrie
konkret mit der Programmiersprache Java verhindert werden konnen. Die genaue Umsetzung
wird in Abschnitt 9 (Seite 85) besprochen.
35
6.1 Angrie des mobilen Codes gegen den Kunden
Der/die Besitzer(in) des Kundenrechners mochte vor Angrien des mobilen Codes auf den
Kundenrechner geschutzt sein. Ousterhout et al. (siehe [OLW98], Seite 220) und Fong (siehe
[Fon98], Seite 10) identizieren als die drei groen Sicherheitsziele fur den Kundenrechner in
Zusammenhang mit mobilem Code:
die Vertraulichkeit der auf ihm vorhandenen Daten und Programme
die Integritat des Kundenrechners
die Verfugbarkeit des Kundenrechners
Der mobile Code soll also von jeglicher Form von Spionage, Daten- und Programmkorruption
und Ressourcendiebstahl abgehalten werden. In den folgenden drei Abschnitten 6.1.1 bis 6.1.3
wird zunachst diskutiert, uber welche Zugrie und Kommunikationskanale solche Angrie moglich sind. Fur mobilen Code sind bestimmte Daten oder Ressourcen auf dem Kundenrechner
bevorzugte Angrisziele. Diese besonderen Angrisziele werden exemplarisch fur den jeweiligen
Angristyp vorgestellt.
Mobiler Code kann durch bestimmtes Verhalten Angrie erleichtern oder auslosen. Die folgenden Verhaltensweisen mobiler Codes werden in den Abschnitten 6.1.4 bis 6.1.6 analysiert:
mehrere Codes konnen unerlaubterweise zusammenarbeiten und ein Komplott bilden
ein Code kann unter falscher Identitat auftreten
ein mobiler Code kann bosartigen Code aus dem Netz laden
In Tabelle 4 auf Seite 37 sind alle Angris- und Verhaltensformen noch einmal aufgelistet.
Abbildung 4 stellt die sieben verschiedenen Kommunikationskanale ((0) bis (6)) auf dem Kundenrechner dar, die mobiler Code fur die im Folgenden beschriebenen Angrie ausnutzen kann.
Welche Manahmen der Kunde ergreifen kann, um Angrie des mobilen Codes abzuwehren,
wird in Abschnitt 6.2 ab Seite 38 diskutiert.
Kunde
mobiler Code 1 Ausführungsumgebung
Pro (6)
Daten gramm mobiler Code 2
(5) (3)
(0)
Pro
Daten gramm (1)
Daten (z.B. Schlüssel)
und Programme
(2)
Außenwelt
Mediator
(4)
Ressourcen
(z.B. Speicher und Prozessor)
Abbildung 4: Angrie des Codes auf den Kunden
6.1.1 Spionage
Mobiler Code kann probieren, beliebige Daten des Kunden einzulesen. Dazu benotigt er Lesezugri auf diese Daten (Kommunikationskanal (0) in Abbildung 4). Im Gegensatz zu mobilen
Agenten kann der mobile Code Daten des Kunden nicht auf andere Wirtsrechner mitnehmen;
36
der mobile Code bleibt ausschlielich auf dem Kundenrechner. Wenn mobiler Code also die
Vertraulichkeit der Daten des Kunden angreift und geheime Daten ausspioniert, kann er daraus nur einen Nutzen ziehen, wenn er die Daten nach auen kommunizieren kann (siehe dazu
auch [OLW98], Seite 220-221). Er benotigt eine Verbindung zu einem anderen Rechner (Kommunikationskanal (2) in Abbildung 4).
Dieser andere Rechner kann inbesondere der Mediator sein; er ist der Sender des mobilen Codes
(das heit, der Kunde wird nicht unbedingt mitrauisch, wenn der Code versucht, eine Verbindung zu seinem Sender herzustellen). Durch die Hande des Mediators gehen alle Anfragen und
Antworten und die durch den Code ausspionierten Daten konnten ihm Vorteile verschaen.
Innerhalb des Multimediamediator-Systems sind die Entschlusselungsschlussel des Kunden fur
Spione von groem Interesse. Der Kunde benutzt die dazugehorigen Verschlusselungsschlussel
typischerweise uber einen langeren Zeitraum in mehreren Anfragen. Wenn der mobile Code
sie einem Angreifer zuganglich macht, kann dieser abgefangene Antworten entschlusseln. Die
reine Spionage ist ein Angri nach dem Modell des ehrlichen aber neugierigen Angreifers (siehe Abschnitt 3.1 auf Seite 8). Wenn der Code aber versucht, die Schutzmechanismen fur die
Entschlusselungsschlussel zu brechen oder eine Verbindung nach auen aufzubauen, kann das
dann schon als aktiver Angri nach dem Modell des bosartigen Angreifers gewertet werden.
6.1.2 Daten- und Programmkorruption
Ein System mit mobilem Code muss dafur sorgen, dass die Integritat der Programme und Daten auf dem Kundenrechner nicht verletzt wird. Mobiler Code konnte jedoch mit Schreibrecht
uber Kommunikationskanal (1) Daten und Programme andern (vgl. dazu [SBK01], Seite 149).
Im Falle des Multimediamediators sind insbesondere andere mobile Codes (uber Kommunikationskanal (3)) betroen. Ein bosartiger mobiler Code konnte den Programmcode anderer
mobiler Codes oder ihre Daten so verandern, dass sie falsche Ergebnisse berechnen. Er konnte
auch die Programmcodes verandern oder austauschen, so dass sie Angrie auf den Kundenrechner ausfuhren; Young und Yung (siehe [YY04], Seite 147) bezeichnen dies als Infektion\ der
Programmcodes. Wenn der Angreifer einfach nur eine Behinderung des Kunden" im Sinn hat,
konnte er versuchen, die Entschlusselungschlussel zu uberschreiben. Dann ist keine Entschlusselung (und damit keine Ausfuhrung) eines anderen mobilen Codes moglich, bis der Kunde die
Schlussel wiederhergestellt hat. Wenn der Kunde die Schlussel nicht wiederherstellen kann und
er sich neue besorgen muss, kann er alte oder in Zwischenzeit empfangene mobile Codes gar
nicht mehr entschlusseln.
Auch die Ausfuhrungsumgebung ist ein ideales Angrisziel, weil sie die Sicherheitseinstellungen und -uberprufungen auf dem Kundenrechner vornimmt. Wenn es einem bosartigen mobilen
Code gelingt, die Sicherheitseinstellungen zu verandern oder die Ausfuhrungsumgebung durch
ein Programm zu ersetzen, das keine Sicherheitsuberprufungen durchfuhrt, onet er damit
Moglichkeiten fur andere Angrie.
6.1.3 Ressourcendiebstahl
Die Verfugbarkeit der Ressourcen des Kundenrechners sollte durch mobilen Code nicht stark
eingeschrankt werden. Ein mobiler Code sollte die Ausfuhrung anderer Prozesse auf dem Rechner kaum beeinussen. Wenn mobiler Code ausgefuhrt wird, konnte er jedoch uber Kommunikationskanal (4) den Prozessor blockieren, allen verfugbaren Arbeitsspeicher belegen oder
auch langdauernde Eingabe- und Ausgabeoperationen durchfuhren. Dies ist fur den Kunden
besonders argerlich, wenn der mobile Code falsche Ergebnisse berechnet oder ohne die Zustimmung des Kunden im Auftrag anderer etwas berechnet und versucht, das Ergebnis an seine
Auftraggeber zu schicken.
37
Angri auf
Integritat
in Form von
Beispiel
Programm- und Loschen oder Verandern von Daten/Programmen
Datenkorruption
auf dem Kundenrechner; insbesondere Verandern
von anderen mobilen Codes oder der Ausfuhrungsumgebung
Vertraulichkeit Spionage
Auslesen und Weitergeben geheimer Informationen;
insbesondere des Schlussels zum Entschlusseln der
Antworten
Verfugbarkeit Ressourcendiebstahl rechenzeit- oder speicherplatzverschwendende Berechnungen; insbesondere mobiler Code, der eine
falsche oder keine Antwort berechnet
alle obigen
Komplott mehrerer obwohl einzelne Codes harmlos erscheinen, fuhCodes
ren sie bei einer Kooperation einen Angri durch;
Code1 liest bspw. den Entschlusselungsschlussel ein
und gibt ihn an Code2 weiter, der eine Netzverbindung aufbaut ! der Entschlusselungsschlussel wird
ausspioniert
alle obigen
Auftreten unter mobiler Code gibt sich als vertrauenswurdiges Profalscher Identitat
grammmodul aus, bspw. als Teil der Ausfuhrungsumgebung
alle obigen
Nachladen
von Code darf eine Netzverbindung aufbauen und ladt
schadlichem Code und startet anderen, schadlichen Code.
Tabelle 4: Angrie des mobilen Codes auf den Kundenrechner
6.1.4 Komplott mehrerer Codes
Bei einem System mit mobilem Code kann es vorkommen, dass sich mehrere mobile Codes zur
gleichen Zeit auf einem Kundenrechner benden und eventuell sogar gleichzeitig ausgefuhrt
werden. Zwar kann es sein, dass die einzelnen mobilen Codes harmlos aussehen; sie bekommen
daher vom Kundenrechner die Erlaubnis, eine Aktion auszufuhren. Wenn die mobilen Codes
die Moglichkeit haben zu kommunizieren (unidirektional uber Kommunikationskanal (3) beziehungsweise uber Kommunikationskanal (5) oder bidirektional uber beide Kanale), konnte
es aber zu Nebenwirkungen kommen, die beim Starten der Codes nicht abzusehen waren. Sie
konnten ein Komplott gegen den Kundenrechner bilden. Wenn einem mobilen Code Code1 beispielweise erlaubt wird, einen privaten Schlussel einzulesen, um eine Entschlusselung von Daten
durchzufuhren, und einem Code Code2 erlaubt wird, eine Netzverbindung aufzubauen, kann
Code1 den Schlussel an Code2 weitergeben, der ihn dann schlielich uber die Netzverbindung
an einen Angreifer schickt. Die Kommunikation wurde uber die Kommunikationskanale (0), (3)
und (2) laufen.
Es ist nicht einmal notwendig, dass beide Codes gleichzeitig laufen. Code1 konnte den Schlussel
auch einlesen (uber Kommunikationskanal (0)), in eine Datei schreiben (Kommunikationskanal
(1)), die Code2 bei einer spateren Ausfuhrung lesen kann. Dies ist ein Beispiel fur den Angri
aber auch die beiden anderen Angrie "Korruption\ und "Ressourcendiebstahl\
"kSpionage\;
onnen durch Komplotte von mobilen Codes ausgefuhrt
werden, ohne dass der Kunde es merkt.
Zwei Codes konnten beispielsweise in standigem Wechsel Methoden voneinander aufrufen und
so die Ressource Prozessor blockieren. Wenn ein Code Lese- und der andere Schreibrecht auf
einer Datei hat, konnen auerdem Daten des Dateisystems korrumpiert werden, indem Code1
die Datei einliest und verandert, an Code2 ubergibt und Code2 die Datei zuruckschreibt.
38
6.1.5 Auftreten unter falscher Identitat
Wenn es dem mobilen Code gelingt, den menschlichen Benutzer zu uberzeugen, dass hinter
ihm eine vertrauenswurdige Identitat steht, konnte er vertrauliche Daten ausspionieren (siehe
dazu [Fon98], Seite 11, und [KLO98], Seite 193, unter dem Begri masquerading). Der Code
konnte zum Beispiel vortauschen, dass er zur Ausfuhrungsumgebung gehort, indem er ein
Eingabefenster onet, und dann den Benutzer um erneute Eingabe eines Passworts bitten. Dazu
benotigt er uber Kommunikationskanal (4) Zugri auf die Ressource Bildschirm. Er konnte den
Benutzer mit einem Warnhinweis auch dazu bringen, Dateien oder Programme von Hand zu
loschen (das ware Korruption der Daten oder Programme) oder Programme unter einer hoheren
Prioritat zu starten (das kann zu Ressourcendiebstahl fuhren). Eine falsche Identitat konnte
ein mobiler Code auch annehmen, wenn er vortauscht, von einem Mediator zu kommen, dem
der Kunde vertraut.
6.1.6 Nachladen von schadlichem Code
Wenn mobilem Code erlaubt wird, eine Netzverbindung uber Kommunikationskanal (2) aufzubauen, und er sogar uber Kommunikationskanal (6) Daten empfangen darf, kann er uber diese
Verbindung auch zusatzlichen Code herunterladen (siehe dazu [YY04], Seite 140, unter dem
Begri malware loaders). Selbst wenn der erste Code fur sich genommen unschadlich ist, muss
er das im Zusammenspiel mit dem nachgeladenen Code nicht mehr sein. Wenn es dem ersten
Code gelingt, den nachgeladenen Code zu starten oder er den Benutzer dazu bringt den Code
zu starten, konnte der nachgeladene Code Angrie auf den Kundenrechner ausfuhren.
Young und Yung ([YY04]) schreiben dazu, dass der Sender des ersten Codes die Verantwortung
fur entstandene Schaden abstreiten konnte, da er selbst nur Code geschickt hat, der fur sich
allein genommen harmlos erscheint.
Der Kundenrechner kann nur automatisiert vor Angrien, wie sie in Abschnitt 6.1 geschildert
wurden, geschutzt werden, wenn der/die Besitzer(in) vorher darlegt, welche Sicherheitsforderungen an den mobilen Code gestellt werden. Die Kontrolle, ob mobiler Code die Sicherheitsforderungen einhalt, kann man generell in statische und dynamische U berprufungen einteilen.
Statische U berprufungen werden vor dem Start des Codes durchgefuhrt und sollen sicherstellen, dass die gepruften Sicherheitseigenschaften uber die ganze Laufzeit des Codes gultig sind.
Dynamische U berprufungen nden wahrend der Laufzeit des Codes statt und kontrollieren
bei jeder einzelnen Operation die Einhaltung der Sicherheitsforderungen. Mischformen sind
moglich und werden zum Beispiel auch von der virtuellen Java-Maschine praktiziert, die ich
in Abschnitt 7 auf Seite 56 kurz vorstelle. Statische U berprufungen bedeuten einen zeit- und
rechenintensiven Schritt vor Programmstart, haben aber keine negativen Auswirkungen auf die
Laufzeit nach dem Start. Dynamische U berprufungen verzogern nicht den Start des Programmes, verlangern jedoch die Laufzeit. Sie bergen auerdem das Problem, dass der Code eventuell
schon Operationen durchgefuhrt und Ressourcen zugewiesen bekommen hat, wenn er durch eine dynamische U berprufung abgebrochen wird; diese Operationen und Ressourcenzuweisungen
mussen eventuell wieder ruckgangig gemacht werden.
In der Literatur habe ich zwei Ansatze fur statische U berprufungen gefunden, die ich im Folgenden vorstellen mochte: "Authentizierung des Codeherstellers\ und "Programmuberprufung\.
Als Beispiel fur dynamische U berprufungen mochte ich die Methode "dynamische Zugrikontrolle\ anfuhren. Das Konzept des "Sandkastens\ kann auf statische und dynamische Weise
umgesetzt werden.
39
6.2.1 Dynamische Zugriskontrolle
Der Kundenrechner muss Zugrie des mobilen Codes auf seine Ressourcen kontrollieren, also zu
einem Zeitpunkt erlauben oder ablehnen konnen. Fong ([Fon98], Seite 13) beschreibt die Grundlage der Zugriskontrolle wie folgt: "In traditionellen Betriebssystemen werden die Ressourcen
eines Wirtsrechners als Objekte und Benutzerprozesse als Subjekte modelliert. Ein Subjekt
kann Operationen auf einem Objekt durchfuhren. Die Erlaubnis, eine bestimmte Operation
auf einem Objekt durchzufuhren, wird als Zugrisberechtigung bezeichnet. Sicherheitsregeln
werden als Zuweisungen von Berechtigungen an Subjekte ausgedruckt. Ein Schutzbereich ist
eine Sammlung von Zugrisrechten. Ein Benutzerprozess erhalt seine Zugrisrechte, indem er
einem Schutzbereich zugewiesen wird.\7 Fur die Umsetzung der Zugriskontrolle nennt Fong
zum Einen die Zugriskontroll-Liste, die zu jedem Objekt angibt, welches Subjekt es mit welchen Rechten benutzen darf, und zum Anderen Fahigkeiten, die Subjekten zugwiesen werden
und ihnen damit das Recht geben, auf das assoziierte Objekt zuzugreifen. Die Zugriskontrolle
ist insofern dynamisch, als dass zur Laufzeit eines Programms bei dem Versuch eines Subjekts,
auf ein Objekt zuzugreifen, gepruft wird, ob das Subjekt die Zugrisberechtigung besitzt. Eventuell kann sich auch die Sicherheitsregel zur Laufzeit andern. Auerdem konnen Subjekte zur
Laufzeit Schutzbereichen neu zugewiesen werden oder wieder aus ihnen entfernt werden. Fong
([Fon98], Seite 11) betont, dass Code nur ein Minimum an Berechtigungen zugewiesen werden
soll; im Idealfall sind das nur die Berechtigungen, die der Code fur seine Ausfuhrung benotigt.
Die Zuweisung kann von mehreren Faktoren abhangig gemacht werden. Beispielsweise kann
gepruft werden, ob und von wem der gerade ausgefuhrte Code signiert wurde. Der Kunde muss
sich beim Aufstellen der Sicherheitsregel dann bewusst sein, welche Bedeutung die Signatur
unter dem Code hat. Genauso konnen auch zeit-, kontext-, vergangenheits-, datenabhangige
Bedingungen in der Zugrisregel angegeben werden (vgl. dazu auch [Den82], Seite 194). Die
Angabe einer zeitabhangigen Bedingung kann dazu dienen, die Ausfuhrung der mobilen Codes von der Ausfuhrung sicherheitskritischer oder rechenintensiver Aufgaben zu trennen. Eine
kontextabhangige Bedingung kann etwa sein, welche anderen mobilen Codes derzeit ausgefuhrt
werden; durch eine solche Bedingung kann verhindert werden, dass zwei potenziell gefahrliche
Codes zusammen ausgefuhrt werden und ein Komplott bilden. Ebenso kann die Ausfuhrung des
Codes davon abhangig gemacht werden, welche Aktionen schon fruher ausgefuhrt wurden und
wieviel Vorwissen der mobile Code damit vielleicht schon hat. Eine Bedingung in Abhangigkeit
von Daten hat zum Beispiel dann Sinn, wenn der Code den Besitz von Daten nachweisen muss,
bevor er andere Aktionen ausfuhren darf.
Dynamische Zugriskontrolle ist nur dann wirklich sinnvoll, wenn Code zur Laufzeit Berechtigungen in Abhangigkeit von den obengenannten Faktoren zugewiesen werden sollen. Ob der
mobile Code des Multimediamediators dies benotigt, hangt vom gewahlten Entwurf ab. Wenn
mobiler Code selbst den Entschlusselungsschlussel einlesen oder seine Antwort in eine Datei
schreiben soll, benotigt er dafur dynamische Berechtigungen. Beispielweise muss jeder Code
einen anderen Schlussel einlesen oder seine Daten in eine andere Datei schreiben. Wenn der
mobile Code jedoch nur unkritische Operationen durchfuhrt und er im Grunde keine dynamischen Berechtigungen braucht (also beispielsweise die Entschlusselung vom Kundenmodul
durchgefuhrt wird), ist eine dynamische Zugriskontrolle fur den mobilen Code gar nicht notwendig.
7 Ubersetzung

aus dem Englischen; Originaltext: "In traditional operating systems, resources of the host are
modeled as objects, while user processes are modeled
as subjects. A subject can perform operations on an
object. The permission to perform a certain operation on an object is said to be an access right. Security
policies are expressed as an assignment of rights to subjects. A protection domain is a collection of access
rights. A user process acquires its access rights by being associated to a protection domain.\
40
6.2.2 Authentizierung des Codeherstellers
Technische Schutzmanahmen, die den mobilen Code auf dem Kundenrechner kontrollieren,
werden selten angewandt. Oftmals wird von Webseiten heruntergeladener oder per Email empfangener Code im Vertrauen auf den Sender ausgefuhrt. Ein Schritt zu einer groeren Vertrauensbasis ist es, den Hersteller des Codes zu authentizieren. Wenn der Hersteller seinen Code
signiert, konnen allen Empfanger die Herkunft des Codes feststellen. Wenn der Empfanger eine
Kette von vertrauenswurdigen Zertikaten aufbauen kann, die die Identitat des Codeherstellers bestatigt, hat der Empfanger fur sich eine Vertrauensbasis fur die Ausfuhrung des Codes
geschaen. Der Empfanger hat aber keine Sicherheit und keinen Beweis, dass der Code unschadlich ist. David M. Chess [Che98] beschreibt auerdem, dass die Signatur unter mobilem
Code verschiedene Bedeutungen fur den Empfanger haben kann. Sie kann beispielsweise belegen, dass der Kunde fur eine Leistung bezahlt hat, dass der Code gepruft und ungefahrlich ist,
oder dass der erste Sender bescheinigt, dass sich der mobile Code in einem korrekten Startzustand bendet. Der Empfanger muss sich der jeweiligen Bedeutung einer Signatur bewut sein.
Es muss sichergestellt werden, dass die Signatur den Codehersteller reprasentiert.
Wenn der Kunde eine Sicherheitsgarantie haben will, dass der Code ihn nicht angreift, muss
der Codehersteller vertraglich die Unbedenklichkeit seines Codes bestatigen (siehe dazu [Yee99],
Seite 262). Solange im Multimediamediator-System nur ein Mediator angefragt wird und keine
Weiterleitung von Teilanfragen stattndet, ist dieser eine Mediator auch der einzige Hersteller des mobilen Codes. Der Mediator kann den Code signieren und dem Kunden vertraglich
zusichern, dass der Code unschadlich ist. Wenn der Kunde auf sicherem Weg den oentlichen
Schlussel des Mediators erhalt, kann er die Signatur unter dem Code prufen und hat damit
den Codehersteller authentiziert. Bei entsprechender rechtlicher Grundlage fur digitale Signaturen und einem Vertrag zwischen Kunde und Mediator kann der Kunde den Mediator fur
entstandene Schaden verantwortlich machen (zumindest solange er nachweisen kann, dass sie
durch mobilen Code des Mediators entstanden sind). Stellvertretend kann eine Zertizierungsstelle diese Position ubernehmen und Zertikate und Vertrage fur Programme ausstellen. Der
Kunde fuhrt das Programm aus, wenn er das Zertikat als echt anerkennt und dem Vertrag
zustimmt.
Bei mobilen Agenten, die mehrere Wirtsrechner besuchen, kann nur ihr statischer Teil vom
Hersteller signiert werden. Peine ([Pei02], Seite 36) schreibt: "Ein mobiler Agent besteht nicht
nur aus Daten sondern auch aus Code, der auf den Daten arbeitet
und sie eventuell wahrend
seiner Ausfuhrung verandert.\8 Dem mochte ich hinzufugen, dass als ein Sonderfall auch der
Code { in einer Art verteilter Programmierung { nicht statisch sein muss, sondern dass Wirte
dem Agenten neue Funktionalitaten hinzufugen konnen und der Code damit mehrere Hersteller
haben kann, die jeweils nur fur den durch sie erstellen Teilcode burgen konnen. Daher konnen
sowohl alle Daten als auch aller Code, die auf den Wirtsrechnern verandert werden, nicht in
die Signatur einieen. Dynamische Daten (und dynamischer Code) des Agenten konnen nur
vom jeweils letzten Wirt, der eine A nderung daran vorgenommen hat, signiert werden. Der
neue Wirt fuhrt dann den Agenten im Vertrauen zu diesem letzten Wirt aus. Da der letzte
Wirt aber eventuell nicht A nderungen anderer Wirte an anderen Teilen des Codes auf ihre
Unbedenklichkeit uberpruft hat, vertraut der neue Wirt auch implizit den vorigen Wirten, die
A nderungen vorgenommen haben. Dieses Verfahren wenden Gray et al. (siehe [GKCR98], Seite 162) in ihrem Agentensystem an. Jeder Wirt musste zur U berprufung der Signaturen die
oentlichen Schlussel aller dieser Wirte auf sicherem Wege erhalten. Das ist in der Regel aber
zu umstandlich und unubersichtlich. Der letzte Wirt muss daher als Treuhander auftreten und
fur die A nderungen der vorigen Wirte burgen.
Dieses Verfahren verkompliziert sich noch, wenn Signaturen fur ungultig erklart und widerrufen werden konnen. Wenn alle Wirte alte Signaturen entfernen und ihre eigene treuhanderisch
8 Ubersetzung

aus dem Englischen; Originaltext: "A mobile agent consists not only of data but also of code,
which operates on and potentially changes the data
during the agent's operation\
41
unter den Code setzen, kann man nicht mehr feststellen ob die Signatur eines vorigen Wirtes zuruckgezogen wurde. A hnliche Probleme treten fur mobilen Code auf, wenn man eine Hierarchie
von Mediatoren betrachtet. Wenn der Mediator Teilanfragen an andere Mediatoren delegiert,
sind diese Mediatoren Hersteller von Teilcode. Welche Folgen es fur die Authentizierung des
Codeherstellers durch den Kunden hat, lege ich in Abschnitt 10 auf Seite 96 dar.
Fur den Multimediamediator soll Code aber nicht nur auf Vertrauens- oder Vertragsbasis ausgefuhrt werden, sondern der Kundenrechner auch technisch abgesichert werden. Signaturen
spielen aber dennoch eine Rolle; mit ihnen kann man prufen, ob die Antwort unverandert zwischen Mediator und Kunde ubertragen wurde. Darauf gehe ich in Abschnitt 6.6 (Seite 47) noch
kurz ein.
6.2.3 Programmuberprufung
Eine Methode, mit der sich der Kunde davon uberzeugen kann, dass ein mobiler Code unschadlich ist, ist die U berprufung des Codes vor der Ausfuhrung. Die fur den Kunden aufwandigste
Methode, die vom menschlichen Benutzer die meiste Interaktion verlangt, ist es, sich den Quellcode des Programms anzuschauen. Es gibt aber auch eine Methode, die den Benutzer entlastet
und die Prufung automatisch vornimmt: beweismitfuhrender Code (engl. proof carrying code,
PCC). Das Konzept des beweismitfuhrenden Codes wurde von Necula und Lee entwickelt (vgl.
[Lee97, NL98]). Teilnehmer eines PCC-Systems sind der Kunde, der Codehersteller und der Beweishersteller. Der mobile Code wird zusammen mit einem Beweis, der die Unbedenklichkeit
des Codes bescheinigt, vom Codehersteller an den Kunden ausgeliefert. Nach einer Prufung
des Beweises wird der Code ohne weitere Laufzeitkontrollen ausgefuhrt.
Fur ein PCC-System benotigt man:
eine Spezikationssprache fur Sicherheitsregeln,
eine Logik, die Programme und Spezikation verknupft, indem sie die Bedingungen darstellt, unter denen ein Code sicher ausgefuhrt werden kann,
eine Sprache, in der die Beweise dargestellt werden, und
einen Algorithmus, um Beweise zu uberprufen.
Der Codehersteller fugt per Hand oder mittels eines entsprechenden Compilers zusatzliche Eintrage in seinen Code ein, anhand derer hinterher der Beweis aufgebaut wird. Der Kunde stellt
zunachst Sicherheitsregeln fur sein System auf, in denen er angibt, welche Ressourcen mobiler
Code wie lange oder wie oft benutzen darf. Nach Erhalt des Codes pruft ein Programm { der
Verikationsbedingungen-Generator (VCGen) { auf dem Kundenrechner einfache Sicherheitseigenschaften des Codes (zum Beispiel Ziele der Sprunge im Programmcode). Falls VCGen eine
Anweisung im Code entdeckt, die eventuell die Sicherheitsregeln verletzt, generiert das Programm ein Pradikat, das angibt, unter welchen Bedingungen die Anweisung sicher ausgefuhrt
werden kann. Dieses Pradikat wird von Necula und Lee Verikationsbedingung genannt. Aus
allen Verikationsbedingungen zusammen wird ein globales Sicherheitspradikat fur den Code
erstellt und vom Kunden an den Beweishersteller geschickt.
Der Beweishersteller versucht das Sicherheitspradikat zu beweisen und schickt im Erfolgsfall
den Beweis an den Kunden. Der Beweishersteller kann identisch mit dem Codehersteller sein
und dann sowohl das Sicherheitspradikat als auch den Beweis selbst erstellen und beides direkt
mit dem Code an den Kunden schicken.
Auf dem Kundenrechner uberpruft ein zweites Programm { der Beweisprufer{, ob jeder Deduktionsschritt im Beweis den Sicherheitsregeln gehorcht. Der Kunde muss aus dem Code
danach noch ein vertrauenswurdiges Sicherheitspradikat ableiten. Der Beweisprufer pruft, ob
der Beweis das richtige Sicherheitspradikat beweist, und dem Kunden kein falsches Sicherheitspradikat mit dem Beweis (beziehungsweise der Beweis fur ein falsches Sicherheitspradikat)
42
Code
hersteller
1. Sicherheitsprädikat SP2 ableiten annotierter
Code
Kunde
Beweis
hersteller
2. Beweis überprüfen
3. SP1 ==SP 2 ?
formaler
Beweis
für SP 1
4. Code ausführen
Abbildung 5: Beweismitfuhrender Code
untergeschoben wurde. Falls alle Schritte durchlaufen wurden, wird der Code nun installiert
und ausgefuhrt.
Mit dem Ansatz des beweismitfuhrenden Codes sind nur statische a-priori U berprufungen moglich; man kann dem Code zur Laufzeit beispielsweise keine zusatzlichen Berechtigungen erteilen.
Peine ([Pei02], Seite 40) bemangelt, dass die Komplexitat eines Beweises von der Komplexitat
des Programmes und der Sicherheitsregeln abhangt. Auerdem kann es schwierig oder sogar
unmoglich sein Beweise uberhaupt zu nden { geschweige denn diese automatisch generieren
zu lassen. Necula und Lee weisen darauf hin, dass die zeitaufwandige Arbeit der Beweiserstellung zumindest nicht den Kunden belastet sondern vom Beweishersteller durchgefuhrt wird. Sie
haben beobachtet, dass die Beweisgroe sich in der Regel linear zur Programmgroe verhalt;
nur in Ausnahmen kommt es zu einer exponentiellen Beweisaufblahung (vgl. [NL98], Seite 88).
Einen Ansatz zur Verkleinerung der Beweise (beziehungsweise zur Verringerung der zu ubertragenden Beweisteile) stelle ich an geeigneter Stelle in Abschnitt 6.7.4 auf Seite 52 vor. Fong
([Fon98], Seite 30) weist des Weiteren auf Ansatze mit zertizierenden U bersetzern hin, bei
denen mobiler Code nicht von einem Beweis sondern nur von einem Zertikat begleitet wird,
dass Sicherheitseigenschaften bescheinigt.
Ein Beispiel-PCC-System von Necula und Lee (Onlinedemo unter [Nec02]) in Java wandelt
den Java-Binarcode in x86-Maschinensprache um und fugt dem Maschinenprogramm gleichzeitig Annotationen zur Ableitung des Sicherheitspradikats und des Beweises hinzu. Die Beweisherstellung erfolgt fur sehr mathematischen Code { beispielsweise Sortier-Algorithmen
{ automatisch. Auf der Kundenseite wird das Maschinenprogramm uber das Java Native
Interface (JNI) eingebunden; der Code unterliegt damit nicht den standardmaigen JavaSicherheitsuberprufungen (Naheres dazu in Abschnitt 7 auf Seite 56).
Leider gibt es nur wenige praktische Beispiele fur beweismitfuhrenden Code und kommerzielle
Systeme sind gar nicht vorhanden. Beweise fur Programme mit viel Benutzerinteraktion oder
Netzkommunikation konnen derzeit kaum automatisch erstellt werden. Auerdem kann es vorkommen, dass Beweise je nach Plattform unterschiedlich ausfallen mussen. Beispielsweise kann
ein Beweis, der die Integritat des Speichers belegen will, von der Speicherwortlange der Plattform abhangig sein. Es fehlen also noch Weiterentwicklungen im Bereich der automatischen
Beweiserstellung, bevor ein kommerzielles System Erfolg hatte, denn nur wenige Programmierer(innen) waren meiner Ansicht nach bereit (oder hatten aus wirtschaftlicher Sicht die Zeit),
ihre Programme von Hand zu beweisen. Dennoch ist beweismitfuhrender Code der einzige mir
bekannte Ansatz, der nur codeinharente Eigenschaften betrachtet und auerliche Gesichtspunkte wie Codehersteller in Form von signierten Programmen nicht zu berucksichtigen braucht.
Aber auch beweismitfuhrender Code kommt nicht ohne ein Programmmodul auf Kundenseite
aus: der Kunde braucht ein Programm zu Erstellung der Sicherheitsregel und zur Beweisuberprufung. Auerdem muss der Code in prozessorlesbarem Klartext verarbeitet werden, um das
43
6.3 Angrie des Mediators gegen den Kunden
Sicherheitspradikat abzuleiten; die Nachteile davon werden in Abschnitt 6.7 dargestellt.
Auch der Multimediamediator kann mit beweismitfuhrendem Code umgesetzt werden. Allerdings wird der Code, der an den Kunden gesendet wird, zur Laufzeit durch den Mediator
erstellt. Der Mediator muss daher auch den Beweis zur Laufzeit erstellen und kann diese zeitaufwandige Arbeit nicht im Vorhinhein durchfuhren. Da jeder Algebrabaum sich aber aus
modularen Operatoren zusammensetzt, kann der Mediator schon Beweise und Sicherheitspradikate fur die Operatoren bereithalten. Nach der Erstellung eines Algebrabaums muss er dann
nur noch einen Beweis fur die sichere\ Zusammensetzung der Operatoren erstellen. Wichtig
ist hierbei, dass die Sprache, in"der die Beweise verfasst sind, solche Zusammensetzungen von
Beweisen zulasst.
Einen weiteren Anwendungsbereich fur beweismitfuhrenden Code innerhalb des Multimediamediator-Systems werde ich in Abschnitt 6.4.2 vorstellen.
6.2.4 Sandkasten
Ein Sandkasten fur mobilen Code ist eine Umgebung, in der dem Code nur eingeschrankte Aktionen auf dem Kundenrechner erlaubt sind. Die Menge der erlaubten Aktionen ist festgelegt
und wird nicht verandert. Ein Sandkasten kann mit dynamischen Sicherheitsuberprufungen umgesetzt werden, indem vor Ausfuhrung des Codes eine Sicherheitsregel deniert wird, die nicht
mehr geandert wird. Auerdem durfen Subjekte keinen weiteren Schutzbereichen zugewiesen
werden. Sie bleiben in dem Schutzbereich, in dem sie sich beim Start des Programms befanden.
Zur Laufzeit des Codes wird gepruft, ob die Sicherheitsregel eine Operation zulasst oder nicht.
Ein Sandkasten kann aber auch statisch die Einhaltung der Sicherheitsanforderungen umsetzen,
indem eine Programmiersprache verwendet wird, die die unerwunschten Operationen gar nicht
enthalt. Volpano und Smith (siehe [VS98]) fordern fur den Entwurf einer sicheren Sprache, dass
zuerst die Schutzziele deniert und danach anhand dieser Ziele die Sprache entworfen werden
sollte. Dem mobilen Code kann auch eine nur eingeschrankte, ungefahrliche Schnittstelle einer
Laufzeitumgebung zur Verfugung gestellt werden.
In einem Entwurf des Multimediamediators, der dem mobilen Code keine Berechtigungen oder
nur eine feste Menge an sicherheitskritischen Operationen zugesteht, ist ein statischer Sandkasten bezuglich der Laufzeit die ezienteste Losung, da zur Laufzeit keine Berechtigungen
uberpruft werden mussen.
6.3 Angrie des Mediators gegen den Kunden
Der Mediator hat im Multimediamediator-System eine zentrale Position. Er hat Zugri auf die
Gesamtanfrage und die Eigenschaftsnachweise, erstellt den Programmcode des mobilen Codes
und erhalt die Teilantworten von den Datenquellen (siehe Abbildung 6). Diese Position kann
Kunde
k pub
r
Gesamtanfrage
mobiler Code
Pro
gramm
Daten
Quelle Mediator
Teilanfrage
Abbildung 6: Zentrale Position des Mediators
44
er ausnutzen, um dem Kunden zu schaden. Im Folgenden mochte ich diskutieren, auf welche
Art der Mediator die Korrektheit der Antwort, die Verfugbarkeit des Kundenrechners und die
informationelle Selbstbestimmung des Kunden angreifen kann. Die moglichen Angrie sind in
Tabelle 5 noch einmal aufgefuhrt. Gegenmanahmen, die der Kunde ergreifen kann, werden in
Abschnitt 6.4 behandelt.
6.3.1 Korrektheit der Antwort
Der Hauptangrispunkt ist fur den Multimediamediator die Antwort, die er an den Kunden
sendet. Da der Mediator vollkommene Kontrolle uber die Erstellung der Antwort hat, kann
er versuchen, sie als bosartiger Angreifer aktiv zu falschen. Er kann vor allem Operatoren
oder Teilantworten vertauschen oder die Aufspaltung der Gesamtanfrage falsch durchfuhren
und in Folge davon falsche Teilanfragen stellen. Aber auch mit der Auswahl der Datenquellen
kann der Mediator die Antwort beeinussen. Wenn der Mediator einige Quellen bevorzugt
auswahlt, fallt die Antwort dementsprechend aus. Der Mediator konnte sogar unabhangige
Quellen durch unzahlige ngierte Anfragen ausschalten, so dass nur noch von ihm gewunschte
Quellen erreichbar sind.
Der Mediator kann auf eine Anfrage auerdem eine Antwort schicken, die er bereits fruher zu
einer anderen Anfrage des Kunden erstellt hat. Dieses Wiedereinspielen fallt dem Mediator
besonders leicht, weil die in der Anfrage enthaltenen Schlussel kennt. Er kann eine Antwort
wiedereinspielen, die mit denselben Schlusseln verschlusselt wurde.
6.3.2 Informationelle Selbstbestimmung
Durch die Hande des Mediators gehen mit jeder Anfrage Eigenschaftsnachweise eines Kunden.
Da die Nachweise Eigenschaften des Kunden mit einem Schlussel verknupfen, kann der Mediator
(wie im U brigen auch die Datenquellen) Prole zu den Schlusseln bilden (vgl. dazu [ABFK03],
Seite 379), die die Eigenschaften zusammenfuhren, die zu einem Schlussel gehoren. Als ehrlicher
aber neugieriger Angreifer konnte der Mediator versuchen, aus der Anfrage des Kunden oder
den Teilantworten der Datenquellen Informationen abzuleiten (vgl. dazu [ABFK03], Seite 374f)
und in die Prole aufzunehmen. Er konnte damit zum Beispiel eine Menge von Eigenschaften
mit bestimmten Themeninteressen verbinden oder im schlimmsten Fall einzelne Person identizieren. Der Mediator kann die Eigenschaftsnachweise auch an Dritte verkaufen, die zum
Beispiel Prole sammeln oder versuchen, die Nachweise zu falschen.
Wenn bei einer Anfrage ein Schlussel verwendet wird, der zu einem Prol gehort, konnte der
Mediator die Auswahl der Datenquellen von diesem Prol abhangig machen und damit wiederum die Korrektheit der Antwort angreifen.
6.3.3 Verfugbarkeit des Kundenrechners
Der Mediator kann dem Kunden auch eine ubertrieben lange Antwort schicken und dadurch
die Verfugbarkeit des Kundenrechners einschranken. Das Gleiche gilt, wenn der Mediator den
Kunden lange auf die Antwort warten lasst.
Angri auf
in Form von
Korrektheit der Antwort
Falschen der Antwort
Korrektheit der Antwort
Wiedereinspielen eines mobilen Codes
Verfugbarkeit des Kundenrechners
Schicken einer langen Antwort
Informationelle Selbstbestimmung des Kunden Sammeln personenbezogener Daten
Informationelle Selbstbestimmung des Kunden Veruntreuen von Eigenschaftsnachweisen
Tabelle 5: Angrie des Mediators auf den Kunden
6.4 Schutz des Kunden vor Angrien des Mediators
45
6.4 Schutz des Kunden vor Angrien des Mediators
Die in Abschnitt 6.3 dargestellten Angrie, sind in einem Mediatorsystem ohne mobilen Code
auch moglich. Insbesondere die Angrie auf die Verfugbarkeit es Kundenrechners (Schicken
langer Antworten und Wartenlassen des Kunden) sind sehr allgemeine Probleme; der Kunde
konnte als einfaches Gegenmittel seine Anfrage abbrechen und den Mediator wechseln.
Zu dem Punkt der informationellen Selbstbestimmung wird in Abschnitt 6.4.1 kurz eine Gegenmanahme angegeben. Da der mobile Code allein fur die U berprufung der Korrektheit der
Antwort eine Erweiterung bringt, mochte ich nur diesen Punkt in Abschnitt 6.4.2 ausfuhrlicher
erlautern.
6.4.1 Informationelle Selbstbestimmung des Kunden
Um die Prolbildung fur den Mediator zu erschweren, sehen [ABFK03] (Seite 379) den Kunden
als verpichtet an, jede seiner Eigenschaften in mehreren Eigenschaftsnachweisen mit verschiedenen Schlussel bereitzuhalten. Der Kunde konnte dann fur jede Anfrage Eigenschaftsnachweise
einen bisher unbenutzten Schlussel benutzen, so dass zumindest nicht mehr der Schlussel als
Verbindungselement zwischen verschiedenen Anfragen zu verwenden ist.
6.4.2 Korrektheit der Antwort
Der Kunde kann Falschungen der Antwort nur schwer feststellen. Der Mediator soll ja gerade
als Mittler zwischen Kunde und Datenquellen auftreten, so dass der Kunde die Datenquellen
nicht kennen und selbst keine Anfragen ein einzelne Quellen stellen muss.
Der Kunde kann groeres Vertrauen in die Antwort eines Mediators mit einem guten Ruf haben. Der Kunde kann Falschungen eventuell entdecken, wenn er dieselbe Anfrage an mehrere
unabhangige Mediatoren sendet. Die Sicherheit, dass die Antwort semantisch und syntaktisch
korrekt ist, hat er aber mit beiden Methoden nicht.
Um zumindest die syntaktische Korrektheit der Antwort nachprufen zu konnen, bietet sich
beweismitfuhrender Code an, der in Abschnitt 6.2.3 auf Seite 41 vorgestellt wurde. Der Mediator muss jetzt aber keinen Beweis liefern, dass der Code gewisse Sicherheitsregeln einhalt,
sondern er legt mit dem Beweis dar, dass der gesendete mobile Code (beziehungsweise der darin
enthaltenen Algebrabaum) eine Antwort auf die Anfrage ist. Der Mediator muss fur die Zusammensetzung der Operatoren im Algebrabaum nachweisen, dass sie eine syntaktisch korrekte
Aufspaltung der Anfrage darstellt { etwa indem er einen Beweis liefert, der den Algebrabaum
wieder auf die ursprungliche Anfrage zuruckfuhrt. Der Kunde muss prufen, ob dieser Beweis
korrekt ist (also nur aus korrekten Schritten besteht und auch die richtige Anfrage beweist)
und sich danach vergewissern, dass der Beweis auch den Algebrabaum als Grundlage benutzt,
der in der Antwort enthalten ist. Damit kann sich der Kunde vor Verandern oder Vertauschen
von Operatoren und auch vor Wiedereinspielen von mobilen Codes schutzen.
Wenn der Kunde nachprufen will, ob die Teilantworten in den Blattern an der richtigen Stelle eingefugt wurden, muss es eine Moglichkeit geben, zu beweisen, dass eine Teilantwort das
Ergebnis der entsprechenden Teilanfrage an eine Datenquelle ist. Als einfaches Mittel konnte der Mediator den Text der Teilanfragen in die Blatter des Antwortalgebrabaums schreiben.
Wenn die Datenquelle unabhangig vom Mediator ist und nicht mit ihm gemeinsam den Kunden
angreifen will, kann sie in ihre verschlusselte Teilantwort den Teilanfragetext mit einbringen.
Die Ausfuhrungsumgebung des mobilen Codes auf dem Kundenrechner kann dann den Teilanfragetext im Blatt des Algebrabaums mit dem Teilanfragetext in der Teilantwort vergleichen.
Eventuell will der Mediator die Information uber die Teilanfrage dem Kunden gar nicht liefern;
er musste dann alternativ in das Blatt des Antwortalgebrabaums eine Kennzier schreiben, die
die Datenquelle in ihre Teilantwort einfugt. Ob die Teilanfragen jedoch korrekt gestellt wurden
und die Teilantworten inhaltlich korrekt sind, kann der Kunde auch mit dieser Methode nicht
nachprufen.
46
6.5 Schutz der Teilantworten auf dem Mediator
Der Mediator ist der Hersteller des Programmcodes des mobilen Codes. Eine Veranderung des
Programmcodes kann daher als Angri des Mediators auf den Kunden gewertet werden (siehe
Abschnitt 6.3.1, Seite 44). Die Daten des mobilen Codes werden jedoch in Form von Teilantworten von den Datenquellen geliefert. Der Mediator konnte daher Interesse daran haben, die
Teilantworten anzugreifen. Diese Gefahr ergibt sich nicht durch den Einsatz von mobilem Code,
sondern tritt allgemein bei Mediation auf. Da mit dem mobilen Code jedoch die Teilantworten
an den Kunden ubertragen werden, ergeben sich fur den Kunden Prufmoglichkeiten, die in
Abschnitt 6.5.2 besprochen werden. Im Folgenden mochte ich Angrie und Gegenmanahmen
sofort zusammen betrachten.
6.5.1 Klartextangri auf den privaten Schlussel
Wenn der Mediator selbst die Berechtigung hat, die Teilantwort auf eine Teilanfrage zu erhalten,
kann er die Teilanfrage einmal mit den Eigenschaftsnachweisen des Kunden und ein zweites
Mal mit seinen Eigenschaftsnachweisen stellen. Er kann so in den Besitz des Klartextes zu
der mit den Schlusseln des Kunden verschlusselten Teilantwort gelangen. Der Mediator kann
damit versuchen, den privaten Schlussel des Kunden zu ermitteln. Diesen Angri beschreiben
[ABFK03] auf Seite 374. Sie geben den Einsatz eines hybriden Verschlusselungsverfahrens und
das Einbringen von Zufallstext in die Teilantwort an, um diesem Angri vorzubeugen.
6.5.2 Verandern der Teilantwort
Unter der Annahme, dass die Verschlusselung der Teilantworten vom Mediator nicht zu brechen
ist, bleibt ihm es moglich, Teile der verschlusselten Teilantwort auf gut Gluck zu verandern. Der
Kunde erhalt jede Teilantwort vollstandig innerhalb des mobilen Codes. Er konnte eine Teilantwort auf solche Veranderungen hin uberprufen, wenn die Datenquelle vor der Verschlusselung
eine Prufsumme der Teilantwort berechnet und sie zusammen mit der Teilantwort verschlusselt.
Nach der Entschlusselung der Teilantwort auf dem Kundenrechner kann der Kunde erneut eine
Prufsumme der Teilantwort berechnen und sie mit der mitgeschickten vergleichen.
Wenn jede Datenquelle nicht nur eine Prufsumme der Teilantwort berechnet, sondern die
Teilantwort signiert, wie es [Yee99] (Seite 266) fur mobile Agenten vorschlagt, konnte im
Zweifelsfalle eine Zuordnung einer Teilantwort zu einer Datenquelle durchgefuhrt werden. Die
Teilantworten mussten signiert werden, bevor sie verschlusselt werden, damit der Mediator die
Signatur nicht abtrennen und eine neue anhangen kann. Im allgemeinen Fall mochte die Datenquelle anonym bleiben. Der Kunde konnte daher den Signaturprufschlussel auf eine Weise
erhalten, die die Anonymitat der Datenquelle wahrt. Dies konnte wie bei den Eigenschaftsnachweisen des Kunden durch eine Trennung von Identitatsnachweis und Prufschlusselnachweis der
Datenquellen geschehen. Mit der Teilantwort erhalt der Kunde dann nur den Prufschlusselnachweis, um die Integritat der Teilantwort prufen zu konnen. Falls er jedoch entdeckt, dass die
Signatur unter einer Teilantwort nicht stimmt, und er vermutet, dass der Mediator die Teilantwort verandert hat, konnte er rechtliche Schritte einleiten. Die Datenquelle konnte identiziert
werden und die korrekte Teilantwort vorlegen9 .
6.5.3 Informationen aus der verschlusselten Antwort
Wenn der Mediator die Teilantworten nicht aktiv angreifen will, hat er immer noch die Moglichkeit, aus den verschlusselten Teilantworten Informationen abzuleiten.
9 Mit diesem Verfahren k
onnte auch eine Qualitatssicherung der Antworten erreicht werden. Wenn der Kunde an
der Qualitat einer Teilantwort zweifelt, konnte er eine Identizierung der Datenquelle und eine Untersuchung
veranlassen.
47

6.6 Schutz des mobilen Codes bei der Ubertragung
Bei einem Verschlusselungsverfahren, in dem gleiche Teilantworten immer zum selben Schlusseltext verschlusselt werden, konnte der Mediator feststellen, welche Teilanfragen dieselben
Teilantworten liefern. Mit einem hybriden Verschlusselungsverfahren ist dies nicht mehr moglich. Wenn namlich die Datenquelle fur jede Antwort, die sie erstellt, einen neuen Sitzungsschlussel produziert, werden gleiche Teilantworten zu unterschiedlichen Schlusseltexten verschlusselt.
Allein aus der Groe der Teil- oder Gesamtantwort konnte der Mediator Schlusse ziehen (siehe
dazu [ABFK03], Seite 374f). Mit dem Einsatz des mobilen Codes kann es diesbezuglich ein Vorteil sein, dass der Mediator die Gesamtanfrage vollstandig aufspaltet. Wie in Abschnitt 5.1.1
(Seite 29) schon angesprochen, hat der Mediator zwar die Moglichkeit, rationellere Teilanfragen zu stellen. Dadurch wird der Algebrabaum kleiner und es gibt weniger Teilantworten;
das wirkt sich dann positiv auf die zu ubertragende Datenmenge und die Berechnungszeit auf
dem Kundenrechner aus. Jedoch verringert sich die Groe der Teilantworten, da sie weniger
uberussige Daten enthalten: Daten, die in der Gesamtantwort nicht benotigt werden, werden
durch die komplexere Teilanfrage schon von der Datenquelle aussortiert. Das Verhaltnis von
relevanten zu uberussigen Daten in den Teilantworten ist hoher. Dadurch fallt es dem Mediator eventuell leichter, die Inhalte der Teilantworten zu erraten. Im Interesse der Datenquellen
(bezuglich der Geheimhaltung der Daten) und des Kunden (bezuglich seiner informationellen
Selbstbestimmung) kann es daher liegen, keine Optimierungen der Teilanfragen durchzufuhren.

6.6 Schutz des mobilen Codes bei der Ubertragung
Mobiler Code muss vor Ausspahen, Verandern, Abfangen oder Wiedereinspielen durch Dritte
geschutzt werden. Er ist dadurch aber nicht mehr gefahrdet als jede andere Nachricht zwischen
Kunde und Mediator. A hnliches beschreibt auch Peine ([Pei02], Seite 35) fur sein System. Die
Gesamtantwort des Mediators bei unverschlusselter Mediation konnte ebenso angegrien werden.
Wenn bei sicherer Mediation nur die Teilantworten verschlusselt sind aber nicht der mobile
Code selbst, kann ein Rechner, der auf dem U bertragungsweg zwischen Kunde und Mediator
steht, den Algebrabaum lesen. Er kann den Baum dann auch unbemerkt verandern, bevor er
den Baum weiter an den Kunden sendet. Daher ist es wichtig, den mobilen Code in geeigneter
Weise verschlusselt und signiert vom Mediator an den Kunden zu ubertragen. Damit konnen
die Geheimhaltung und die Integritat des mobilen Codes sichergestellt und auerdem der Mediator als Absender authentiziert werden.
Wenn der Angreifer die Antwort des Mediators abfangt, wird das Ausbleiben der Antwort
dem Kunden auallen. Jedoch kann der Angreifer das Abfangen einer Antwort mit dem Wiedereinspielen einer Antwort fur den Kunden verbinden, die er bereits fruher abgefangen hat.
Wenn der Kunde dieselben Schlussel in den beiden entsprechenden Anfragen angegeben hat,
wird er die wiedereingespielte Antwort entschlusseln konnen und (falls dem Kunden die falsche
Antwort uberhaupt auallt) dem Mediator die Schuld fur die falsche Antwort geben. Um dem
entgegenzuwirken kann der Kunde eine Seriennummer (oder einen Zeitstempel) mit jeder Anfrage mitschicken. Die Anfrage muss dabei verschlusselt werden, da sonst ein Angreifer die
Seriennumer in der Anfrage auslesen und eine falsche Antwort mit dieser Seriennummer an
den Kunden senden konnte. Der Mediator fugt die Seriennummer in seinen mobilen Code ein,
bevor er ihn verschlusselt. Der Kunde kann nach dem Entschlusseln anhand der Seriennummer
erkennen, ob er die richtige Antwort erhalten hat.
Der Angreifer kann weiterhin anhand des verschlusselten mobilen Codes Schlusse zu ziehen.
Chess (siehe [Che98], Seite 12) schreibt: "Hier gibt es immer noch Anfalligkeiten fur die Analyse
des Datenaufkommens, gestohlene Schlussel, Angrie auf die Schlusselverteilungs-Infrastruktur
und so weiter; aber zumindest sind die Probleme grotenteils wohlverstanden.\ Mit solchen
10
10 Ubersetzung

aus dem Englischen; Originaltext: "There are still vulnerabilities here, to trac analysis, stolen
keys, attacks on the key-distribution infrastructure,
and so forth, but at least the problems are mostly well
48
Angrien mochte ich mich innerhalb dieser Diplomarbeit nicht weiter befassen.
6.7 Schutz des mobilen Codes auf dem Kundenrechner
Es muss nicht nur der Kunde vor dem mobilen Code geschutzt werden. Auch der mobile Code
selbst muss vor einem Zugri durch den Kunden geschutzt werden. Der Codehersteller mochte dem Kunden seinen Algorithmus und seine Daten nur insofern zur Verfugung stellen, dass
der Kunde am Ende die angeforderten Ergebnisse erhalt. Aus wirtschaftlichen und urheberrechtlichen Interessen mochte der Codehersteller eventuell seinen Algorithmus oder auch sein
Datenformat geheimhalten. Fur den Schutz der Daten kommt im Multimediamediator-System
zusatzlich hinzu, dass die Datenquellen ihre Daten nur Berechtigten zuganglich machen wollen.
Um den mobilen Code ausfuhren zu konnen, muss zumindest der Prozessor des Kundenrechners Zugri auf den mobilen Code haben. Der Kunde hat damit potenziell die Moglichkeit, alle
Operationen zu sehen, die der mobile Code ausfuhrt. Zudem liegen Programmcode und Daten
des mobilen Codes in der Regel vor der Ausfuhrung auf der Festplatte des Kunden. Dort kann
er auf jeden Fall Einblick nehmen, wenn es sich um eine interpretierte Sprache handelt oder
der Binarcode einer kompilierten Sprache dekompiliert werden kann.
Der Codehersteller ist daher an Techniken interessiert, bei denen der Code in einem speziellen
Format oder in einer speziellen Umgebung ausgefuhrt wird, so dass der Kunde den Code nicht
zu Gesicht bekommt. Dieses Interesse steht zunachst einmal im Konikt mit dem Interesse des
Kunden, der den mobilen Code einsehen mochte, um seine Unbedenklichkeit zu uberprufen.
Der Kunde musste zur Programmuberprufung auf eine andere Schutzmethode zuruckgreifen,
bei der er nicht Einblick in den Code nehmen muss; hier kommen im Grunde nur zertizierter
oder signierter Programmcode (mit entsprechender vertraglicher Bindung des Codeherstellers)
oder ein Sandkasten in Frage. Selbst beweismitfuhrender Code muss das Klartextprogramm
bearbeiten, um das Sicherheitspradikat berechnen zu konnen.
Im Gegensatz zu mobilen Daten enthalt der mobile Code Programmcode, der auf Daten arbeitet. Wenn diese Daten und der Programmcode aus verschiedenen Quellen stammen, wie das
bei Multimediamediator der Fall ist, kann es im Interesse des Programmcodes liegen, die Daten
falsch zu bearbeiten. Wenn auerdem verschiedene Teile des Codes aus unterschiedlichen Quellen stammen, konnen sich diese Programmteile sogar gegenseitig angreifen. Der mobile Code
muss also gewissermaen vor sich selbst geschutzt werden.
Ob und wie weit es fur mobilen Code moglich ist, die Schutzziele "Geheimhaltung des Programmcodes und der Daten\ und "Integritat der Daten und der Programmausfuhrung\ zu
erreichen, mochte ich in den folgenden Abschnitten diskutieren. Dazu gehe ich zunachst auf
Softwaremethoden zum Schutz der Daten und des Programmcodes ein und stelle dann eine
Hardwarelosung in Abschnitt 6.7.5 vor.
6.7.1 Datenintegritat wahrend des Aufenthalts auf dem Kundenrechner
Berechnungen auf verschlusselten Daten (siehe Abschnitt 3.1, Seite 8) sind auch auf dem Kundenrechner nicht moglich. Sind die Daten eines mobilen Codes aber erst einmal entschlusselt,
unterliegen sie der vollstandigen Kontrolle des Kunden und der mobile Code kann sie nicht vor
Loschen oder Verandern schutzen. Eine Korruption der Daten lasst sich durch eine alleinige
Softwarelosung nicht verhindern (vgl. dazu die allgemeinen Anmerkungen in [Pei02], Seite 46).
Aber eine Veranderung der Daten von mobilem Code, der nur auf seinem Kundenrechner residiert, schadet nur diesem einen und nicht weiteren Empfangern. Wenn ein Kunde beispielsweise
absichtlich Teilantworten verfalscht (siehe Pfeil (0) in Abbildung 7), bekommt auch nur er eine
falsche Gesamtantwort zu sehen.
Ein Angri auf die Datenintegritat eines mobilen Codes ist jedoch auch ohne aktive Beteiligung
des Kunden moglich. Wahrend seiner Ausfuhrung kann ein mobiler Code versuchen, die Daten
understood.\
49
eines anderen Codes zu verandern (siehe Pfeil (1) in Abbildung 7). Dem Kunden wurde das
eventuell nicht einmal auallen. Die Ausfuhrungsumgebung muss solche Angrie verhindern,
indem sie die Daten verschiedener mobiler Codes voneinander abtrennt. Wenn mobile Codes auf
dem Kundenrechner auf gar keinen Fall zusammenarbeiten durfen, ist das einfach umzusetzen
(beispielsweise durch getrennte Ausfuhrungsumgebungen). Wenn es jedoch zur Funktionalitat
der mobilen Codes gehort, mit anderen zusammenzuarbeiten und gemeinsam Berechnungen
auf dem Kundenrechner auszufuhren, ist es schwer zu kontrollieren, ob ein Zugri auf einen
anderen mobilen Code Daten diese mobilen Codes in unzulassiger Weise geandert hat. Chess,
Harrison und Kershenbaum (siehe [HCK95], Seite 4) schreiben dazu allgemein im Fall eines
mobilen Agenten: "Es ist schwierig, notwendige und hinreichende Tests zu denieren, die der
Agent bestehen muss, um festzustellen, ob er das Wirtssystem inzieren oder auf andere Weise
korrumpieren will.\11 .
Fur den Multimediamediator ist zunachst einmal keine Kooperation von mobilen Codes auf
dem Kundenrechner vorgesehen. Deswegen sollten verschiedene mobile Codes physisch und logisch so von einander getrennt werden, dass sie nicht gegenseitig ihre Daten verandern konnen.
Eine denkbare Erweiterung des Multimediamediator-Systems ware es, mehrere mobile Codes
ihre Ergebnisse durch weitere relationale Operatoren verknupfen zu lassen. Dafur musste dann
sichergestellt werden, dass die Daten der mobilen Codes in ihrer Integritat nicht verletzt werden.
Kunde
(2)
Pro
gramm
(0)
Daten mobiler Code 2
Pro
gramm Daten (1)
mobiler Code 1
Abbildung 7: Drei mogliche Angreifer auf die Datenintegritat
Im Fall des Multimediamediators stammen die Daten von mehreren Datenquellen, die Operatoren werden jedoch vom Mediator bereitgestellt. Der Mediator kennt daher das Datenformat der
Quellen. Er kann seine Operatoren so entwickeln, dass sie die Teilantworten falsch auswerten
(siehe Pfeil (2) in Abbildung 7). Da die Operatoren die Teilantworten unverschlusselt auswerten, konnen sie sogar beliebige Werte in den Teilantworten ersetzen. Der Kunde kann solche
Angrie entdecken, wenn er eine U berprufung des Programmcodes der Operatoren durchfuhrt
(siehe Abschnitt 6.2.3 auf Seite 41). Ein Mediator kann seine Operatoren aber auch von einer
unabhangigen Prufstelle, die fur den Kunden als Vertragspartner fungiert, zertizieren lassen;
eine solches Verfahren schlagen Seltzsam, Borzsonyi und Kemper mit ihrem OperatorCheck server vor (siehe [SBK01]). Alternativ kann der Mediator beweismitfuhrenden Code verwenden
und Beweise fur die semantische Korrektheit seiner Operatoren mitsenden.
Die Forderung nach Integritat der mit dem Code verschickten Daten ist noch viel wichtiger im
Kontext der mobilen Agenten, insbesondere wenn eine Veranderung der Daten durch Wirtsrechner Auswirkungen auf die Funktionsweise des Agenten hat. Wenn neu hinzugekommene
Teilergebnisse von jedem Wirtsrechner signiert werden, kann der Auftraggeber zumindest feststellen, dass die den Agenten begleitenden Daten verandert wurden, wenn der Auftraggeber
11 Ubersetzung

aus dem Englischen; Originaltext: It is dicult to dene necessary and sucient tests that the
agent must pass in order to determine whether "it intends to infect or otherwise corrupt the host system.\
50
alle Signaturprufsschlussel hat. Karjoth et al. (siehe [KAG98]) entwarfen eine Signatur- und
Verschlusselungskette fur mobile Agenten, mit der auch die Integritat und Geheimhaltung der
Teilergebnisse der einzelnen Wirtsrechner sichergestellt werden kann; sie funktioniert jedoch
nur, wenn Wirte nicht mit den Teilergebnissen der anderen Wirte rechnen mussen.
6.7.2 Geheimhaltung der Daten nach Auslieferung an den Kunden
Das Konzept der sicheren Mediation mit dem Multimediamediator hat seine Anwendung in verteilten Informationssystemen, in denen Vertraulichkeit von Daten gewahrleistet werden muss.
Auf dem Weg von den Datenquellen zum Kunden sind vertrauliche Daten in den Teilantworten
dadurch geschutzt, dass sie mit Schlusseln verschlusselt sind, die an Eigenschaften geknupft
sind, die nachweisen, dass der Besitzer der Schlussel berechtigt ist, die Daten zu sehen. Wenn der
empfangende Kunde die Entschlusselung vornehmen kann, hat er sich als Besitzer der Schlussel
authentiziert und somit letztlich gezeigt, dass er berechtigt ist, die Daten zu lesen. Allerdings
hat er dann auch die Moglichkeit, Daten zu kopieren und an Leute weiterzuverbreiten, denen
die Datenqellen nicht die Berechtigung erteilen wurden, die Daten zu lesen. Dies konnen die
Datenquellen mit Softwaremanahmen allein nicht verhindern. Sie (oder die Dateneigentumer)
konnen jedoch in ihre Daten ein digitales Wasserzeichen einrechnen, mit dem sie ihre Urheberrechte deutlich machen konnen. Zum derzeitigen Stand der Technik sind digitale Wasserzeichen
aber vorwiegend fur Bild- und teilweise fur Tondokumente anwendbar, bei denen ein Grundrauschen beziehungweise ein Verandern von niedrigwertigen Bits keine (oder zumindest keine
groe) Auswirkung auf die enthaltene Information haben. Digitale Wasserzeichen sind nicht
falschungssicher und Kopierschutzmechanismen, die auf Wasserzeichen aufbauen, sind auf manipulationssichere Hardware angewiesen (vgl. zu diesem Themenkomplex [PAK98] in [Auc98]
und [Dit00]).
Fur textuelle Daten wie Datenbanktabellen sind digitale Wasserzeichen im Allgemeinen schwierig zu realisieren. Im Multimediamediator-Konzept kommt hinzu, dass aus mehreren Tabellen
eine Gesamtantwort ausgerechnet wird, in der sich dann nur Teile der ursprunglichen Tabellen
benden. Eine Tabelle kann daher nicht einmal als Ganzes markiert werden. Wenn stattdessen
die Datenzellen einer Tabelle einzeln gekennzeichnet wurden, ware die Zusammengehorigkeit
der Daten damit nicht mehr markiert. Fur Tabellen, auf denen Berechnungen ausgefuhrt werden, ware daher eine wichtige Anforderung an ein Wasserzeichen-Verfahren, dass Teile aus einer
Tabelle herausgenommen werden konnen, ohne das Wasserzeichen zu zerstoren.
Ein anderer Aspekt beim Multimediamediator ist, dass der Kunde samtliche unverschlusselte Teilantworten in die Hand bekommt. Er hat damit Zugri auf viel mehr urheberrechtlich
geschutztes oder vertrauliches Material, als er in der Gesamtantwort benotigt. Dasselbe trit
auf den Mediator im Fall der unverschlusselten Mediation zu. Aus diesem Gesichtspunkt ware
fur die Datenquellen eine Optimierung des Aufspaltungsalgorithmus' von Vorteil (siehe Abschnitt 5.1.1 auf Seite 29); sie wurden komplexe Teilanfragen, auf die sie wenige Daten zuruckliefern, bevorzugen. Das steht im Widerspruch zum Wunsch, den Umfang der relevanten
Daten in den Teilantworten vor dem Mediator in einer groeren Teilantwort zu verstecken (siehe Abschnitt 6.5.3, Seite 46). Die Datenquelle muss entscheiden, was sie als die groere Gefahr
ansieht; davon abhangig kann sie einen Mediator als Vertragspartner auswahlen, der ihr entweder komplexe oder atomare Teilanfragen sendet. Vielleicht kann hier auch eine Erweiterung des
Multimediamediator-Konzepts Abhilfe schaen. Belmon und Yee schlagen in [BY98] beispielsweise den Einsatz von mobilen Agenten vor, um auf Datenbanken nur die minimal benotigte
Menge von Daten herauszusuchen. Der Mediator konnte, anstatt jede Datenquelle einzeln anzusprechen, einen solchen Agenten erstellen und ihn die Teilantworten auf den Datenquellen
zusammensuchen lassen. Wenn die Teilantworten alle zusammen verschlusselt werden, erfahrt
der Mediator auch nichts uber die Groe einzelner Teilantworten.
51
6.7.3 Geheimhaltung des Programmcodes auf dem Kundenrechner
Wenn Code ausgefuhrt wird, also in den Hauptspeicher geladen und im Prozessor verarbeitet
wird, ist er fur den ausfuhrenden Rechner sichtbar. Gerade Java-Code ist auch im Binarformat
nicht "geschutzt\, da Dekompilierer aus dem Bytecode wieder fur Menschen lesbaren Quelltext erstellen konnen. Eine einfache Gegenmanahme gegen einen Leseangri ist es, den Code
funktional und syntaktisch korrekt zu lassen, aber durch Einfuhrung zusatzlicher Variablen,
Kontrollanweisungen oder Methoden die Funktion und den Kontrollu zu verschleiern. Diese
Verschleierung des Codes bietet aber hochstens einen kurzzeitigen Schutz, denn auch hier gibt
es Programme, die den verschleierten Code wieder vereinfachen (siehe [Rou03] zur Verschleierung von Java-Programmen).
Die theoretische Betrachtung der Codeverschleierung steht gerade erst am Anfang. Barak et
al. (siehe [BGI+ 01]) geben eine Familie F von Programmen an, fur die es keine Verschleierung
geben kann: eine Eigenschaft : F ! f0; 1g kann mit bloem Orakelzugri auf ein Programm
f der Familie nicht ezient berechnet werden (die Wahrscheinlichkeit, dass die Eigenschaft
von einer probabilistischen Turingmaschine in polynomieller Zeit mit f als Orakel berechnet
wird, hat nur einen vernachlassigbaren Unterschied zu bloem Raten); mit Rechenzugri auf
eine beliebiges Programm der Familie kann die Eigenschaft jedoch ezient berechnet werden.
Dagegen geben Lynn et al. (siehe [LPS04]) erste positive Ergebnisse der Codeverschleierung an.
Sie verschleiern die Funktionalitat eines Zugriskontrollmechanismus' durch die Komposition
mehrerer Verschleierungsfunktionen.
Selbst wenn eine Dekompilierung nicht moglich ist, kann der Rechner den Code beliebig oft
mit unterschiedlichen Parametern ausfuhren und so versuchen den Algorithums zu erraten (vgl.
dazu etwa Hohl [Hoh98], Seite 110).
Das Konzept der umgebungsabhangigen Schlussel ermoglicht es zumindest, Teile des Programmcodes solange verschlusselt zu halten, bis vorher festgelegte Bedingungen erfullt sind.
Riordan und Schneier (siehe [RS98]) benutzen als Beispiel eine Patentdatenbank, in der ein
Softwareagent nachschaut, ob ein bestimmtes Patent schon angemeldet wurde. Eine Variante
der umgebungsabhangigen Schlussel sind zeitabhangige Schlussel, die aber einen zuverlassigen
externen Zeitgeber benotigen, damit eine Zeit-Worterbuchattacke { also das Ausfuhren des
Programms mit verschiedenen Systemzeiten { verhindert werden kann.
Eine Geheimhaltung des Funktionsweise eines Programms bieten Berechnungen mit verschlusselten Funktionen (engl. computing with encrypted functions, CEF). Die verschlusselte Funktion
wird an den Berechner gesendet, der auch die geheimen Eingabedaten besitzt, das verschlusselte Ergebnis zu seiner Eingabe berechnet und das Ergebnis zuruck an den Auftraggeber;
idealerweise ist keine weitere Interaktion notig.
Tomas Sander und Christian Tschudin (siehe [ST98], Seite 48) unterscheiden zwischen einer
Funktion F und einem Programm P (F ) (in prozessorverarbeitbarem Klartext), das die Funktion berechnet. Um die Funktion F zu verstecken, soll sie zu einer Funktion E (F ) verschlusselt
werden, die wiederum in einem Klartextprogramm P (E (F )) dargestellt werden kann. Betrachten wir wieder Alice und Bob als Teilnehmer der verteilten Berechnung. Alice erstellt das
verschlusselte Programm P (E (F )) und sendet es an Bob. Bob berechnet P (E (F ))(x) zu seiner
Eingabe x und sendet das Ergebnis an Alice. Nach der Entschlusselung erhalt Alice f (x). Der
Rechenablauf ist in Abbildung 8 schematisch dargestellt. Zunachst betrachteten die Autoren
die Auswertung von verschlusselten Polynomen mit Hilfe eines homomorphen Verschlusselungsschemas (siehe Abschnitt 3.1 auf Seite 9).
Die Ergebnisse der Berechnung auf verschlusselten Daten (wie in Abschnitt 3.1 beschrieben;
siehe [SYY99]) lassen sich auf verschlusselte Programme ubertragen. Als Eingabedaten kodierte (und verschlusselte) Schaltkreise konnen von universellen Schaltkreisen ausgewertet werden.
Universelle Schaltkreise haben jedoch polynomielle Tiefe und Groe im Vergleich zu den kodierten Schaltkreisen, die sie auswerten sollen. Der universelle Schaltkreis fur Schaltkreise aus
NC 1 benden sich in der Komplexitatsklasse NC 2 , die die Familie der Schaltkreise mit qua-
52
Alice
(4)
(5)
f(x)
(1)
E(f)(x)
(2)
P(E(f))(x)
Bob
x
(3)
Abbildung 8: Berechnungen mit verschlusselten Funktionen
dratischer Groe und quadratisch logarithmischer Tiefe umfasst. Um die Berechnungen auf
verschlusselten Schaltkreisen in polynomieller Zeit durchfuhren zu konnen, mussen ihre universellen Schaltkreise aus der Klasse NC 1 sein. Daspschrankt die Eingabemenge ein;
p beispielsweise
auf Familien von Schaltkreisen der Tiefe d = O( log n) und der Groe s = 2O( log n) bezuglich
der Lange n der Eingabe fur den ursprunglichen Schaltkreis.
Wenn jedoch Berechnungen mit verschlusselten Funktionen und damit auch Berechnungen auf
verschlusselten Daten allgemein und ezient moglich waren, sollte der Mediator sofort die
Gesamtantwort aus den verschlusselten Teilantworten berechnen (siehe Abschnitt 3 auf Seite
8).
6.7.4 Integritat der Codeausfuhrung
Abgesehen vom Ausspahen des Codes (siehe Abschnitt 6.7.1) kann der Kunde auch die Ausfuhrung des Codes beeinussen. Damit hat er die Moglichkeit, den Code falsche Ergebnisse
berechnen zu lassen. Fur mobilen Code bedeutet das lediglich, dass der Kunde sich selbst
schadet. Wiederum sind es die mobilen Agenten fur die sichergestellt werden muss, dass alle
Wirtsrechner sich korrekt verhalten. Ich mochte hier kurz zwei probabilistische Verfahren zur
Integritatsprufung anfuhren:
Um nachzuweisen, dass ein Agent auf jedem Wirtsrechner korrekt ausgefuhrt wurde,
benutzen Biehl, Meyer und Wetzel (siehe [BMW98]) probabilistische Beweise, die der
Agent mit sich fuhrt und die vom Auftraggeber des Agenten uberpruft werden konnen.
Wenn der Auftraggeber schon vor dem Senden des Agenten zufallig die Bits auswahlt,
die er in den Beweisen uberprufen will, und Angaben uber diese Bits mit dem Agenten
mitsendet, muss jeder Wirtsrechner nur diese Bits seines Beweises schicken. Damit der
Wirtsrechner nicht erfahrt, welche Bits der Auftraggeber sehen will, benutzen Biehl et al.
die Methode der "vertraulichen Informationsabfrage\ (engl. private information retrieval).
Loureiro et al. (siehe [LBR02]) betrachten Berechnungen mit verschlusselten Funktionen,
die sich durch Schaltkreise darstellen lassen. In die Darstellung eines Schaltkreises fugen sie kleine Fehler ein. Die Fehler erzeugen im Ergebnis einen Fehlervektor mit einem
Hamminggewicht t (das ist die Anzahl der Nicht-Null-Bits). Aus dem Endergebnis des
Agenten, der die verschlusselte Funktion enthalt, rechnet der Auftraggeber den Fehlervektor heraus und vergleicht dessen Hamminggewicht mit t. Stimmt das Hammingewicht
des Ergebnisses, akzeptiert er das Ergebnis.
6.7.5 Sichere Koprozessoren
Seit einiger Zeit gibt es Bemuhungen, Datenverarbeitung mit einem abgesicherten HardwareModul (oft in Form eines Koprozessors) durchzufuhren, das es unmoglich macht, auf Daten
innerhalb dieses Moduls zuzugreifen. Das Modell von Yee und Tygar (siehe [YT95]) sieht vor,
dass der Koprozessor aus einer Recheneinheit, einem Nur-Lese-Speicher und sicherem nicht-
6.8 Verhinderbarkeit von Angrien mit Java
53
uchtigen Speicher besteht12 . Die Hardware muss soweit wie moglich vor physischen U bergriffen geschutzt werden. Der Speicher des Koprozessors enthalt einen geheimen symmetrischen
Schlussel und ein asymmetrisches Schlusselpaar. Der Koprozessor besitzt eine Verschlusselungsund eine Entschlusselungsoperation. Spezielle Ver- und Entschlusselungshardware kann die Recheneinheit zusatzlich unterstutzen.
Der Entwurf der Trusted Computing Group (TCG, siehe [TCG]) unter den Namen "zuverlassige Datenverarbeitung\ (engl. trusted computing) beziehungsweise "vertrauenswurdige
Datenverarbeitung\ (engl. trustworthy computing; vorwiegend von der Microsoft Corporation [MIC]
verwendet) sieht auerdem einen "sicheren Pfad\ zwischen den Eingabe- und Ausgabegeraten
und dem Koprozessor vor. Die Schlusselverwaltung (insbesondere die Neugenerierung oder die
Migrierung auf andere Rechner) soll in dem Entwurf nur eingeschrankt moglich sein.
Innerhalb des Prozessors werden Daten unverschlusselt bearbeitet. Nur registrierte, "vertrauenswurdige\ Programme konnen auf Daten zugreifen, die vom kryptographischen Prozessor
entschlusselt wurden. Ein beliebtes Beispiel ist ein Abspielprogramm fur Filme, die urheberrechtlich geschutzt sind. Ein Film wird dann nur verschlusselt ausgeliefert. Wenn der Kunde
vom Rechteinhaber einen Entschlusselungsschlussel gekauft hat, kann ein registriertes Abspielprogramm den kryptographischen Prozessor beauftragen, den Film zu entschlusseln, und danach den entschlusselten Film anzeigen. Auf diese Weise kann auch Programmcode geheim gehalten werden. Der Programmcode wird nur innerhalb des Prozessors entschlusselt und dann
ausgefuhrt. Die Verwendung von Einmalschlusseln ermoglicht es, dass der Code nur einmal
ausgefuhrt werden kann.
Zuverlassige Datenverarbeitung kann auch dazu dienen, Daten an einen Rechner zu binden.
Der kryptographische Prozessor muss dazu feststellen, ob der Rechner, in dem er und die Daten
sich benden, ein anderer ist als der, auf dem die Daten erstellt wurden, oder ob der Rechner
verandert wurde, seit die Daten verschlusselt wurden. Beim Systemstart wird beispielsweise aus
den Seriennummern der angeschlossenen Hardware-Komponenten ein Kennwert des Systems
berechnet. Bei der Verschlusselung von Daten wird dieser Kennwert den Daten vorangestellt.
Der kryptographische Prozessor gibt nach der Entschlusselung die Daten nur frei, wenn der
Kennwert der verschlusselten Daten mit dem aktuellen System-Kennwert ubereinstimmt. Handelt es sich um einen fremden Rechner oder wurde der Rechner zwischenzeitlich verandert,
konnen die Daten nicht mehr entschlusselt werden.
Voraussetzung fur diese Ansatze ist immer, dass ein Kundenrechner mit der entsprechenden
Hardware ausgerustet ist. Wenn ein Kunde des Multimediamediator-Systems im Besitz eines
sicheren Koprozessors ist, kann ein Mediator seinen mobilen Code bei einer Zertizierungsstelle registrieren lassen. Er erhalt dann ein Zertikat fur seinen Code. Der Mediator sendet
den Code mit dem Zertikat an den Kunden. Der sichere Koprozessor des Kunden pruft das
Zertikat. Wenn er es akzeptiert, fuhrt er den Code aus, ohne dass der Kunde den Code zu
sehen bekommt.
6.8 Verhinderbarkeit von Angrien mit Java
Tabelle 6 (Seite 54) stellt dar, welche Angrie durch welche Mechanismen der Programmiersprache Java oder bereits vorhandene Bibliotheken verhindert werden konnen. Die erste Spalte
gibt den Angri an. Die
zweite Spalte (mit dem Titel ?\) gibt an, ob der Angri verhinderbar
ist (mit dem Zeichen "p\) oder nicht (mit dem Zeichen""{\). Die dritte Spalte enthalt eine kurze
Begrundung, warum ein Angri nicht verhindert werden kann, oder eine kurze Erklarung, wie
ein Angri verhindert werden kann.
Die vorgeschlagenen Gegenmanahmen zum Schutz der Teilantworten (Einbringen einer Seriennummer oder des Teilanfragetextes in die Teilantwort und Signierung der Teilantworten)
12 Im
englischen Original: "A secure coprocessor is a hardware module containing (1) a CPU, (2) bootstrap
ROM, and (3) secure non-volatile
memory.\
54
wurden nicht implementiert. Sie konnen bei einer Erweiterung des Systems umgesetzt werden.
Dazu mussen insbesondere auf Kundenseite Methoden eingefugt werden, die die entsprechenden U berprufungen vornehmen. Die restlichen Gegenmanahmen wurden implementiert und
die vierte Spalte verweist auf die Abschnitte, in denen die Manahmen ausfuhrlicher erklart
werden.
Angri
Spionage
mobiler Code gegen Kunde
?
Begr
undung/Erklarung
p
Abschnitt
keine Leserechte auf Dateien fur den Code vorhan- 9.1.7 und
den, keine Referenzen auf Kundenmodulklassen und 9.1.3
keine Netzverbindung fur den Code moglich
Programm- und p keine Schreibrechte fur den Code vorhanden
9.1.4 und
Datenkorruption
9.1.5
Ressourcendiebstahl { Lange Berechnungen, Belegen des Arbeitsspeichers, 9.1.1 und
Starten von Threads und Blockierung von Eingabe- 9.1.7
und Ausgabestromen moglich
Komplott mehrerer p eigene virtuelle Maschine fur jeden Code
9.1.8
Codes
Auftreten unter p keine Benutzungsschnittstellen und kein nativer Co- 9.1.2 und
falscher Identitat
de fur den Code moglich
9.1.6
Nachladen
von p keine Netzverbindung fur den Code moglich
9.1.3
schadlichem Code
Mediator gegen Kunde
p Auswahl
Prolbildung
verschiedener Verschlusselungsschlussel
8.3
Falsches Einsetzen p Seriennummer oder Teilanfragetext in der Teilant- {
der Teilantwort
wort
Mediator gegen Teilantworten
p
Verandern
der
Signieren der Teilantworten
{
Teilantwort
p hybrides Verschlusselungsverfahren
Klartextangri;
8.1
Ableiten von Informationen
Dritte gegen mobilen Code
Abfangen und Wie- p Zeitstempel
9.2
dereinspielen
Kunde gegen mobilen Code
Lesen und Veran- { Dekompilieren des Binarcodes und Lesen der Daten 9.3
dern
moglich
mobiler Code gegen eigene Teilantworten
Schadliche Opera- { Falsche Auswertung von Teilantworten moglich
9.3.1
toren
U berschreiben des p nur Entdeckung von Duplikaten in Java-Archiven 9.3.2
Datenformats
andere mobile Codes gegen mobilen Code
Lesen und Veran- p eigenes Arbeitsverzeichnis und eigene virtuelle Ma- 9.3
dern
schine fur jeden Code
Tabelle 6: Verhinderbarkeit von Angrien mit Java
55
III.
Implementierung
Inhalt
7 Eingesetzte Java-Mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . .
...
...
...
...
...
...
...
...
...
8 Umsetzung des Multimediamediators mit mobilem Code . . .
8.1 Datenquellenmodul . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Mediatormodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Kundenmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Mogliche Angrie auf das Mediatorsystem . . . . . . . . . . . .
9.1 Angrie des mobilen Codes auf den Kunden . . . . . . . . . . . . .
9.2 Angrie Dritter wahrend der U bertragung . . . . . . . . . . . . . .
9.3 Angrie auf mobilen Code wahrend des Aufenthalts beim Kunden
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
Sicherheit auf Binarcode-Ebene . . . . . .
Entstehung des Java-Sicherheitskonzepts .
Klassenlader-Hierarchie . . . . . . . . . .
Das Java-Berechtigungskonzept . . . . . .
Beispielhafte Berechtigungen . . . . . . .
Privilegierter Code . . . . . . . . . . . . .
Kryptographie . . . . . . . . . . . . . . .
Schutz von Java-Archiven . . . . . . . . .
JDBC, RMI und JNI . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
57
58
58
61
62
62
64
65
66
66
69
78
85
85
91
92
Vertrauen bedeutet nicht Blindheit. Es geht zusammen mit Kontrolle: Man
"kann
es nur erwarten, wenn man Menschen ihr eigenes Urteil lasst und
Transparenz garantiert.\
Gesine Schwan
56
7 Eingesetzte Java-Mechanismen
Das Konzept des Mediators sieht wechselnde Kunden und Datenbanken und damit eine Vielzahl
von Plattformen vor. Die Programmiersprache Java [JAV] ist fur ein solches System pradestiniert, da sie von der zugrundeliegenden Plattform abstrahiert und eine einheitliche Laufzeitumgebung bereitstellt. Die Plattformunabhangigkeit der Programmiersprache Java wird durch
die Umsetzung des Konzeptes einer virtuellen Maschine (Abk.: VM) realisiert.
Java Quellcodes werden in Binardateien ubersetzt, die aus Befehlen in der Sprache der virtuellen
Maschine bestehen. Die Java-Binardateien werden als Klassendateien bezeichnet. Ausgefuhrt
werden die Dateien in einer Laufzeitumgebung, die den Befehlssatz der virtuellen Maschine
emuliert. Die virtuelle Maschine sorgt dafur, dass die Binarcodes auf allen Plattformen von der
gleichen Speicherwortlange und Byteordnung ausgehen konnen. Die Grundeinheit der virtuellen Maschine sind 8 Byte; langere Worter werden in Dickender-Reihenfolge (engl. big endian
byte order13 ) zusammengesetzt.
Java ist fur die Umsetzung des Multimediamediators gut geeignet, da zum Einen auf der Sprachebene (in der virtuellen Maschine) Prufungen des Binarcodes zur Laufzeit stattnden und zum
Anderen eine breitgefacherte kryptographische Programmierschnittstelle zur Verfugung gestellt
wird. Die Java-Standardumgebung enthalt auerdem Pakete fur Datenbankzugrie und Netzwerkkommunikation. Die von mir verwendete Java-Version ist 1.4.2; Java 1.5 bendet sich
derzeit noch im Beta-Stadium. Als Entwicklungsumgebung hat mir Eclipse [ECL] gute Dienste
geleistet.
7.1 Sicherheit auf Binarcode-Ebene
Java ist auf hardwarenaher Ebene sicherer entworfen worden als andere Programmiersprachen
(vgl. [JAS]). Davon will ich an dieser Stelle nur einige Aspekte aufgreifen. Nahere Angaben sind
beispielsweise unter [Yel96] und [Eng03] zu nden. Ein entscheidender Gegensatz zum Beispiel
zu C++ ist es, dass in Java keine Zeiger existieren und damit auch keine Zeigerarithmetik
moglich ist. Es gibt nur Referenzen auf Objekte; Speicheradressen sind also immer an Objekte
gebunden und ein direkter Zugri auf eine Speicheradresse ist nicht moglich. Java lat keine
uninitialisierten Variablen im dynamischen Speicher zu und die primitiven Datentypen haben
auf allen Plattformen dieselbe Lange. Java ist zudem streng typisiert: Jedes Objekt muss zu
einer vorher denierten Klasse gehoren und zur Laufzeit kann der Typ eines Objektes nicht
in einen inkompatiblen Typ umgewandelt werden. Dies alles sorgt dafur, dass Speicherzugrie
immer ein wohldeniertes Ergebnis zuruckliefern. Wichtig fur die sichere Ausfuhrung eines Programms ist auerdem, dass die Speicherverwaltung zuverlassig funktioniert. Java besitzt eine
automatische Speicherbereinigung (engl. garbage collection), die unreferenzierten dynamischen
Speicher wiedergewinnt und damit Speicherlocher vermeidet. Die Programmiererin oder der
Programmierer mussen Speicher nicht explizit wieder freigeben.
Einige sicherheitskritische Operationen sind mit Java also gar nicht moglich; dennoch muss Programmcode auf die Einhaltung weiterer Sicherheitsanforderungen uberpruft werden. Ein paar
der Sicherheitsuberprufungen konnen schon zum Zeitpunkt der U bersetzung des Quellcodes
stattnden. Allerdings konnen solche U berprufungen durch bosartige U bersetzer umgegangen
werden. Daher wird im laufenden Java-System jeder geladene Klassencode uberpruft. Alle statischen U berprufungen werden direkt nach dem Laden des Klassencodes durchgefuhrt. Dazu
gehort, dass die Klassendatei syntaktisch korrekt ist, keine Speicherbereiche uber- oder unterlaufen, keine unzulassigen Speicherzugrie stattnden, jede Anweisung die korrekten Parameter
erhalt, Sprunge nur zum Anfang einer Anweisung fuhren und Typumwandlungen legal sind.
13 Zum
Ursprung des Begries siehe beispielsweise http://www.computerbase.de/lexikon/Byte-Reihenfolge
(Stand der Webseite: 22. Juni 2009) und Jonathan Swift: "Gullivers Reisen\.
7.2 Entstehung des Java-Sicherheitskonzepts
57
Andere Bedingungen werden dynamisch zur Ausfuhrungszeit des Objektes uberpruft. Dazu
gehort, dass Referenzen auf andere Klassen und Zugrie auf Methoden und Attribute legal
sind. Mit diesen Sicherheitsuberprufungen schutzt Java das ausfuhrende System auf der Ebene
des Arbeitsspeichers gegen Spionage und Veranderungen von Speicherinhalten auerhalb des
Zugrisbereichs. Allerdings lasst sich Ressourcendiebstahl mit Java nicht verhindern. Es ist
weder moglich, die Menge an Arbeitsspeicher zu begrenzen, die einem Objekt zugewiesen wird,
noch die von einem Objekt verwendeten Rechenzyklen einzuschranken. Ein Java-Objekt kann
daher allen der virtuellen Maschine zugewiesenen Arbeitsspeicher14 fur sich beanspruchen oder
sehr rechenintensive Operationen ausfuhren. Ein anderer Aspekt ist, dass die Bereichsmodikatoren (public, protected, Paketzugri und private) nicht ausreichend sind, um Zugrie von
anderen Klassen zu verhindern. Aus softwaretechnischer Sicht ist es meistens sinnvoll, Klassen
auf mehrere Pakete zu verteilen. Dadurch mussen aber eventuell Klassen oentlich gemacht
werden, die nur von einer geringen Anzahl anderer Klassen aus anderen Paketen zugreifbar
sein sollten. Einen Zugri aber nur einer bestimmten Anzahl von Klassen zu erlauben, ist nicht
moglich, sondern die jeweilige Klasse ist dann von uberall her zugreifbar. Die Bereichsmodikatoren sind also kein Mittel, um unerwunschte Zugrie auf eine Klasse zu verhindern und es
mussen andere Mittel eingesetzt werden, um Klassenzugrie zu steuern.
7.2 Entstehung des Java-Sicherheitskonzepts
Neben der Binarcode-U berprufung, die vorwiegend die syntaktische Korrektheit einer Klassendenition sicherstellt, bietet Java auch Mechanismen, mit denen auf der Ebene von Programmmodulen (also einer Menge von Klassen) Einschrankungen fur die Ausfuhrung von Klassen
vorgenommen werden konnen. Verfolgt man die Entwicklung der Programmiersprache Java
in den Jahren 1994 bis 2004, wird deutlich, dass die Sicherheitsmechnismen einen immer hoheren Stellenwert eingenommen haben und deutlich komplexer geworden sind (vgl. dazu auch
[Gon02]). In der Java-Version 1.0 gab es zunachst eine strikte Trennung zwischen lokalem Code
und heruntergeladenem Code; lokaler Code umfasste Anwendungen, die von der Festplatte geladen wurden, und heruntergeladener Code waren Applets innerhalb einer Webseite. Wahrend
lokaler Code uneingeschrankten Zugri auf die Java-Programmierschnittstelle und die daruber zugreifbaren Ressourcen hatte, wurde der Funktionsumfang des heruntergeladenen Codes
dadurch eingeschrankt, dass Browserprogramme ihn in einem Sandkasten ausfuhrten. Dieser
Sandkasten erlaubte dem Code nur eine festgelegte Menge von Operationen. In der Version
1.1 bestand die Moglichkeit, heruntergeladenen Code durch Signaturen aus dem Sandkasten
herauszulassen. Galt die Signatur des Codes auf dem Empfangersystem als vertrauenswurdig,
wurde er wie lokaler Code behandelt. Code, der von einem nicht vertrauenswurdigen Signierer,
falsch oder gar nicht signiert wurden, wurde weiterhin im Sandkasten ausgefuhrt.
Im Laufe der Zeit wurde deutlich, dass auch lokaler Code aus nichtvertrauenswurdiger Quelle
stammen kann. Seit Version 1.2 ist es moglich, jedes Java-Programm mit Sicherheitsuberprufungen auszufuhren. Es gibt kein "Schwarz-Wei\-Prinzip mehr, das Programme in lokalen oder
heruntergeladenen Code einteilt, sondern verschiedenen Codes und Programmmodulen konnen
eine Vielzahl von Berechtigungen zugewiesen werden. Applets laufen weiterhin standardmaig
innerhalb eines Sandkastens, aber auch ihnen konnen zusatzliche Berechtigungen zugewiesen
werden.
Im Folgenden werde ich grundlegende Java-Mechanismen und Teile der aktuellen Sicherheitsarchitektur vorstellen. Ich beginne in Abschnitt 7.3 mit dem Vorgehen zum Laden von Klassen; fur den Multimediamediator mussste ein Mechanismus geschaen werden, um Klassen,
die beim Start der virtuellen Maschine unbekannt waren, zur Laufzeit einbinden zu konnen.
Abschnitt 7.4 behandelt die Vergabe von Berechtigungen an Programmmodule und die U ber14 Die
Menge an Arbeitsspeicher, die der virtuellen Maschine zugewiesen wird, kann mit der Kommandozeilenoption -Xmx beim Start der virtuellen Maschine festgelegt werden. Dadurch ist indirekt der Arbeitsspeicher
fur Programme, die in dieser virtuellen Maschine ausgefuhrt werden, auf diesen Wert begrenzt.
58
prufung dieser Berechtigungen; Abschnitt 7.5 stellt exemplarisch einige Berechtigungen vor,
die dem mobilen Code nicht erteilt werden sollen. Privilegierter Code, der in Abschnitt 7.6 eingefuhrt wird, bietet eine Moglichkeit, die Berechtigungsuberprufungen vorzeitig abzubrechen;
er wurde aus diesem Grund nicht fur den Multimediamediator mit mobilem Code eingesetzt.
Abschnitt 7.7 stellt dar, wie Verschlusselung und Signierung mit Java durchgefuhrt werden
konnen; ohne diese Funktionen kommt das sichere Multimediamediator-System nicht aus. Der
Schutz von einzelnen Programmmodulen ist Thema des Abschnitts 7.8; die dort erklarten Verfahren, erschweren es dem mobilen Code, einzelne Klassen anzugreifen. Der letzte Abschnitt
7.9 stellt zum Einen zwei Programmierschnittstellen vor, die funktionell fur die Umsetzung des
Multimediamediators benotigt wurden. Zum Anderen beschreibt er eine Programmierschnittstelle, die die Einbindung von anderen Programmiersprachen erlaubt; dies soll dem mobilen
Code nicht erlaubt werden.
7.3 Klassenlader-Hierarchie
Bevor ein Objekt ausgefuhrt werden kann, muss sein Klassen-Binarcode in eine virtuelle Maschine geladen werden. Diese Aufgabe ubernehmen Klassenlader. Beim Start der virtuellen
Maschine werden standardmaig drei Klassenlader gestartet: der Urklassenlader, der Erweiterungsklassenlader und der Systemklassenlader. Der Urklassenlader ist eng verknupft mit der
virtuellen Maschine und ladt alle Klassen, die zur Java-Standardumgebung gehoren. Der Erweiterungsklassenlader ladt alle Klassen aus Java-Archiven, die in einem bestimmten Verzeichnis
liegen (dem sogenannten Erweiterungsverzeichnis); diese Archive konnen den Binarcode einer Anwendung oder einer von mehreren Anwendungen verwendeten Bibliothek enthalten. Im
Erweiterungsverzeichnis hat nur ein Administrator Schreibrecht und die gewunschten JavaArchive mussen per Hand in das Verzeichnis kopiert werden; daher sollte es sich um vom
Administrator gepruften, zuverlassigen Code handeln. Der Systemklassenlader schlielich ladt
alle Klassen innerhalb eines Suchpfades (des sogenannten Klassenpfads), der beim Starten der
virtuellen Maschine angegeben wird. Der Klassenpfad kann bei jedem Aufruf verschieden sein.
Jeder Klassenlader auer dem Urklassenlader hat einen Elternklassenlader; alle Klassenlader einer laufenden virtuellen Maschine benden sich in einer baumartigen Hierarchie, deren Wurzel
der Urklassenlader ist. Der Systemklassenlader ist Kind des Erweiterungsklassenladers und der
Erweiterungsklassenlader ist Kind des Urklassenladers; siehe dazu auch Abbildung 9. Die JavaSpezikation sieht vor, dass ein Klassenlader, wenn er aufgerufen wird, eine Klasse zu laden,
diese Aufgabe zunachst an seinen Elternklassenlader delegiert. Erst wenn der Elternklassenlader die Klasse nicht ndet, versucht der aufgerufenen Klassenlader, die Klasse zu laden. Das
stellt sicher, dass die Java-Standardklassen vom Urlader geladen werden und nicht durch gefalschte Klassen ersetzt werden konnen, die von einem Klassenlader geladen werden, der sich
tiefer in der Hierarchie bendet.
Mit den Standard-Klassenladern kann nur ein statischer Satz von Binarcodes geladen werden.
Alle benotigten Binarcodes mussen beim Start der virtuellen Maschine in den Erweiterungsverzeichnissen vorhanden oder ihr Dateiname im Klassenpfad enthalten sein. Zur Laufzeit konnen
dort keine Binarcodes hinzugefugt werden.
Es konnen anwendungsspezische Klassenlader implementiert und in die Hierarchie eingeordnet werden. Um diese Klassenlader innerhalb der Anwendung zu benutzen, muss explizit entweder die Methode ClassLoader.loadClass(String classname) oder die Methode
Class.forName(String classname, boolean resolve, ClassLoader classloader) aufgerufen werden.
7.4 Das Java-Berechtigungskonzept
Jedes instanziierte Objekt in der virtuellen Maschine bendet sich in einem Schutzbereich, der
durch ein Objekt der Klasse java.security.ProtectionDomain dargestellt wird. Schutzbe-
59
7.4 Das Java-Berechtigungskonzept
Urklassenlader
loadClass()
Erweiterungsklassenlader
loadClass(){
parent.loadClass();
...
}
Systemklassenlader
loadClass(){
parent.loadClass();
...
}
Abbildung 9: Standardklassenlader-Hierarchie
reiche trennen Objekte mit unterschiedlichen Berechtigungen voneinander. Eine spezielle Art
von Schutzbereichen sind Systembereiche, die alleinigen Zugri auf die externen Ressourcen wie
Dateisystem, Netzwerk, Bildschirm und Tastatur haben. Andere Objekte, die auf eine Ressource zugreifen wollen, mussen dafur ein Objekt aus einem Systemschutzbereich aufrufen { zum
Beispiel System.out fur die Standardausgabe. Der Schutzbereich, dem ein Objekt zugewiesen
wird, wird bestimmt durch
den Herkunftsort des Codes (das ist ein Objekt der Klasse java.security.CodeSource),
eine Menge von Zertikaten, die die oentlichen Schlussel enthalten, mit deren privaten
Gegenstucken der Code signiert wurde,
eine Menge von Prinzipalen (das sind in diesem Zusammenhang Benutzer, die ein Programm ausfuhren),
und den Klassenlader, der das Objekt geladen hat.
Zwei Klassen, bei denen alle vier Werte ubereinstimmen, gehoren zum selben Schutzbereich.
Unterscheiden sich zwei Klassen hingegen in mindestens einem der Werte, gehoren sie zu verschiedenen Schutzbereichen.
Wenn einem ProtectionDomain-Objekt bei der Instanziierung eine Menge von Berechtigungen ubergeben wird, bleiben diese als statische Berechtigungen uber die ganze Lebensdauer
des Objektes in Kraft. Zur Laufzeit werden aber bei jeder Berechtigungsuberprufung noch die
in der aktuellen Sicherheitsregel enthaltenen dynamischen Berechtigungen berucksichtigt, die
diesem Schutzbereich nach der Instanziierung zugewiesen wurden. Alle Berechtigungsuberprufungen werden mit Hilfe einer Instanz der Klasse java.lang.SecurityManager durchgefuhrt.
Wenn ein Objekt eine sicherheitsrelevante Operation ausfuhren will, wird in der aufgerufenen
Methode mittels des SecurityManagers uberpruft, ob das aufrufende Objekt berechtigt ist, die
Operation auszufuhren. Der SecurityManger benutzt dazu eine seiner check-Methoden. Wird
beispielsweise die delete-Methode eines java.io.File-Objekts aufgerufen, ruft diese Methode
wiederum die checkDelete-Methode des SecurityMangers auf. Nur wenn diese Methode keine
java.security.AccessControlException wirft, wird die Datei schlielich geloscht. Hier ist
der relevante Abschnitt aus der Klasse File:
60
...
public class File implements java.io.Serializable, Comparable {
static private FileSystem fs = FileSystem.getFileSystem();
...
public boolean delete() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkDelete(path);
}
return fs.delete(this);
}
...
}
Die Sicherheitsregel, die zur Laufzeit in Kraft ist und die vergebenen Berechtigungen angibt,
wird reprasentiert durch die Klasse java.security.Policy. Diese Klasse selbst ist eine abstrakte Klasse und muss daher von einer geeigneten Klasse beerbt werden. Ein Objekt einer
solchen Unterklasse bildet jeden vorhandenen Schutzbereich auf eine Menge von Berechtigungen ab. Die mit Java mitgelieferte Standardimplementierung von Sun Microsystems (siehe
[SUN]) initialisiert eine Sicherheitsregel, indem sie Kongurationsdateien einliest. Neben zwei
voreingestellten Dateistandorten { im Java-Installationsverzeichnis und im Startverzeichnis des
aktuellen Benutzers { kann man beim Programmaufruf oder im Programm selbst, bevor ein
SecurityManager gestartet wird, eine zusatzliche Kongurationsdatei angeben. Mit diesem
Verfahren ist nur eine statische Sicherheitsregel realisierbar; zur Laufzeit konnen nach dem
Start des SecurityManagers keine weiteren Berechtigungen vergeben werden.
Berechtigungen werden durch Unterklassen der Klasse java.security.Permission dargestellt,
die ebenfalls abstrakt ist. Zu einem Permission-Objekt kann man ein Ziel und mehrere Aktionen angeben; das heit, dass die Berechtigung fur die Ausfuhrung der Aktionen auf dem
Ziel-Objekt erteilt wird. Beispielsweise kann man fur die Klasse java.io.FilePermission
einen Dateinamen und eine Zugrisart angeben: FilePermission("/tmp/a.txt", "read")
erlaubt den Lesezugri auf die Datei /tmp/a.txt.
Die Klasse Permission gibt die Methode implies(Permission permission) vor; mit dieser
Methode muss jede Berechtigung entscheiden konnen, ob sie die als Parameter ubergebene
Berechtigung impliziert. Eine Leseberechtigung fur ein Dateisubsystem beinhaltet auch eine
Leseberechtigung fur jede einzelne Datei in diesem Subsystem. Wenn es zum Beispiel im Verzeichnis /tmp/ eine Datei a.txt gibt, dann gilt: FilePermission("/tmp/*", "read") impliziert FilePermission("/tmp/a.txt", "read").
Selbst wenn man von der Schadlosigkeit eines Programms uberzeugt ist, sollte man ihm nur
das Minimum an Berechtigungen geben, dass es fur seine Berechnungen braucht. Das verringert die Zahl moglicher Angrisziele, falls das Programm durch ein schadliches mit dem selben
Herkunftsort ersetzt wird oder zwei Programme kooperieren und damit de facto ihre Berechtigungen kombinieren. Auerdem sollte man sich bewut sein, welche Nebenwirkungen die
Vergabe von Berechtigungen haben kann. Eine Schreibberechtigung fur das gesamte Dateisystem bedeutet beispielsweise auch, dass Java-Standardbibliotheken durch schadliche Varianten
ersetzt werden konnen. Eine Berechtigung zum Erstellen von Klassenladern erlaubt es einem
Programm, schadliche Klassen zu laden und in einen beliebigen Schutzbereich einzufugen. Sun
Microsystems hat auf einer Webseite weitere Gefahrdungen aufgelistet, die durch die Vergabe
von Berechtigungen entstehen konnen (siehe [Per97]).
Das Berechtigungskonzept von Java verlangt, dass in einer Kette von Methodenaufrufen zwischen verschiedenen Objekten alle Objekte in dieser Aufrufkette auch die Berechtigung haben,
die das letzte Objekt in der Kette fur eine sicherheitsrelevante Operation benotigt. Wenn Ob-
61
7.5 Beispielhafte Berechtigungen
jekt A eine Methode von Objekt B aufruft und diese Methode eine Datei loschen soll, mussen
sowohl Objekt B als auch Objekt A berechtigt sein, diese Datei zu loschen. Ware dem nicht
Berechtigungen 1
Berechtigungen 2
FilePermission("a.txt", "delete")
Schutz
bereich 1
eteFile
del
()
B.
Objekt A
Schutz
bereich 2
Objekt B
delete(„a.txt
le.
“)
Fi
a.txt
Abbildung 10: Aufrufkette zwischen verschiedenen Schutzbereichen
so, konnte jedes Objekt ein anderes Objekt mit der entsprechenden Berechtigung instanziieren und die sicherheitsrelevante Operation aufrufen. Sobald ein Objekt in der Aufrufkette die Berechtigung nicht besitzt, wird die Ausfuhrung der gesamten Aufrufkette mit einer
AccessControlException in der check-Methode abgebrochen; im positiven Fall beendet sich
die Methode einfach ohne Ruckgabewert.
Die Gesamtmenge an Berechtigungen fur eine Aufrufkette entspricht dem Durchschnitt der Berechtigungsmengen der einzelnen Objekte in der Aufrufkette. Diese Durchschnittsbildung, also
die Berechtigungsuberprufung fur einen Aufruf, wird aber nicht bei jedem Wechsel des Schutzbereichs in der Aufrufkette durchgefuhrt, sondern erst, wenn eine sicherheitskritische Operation aufgerufen wird; denn erst dieser Aufruf macht eine Berechtigungsuberprufung notwendig.
Durch diese Art der U berprufung wird die Ausfuhrung der sicherheitskritischen Operation
zwar verlangert, der nichtsicherheitskritische Fall { wenn keine sicherheitskritische Operation
aufgerufen wird { lauft aber schneller ab.
7.5 Beispielhafte Berechtigungen
Neben den Aktionen "Lesen\ und "Loschen\ gibt es fur Datei-Berechtigungen auch Aktionen
zum Schreiben und Ausfuhren von Dateien; beispielsweise gibt folgendes Berechtigungsobjekt
die Berechtigung fur alle Aktionen auf der der Datei "/tmp/a.txt\:
FilePermission("/tmp/a.txt", "read, write, delete, execute").
Jeder Code kann eine graphische Benutzungsschnittstelle starten. Standardmaig ist ein solches Fenster aber mit einem Warntext ausgestattet, der signalisiert, dass der Code, der das
Fenster geonet hat, nicht dazu autorisiert worden ist. Wenn der onende Code jedoch die
Berechtigung java.awt.AWTPermission("showWindowWithoutWarningBanner") erhalt, wird
der Warntext nicht mehr angezeigt.
Es gibt eine spezielle Berechtigungen zum Beenden der virtuellen Maschine, so dass nicht
jeder beliebige Code die Ausfuhrung des Programms abbrechen kann. Nur Code, der die Berechtigung java.lang.RuntimePermission("exitVM") innehat, darf das Programm beenden.
Auerdem gibt es Berechtigungen, um eine Referenz auf ein Klassenladerobjekt zu bekommen
(java.lang.RuntimePermission("getClassLoader")) und selbst einen neuen Klassenlader
zu instanziieren (java.lang.RuntimePermission("createClassLoader")). Da die Klassenlader bestimmen, ob und welche Klassen geladen werden, sollte nicht jeder Code Zugri auf
die Klassenlader haben oder gar einen neuen erstellen konnen.
Um den Aufbau einer Netzverbindung zu erlauben, gibt es die java.net.SocketPermission.
62
Der Name und Port des Rechners, zu dem die Kommunikation aufgenommen werden soll,
werden als Ziel angegeben; als Aktionen sind das Annehmen einer Verbindung, das Verbinden zum angegeben Rechner, das Warten auf Verbindungen und das Auosen des Rechnernamens moglich. SocketPermission("host.de:777","accept, connect, listen, resolve")
erlaubt zum Beispiel alle Verbindungsaktionen zum Rechner host.de auf Port 777.
Den Zugri auf Klassen kann nur paketweise kontrolliert werden. Dazu muss aber zunachst der
Name des Pakets an die Systemvariable package.access angehangt werden. Nur fur Pakete,
deren Namen in der Variablen steht, wird uberhaupt eine Zugriskontrolle durchgefuhrt; auf alle anderen Pakete wird der Zugri immer gestattet. Steht der Name eines Paketes jedoch in der
Variablen, konnen Klassen aus dem Paket nur von Code geladen werden, der eine Berechtigung
dazu hat. RuntimePermission("accessClassInPackage.javax.swing.*") beispielsweise erlaubt den Zugri auf alle Klassen im Paket javax.swing.
7.6 Privilegierter Code
Es besteht eine Moglichkeit, eine sicherheitsrelevante Operation durchzufuhren, obwohl der
Aufrufer die Berechtigung dazu selbst nicht hat; dazu muss er eine Methode mit sogenanntem privilegierten Code aufrufen. Privilegierter Code ist Code, der innerhalb der statischen
doPrivileged-Methode aus der Klasse java.security.AccessController ausgef
uhrt wird.
Die doPrivileged-Methode benotigt als Parameter ein Objekt einer neu denierte Klasse, die das Interface java.security.PrivilegedAction implementiert. Diese Klasse wird
im Kompilierungsschritt in eine eigenen Binardatei (.class-Datei) ubersetzt. Weitere technische Hinweise zu privilegiertem Code nden sich auf der Sun-Webseite [Pri01]. Wenn das
PrivilegedAction-Objekt die Berechtigung hat, die entsprechende sicherheitsrelevante Operation durchzufuhren, und alle in der Aufrufkette folgenden Klassen ebenfalls die Berechtigung
haben, wird die Operation erlaubt. Der Aufrufer der doPrivileged-Methode und seine Vorganger in der Aufrufkette brauchen die Berechtigung selbst nicht. Der Vorteil des privilegierten
Codes ist es, dass der sicherheitskritische Bereich klein gehalten wird. Das bedeutet, dass die
jeweilige Berechtigung nur einem kleinen Stuck Code zugewiesen wird { idealerweise nur der
PrivilegedAction-Klasse. Code, der sich sonst mit dem sicherheitsrelevanten Code in einer
Klasse benden wurde (oder im selben Java-Archiv; siehe dazu Abschnitt 7.8 auf Seite 64)
aber selbst keine sicherheitsrelevanten Operationen durchfuhrt, braucht mit Benutzung des
privilegierten Codes die Berechtigung nicht, da der Code, der die Berechtigung benotigt, in
die PrivilegedAction-Klasse ausgelagert wird. Die Berechtigungsprufung wird dadurch auch
schneller, da nicht die gesamte Aufrufkette gepruft wird, sondern nur bis der privilegierte
Code erreicht wird. Diese Methode hat jedoch auch Nachteile: Die Aufrufe von sicherheitsrelevanten Operationen werden schwieriger zu kontrollieren. Mit privilegiertem Code ist es zudem wichtig, dass der privilegierte Code sensible Daten nicht an seinen Aufrufer weiterreicht.
Der Aufrufer ist ja eventuell nicht berechtigt, diese Daten zu sehen. Beispielsweise sollte eine
PrivilegedAction, die eine Entschl
usselung durchfuhrt, den Entschlusselungsschlussel nicht
als Ruckgabewert an ihren Aufrufer zuruckgeben. Diese semantischen Sicherheitsanfoderungen
konnen von Java nicht automatisch uberpruft werden.
7.7 Kryptographie
Java bietet mit dem Paket javax.crypto und Teilen des Paketes java.security eine Schnittstelle fur kryptographische Algorithmen an, die auch unter dem Namen Java Cryptography
Extensions (JCE) bekannt ist. Bereitgestellte Algorithmen sind beispielsweise symmetrische
Block- und Datenstromverschlusselungsverfahren und Signierungsverfahren. Da JCE nur fur einige Algorithmen eine Implementierung bereitstellt, konnen sogenannte Kryptographie-Anbieter
(engl. cryptography provider) eingebunden werden und ebenfalls uber die JCE-Schnittstelle benutzt werden, wenn die Ver- und Entschlusselungsobjekte mit dem jeweiligen Anbieter initiali-
7.7 Kryptographie
63
siert werden. Der Binarcode der Kryptographie-Anbieter liegt meist als Java-Archiv vor; dieses
Archiv muss im Suchpfad des Klassenladers vorhanden sein, damit der Klassenlader Klassen aus
ihm laden kann. Auerdem muss der Kryptographie-Anbieter bei der Java-VM registriert werden, bevor ein Java-Programm ihn verwenden kann. Die Registrierung eines Anbieters kann statisch durch einen Eintrag in eine Kongurationsdatei, beim Start der virtuellen Maschine durch
einen Kommandozeilenparameter oder aber auch durch das Programm selbst erfolgen, soweit
das Programm die entsprechende Berechtigung (namlich java.security.SecurityPermission
mit dem Ziel "setProperty.security.provider.providername ") besitzt.
Die Verwaltung kryptographischer Schlussel und Zertikate ndet in Java durch einen \Schlusselspeicher\ (ein Objekt der Klasse java.security.KeyStore) statt. Fur Schlusselspeicher,
die im Standardformat JKS (Abkurzung fur Java Keystore) auf der Festplatte gespeichert werden, ist das Kommandozeilenprogramm keytool im Java-Standardpaket enthalten, mit dem
Schlusselspeicher erstellt, Schlussel(paare) generiert und Zertikate im- und exportiert werden
konnen. Jeder Eintrag { egal ob Schlussel oder Zertikat { wird mit einem Alias versehen, uber
den der Zugri geregelt wird. Ein Schlusseleintrag ist entweder ein asymmetrischer, privater
Schlussel zusammen mit einer Zertikatskette fur den dazugehorenden oentlichen Schlussel
oder ein symmetrischer, geheimer Schlussel. Ein Zertikatseintrag ist ein Zertikat mit dem
oentlichen Schlussel einer Person oder Firma; wichtig ist hierbei, dass die Authentizitat des
Zertikats gewahrleistet ist, da aus den Zertikatseintragen Zertikatsketten aufgebaut werden, um Signaturen zu uberprufen. Der Besitzer eines Schlusselspeichers sollte nicht unbedacht
Zertikate aufnehmen.
Geheime Schlusseleintrage (also symmetrische Schlussel oder der private Teil asymmetrischer
Schlussel) werden durch passwortbasierte Verschlusselung geschutzt; gerat das Passwort in
Vergessenheit, ist der Schlussel nicht wiederherzustellen. Zertikatseintrage und Zertikate des
oentlichen Teils eines asymmetrischen Schlussels konnen ohne Angabe eines Passwortes ausgelesen werden. Auch dem Schlusselspeicher selbst wird ein Passwort beim Erstellen zugewiesen.
Bei jedem Speichern des Schlusselspeichers muss das Passwort angegeben werden, denn aus
dem Passwort und dem gesamten Schlusselspeicher-Inhalt wird eine SHA-Prufsumme gebildet,
die an das Ende der Schlusselspeicher-Datei geschrieben wird. Wenn das Passwort auch beim
Laden des Schlusselspeichers angegeben wird, kann seine Integritat gepruft werden. Die Integritatsprufung ist aber nicht obligatorisch und daher die Angabe des Passworts beim Laden
optional.
Sun Microsystems (siehe [SUN]) liefert mit dem Java-SDK einen Schlusselspeicher aus, der
selbstsignierte Zertikate einiger Zertizierungsbehorden (Certication Authorities, CAs) enthalt. Diese Zertikate dienen als Wurzel von Authentizitatsprufungen. Die SchlusselspeicherDatei mit den Wurzelzertikaten ist /jre/lib/security/cacerts. Diese Datei bendet sich
im Java-Installationsverzeichnis.
Die Hauptklasse fur jede Ver- und Entschlusselung ist javax.crypto.Cipher. Ein Objekt dieser
Klasse kann mit Algorithmen von verschiedenen Kryptographie-Anbieter initialisiert werden.
Cipher f
uhrt die Ver- und Entschlusselung eines Byte-Feldes (byte[]) durch. Fur die Verschlusselung von serialisierbaren Java-Objekten kann man der Klasse javax.crypto.SealedObject
einen initialisierten Cipher ubergeben. SealedObject erstellt dann die serialisierte Darstellung des Objektes und verschlusselt diese mit dem Cipher. Die Entschlusselung wird auch mit
einem Cipher durchgefuhrt. SealedObject deserialiert nach der Entschlusselung das in ihm
enthaltenen Objekt, so dass es im laufenden Programm sofort verwendet werden kann.
Analog zum Cipher gibt es fur die Signierung die Klasse java.security.Signature. Diese Klasse kann beliebige Signieralgorithmen ausfuhren, wenn sie mit einem entsprechenden
Kryptographie-Anbieter initialisiert wurde. Es kann eine Signatur fur ein Byte-Feld erstellt
werden. Fur die Signierung eines Java-Objekts wird das Signature-Objekt verwendet, indem es
dem Konstruktor eines java.security.SignedObject ubergeben wird. Auch fur die Prufung
einer Signatur ist die Klasse Signature zustandig: entweder direkt mit der Methode verify()
fur ein Byte-Feld oder wiederum als U bergabeparameter fur das zu prufende SignedObject.
64
7.8 Schutz von Java-Archiven
Eine Menge von Java-Klassen (insbesondere deren Binarcodes aber auch die Quellcodes oder
andere Materialen wie Graphiken) konnen in einem Java-Archiv (JAR) zusammengefasst werden. Die Dateistandorte solcher Archive konnen dem Suchpfad eines Klassenladers hinzugefugt
werden. Der Klassenlader kann dann Klassen aus diesem Archiv laden. Die archivierten Klassen
mussen nicht alle aus einem Paket stammen, sondern ein Archiv kann Klassen aus verschiedenen Paketen enthalten. Ebenso konnen Klassen aus einem Paket uber mehrere JARs verteilt
sein. Metainformationen uber das Java-Archiv sind in der sogenannten Manifest-Datei im JAR
enthalten. Mit dem folgenden Eintrag kann beispielsweise die Hauptklasse einer Anwendung
und ein initialer Suchpfad fur den Klassenlader angegeben werden:
Manifest-Version: 1.0
Created-By: 1.4.2_03 (Sun Microsystems Inc.)
Class-Path: bin/client.jar
Main-Class: org/mmm/start/Starter
Um immer die richtige Version einer Klasse zu laden oder auch das U berschreiben von Klassen
durch gefalschte Klassen auerhalb des Archivs zu verhindern, mochte man oft sicherstellen,
dass alle Klassen eines Pakets aus demselben Java-Archiv geladen werden. Dazu verwendet
man das Versiegeln von Java-Archiven. Es wird folgender Eintrag in das Manifest des Archiv
eingefugt:
Sealed: true
Der Klassenlader ladt dann die Klassen aller Pakete innerhalb des Archivs nur aus diesem Archiv. Solange dieser Manifest-Eintrag selbst nicht verandert oder das JAR ausgetauscht wird,
bietet das Sicherheit davor, dass sich Klassen in Pakete "einschleichen\. Wenn zum Beispiel
das Paket org.mmm.client im versiegelten JAR client.jar eingepackt ist und eine Klasse
org.mmm.client.Attack im Paket attack.jar abgelegt ist, wird der Versuch, diese Klasse zu laden, einen Programmfehler produzieren: java.lang.SecurityException: sealing
violation: package org.mmm.client is sealed.
Der Dateistandort eines Java-Archivs ist fur die Klassen im Archiv der Herkunftsort und bestimmt daher den Schutzbereich der Klassen mit, wie es in Abschnitt 7.4 (Seite 58) beschrieben
wurde. In der Kongurationsdatei fur die aktuelle Sicherheitsregel kann der Dateistandort des
Java-Archivs benutzt werden, um allen Klassen innerhalb des Archivs eine Menge von Berechtigungen zuzuweisen. Ein Eintrag in der Kongurationsdatei sieht dann etwa so aus:
grant codeBase "file:client.jar" {
permission java.io.FilePermission "a.txt","read";
};
Alle Klassen innerhalb des Archivs client.jar erhalten die Berechtigung die Datei a.txt
(relativ zum Dateistandort der Kongurationsdatei { also im selben Verzeichnis) zu lesen.
Auerdem gibt es die Moglichkeit, Java-Archive zu signieren. Damit kann sichergestellt werden,
dass ein JAR nicht verandert wurde, seit es die Hande des Signierers verlassen hat. Abhangig
von den Signaturen konnen auch wieder Berechtigungen an das JAR vergeben werden. Ein
Eintrag in der Kongurationsdatei ware zum Beispiel der folgende:
keystore "myprivatekeystore";
grant signedBy "trustedcert1,trustedcert2" {
permission java.io.FilePermission "a.txt","write";
};
Der Schlusselspeicher myprivatekeystore muss vorhanden sein und die Zertikate mit den
oentlichen Signaturprufschlussel trustedcert1 und trustedcert2 enthalten. Wenn zwei Si-
7.9 JDBC, RMI und JNI
65
gnaturen eines Archivs mit diesen beiden Schlusseln veriziert werden konnen, erhalten alle
Dateien innerhalb des Archivs die Berechtigung, in die Datei a.txt zu schreiben.
7.9 JDBC, RMI und JNI
Fur die Umsetzung des Multimediamediator musste ich neben der Erstellung einer Sicherheitsarchitektur auch Datenbankzugrie und Kommunikation zwischen mehreren Rechnern ermoglichen. Ich habe dafur Java Database Connectivity (Abk. JDBC) und Remote Method Invocation
RMI verwendet, die beide zur Java-Standardumgebung gehoren.
Um mit Java auf einen Datenbankserver zugreifen zu konnen, benotigt man einen zusatzlichen Treiber, der in der Regel von den Datenbankherstellern bereitgestellt wird. Alle JavaDatenbanktreiber mussen die JDBC-Spezikation einhalten. Eine Anwendung, die auf eine
Datenbank zugreifen will, ladt den Treiber und baut uber ihn unter Angabe von Datenbankname, Benutzername und Passwort eine Verbindung zur Datenbank auf. U ber diese Verbindung
werden die Datenbankanfragen gestellt. Der Ruckgabewert zu einer Anfrage ist ein Objekt vom
Typ java.sql.ResultSet, das von der Anwendung zeilenweise bearbeitet werden kann.
Remote Method Invocation (RMI) ist die Java-Implementierung von externen Methodenaufrufen (siehe Abschnitt 5, Seite 28). Eine RMI-Registratur (im englischen Original rmiregistry)
verwaltet alle aktiven und registrierten RMI-Objekte eines Rechners. Eine RMI-Registratur
wird uber den Rechnernamen oder die IP-Adresse des Rechners adressiert, der sie ausfuhrt. Zu
jedem Objekt, das von auen angesprochen werden soll, wird eine Schnittstelle veroentlicht.
Unter dem Namen dieser Schnittstelle wird das Objekt bei der RMI-Registratur registriert und
ist ab dann zu erreichen. Beim Aufruf eines externen Objektes wird auf den aufrufenden Rechner ein Objektstumpf ubertragen; dieser Stumpf reprasentiert das externe Objekt lokal und
fuhrt die Methodenaufrufe auf diesem Objekt durch. U bergabeparameter und Ruckgabewerte
brauchen keine Objektstumpfe; sie werden in serialisierter Form ubertragen.
Ich benutze RMI nicht wie in Abschnitt 5 beschrieben zum Aufbau einer Kommunikation mit
mobilen Daten, bei der in einem Anfrage-Antwort-Dialog die Gesamtantwort aufgebaut wird.
Vielmehr setze ich RMI als U bertragunsprotokoll fur den mobilen Code ein. Es wird also nur
ein externer Methodenaufruf als Anfrage durchgefuhrt, dessen Ruckgabewert alle benotigten
Bibliotheken und Daten des mobilen Codes sind.
Abschlieend stelle ich noch eine Technik vor, die die Funktionalitat von Java-Programmen
erweitert, sie aber auch sehr angreifbar macht. Das Java Native Interface (JNI) bietet eine
Schnittstelle zwischen Java-Code und Programmen, die in einer anderen Programmiersprache verfasst wurden. Diese Programme werden als sogenannte Bibliotheken vom Java-Code
mit einem Aufruf von System.loadLibrary() geladen. Die JNI ermoglicht eine bidirektionale Kommunikation: Einerseits kann der Java-Code Methoden des nativen Codes aufrufen und
ihnen mit der nativen Sprache kompatible Parameter ubergeben (und auch Objekte erzeugen, wenn die andere Programmiersprache objektorientiert ist); andererseits kann der native
Code Java-Objekte erzeugen und Java-Methoden aufrufen und kompatible Parameter ubergeben. Nativer Code unterliegt aber nicht den Java-Binarcode-U berprufungen. Bei einem Aufruf
von nativem Code innerhalb von Java-Code wird nur gepruft, ob der Aufrufer berechtigt ist,
Bibliotheken mit dem angegebenen Namen zu laden.
66
8 Umsetzung des Multimediamediators mit mobilem Code
Mein Programm unterteilt sich entsprechend den Teilnehmern, die im MultimediamediatorSystem identiziert wurden, in ein Kundenmodul, ein Mediatormodul und ein Datenquellenmodul. Demzufolge habe ich mein Programm in drei Pakete eingeteilt: org.mmm.client,
org.mmm.mediator und org.mmm.datasource. Die drei Unterpakete org.mmm.client.view,
org.mmm.mediator.view und org.mmm.datasource.view enthalten die jeweiligen Benutzungsschnittstellen. Zum Kundenmodul gehort auch das Paket org.mmm.start, das sicherheitsrelevante Einstellungen auf dem Kundenrechner durchfuhrt, bevor das eigentliche Anfrageprogramm gestartet wird. Zusatzlich gibt es noch das Paket org.mmm.core, das Klassen enthalt,
die die anderen Pakete gemeinsam benutzen. Das hat den Vorteil, dass die obengenannten Pakete nur Klassen aus org.mmm.core importieren mussen, aber von den jeweils anderen Paketen
unabhangig sind. Eine U bersicht uber die in org.mmm enthaltenen Pakete und Klassen gibt
Abbildung 28 in Anhang A auf Seite 115.
Die Software soll alle Sicherheitsforderungen aus dem Abschnitt 6 erfullen aber dennoch ergonomisch und auch performant sein. Dies ist zunachst einmal ein Zielkonikt; gerade die
Verschlusselungsalgorithmen, die Java-inharenten Sicherheitsuberprufungen aber auch graphische Benutzungsschnittstellen fuhren zu Verzogerungen. Um die Bedienbarkeit zu erleichtern
habe ich trotzdem fur alle Module eine graphische Benutzungsschnittstelle erstellt. Auf die Verschlusselung und die Sicherheitsuberprufungen kann hier nicht verzichtet werden. Im Vergleich
zu einer unverschlusselten und unuberpruften Antwort muss also eine langere Ausfuhrungsdauer in Kauf genommen werden.
In den folgenden Abschnitten stelle ich die drei Module im Einzelnen vor. Ich gehe dabei insbesondere auf ihr Zusammenspiel und die sicherheitsrelevanten Aspekte ein. Das Mediatormodul
benutzt fur die Aufspaltung der Anfrage die SQL2Algebra-Bibliothek, die lehrstuhlintern von
Jan-Hendrik Lochner entwickelt wurde. Da die Algebra nur eine Teilmenge der SQL umfasst,
kann nur eine eingeschrankte Menge von SQL-Konstrukten in Anfragen verwendet werden.
Auerdem muss die von Jan-Hendrik Lochner denierte Anfrage-Syntax eingehalten werden.
8.1 Datenquellenmodul
Zunachst einmal benotigt man einen Rechner, auf dem ein Datenbankserver lauft, der die Relationen verwaltet und die Teilanfragen des Mediators beantworten soll. Das Datenquellenmodul,
mit dem der Mediator kommuniziert, kann, muss aber nicht auf demselben Rechner laufen. Es
benotigt aber Zugri auf den zur Datenbank passenden Java-Datenbanktreiber, der in Abschnitt 7.9 (Seite 65) vorgestellt wurde. Das Datenquellenmodul baut uber den Datenbanktreiber eine Verbindung zum Datenbankmanagementsystem auf dem Datenbankserver auf. U ber
diese Verbindung sendet das Datenquellenmodul SQL-Anfragen an das Datenbankmanagementsystem und erhalt die Teilantwort-Relationen zuruck. Die Kommunikation des Mediators
mit dem Datenquellenmodul lauft ausschlielich uber Remote Method Invocation (RMI); auer
fur das Datenquellenmodul sollten fur niemanden direkte SQL-Anfragen an den Datenbankserver moglich sein, da das Datenquellenmodul die Teilantworten noch verschlusseln muss. Auf
dem Rechner des Datenquellenmoduls muss also auerdem eine RMI-Registratur gestartet werden. Das Datenquellenmodul registriert seine RMI-Schnittstelle org.mmm.core.Datasource bei
der RMI-Registratur. Danach startet es die graphische Benutzungsoberache. Der oder die Administrator(in) des Datenquellenmoduls kann daruber die IP-Adresse oder den Rechnernamen
des Datenbankservers angeben und auch zur Laufzeit andern. Auch der Klassenname des Datenbanktreibers wird durch ein Eingabefeld in der Benutzungsoberache angegeben; dadurch
kann das Datenquellenmodul mit allen Datenbanken und deren Treibern arbeiten, die sich
an die JDBC-Schnittstelle halten. Auerdem kann in der Benutzungsschnittstelle der symme-
67
8.1 Datenquellenmodul
Abbildung 11: Benutzungsschnittstelle des Datenquellenmoduls
Q
trische Verschlusselungsalgorithmus und die Schlussellange fur das Verschlusselungsverfahren
angegeben werden, mit dem die Teilantwort-Relationen verschlusselt werden. Die Benutzungsschnittstelle ist in Abbildung 11 dargestellt. Nahere Erlauterungen zu RMI und JDBC nden
sich im Abschnitt 7.9 (Seite 65).
Nach dem Start wartet das Datenquellenmodul auf Anfragen eines Mediators in Form eines
org.mmm.core.QueryWithCertificate. Eine Anfrage wird u
ber den JDBC-Treiber an den Datenbankserver weitergeleitet; die Antwort ist vom Typ java.sql.ResultSet. Das Datenquellenmodul wandelt mittels der Formatted Dataset API (FDSA; sieht [FDS]) das ResultSet in ein
String-Feld (java.lang.String[]) mit den Metadaten und eine Object-Matrix (java.lang.
Object[][]) mit dem Tabelleninhalt um. Daraus erstellt das Datenquellenmodul die Teilantwort als Instanz der Klasse org.mmm.datasource.array.ArrayResult. Diese Teilantwort wird
ry
ue
Certi
With
ficate
Da
Datenbanktreiber
tenquelle
Mediator
k pub
Se
al
e dR
esult
FDSA
seal
transform
k session
seal
Datenbank
server
ResultSet
ArrayResult
SealedResult
k pub : öffentlicher Schlüssel des Kunden
k session : Sitzungsschlüssel
Abbildung 12: Ablaufschema fur das Datenquellenmodul
vom Datenquellenmodul verschlusselt und an den aufrufenden Mediator zuruckgegeben. Ein
schematischer Ablauf der Aufgaben des Datenquellenmoduls ist in Abbildung 12 dargestellt.
Auerdem bendet sich im Anhang C (Abbildung 30, Seite 117) das Sequenzdiagramm fur das
Datenquellenmodul.
In den folgenden beiden Abschnitten stelle ich das Verschlusselungsverfahren vor und gehe auf
mogliche Datenformate ein.
68
8.1.1 Verschlusselung einer Teilantwort
Die Verschlusselung einer Teilantwort ndet mit einem hybriden Verfahren statt. Das Datenquellenmodul erstellt einen symmetrischen Sitzungsschlussel (entsprechend den Angaben
in der Benutzungsschnittstelle), mit dem die Teilantwort verschlusselt wird; dieser symmetrische Schlussel selbst wird mit dem oentlichen Schlussel aus der Anfrage verschlusselt. Die
verschlusselte Teilantwort liegt dann als javax.crypto.SealedObject und der verschlusselte symmetrische Schlussel als byte[] vor. Sie werden in einem org.mmm.core.SealedResult
zusammengefasst. Bei der Verschlusselung greife ich auf die Klasse javax.crypto.Cipher zuruck, die ich im Rahmen der Java Cryptography Extension in Abschnitt 7.7 (Seite 62) vorgestellt
habe. Das hybride Verfahren bietet den Vorteil, dass die unter Umstanden groe Menge von
Antwortdaten mit einem schnelleren symmetrischen Verfahren und der kurze Sitzungschlussel mit einem langsameren asymmetrischen Verfahren verschlusselt werden. Da jede Antwort
zudem mit einem neuen Sitzungsschlussel verschlusselt wird, werden Angrie erschwert, die
durch den Vergleich mehrerer verschlusselter Texte den Schlussel herausbekommen wollen.
Fur die symmetrische Verschlusselung der Daten kann ein beliebiger Algorithums gewahlt werden. Die einzigen Voraussetzungen sind,
dass das Datenquellenmodul Zugri auf einen Kryptographie-Anbieter hat, der den Verschlusselungsalgorithmus mit der gewahlten Schlussellange anbietet
dass der erzeugte symmetrische Sitzungsschlussel nicht zu lang ist, um mit dem oentlichen Schlussel verschlusselt zu werden
dass das Kundenmodul Zugri auf einen Kryptographie-Anbieter hat, der den Entschlusselungsalgorithmus mit der gewahlten Schlussellange anbietet.
Der Name des verwendeten Algorithmus' ist im SealedObject enthalten und wird vom Kundenmodul vor der Entschlusselung abgefragt.
Der oentliche Schlussel in der Anfrage ist Teil eines asymmetrischen Schlusselpaares. Die Java Cryptography Extensions bieten jedoch keine Implementierung asymmetrischer Verschlusselungsalgorithmen. Daher habe ich fur die asymmetrische Verschlusselung des Sitzungsschlussels (und auch dessen Entschlusselung) auf den Kryptographie-Anbieter Bouncy Castle Provider (siehe [BCP]) zuruckgegrien. Dieser Anbieter stellt als einziges asymmetrisches Blockverschlusselungsverfahren einen Algorithmus mit RSA-Schlusseln und dem Modus Electronic
Cipherbook (ECB) zur Verfugung (zu Algorithmenarten und Betriebsmodi siehe etwa [Sch02]
ab Seite 223). Da sowieso nur Klartexte verschlusselt werden konnen, die kurzer sind als der
Modulus des RSA-Schlussel, ist ECB auch der einzig sinnvolle Modus { die Lange des Modulus
entspricht der verschlusselbaren Blocklange. Der einzige variable Wert ist der der Auspolsterung von zu kurzen Blocken. Hier hab ich mich fur Optimal Asymmetric Encryption Padding
(OAEP) entschieden, wie es von den RSA Laboratories empfohlen wird (siehe [RSA]). Die
asymetrische Verschlusselung ist auf diesen Algorithmus festgelegt und kann nicht geandert
werden.
Die Teilantworten sollten bei der U bertragung von den Datenquellen zum Kunden nicht nur
verschlusselt sondern auch signiert werden, damit der Mediator die Integritat uberprufen kann.
Der Mediator benotigt fur die Signaturprufung allerdings oentliche Signaturprufschlussel von
allen Datenquellen, die er benutzt. Da dieses Problem der Schlusselverwaltung nicht direkt mit
der Umsetzung des mobilen Codes zu tun hat, habe ich die Signaturprufung der Teilantworten
zunachst nicht implementiert.
8.1.2 Datenformate
Die Datenquellen sind frei in der Wahl der verwendeten Datenformate. Ich habe das Format
org.mmm.arrayformat.ArrayResult implementiert, das die Metadaten als String[] und die
8.2 Mediatormodul
69
Tabellendaten als Object[][] enthalt. Wenn eine Datenquelle dagegen ein Format bereithalt,
das die Antwortdaten beispielsweise in einer Liste oder einer XML-Datei speichert, muss sie
eine Antwort-Klasse bereitstellen, die org.mmm.core.Result implementiert. Dieses Interface
wird vom Kundenmodul benutzt. Das Kundenmodul ist damit unabhangig vom tatsachlich
verwendeten Datenformat. Wenn zudem mehrere Teilantworten in unterschiedlichen Formaten
zusammengefugt werden mussen, mussen die einzelnen Datenquellen oder der Mediator Umwandlungsoperatoren in die anderen Formate bereitstellen oder das in [ABFK03] beschriebene
Datenhullen-Konzept umsetzen, das die Umwandlung in ein anderes Format schon auf der
Datenquellenseite vornimmt. Auf Seiten des Kunden ergeben sich dadurch aber keine A nderungen. Hier tritt der Vorteil des Konzepts des mobilen Codes zu Tage, da das Kundenmodul
zur Laufzeit neue Datentypen einbinden kann, die im mobilen Code enthalten sind.
8.2 Mediatormodul
Auch die Kommunikation eines Kunden mit einem Mediator lauft uber Remote Method Invocation. Auf dem Mediatorrechner muss daher eine RMI-Registratur gestartet werden. Die RMISchnittstelle, die das Mediatormodul bereitstellt, ist das Interface org.mmm.core.MMMTask;
dessen Methode request() wird von einem anfragenden Kundenmodul aufgerufen. Das Mediatormodul registriert nach dem Start seine Schnittstelle bei der RMI-Registratur und startet
die graphische Benutzungsschnittstelle.
Abbildung 13: Benutzungsschnittstelle des Mediatormoduls (Datenquellenauswahl)
In dem von mir erstellten Programm wird eine Teilanfrage nur an eine Datenquelle gestellt, da
der Algorithmus zur Zuweisung von mehreren Teilanfragen an verschiedene Datenquellen noch
nicht existiert. U ber die Benutzungsschnittstelle des Mediators kann also nur eine Datenquelle
ausgewahlt werden, zu der der Rechnername der Datenquelle, der Name der Datenbank und
Benutzername und Passwort des Datenbankservers angegeben werden. Der Mediator muss ein
registrierter Benutzer des Datenbankmanagementsystems sein, um eine Anfrage ausfuhren zu
konnen. Ein Bildschirmfoto der Benutzungsschnittstelle (mit aktiviertem ersten Reiter) ist in
Abbildung 13 zu sehen.
Fur jede eingehende Anfrage wird ein org.mmm.mediator.RequestSplitter erzeugt, der die
weitere Behandlung der Anfrage ubernimmt. Der RequestSplitter leitet die Anfrage zunachst
an ein Objekt der Klasse org.mmm.mediator.TreeGenerator weiter, das fur den Aufbau des
mobilen Codes zustandig ist. Der TreeGenerator benutzt die SQL2Algebra-Bibliothek von
70
Jan-Hendrik Lochner, die aus der Anfrage zuerst einen Syntaxbaum und schlielich einen Algebrabaum erstellt. In diesem Baum stehen lediglich java.lang.Strings in den Knoten; daher
nenne ich ihn im Folgenden Stringbaum\, um ihn von dem Algebrabaum (dem "Antwortbaum\) zu unterscheiden, der "den mobilen Code reprasentiert. Eine beispielhafte U bersetzung
einer Anfrage in den Syntaxbaum und den Stringbaum ist in Abbildung 14 angegeben.
select distinct tv1.COF_NAME from COFFEES tv1 where tv1.PRICE=7.99;
+
Syntaxbaum der SQL-Anfrage
---------------------------->Start
-> Anfrage
-> EinfacheAnfrage
-> Select
->
ATListe
->
ATerme
->
ATerm
->
TVariable
->
Attribut
-> From
->
VBListe
->
RSymbol
->
TVariable
-> Where
->
Bedingung
->
Formel
->
Atomformel
->
Term
->
ATerm
->
TVariable
->
Attribut
->
VglPraedikat
->
Term
->
Zahl
)
Algebra-Baum ("Stringbaum")
-------------|- PROJECT{COF_NAME}
|-- SELECT{PRICE=7.99}
|--- COFFEES
Abbildung 14: U bersetzung einer SQL-Anfrage in einen Stringbaum
Der RequestSplitter baut den Antwortbaum auf, indem er im Stringbaum eine Tiefensuche
durchfuhrt. Gelangt er dabei an ein Blatt, liest er die Teilanfrage aus, mit der das Blatt beschriftet ist. Er erstellt aus dieser Teilanfrage und dem Zertikat aus der Anfrage des Kunden
ein QueryWithCertificate-Objekt. Dieses Objekt schickt er an die ausgewahlte Datenquelle
weiter, indem er ihre Methode request() aufruft (beziehungsweise requestSigned(), wenn er
eine signierte Antwort haben mochte). Er ubergibt ihr zusatzlich die eingegebenen Anmeldeinformationen fur das Datenbankmanagementsystem. Die Teilantwort, die er bekommt, dient
als Blatt im Antwortbaum. Nahere Informationen dazu liefert der Abschnitt 8.2.2. Der Antwortbaum wird also beginnend bei den Blattern aufgebaut. Auf dem Ruckweg der Tiefensuche
auf dem Stringbaum wird fur jeden inneren Knoten ein entsprechendes Operator-Objekt fur
den Antwortbaum erzeugt und die zuvor bearbeiteten Knoten als Kinder eingesetzt. Welche
71
8.2 Mediatormodul
konkrete Klasse instanziiert wird, hangt zum einen vom Datenformat der Kinder und zum anderen von der Beschriftung des Knotens im Stringbaum ab. Steht im Stringbaum beispielsweise
UNION\ und ist das Datenformat der Kindknoten org.mmm.arrayformat.ArrayResult, dann
"wird
ein org.mmm.arrayoperators.ArrayResultUnion erstellt. Wie man anhand der unterschiedlichen Paketnamen bereits vermuten kann, werden die Binarcodes der Operatoren nicht
von den Datenquellen sondern vom Mediator bereitgestellt. Die von mir implementierten Operatoren werden im Abschnitt 8.2.3 noch naher erlautert. Der gesamte Antwortbaum wird in
einem Objekt der Klasse org.mmm.core.ResultExtractor gekapselt, das eine Referenz auf die
Wurzel des Antwortbaums enthalt. Nach dem Aufbau des Antwortbaums fugt der Mediator
dem ResultExtractor Java-Archive in Form von Byte-Feldern (byte[]) hinzu; sie enthalten
den Binarcode fur die verwendeten Datenformate und Operatoren, damit diese auch auf vom
Kundenmodul instanziiert werden konnen. Nun ist der mobile Code fertiggestellt. Er wird verschlusselt und signiert und die RMI-Methode gibt ihn an den Kunden zuruck. Alle Aufgaben
des Mediatormoduls sind im Ablaufschema in Abbildung 15 dargestellt. Der zeitliche Ablauf ist
am Sequenzdiagramm in Abbildung 30 (Anhang C, Seite 117) zu sehen. Ein paar Einzelheiten
des Mediatormoduls mochte ich im Folgenden noch naher erlautern.
ficate
hCerti
SQL2Algebra
AlgebraTreeComponent
Kunde
ResultOperator
i
Kn nne
ot rer
en
t
yWi
er
Qu
Blatt
Datenquelle
SealedResult
Mediator
ResultExtractor
Re
sul
tExt
ractor
ResultProxy
JARDatei
Abbildung 15: Ablaufschema fur das Mediatormodul
8.2.1 Aufbau des Algebrabaums
Fur den Antwortbaum habe ich das Entwurfsmuster der rekursiven Komposition (recursive
composition; vgl. [GHJV95], Seite 36) gewahlt. Alle Knoten im Baum mussen das Interface org.mmm.core.AlgebraTreeComponent implementieren und referenzieren andere Knoten
des Baumes nur uber dieses Interface. AlgebraTreeComponent schreibt den implementierenden
Klassen die Methode calculateResult() vor; der Ruckgabewert ist ein Result. Diese eindeutige Schnittstelle ermoglicht es den einzelnen Klassen, auf dem Kundenrechner von der Wurzel
des Antwortbaums beginnend rekursiv die Gesamtantwort auszurechnen.
Abbildung 16 zeigt die Komponenten, die im Baum auftauchen. Ein Knoten des Baums kann
ein Operator vom Typ org.mmm.core.ResultOperator oder eine Teilantwort-Referenz vom
Typ org.mmm.core.ResultProxy sein, die ich in den folgenden beiden Abschnitten vorstellen
werde. In der Abbildung sieht man auch, dass ein Objekt der Klasse ResultExtractor eine
Referenz auf genau ein Objekt vom Typ AlgebraTreeComponent hat; das ist die Wurzel des
Algebrabaumes. Operatoren haben mehrere Referenzen auf weitere Baumkomponenten; das
sind die Kinder des Operators im Algebrabaum.
72
Abbildung 16: Rekursive Komposition fur den Algebrabaum
8.2.2 Teilanfragen
In der derzeitigen Version der SQL2Algebra-Bibliothek sind die Teilanfragen alle von der Form
select distinct * from tabellenname\, da die Gesamtanfrage vollstandig in atomare Aus"dr
ucke zerlegt wird. Als Teilantwort zu einer solchen Teilanfrage liefert die Datenquelle immer
die ganze Tabelle an den Mediator zuruck. Der Mediator sendet mit dem Antwortbaum alle
Teilantworten weiter an den Kunden. Von einer Teilantwort werden aber eventuell nur wenige
Spalten und Zeilen in der Gesamtantwort benotigt, denn durch Projektionen und Selektionen
werden viele Eintrage dieser Tabelle hinterher wieder verworfen. In meinem Programm setze
ich die in Abschnitt 5.1 (Seite 28) erwahnten Optimierungen aber nicht ein; die Datenquelle
liefert immer eine vollstandige Tabelle als Teilantwort zuruck.
Die Teilantwort bekommt der Mediator als org.mmm.core.SealedResult. Diese Teilantwort
wird nicht direkt als Blatt in den Antwortbaum eingesetzt sondern in eine Teilantwortentabelle
(eine java.util.Hashtable) eingetragen, in der alle verschlusselten Teilantworten des mobilen Codes gespeichert werden. Als Blatt wird ein org.mmm.mediator.ResultProxy, der auf
den Eintrag in der Teilantwortentabelle verweist, erzeugt und in den Algebrabaum eingehangt.
Dieser ResultProxy ermoglicht es, auf dem Kundenrechner die verschlusselte durch die entschlusselte Teilantwort zu ersetzen, ohne in den Elternknoten der Blatter die Referenz auf die
verschlusselte Teilantwort durch eine neue Referenz auf die entschlusselte Teilantwort ersetzen
zu mussen. Es wird spater auf dem Kundenrechner das SealedResult entschlusselt und das daraus entstehende Result an dieselbe Stelle in der Teilantwortentabelle eingetragen. ResultProxy
implementiert das Interface AlgebraTreeComponent. Seine calculateResult-Methode sucht
den entsprechenden unverschlusselten Eintrag aus der Teilantwortentabelle heraus und gibt
ihn zuruck. Es braucht dazu eine Referenz auf die Teilantwortentabelle. Die erhalt es von dem
ResultExtractor, in dem es enthalten ist; deswegen braucht ein ResultProxy-Objekt auch
immer eine Referenz auf den entsprechenden ResultExtractor, wie es in Abbildung 16 zu
sehen ist.
73
8.2 Mediatormodul
8.2.3 Operatoren
Das Kundenmodul arbeitet nur mit der abstrakten Klasse org.mmm.core.ResultOperator.
Hier stelle ich die Operatoren fur das Format org.mmm.arrayformat.ArrayResult vor, die im
Paket org.mmm.arrayoperators deniert sind.
Abbildung 17: Relationale Operatoren
Wie in Abschnitt 3 erwahnt, habe ich zunachst die Operatorenklassen
ArrayResultSelection,
ArrayResultProjection,
ArrayResultUnion,
ArrayResultDifference,
ArrayResultCrossproduct und
ArrayResultRenaming
74
implementiert. Da ResultOperator das Interface AlgebraTreeComponent implementiert, mussen alle Operatoren die Methode calculateResult() implementieren. Alle Operatoren rufen
zunachst diese Berechnungsmethode auf ihren Kindern (beziehungsweise ihrem Kind { denn
der Umbenennungs-, der Selektions- und der Projektionsoperator sind unar und haben nur ein
Kind) auf und wenden danach auf die zuruckgegebenen Result-Objekte ihren Algorithmus an.
Der Selektionsoperator ArrayResultSelection ist etwas komplexer als die anderen Operatoren: ihm muss zusatzlich ein Selektionspradikat ubergeben werden. Innerhalb des Selektionspradikats lasse ich nur die arithmetischen Vergleichsoperatoren (=, , , , und 6=)
zu. Die logischen Operatoren (_, ^ und :) konnen durch eine weitere Ebene im Antwortbaum
dargestellt werden; ^ beispielweise durch Mengendierenz. Da die von Jan-Hendrik Lochner
verwendete Algebra allerdings nur die Vergleichsoperatoren = und 6= enthalt, konnen nur diese
in einer Anfrage verwendet werden. Von meiner Seite aus sind alle obengenannten arithmetischen Vergleichsoperatoren fur die Selektion moglich und konnen bei einer Erweiterung der
Algebra benutzt werden.
Abbildung 18: Vergleichsoperatoren fur die Selektion
75
8.2 Mediatormodul
Die arithmetischen Vergleichsoperatoren werden jeweils durch eine eigene Unterklasse des Interface org.mmm.selectioncomparators.SelectionComparator dargestellt. Alle vorhandenen
Vergleichsoperatoren sind in Abbildung 18 abgebildet. Einem Selektionsoperator wird bei der
Instanziierung ein SelectionComparator ubergeben. Mit ihm wird dann bei der Auswertung
der Selektion auf der Kindrelation entschieden, welche Zeilen in das Selektionsergebnis ubernommen werden. Dabei kann ein Vergleichsoperator in einem von drei Modi laufen: Zahlenvergleich, Zeichenkettenvergleich oder Attributvergleich. Zahlenvergleich und Zeichenkettenvergleich sind Vergleiche mit einem konstanten Wert (also entweder einer Zahl oder einer Zeichenkette). Der Selektionsoperator erhalt bei der Instanziierung den Namen des Attributs, auf
dem der Vergleich ausgefuhrt werden soll. Die Modi Zahlenvergleich und Zeichenkettenvergleich
werden beim Setzen der Vergleichskonstante mit der Methode setComparisonvalue(Object
object, int comparisontype) festgelegt. Bei der Auswertung des Vergleichs ruft der Selektionsoperator fur jede Zeile der Kindrelation die Methode check(Object value1) des Vergleichsoperators auf, der er den Wert des Attributs in der aktuellen Zeile ubergibt. Die Methode
vergleicht den eingegebenen Wert mit der Konstante und gibt als boolschen Wert zuruck, ob
der Vergleich erfolgreich war oder nicht. Beispiel fur eine Selektion mit einem Zahlenvergleich
ist:
"select distinct * from COFFEES tv1 where tv1.PRICE!=7.99;"
oder als algebraische Formel:
PRICE6=7:99 (COFFEES).
Die in diesem und den folgenden Beispielen verwendeten Tabellen sind in Anhang F aus Seite 120 zu nden. Diese Anfrage soll alle Kaees in der Relation COFFEES zuruckliefern, die
nicht 7,99 kosten. Hierfur wird ein Objekt der Klasse NotEqualComparator erstellt und die
Vergleichskonstante "7.99\ und der Modus Zahlenvergleich gesetzt.
Ein Vergleichsoperator
im Modus Attributvergleich vergleicht zwei variable Werte miteinander. Dem Selektionsoperator werden bei der Instanziierung die Namen der beiden Attribute
ubergeben, deren Werte fur jede Zeile der Relation verglichen werden sollen. Der Selektionsoperator wertet das Selektionspradikat dann mit der Methode check(Object value1, Object
value2) aus. Die beiden Eingabewerte sind die Werte der Vergleichsattribute in der aktuellen
Zeile. Diese Methode gibt ebenfalls einen boolschen Wert zuruck, der angibt, ob die beiden
Eingabewerte das Pradikat erfullen oder nicht. Zum Beispiel wird fur die Selektion
"select distinct * from COFFEES tv1 where tv1.SUPPLIER_ID = tv1.VENDOR_ID;"
beziehungsweise SUPPLIER ID=VENDOR ID (COFFEES),
die alle Kaees der Relation COFFEES ausgibt, die von Direkthandlern vertrieben werden, ein
Objekt der Klasse EqualComparator erstellt, dem bei der Instanziierung gleich die Namen der
Vergleichsattribute "SUPPLIER_ID\ und "VENDOR_ID\ ubergeben werden.
In der Anfrageubersetzung mit der SQL2Algebra-Bibliothek kamen zunachst nur die Operatoren Select, Project, Union, Join beziehungweise Join gefolgt von einem Complement vor. Um
eine Ebene im Baum zu sparen, habe ich zusatzlich zu den anfangs genannten die Operatorklasse ArrayResultJoin implementiert, anstatt den naturlichen Verbund aus den Basisoperatoren Kreuzprodukt, Selektion und Projektion zusammenzusetzen. Bei einer Erweiterung der
SQL2Algebra-Bibliothek um weitere Operatoren konnen auch meine zusatzlichen Operatoren
zum Einsatz kommen.
Fur den Komplementoperator ergab sich das Problem, dass auf einer realen Tabelle, die Attribute mit einem unendlichen oder sehr groen Wertebereich hat (wie zum Beispiel Daten oder
Zahlen), ein Komplement nicht umsetzbar ist. Es wurde sich eine unendliche oder sehr groe
Tabelle ergeben. Ein Komplement muss daher immer in Zusammenhang mit dem ubergeordneten Operator betrachtet und der Operator und das Komplement zusammen ausgefuhrt werden.
76
Fur den Fall des Join gefolgt von einem Complement wurden diese beiden Operatoren in der
SQL2Algebra-Bibliothek zu einem neuen binaren Operator JoinComplement verschmolzen.
Dieser Operator negiert die zweite Kindrelation bei der Auswertung des naturlichen Verbunds
mit der ersten Kindrelation. Der neue Operator JoinComplement kommt in Anfragen vor, in
denen eine "NOT-EXISTS\-Klausel auftritt, also beispielsweise
"select distinct tv1.COF_NAME, tv1.PRICE from COFFEES tv1 where not
exists(select distinct * from COFFEESTASTE tv2 where TASTE= 'sweet' and
tv1.COF_NAME = tv2.COF_NAME);".
In dieser Anfrage werden Name und Preis aller Kaees herausgesucht, deren Geschmack nicht
su ist. Der Geschmack ist in einer zweiten Relation namens COFFEESTASTE deniert. Fur JoinComplement wurde kein neues Operator-Objekt im Paket org.mmm.arrayoperators angelegt.
Stattdessen wurde der bestehenden Klasse ArrayResultJoin ein Konstruktor hinzugefugt, dem
mit einem boolschen Wert ubergeben werden kann, ob auf der zweiten Relation ein Komplement ausgefuhrt werden soll.
In spateren Versionen der SQL2Algebra-Bibliothek sollte die U bersetzung von Anfragen, in denen "NOT-EXISTS\-Klauseln oder "EXISTS\-Klauseln auftreten, nochmal uberarbeitet werden, da ihre Auswertung zur Zeit nicht der SQL-Semantik entspricht, wenn mehrere gemeinsame Attribute in den Tabellen vorhanden sind oder in der Anfrage keine Vergleichsattribute angegeben werden (wie etwa tv1.COF_NAME = tv2.COF_NAME). Derzeit wird auch noch ein
Komma zwischen zwei Relationennamen in einen Verbund und nicht { wie es der SQL-Semantik
entspricht { in ein Kreuzprodukt umgewandelt.
Die Laufzeiten der Operatoren im ungunstigsten Fall sind in Tabelle 7 aufgelistet. Die Laufzeiten sind bezuglich der Zeilenanzahl (durch jj jj gekennzeichnet) der bearbeiteten Tabellen
angegeben. Die Operatoren lieen sich eventuell noch optimieren; insbesondere konnten andere Datenformate implementiert werden, deren Operatoren kurzere Laufzeiten haben. Der
Projektions-Operator ArrayResultProjection hat die Laufzeit O(jjrjj logjjrjj). Der Faktor
logjjrjj tritt durch die Beseitigung von mehrfach vorhandenen Tupeln auf. Eine Laufzeit von
logjjrjj fur das Entdecken der Duplikate ist sichergestellt durch die Verwendung der Klasse
java.util.TreeSet. Wahrend die Ergebnisrelation der Projektion aufgebaut wird, werden die
Tupel der Ergebnisrelation in einem Objekt dieser Mengen-Klasse zwischengespeichert; Duplikate werden dabei nicht aufgenommen. Die Klasse TreeSet hat eine garantierte logarithmische
Laufzeit fur alle Operationen auf der Menge.
Klasse
ArrayResultSelection
ArrayResultProjection
ArrayResultUnion
ArrayResultDifference
ArrayResultCrossproduct
ArrayResultRenaming
ArrayResultJoin
Operator
Laufzeit
(R )
O(jjRjj)
(R )
O(jjRjj logjjRjj)
R[S
O(jjRjj + jjS jj)
R S
O(jjRjj jjS jj)
RS
O(jjRjj jjS jj)
(R)
O(1)
Ro
nS
O(jjRjj jjS jj)
Tabelle 7: Laufzeiten der Operatoren
8.2.4 Signierung und Verschlusselung des mobilen Codes
Der Multimediamediator muss die Integritat und Geheimhaltung des mobilen Codes auf dem
U bertragungsweg zum Kunden gewahrleisten. Um das sicherzustellen, verschlusselt das Mediatormodul mit dem oentlichen Schlussel des Kunden den fertigen mobilen Code zu einem
org.mmm.core.SealedResultExtractor. Er verwendet dazu das hybride Verfahren wie schon
8.2 Mediatormodul
77
die Datenquellen bei den Teilantworten. Im SealedResultExtractor sind der verschlusselte
Sitzungsschlussel als byte[] und eine Menge verschlusselter Binarcodes sowie der verschlusselte Antwortbaum (der ResultExtractor) innerhalb eines SealedObject enthalten. Der Mediator signiert schlielich dieses Objekt mit einem seiner privaten Signierschlussel und erhalt ein
java.security.SignedObject.
Abbildung 19: Benutzungsschnittstelle des Mediatormoduls (Algorithmenauswahl)
U ber die Benutzungsschnittstelle lassen sich der Signierschlussel des Mediators, der Signieralgorithmus und der symmetrische Verschlusselungsalgorithmus einstellen. Wie in Abbildung 19 zu
sehen ist, wahlt der oder die Administrator(in) des Mediators aus einem Schlusselspeicher einen
privaten Signierschlussel aus. Die Eingabe des Passworts zum Signierschlussel ist notwendig, da
er sonst nicht geladen werden kann. Es wird auerdem der Signieralgorithmus angegeben; der
Signieralgorithmus muss zum Schlussel passen { ein RSA-Schlussel sollte etwa zusammen mit
einem RSA-Signieralgorithmus verwendet werden. Freie Wahl hat man nur beim Prufsummenalgorithmus, der bei der Signierung verwendet werden soll { beispielsweise MD5 oder SHA1.
Der Schlusseltyp und der Prufsummenalgorithmus ergeben zusammen den Signieralgorithmus;
beispielsweise MD5/RSA, wie es in Abbildung 19 angegeben ist. Die Signierung selbst wird mit
der Klasse java.security.Signature (siehe Abschnitt 7.7 auf Seite 63) durchgefuhrt. Eine
Instanz dieser Klasse wird mit dem gewahlten Algorithmus initalisiert und an den Konstruktor
des SignedObjects ubergeben.
Der symmetrische Verschlusselungsalgorithums und die Schlussellange fur den neu zu erzeugenden Sitzungsschlussel konnen unter der Voraussetzung frei gewahlt werden, dass der Sitzungsschlussel kurz genug ist, um mit dem asymmetrischen Schlussel verschlusselt zu werden. Die
Algorithmen fur Signierung und Verschlusselung mussen fur das Mediatormodul uber einen
Kryptographie-Anbieter verfugbar sein. Das SignedObject und die SealedObjects im verschlusselten mobilen Code enthalten Informationen uber die verwendeten Algorithmen. Deshalb kann auf Kundenseite der entsprechende Verizierungsalgorithmus fur die Signatur und
der Entschlusselungsalgoritmus fur den mobilen Code aufgerufen werden. Voraussetzung ist
dabei, dass das Kundenmodul Zugri einen entsprechenden Kryptographie-Anbieter hat. Die
RMI-Methode, die der Kunde beim Mediator aufruft, um eine verschlusselte und signierte Antwort zu erhalten, ist requestSealedAndSigned().
Der Kunde muss den oentlichen Schlussel der Mediators bereits auf sicherem Weg erhalten
haben, damit er die Signatur prufen kann. Er kann sich beispielsweise von der Webseite des
Mediators ein Zertikat herunterladen, das diesen Schlussel enthalt. Das Zertikat kann er
78
dann in einen seiner Schlusselspeicher importieren. Die Erklarung, wie er dazu vorgehen muss,
folgt im Abschnitt 8.3.2 (Seite 82).
8.3 Kundenmodul
Das Kundemodul sendet RMI-Anfragen an einen Multimediamediator. Es stellt aber selbst keine RMI-Methoden zu Verfugung. Daher muss auf dem Kundenrechner keine RMI-Registratur
laufen. Wenn das Kundenmodul gestartet wird, erscheint ein Eingabefenster wie es in Abbildung 20 dargestellt ist. Der oder die Benutzer(in) wahlt zuerst im Eingabefenster eine Datei
aus, die einen Schlusselspeicher enthalt; dazu gibt er oder sie auch das Passwort an. Da-
Abbildung 20: Benutzungsschnittstelle des Kundenmoduls vor der Anfrage
Abbildung 21: Benutzungsschnittstelle des Kundenmoduls nach Ausfuhrung des mobilen Codes
8.3 Kundenmodul
79
nach werden in einer Ausklappliste die Aliasse aller Schlussel aufgelistet, die in dem gewahlten
Schlusselspeicher enthalten sind. Wenn der/die Benutzer(in) einen Alias ausgewahlt hat, gibt
er/sie auch dazu das Passwort ein. Ich verlange fur den Schlusselspeicher auf jeden Fall die
Eingabe des Passworts, um dessen Integritat zu uberprufen. Fur den Alias (also im Grunde
den dahinterliegenden privaten Schlussel) verlange ich ebenfalls das Passwort; hier fallt es also
schon vor dem Start der Anfrage auf, wenn das Kundenmodul die Antwort uberhaupt nicht
entschlusseln kann, da der oder die Benutzer(in) keinen Zugri auf den privaten Schlussel hat.
Der Mediator, an den eine Anfrage gestellt werden soll, wird ausgewahlt, indem man seinen
Rechnernamen oder seine IP-Adresse eingibt. Zu dem Mediator kann der oder die Benutzer(in)
aus einem Schlusselspeicher ein Zertikat auswahlen, das den oentlichen Schlussel des Mediators enthalt. Diese Schlussel wird zur Signaturprufung verwendet. Bleibt das Auswahlfeld
leer, wird keine Signaturprufung durchgefuhrt, aber es wird eine Warnung angezeigt, die darauf hinweist, dass die Authentizitat und Integritat der Antwort nicht uberpruft werden kann.
Die Anfrage selbst wird in das Suchfeld eingetragen und mit einem Klick auf den Suchknopf
wird die Suche gestartet. Wenn die Antwort des Mediators angekommen ist, wird dem/der
Benutzer(in) ein Abfragefenster angezeigt, in dem ausgewahlt werden kann, ob der Code sofort
ausgefuhrt und danach geloscht, ausgefuhrt und gespeichert, nur gespeichert oder verworfen
werden soll. Entscheidet er/sie sich fur das Ausfuhren des Codes, berechnet das Kundemodul
die Gesamtantwort, die anschlieend in der Ergebnistabelle der Benutzungschnittstelle angezeigt wird, wie in Abbildung 21 zu sehen ist.
Fur jede Anfrage wird ein org.mmm.client.SQLRequestor erzeugt. Der SQLRequestor ist die
Anwendungsklasse auf Kundenseite, die die notigen Einstellungen vornimmt, um den mobilen
Code entschlusseln und ausfuhren zu konnen. Zu den Aufgaben des SQLRequestor gehoren:
das Erstellen des Arbeitsverzeichnisses des mobilen Codes: Er erstellt fur jede Anfrage ein
Verzeichnis (ein Unterverzeichnis des Verzeichnisses repository im Startverzeichnis des
Kundenmoduls), das dem mobilen Code als Arbeitsverzeichnis dient. Dabei wird mit der
Methode java.io.File.createTempFile() ein eindeutiger Verzeichnisname generiert.
das Laden der Schlussel in die Ausklappliste: Er ladt zunachst den ausgewahlten Schlusselspeicher und erhalt mit der Methode KeyStore.aliases() die Aliasse aller Eintrage.
In die Ausklappliste werden nur die Aliasse eingefugt, die zu einem Schlusseleintrag gehoren.
das Erstellen der Anfrage: Da bisher noch keine Eigenschaftsnachweise bestehen, benutze ich in meinem Programm Zertikate, die keine weiteren Angaben uber Eigenschaften enthalten. Der Java-Schlusselspeicher erstellt bei der Generierung eines RSASchlusselpaars ein X.509-Zertikat fur den oentlichen Schlussel. Der SQLRequestor ladt
zu dem ausgewahlten Alias das Zertikat des oentlichen Schlussels aus dem Schlusselspeicher. Handelt es sich dabei nicht um einen RSA-Schlussel, wird eine Fehlermeldung geworfen. Aus dem Zertikat und dem eingegebenen Anfragetext erzeugt er ein
org.mmm.core.QueryWithCertificate.
das Erstellen des Entschlusselungsobjekts: Er erstellt einen org.mmm.client.Unsealer,
der die Entschlusselungsinformationen zwischenspeichert; das sind der Dateiname des
Schlusselspeichers, das Passwort des Schlusselspeichers, der Alias und das zugehorige
Passwort.
das Senden der Anfrage: Mit dem zuvor erstellten QueryWithCertificate als Parameter
wird die oentliche RMI-Methode requestSealedAndSigned() des Mediators aufgerufen. Als Ruckgabewert erhalt der SQLRequestor den mobilen Code als SignedObject,
das mit dem privaten Schlussel des Mediators signiert wurde.
das Prufen der Signatur (wenn ein Prufschlussel ausgewahlt wurde): Er pruft die Signatur
mit dem ausgewahlten Schlussel des Mediators. Aus dem SignedObject wird der mobile
80
Code in Form eines SealedResultExtractors extrahiert, der mit dem in der Anfrage
angegebenen oentlichen Schlussel des Kunden verschlusselt wurden. Wenn die Signatur
als nicht korrekt erkannt wurde, wird eine Warnmeldung angezeigt und der Benutzer
kann entscheiden, ob er den Code trotzdem entschlusseln und ausfuhren mochte.
je nach Auswahl das Entschlusseln des mobilen Codes und das Speichern des Binarcodes:
Wenn der Code ausgefuhrt werden soll, wird die Ausfuhrung des mobilen Codes damit
vorbereitet, dass der SQLRequestor das Entschlusselungsobjekt beauftragt, den mobilen
Code zu entschlusseln. Dabei erhalt es den Antwortbaum als ResultExtractor und den
Binarcode als eine Menge von Byte-Feldern (byte[]). Die Byte-Felder werden als JavaArchive in das Arbeitsverzeichnis des mobilen Codes gespeichert. Dann holt sich der
SQLRequestor vom ResultExtractor eine Referenz auf die Teilantwortentabelle, die die
verschlusselten Teilantworten des mobilen Codes verwaltet. Mit dem Entschlusselungsobjekt entschlusselt der SQLRequestor alle Teilantworten. Im Abschnitt 8.3.3 gehe ich
auf weitere Einzelheiten des Entschlusselungsverfahrens ein.
je nach Auswahl das Hinzufugen der Binardateien in den Suchpfad: Vor der eigentlichen
Ausfuhrung fugt das Kundenmodul des Codes die Namen der zum Code gehorende JARDateien zum Klassenlader-Suchpfad hinzu, damit der Binarcode der im Baum enthaltenen
Operatoren gefunden und geladen werden kann. Details zum Laden des mobilen Codes
nden sich im Abschnitt 8.3.1.
je nach Auswahl das Berechnen des Antwortbaumes: Der SQLRequestor stot den mobilen Code an, die Gesamtantwort zu berechnen. Dazu ruft beginnend bei der Wurzel jeder
innere Knoten im Baum rekursiv die Berechnungsmethode calculateResult() seiner
Kinder auf und fuhrt, wenn er deren Ergebnisse erhalten hat, den algebraischen Operator, den er reprasentiert, auf diesen Ergebnissen aus. Wenn ein Blatt im Baum erreicht
wird, sucht der dort bendliche ResultProxy aus der Teilantwortentabelle die zu ihm
gehorende entschlusselte Teilantwort heraus und gibt sie zuruck.
je nach Auswahl das Loschen des Binarcodes aus dem Suchpfad: Nachdem die Gesamtantwort berechnet wurde, werden die Klassendateien des mobilen Codes nicht mehr benotigt.
Damit spater ausgefuhrte mobile Codes nicht auf die falschen Klassendateien zugreifen
und auch damit der Suchpfad nicht zu lang wird, entfernt der SQLRequestor die Namen
der JAR-Dateien wieder aus dem Klassenlader-Suchpfad. Da die Klassendateien eines
mobilen Codes potenziell gefahrlich fur den Kundenrechner sind, ist es zudem sinnvoll,
den Zugri auf diese Dateien zeitlich nur auf die Ausfuhrung des Codes zu beschranken.
Auf das genaue Vorgehen gehe ich im folgenden Abschnitt 8.3.1 noch ein.
je nach Auswahl das Speichern des Antwortbaumes im Arbeitsverzeichnis: Wenn der
mobile Code gespeichert werden soll, wird der verschlusselte und signierte mobile Code (das SignedObject, das den SealedResultExtractor enthalt) serialisiert und in das
Arbeitsverzeichnis gespeichert. Damit spater auch eine Entschlusselung moglich ist, wird
zusatzlich das Entschlusselungsobjekt serialisiert und ebenfalls dort gespeichert; allerdings werden vorher die Passworter aus dem Objekt geloscht, damit der Benutzer sie
beim erneuten Ausfuhren wieder eingeben muss.
je nach Auswahl das Loschen des Arbeitsverzeichnisses: Wenn der mobile Code nicht
gespeichert werden soll, wird das gesamte Arbeitsverzeichnis des mobilen Codes nach
seiner Ausfuhrung geloscht. Damit wird auch der potenziell gefahrliche Binarcode des
mobilen Codes wieder vom Kundenrechner entfernt.
In Anhang B auf Seite 116 bendet sich ein Sequenzdiagramm, das die Ablaufe im Kundenmodul darstellt.
Michael Englbrecht (vgl. [Eng03], Seite 313-314) beschreibt, dass eine schmale Schnittstelle
8.3 Kundenmodul
81
zwischen Kundenrechner und mobilem Code { idealerweise also mobiler Code mit nur einem
Einstiegspunkt { unkontrollierten Informationsuss vermeiden hilft, da der Zugri auf den Code und dessen Ausfuhrung dadurch besser kontrollierbar ist. Im Gegensatz dazu gibt es in
meinen mobilen Code drei Einstiegspunkte: die Methoden getJarFiles(), getResultHash()
und calculateResult(). Dies liegt daran, dass das Kundenmodul so die sicherheitsrelevanten
Operationen "Speichern des Binarcodes\, "Entschlusseln der Teilantworten\ und "Starten der
Ausfuhrung\ ubernimmt und sie nicht dem mobilen Code uberlasst. Das bedeutet insbesondere, dass der mobile Code auf dem Kundenrechner keine Berechtigungen benotigt; darauf gehe
ich in den Abschnitten 8.3.3 und 9.1 noch naher ein.
In den folgenden Abschnitte mochte ich einige Implementierungsdetails des Kundenmoduls
herausheben. Im folgenden Abschnitt 9 werden ich dann mogliche Angrie auf das Multimediamediatorsystem diskutieren.
8.3.1 Ersetzen des Systemklassenladers
Der Mediator schickt mit einer Antwort dem Kunden auch den Binarcode der Operatoren
und Datenformate innerhalb des Antwortbaums zu. Dieser Code muss dem laufenden Kundenmodul zur Verfugung gestellt werden. Wie in Abschnitt 7.3 beschrieben, konnen den bereits gestarteten Standard-Klassenladern keine Binarcodes hinzugefugt werden. Daher musste ich einen eigenen Klassenlader { den org.mmm.start.MMMClientLoader { implementieren, der das dynamische Hinzufugen von Binarcodes ermoglicht. Wie im selben Abschnitt
erwahnt, muss ein selbstdenierter Klassenlader von Code, der ihn benutzen will, explizit
angesprochen werden. Fur den mobilen Code bedeutet das, dass er anstelle eines Konstruktors (new klassenname ()), der immer den Systemklassenlader benutzt, entweder die Methode
MMMCLientLoader.loadClass(klassenname ) oder die Methode Class.forName(klassenname ,
resolve, mmmClientLoader) aufrufen m
usste, um Instanzen von selbstdenierten Klassen zu
erzeugen. Programmiererinnen oder Programmierer von mobilem Code durften also nur fur
die Java-Standardklassen den new-Operator benutzen und mussten fur Klassen, die allein zum
Binarcode des mobilen Codes gehoren, eine der Methoden wahlen. Abgesehen davon, dass dieses Vorgehen die Implementierung des mobilen Codes verkompliziert, will man dem mobilen
Code auch keinen direkten Zugri auf den Klassenlader erlauben, da er mit dieser Referenz
auch andere Methoden auf diesem Objekt aufrufen konnte. Da die Zugrissteuerung in Java
immer paketweise geschieht, wurde die Berechtigung fur den Zugri auf den Klassenlader sogar den Zugri auf andere Klassen im selben Paket beinhalten. Ein zweiter Punkt ist, dass
das Kundenmodul beim Entschlusseln und Wiederherstellen des Algebrabaum-Objektes (des
ResultExtractors) die Moglichkeit haben muss, auf die innerhalb des Codes benutzten Klassen
zuzugreifen, da sie auf dem Kundenrechner dabei neu instanziiert werden. Diese Instanziierung
wird aber implizit von den Java-Bibliotheksklassen durchgefuhrt, so dass ich als Programmiererin den dafur benutzten Klassenlader gar nicht bestimmen kann.
Es gibt eine einzige Moglichkeit, die Benutzung von Konstruktoren im mobilen Code zuzulassen, den Zugri auf den Klassenlader innerhalb des mobilen Codes zu verhindern und das
automatische Instanziieren des Antwortbaums im Kundenmodul zu ermoglichen: mein Klassenlader MMMClientLoader muss Systemklassenlader werden. Dies geschieht, indem man der
Java-Systemvariable java.system.class.loader als Wert den Klassennamen des Klassenladers zuweist. Ich tue das beim Starten der virtuellen Maschine in der Kommandozeile:
java -cp ./start.jar -Djava.system.class.loader=org.mmm.start.MMMClientLoader
org.mmm.start.Starter
Der MMMClientLoader ist dann, wie in Abbildung 22 dargestellt, direktes Kind des Erweiterungsklassenladers.
Der MMMClientLoader besitzt zwei neue Methoden: eine zum Hinzufugen Dateistandorten
zu seinem Suchpfad und eine zum Loschen von Dateistandorten aus seinem Suchpfad. Die
82
Urklassenlader
loadClass()
Erweiterungsklassenlader
loadClass(){
parent.loadClass();
...
}
MMMClientLoader
loadClass(){
parent.loadClass();
...
}
addURLLocation()
removeURLLocation()
Abbildung 22: MMMClientLoader als Systemklassenlader
Klasse, die den mobilen Code auf dem Kundenrechner verwaltet, namlich der SQLRequestor,
bekommt mit der Methode ClassLoader.getSystemClassLoader() eine Referenz auf den
MMMClientLoader. Auf diesem Objekt ruft der SQLRequestor vor dem Starten des mobilen Codes die Methode zum Hinzufugen von Dateinstandorten auf (addURLLocations(URL[]
urls)). Der Eingabeparameter ist ein Feld mit den Dateinamen, unter denen der Binarcode
(als Java-Archive) im Arbeitsverzeichnis des mobilen Codes gespeichert wurden. Damit kann
der MMMClientLoader zur Laufzeit die im mobilen Code verwendeten Klassen nden und laden.
Bei gleichlautenden Klassennamen wird der Klassenlader den Dateistandort zum Laden der
Klasse wahlen, der sich zuerst in seinem Suchpfad bendet. Wenn die hinzugefugten Dateinamen der Java-Archive nie aus dem Suchpfad geloscht wurden, wurde eine Klasse eines spateren
Codes, die denselben Namen hat wie eine Klasse eines fruheren Codes, nie geladen; der Klassenlader wurde vielmehr immer die zuerst hinzugefugte Klasse laden. Damit ist der spatere mobile
Code aber wahrscheinlich nicht mehr ausfuhrbar. Wenn der fruhere mobile Code Angrie auf
den Kundenrechner durchfuhren will, die aber beim ersten Ausfuhren des Codes verhindert
wurden, kann es damit sogar sein, dass die Angrie beim Ausfuhren eines ganz anderen mobilen Codes Erfolg haben. Ein fruherer und ein spaterer Code konnten sogar ein Komplott bilden:
Der erste Code hat in seinem Binarcode eine bosartige Klasse aber greift gar nicht auf sie zu;
der zweite Code hat die Klasse nicht in seinem Binarcode, wird aber auf sie zugreifen und
den Angri ausfuhren. Auerdem verlangert ein langer Suchpfad die Suche nach einer Klasse,
da viel mehr Dateinstandorte gepruft werden mussen, bevor der richtige gefunden wird. Auf
jeden Fall ist es also sinnvoll, dass der SQLRequestor mit der Methode removeURLLocations()
die Dateinamen des Binarcodes wieder aus dem Suchpfad entfernt, sobald die Gesamtantwort
berechnet wurde.
8.3.2 Signaturprufung und Entschlusselung des mobilen Codes
Der Benutzer oder die Benutzerin muss wissen, welchen Schlussel der Mediator zu Signierung
seiner Antwort verwendet. Sie wollen mit dem oentlichen Gegenstuck prufen, ob der mobile
Code wirklich vom ausgewahlten Mediator kommt und bei der U bertragung nicht verandert
8.3 Kundenmodul
83
wurde. Sie mussen ein entsprechendes Zertikat, dass den oentlichen Schlussel fur die Prufung
der Signatur enthalt, bereits vor dem Start der Anfrage erhalten haben. Dieses Zertikat muss
dann in einen Schlusselspeicher importiert werden. Dazu benutzt man das KommandozeilenProgramm keytool. Der Import des Zertikats "mediatorrsa.cer\ in den Schlusselspeicher
"clientstore\ geschieht beispielsweise mit diesem Aufruf:
keytool -keystore clientstore -import -alias mediatorrsa -file mediatorrsa.cer
fragt noch einmal nach, ob dem Zertikat vertraut werden soll, bevor der Eintrag
erstellt wird.
Fur die U berprufung der Signatur in meinem Programm benutze ich wiederum ein SignatureObjekt (siehe Abschnitt 7.7 auf Seite 63). Das Kundenmodul ladt aus dem ausgewahlten Zertikat des Mediators dessen oentlichen Schlussel und ruft dann mit diesem Schlussel und dem
Signature-Objekt die verify-Methode des zu pr
ufenden SignedObject auf. Der Benutzer
muss den Signaturprufungsalgorithmus nicht selbst angeben, da das SignedObject diese Information bereithalt.
Wenn die Signatur als nicht gultig erkannt wurde, wird der Benutzer darauf hingewiesen. Es
liegt dann in seiner Entscheidung, ob er den Code trotzdem ausfuhren mochte. Da die Signatur
hier nur als Mittel zur Integritatssicherung aber nicht als Grundlage fur Sicherheitsuberprufungen eingesetzt wird, ist die grote Gefahr bei einer falschen Signatur darin zu sehen, dass
die Daten verfalscht wurden und damit die Antwort nicht glaubwurdig ist.
Der SQLRequestor ruft zur Entschlusselung des mobilen Codes eine Methode des Entschlusselungsobjekts Unsealer auf: unsealResultExtractor(). Die Methode benutzt zunachst einen
Cipher, der mit dem asymmetrischen Algorithmus "RSA/ECB/OAEPPadding" den Sitzungsschlussel entschlusselt. Danach verwendet sie einen symmetrischen Cipher, der mit dem Algorithmus initialisiert wird, mit dem die Verschlusselung auf Mediatorseite durchgefuhrt wurde.
Die Information uber den verwendeten Algorithmus ist, wie bereits erwahnt, im verschlusselten
Objekt enthalten. Mit dem Cipher wird dann der Binarcode des mobilen Codes entschlusselt und als eine oder mehrere JAR-Dateien in das Arbeitsverzeichnis des Codes gespeichert.
Schlielich wird der Algebrabaum zu einem ResultExtractor entschlusselt und zur weiteren
Bearbeitung an den SQLRequestor zuruckgegeben.
keytool
8.3.3 Entschlusselung der Teilantworten
Mein erster Ansatz zur Entschlusselung der Teilantworten innerhalb des mobilen Codes auf
dem Kundenrechner war es, dem mobilen Code eine Referenz auf das Entschlusselungsobjekt Unsealer zu geben. In diesem Fall muss die Verschlusselung nicht vom Kundenmodul in einem extra Methodenaufruf angestoen werden, sondern wird aus dem mobilen Code selbst aufgerufen. Der Unsealer benotigt zum Entschlusseln den privaten Schlussel des
Kunden aus dem entsprechenden Schlusselspeicher. Um den Schlussel auszulesen, braucht der
Unsealer eine Leseberechtigung auf der Schl
usselspeicher-Datei. Wegen der Referenz des mobilen Codes auf den Unsealer musste auch der mobile Code die Leseberechtigung auf der
Schlusselspeicher-Datei haben (so wie es das Berechtigungskonzept vorsieht; siehe Abschnitt
7.4 auf Seite 60). Diese sollte er aber nicht bekommen, da er damit potenziell Zugri auf
vertrauliche Daten hat; und das selbst wenn der Unsealer keine Passworter oder Aliasnamen an den mobilen Code "verrat\. Wie oben erwahnt, kann ein Angreifer ohne ein Passwort anzugeben Kenntnis von allen Aliassen erlangen, indem er einfach KeyStore.aliases()
aufruft. Er kann damit zumindest das Erstellungsdatum eines Schlusseleintrages mit der Methode java.security.KeyStore.getCreationDate(String alias) erfragen; einen Schlussel,
der nicht durch ein Passwort geschutzt wurde, kann er sogar komplett auslesen. Dieser Ansatz
ist daher nicht praktikabel.
Als zweiten Ansatz habe ich uberlegt, die Entschlusselungsoperation des Entschlusselungsobjekts als privilegierten Code zu implementieren. Der mobile Code kann mit einer Referenz
84
auf den Unsealer selbst die Entschlusselung durchfuhren ohne eine Leseberechtigung fur den
Schlusselspeicher zu haben, wenn der Unsealer die sicherheitsrelevanten Teile der Entschlusselung in einem doPrivileged-Block ausfuhrt. Der mobile Code erhalt dann weiterhin eine Referenz auf das kundenseitige Entschlusselungsobjekt, aber er braucht keine Leseberechtigung fur
den Schlusselspeicher. Wie in Abschnitt 7.6 beschrieben ist der Aufruf der Entschlusselungsmethode vom Kundenmodul nicht mehr zu kontrollieren. Der mobile Code konnte die Methode
beliebig oft aufrufen.
Das entscheidende Argument gegen die beiden oben vorgestellten Ansatze ist meiner Meinung
nach jedoch, dass der mobile Code in beiden Fallen eine Referenz auf ein Kundenmodul-Objekt
erhalt. Das fuhrt dazu, dass das Kundenmodul fur den mobilen Code sichtbar und zugreifbar gemacht wird, so dass er dort Methoden aufrufen kann. Es muss dann sichergestellt werden, dass
nicht ungewollt Informationen aus Kundenmodul-Objekten zu Objekten des mobilen Codes
ieen. Ich habe mich gegen die Ansatze mit Referenzen auf Kundenmodul-Objekte entschieden, so dass der mobile Code keine unsichtbaren und unkontrollierbaren Methodenaufrufe auf
Kundenmodul-Objekten ausfuhren kann. Ich habe deswegen zwar mehrere Einstiegspunkte in
den mobilen Code, aber sie stellen eine klare oentliche Schnittstelle dar, die vom Kundenmodul
kontrolliert aufgerufen wird.
85
9 Mogliche Angrie auf das Mediatorsystem
Das von mir entwickelte System muss mit den in Abschnitt 6 (ab Seite 34) diskutierten Sicherheitsrisiken, die die Verwendung von mobilem Code mit sich bringt, umgehen konnen. Da nicht
alle geschilderten Sicherheitsrisiken durch mobilen Code entstehen, will ich hier nur auf die relevanten Punkte eingehen. Fur die Angrie des Mediators auf den Kunden (siehe Abschnitt 6.4
auf Seite 45) gilt beispielsweise, dass das Senden einer langen Antwort und das Veruntreuen
von Eigenschaftsnachweisen auch in Systemen ohne mobilen Code moglich ist. Da auerdem
bei der Implementierung kein beweismitfuhrender Code eingesetzt wurde, kann die Korrektheit
der Antwort des Mediators nicht mit der Methode, die in Abschnitt 6.4.2 beschrieben wurde,
sichergestellt werden.
Im nachsten Abschnitt beschreibe ich, welche Angrie auf das Kundenmodul durchgefuhrt
werden konnen. Danach gehe ich auf Angrie auf den Code wahrend der U bertragung und auf
dem Kundenrechner ein.
9.1 Angrie des mobilen Codes auf den Kunden
In der Implementierung des Kundenmoduls, wie sie Abschnitt 8.3 vorgestellt wurde, benotigt der mobile Code keine Berechtigungen { insbesondere keine, die sich dynamisch andern.
Daher eignet sich das Sandkasten-Konzept (siehe Abschnitt 6.2.4, Seite 43) zum Schutz des
Kunden vor Angrien des mobilen Codes. Den Sandkasten habe ich mit Java-Berechtigungen
(beziehungsweise der Nicht-Vergabe von Berechtigungen an den mobilen Code) umgesetzt. Das
mochte ich im Folgenden noch naher erlautern.
Beim Starten des Kundenmoduls wird eine Berechtigungsdatei eingelesen, die die zu vergebenden Berechtigungen fur die einzelnen Java-Archive auistet. Da der mobile Code keine Berechtigungen (auch nicht indirekt uber doPrivileged-Aufrufe) bekommt, enthalt die Berechtigungsdatei nur Eintrage fur die Java-Archive start.jar (in dem das Paket org.mmm.start
enthalten ist) und bin/client.jar (das die Pakete org.mmm.client, org.mmm.client.view
und org.mmm.core bundelt). Diese Pakete bilden das Kundenmodul und sind standig auf dem
Kundenrechner vorhanden. Von ihnen wird kein Angri auf den Kundenrechner erwartet. Sie
erhalten mittels des in Abbildung 23 abgebildeten Auszugs aus der Berechtigungsdatei allerdings auch nur das Minimum an Berechtigungen, das sie fur die Ausfuhrung des Kundenmoduls
benotigen.
Das Paket org.mmm.start enthalt zum Einen die Klasse Starter, die grundlegende, sicherheitsrelevante Einstellungen vornimmt: Sie legt die Paketzugrisuberprufung fest und dazu
bekommt das Java-Archiv start.jar die Berechtigungen zum Lesen und Setzen der Systemvariablen package.access. Auerdem fugt sie den BouncyCastleProvider (siehe [BCP]) als
Kryptographie-Anbieter hinzu und deswegen bekommt das Java-Archiv start.jar die Berechtigungen zum Lesen und Setzen der Systemvariablen security.provider. Das Paket enthalt zum Anderen den Klassenlader MMMClientLoader. Da der MMMClientLoader Systemklassenlader ist und beim Start der virtuellen Maschine geladen wird, benotigt das Java-Archiv
start.jar die Berechtigung zum Erstellen eines Klassenladers. Der Suchpfad des Klassenladers wird mit dem Dateistandort bin/client.jar initialisiert. Um Klassen aus diesem JavaArchiv laden zu konnen, bekommt das Java-Archiv start.jar die Berechtigung zum Lesen
dieses Dateistandorts. Zur Laufzeit ladt der MMMClientLoader Klassen aus den Binarcodes
der mobilen Codes und muss daher lesend auf die Arbeitsverzeichnisse der mobilen Codes (als
Unterverzeichnisse des Verzeichnisses repository) zugreifen konnen. Andere Berechtigungen
zum Lesen von Dateien sieht dieser Eintrag fur das Java-Archiv start.jar aber nicht vor.
Der zweite Eintrag der Berechtigungsdatei ist fur das Archiv client.jar zustandig. Die Klassen innerhalb diese Archivs durfen auf alle Dateien innerhalb des Verzeichnisses keystores
86
grant codeBase "file:start.jar" {
...
permission java.io.FilePermission "bin/client.jar","read";
permission java.io.FilePermission "repository/-","read";
permission java.lang.RuntimePermission "createClassLoader";
permission java.security.SecurityPermission "getProperty.security.provider.*";
permission java.security.SecurityPermission "setProperty.security.provider.*";
permission java.security.SecurityPermission "getProperty.package.access";
permission java.security.SecurityPermission "setProperty.package.access";
...
};
grant codeBase "file:bin/client.jar" {
...
permission java.io.FilePermission "keystores/-","read";
permission java.io.FilePermission "repository/-","read, write, delete";
permission java.lang.RuntimePermission "exitVM";
permission java.lang.RuntimePermission "getClassLoader";
permission java.net.SocketPermission "*","connect,resolve";
...
};
Abbildung 23: Auszug aus der Berechtigungsdatei des Kundenmoduls
lesend zugreifen. Hier sollen sich alle Schlusselspeicher des Kunden benden und das Paket
org.mmm.client braucht diese Leseberechtigung, um einen Schl
usselspeicher laden und Schlussel und Zertikate auslesen zu konnen. Eine Klasse des Pakets org.mmm.client speichert die
Binarcodes der mobilen Codes in das Arbeitsverzeichnis und loscht sie von dort auch wieder. Daher wird dem Archiv client.jar die Schreib- und Loschberechtigung fur Unterverzeichnisse des
Verzeichnisses repository zugewiesen. Das Archiv bekommt auch Lesezugri auf diese Arbeitsverzeichnisse der mobilen Codes. Daran sieht man, dass in einer Aufrufkette die aufrufenden
Klassen ebenfalls die Berechtigungen benotigen, die die aufgerufenen Klassen brauchen. Denn
das Archiv client.jar ruft die die Methode des Klassenladers (der sich in start.jar bendet)
zum Hinzufugen von Dateistandorten in den Suchpfad auf. Bei der Ausfuhrung diese Methode
wird schon Leseberechtigung auf diesen Dateistandorten uberpruft. Da diese Anweisung sich in
einer Aufrufkette bendet, die von einer Klasse aus client.jar angestoen wurde, muss auch
client.jar die Leseberechtigung zugewiesen werden. Das Paket org.mmm.client benotigt
auch eine Berechtigung fur den Zugri auf den Klassenlader, um eine Referenz auf den Klassenlader zu erhalten und die Hinzufuge- und Loschmethoden von Dateistandorten uberhaupt
aufrufen zu konnen. Fur den Aufbau einer Verbindung zu einem Mediatorrechner bekommt
das Archiv client.jar auch die entsprechende Berechtigung java.net.SocketPermission.
Und da beim Schlieen des Eingabefenster auch der Java-Prozess beendet werden soll, weist
der Eintrag dem Paket schlielich noch die Berechtigung zum Beenden der virtuellen Maschine
zu.
Die Pakete org.mmm.core und org.mmm.client habe ich deswegen im Archiv client.jar
zusammengefasst, da Klassen aus core nur von Klassen aus client aufgerufen werden und
sich damit immer innerhalb einer Aufrufkette benden, die von einer Klasse aus client initiiert wurde. Die Berechtigungen, die dem Paket core zugewiesen werden, sind daher in jedem
Fall eine Teilmenge der Berechtigungen, die dem Paket client zugewiesen werden, und ich
habe die Zuweisungen zu einem Eintrag in der Sicherheitsregel zusammengefasst. Das Paket
org.mmm.start hingegen hat viele Berechtigungen, die nur beim Starten des Programms eine
Rolle spielen und die die anderen Pakete nicht benotigen. Daher ist es in einem eigenen Java-
87
Archiv enthalten.
Leider lassen sich durch die Nichtvergabe von Privilegien an Code nicht alle Angrie verhindern. Im Paket org.mmm.attacks sind Klassen enthalten, die versuchen, Angrie auf den
Kundenrechner durchzufuhren. Ob die in Abschnitt 6.2 aufgefuhrten Schutzziele mit JavaMechanismen einzuhalten sind, oder ob die Angrie der Angrisklassen Erfolg haben, mochte
ich in den folgenden Abschnitten untersuchen. Die Aufteilung auf die einzelnen Schutzziele
sieht wie folgt aus: Die Integritat von Daten und Programmen wird in den Abschnitten 9.1.4
und 9.1.5 und die Vertraulichkeit von Daten in den Abschnitten 9.1.7 und 9.1.3 behandelt.
Die Abschnitte 9.1.1 und 9.1.7 betrachten Angrie auf die Verfugbarkeit des Kundenrechners.
Mit dem Komplott zweier mobiler Codes befasst sich Abschnitt 9.1.8 und die Abschnitte 9.1.2
und 9.1.6 gehen auf das Auftreten des mobilen Codes unter falscher Identitat ein. Abschnitt
9.1.3 beschaftigt sich mit dem moglichen Nachladen von Code. Tabelle 8 gibt noch einmal eine
U bersicht uber die moglichen Angrie.
Angri auf
Integritat
in Form von
Programm- und
Datenkorruption
Vertraulichkeit Spionage
Verfugbarkeit Ressourcendiebstahl
alle obigen
alle obigen
alle obigen
Beispiel
Zugri auf den Klassenlader und Kundenmodulklassen; Zugri auf das Dateisystem
Zugri auf das Dateisystem und andere Ressourcen
Zugri auf Java-Standardklassen; Zugri auf den
Prozessor und den Arbeitsspeicher
Komplott mehrerer Kommunikation zweier mobiler Codes uber das
Codes
Einzelganger-Muster
Auftreten unter Benutzung von nativen Bibliotheken; O nen eines
falscher Identitat
Eingabefensters
Nachladen
von Code darf auf die Netzwerkschnittstelle zugreifen
schadlichem Code und Daten empfangen
Tabelle 8: Javatypische Angrie des mobilen Codes
9.1.1 Angri: Zugri auf Java-Standardklassen
Der mobile Code benotigt fur seinen Berechnungen zumindest die Klasse java.lang.Object
und einfache Datentypen beziehungweise ihre Hullklassen (engl. wrapper classes), die sich ebenfalls im Paket java.lang benden. Auerdem sollte er Zugri auf grundlegende Datenstrukturen haben, wie sie im Paket java.util vorhanden sind. Allerdings gibt es einige Klassen in
der Java-Standardumgebung, auf die der mobile Code keinen Zugri haben sollte.
Das Kundenmodul hangt direkt nach dem Start an die Systemvariable package.access die
Namen der Pakete, fur die ein Zugri kontrolliert werden soll. Das sind die Pakete java.io,
java.security, java.util.logging und java.lang.reflect. Damit werden der Zugri auf
das Dateisystem und die Sicherheitsklassen sowie die Benutzung von Kontrollausgaben und
Java-Reektion { die den Zugri auf Klassen erlaubt, ohne die Bereichsmodikatoren zu beachten { unterbunden.
Eine feinere Zugriskontrolle fur einzelne Klassen ist nicht moglich. Zum Beispiel lasst sich
mit diesem Mechanismus nicht der Zugri auf java.lang.Thread verhindern, da das Paket
java.lang die grundlegende Java-Klasse Object und weitere Klassen enthalt, die der mobile
Code in jedem Fall benotigt. Der mobile Code kann also unkontrolliert viele neue Threads
starten. Diese Threads sind vom Kundenmodul nicht mehr zugreifbar, da kein KundenmodulObjekt Referenzen auf diese Threads hat. Daher hat der Angri Erfolg, den meine Angrisklasse org.mmm.attacks.ThreadProducer durchfuhrt: Sie startet in einer Endlosschleife neue
Threads, die nur durch das Schlieen des Kundenmodulfensters und damit das Beenden der
virtuellen Maschine gestoppt werden konnen. Abgesehen davon, dass die neu erstellten Threads
88
unerreichbar sind, ist zudem das Stoppen von Threads in einer laufenden virtuellen Maschine ein bisher ungelostes Problem in Java. Der Aufruf der Methode stop() fur einen Thread
kann zu einer Blockierung (einem deadlock) der ganzen virtuellen Maschine fuhren. Ein weiteres Beispiel fur die zu grobe Zugriskontrolle von Java sind die Eingabe- und Ausgabestrome (standardmaig Tastatureingaben und Bildschirmausgaben). Die Strome werden von der
Klasse System verwaltet, die sich ebenfalls im Standardpaket java.lang bendet. Der mobile
Code kann mit dem Aufruf System.in.read() seine Ausfuhrung unterbrechen und auf eine
Eingabe des Standardeingabestroms warten. Dadurch wird auch die Benutzungsschnittstelle
unbedienbar. Selbst ein Schlieen des Fensters ist nicht mehr moglich und der Benutzer muss
den Java-Prozess auf eine andere Weise beenden. Auch beliebige (sogar endlose) Bildschirmausgaben sind dem mobilen Code mit dem Aufruf System.out.println() moglich. Meine Klasse
uhrt diese beiden Angrie durch. Verhindert werden konnen diese
org.mmm.attacks.InOut f
Angrie nur durch eine Erweiterung der Java-Standardklassen. So konnte zum Erstellen von
Threads eine neue Berechtigung eingefuhrt werden.
Fur einige spezielle Methodenaufrufe auf Java-Standardklassen gibt es besondere Berechtigungen. Beispielsweise kann man die Eingabe-/Ausgabestrome mit den Methoden System.setIn()
und System.setOut() umlenken. Dafur benotigen die aufrufenden Klassen jedoch die Berechtigung java.lang.RuntimePermission mit der Aktion setIO. Ebenso braucht man fur
die Aufrufe von System.exit oder Runtime.exit zum Beenden der virtuellen Maschine eine
RuntimePermission mit der Aktion exitVM. Es sind aber nicht alle Methodenaufrufe so geschutzt. So kann der mobile Code uber die Klasse java.lang.Runtime mit den Aufrufen von
totalMemory() und freeMemory() die Groe des gesamten Arbeitsspeicher, der der virtuellen
Maschine zugewiesen wurde, sowie des davon noch unbenutzten Speichers abfragen. Die Klasse,
die einen solchen Angri durchfuhrt, ist org.mmm.attacks.SystemAccessor.
An diesen Beispielen wird deutlich, dass die Java-Zugriskontrolle noch durch eine Vielzahl
von Berechtigungen erganzt werden konnte. Da Berechtigungsuberprufungen aber auch immer
Einbuen in der Laufzeit nach sich ziehen, sollten aber auch nicht ubermaig viele neue Berechtigungen hinzukommen. Eine Kontrolle uber den Zugri auf Threads und die Eingabe- und
Ausgabestrome halte ich aber fur sehr sinnvoll.

9.1.2 Angri: Onen
eines Eingabefensters
Eine besonders kritische Form des Zugris auf Standardklassen ist die Benutzung von Elementen graphischer Benutzungsschnittstellen. U ber Benutzungsschnittstellen kann der mobilde Code eine Kommunikation mit dem Benutzer herstellen. Beispiels weise kann der mobile Code mit
einem Dialogfenster den Benutzer zur erneuten Eingabe seines Schlusselpasswortes auordern.
Abgesehen von dem oben erwahnten Warnhinweis (Abschnitt 7.5, Seite 61), kann der Benutzer nicht zwischen den vom Kundenmodul und den vom mobilen Code erzeugten Fenstern
unterscheiden. Einen Beispielangri fuhrt die Klasse org.mmm.attacks.GUIOpener durch; sie
erzeugt eine javax.swing.JOptionPane. Alle Elemente graphischer Benutzungsschnittstellen
benden sind in den Paketen java.awt und javax.swing. Wenn diese Namen der Systemvariable package.access hinzugefugt werden, darf Code nur Klassen aus den Paketen laden,
wenn er die Berechtigung dazu hat. Beim einem erneuten Angrisversuch nach dem Setzen der
Variablen fuhrt das O nen der JOptionPane zu einer AccessControlException. Wird anstelle
der JOptionPane ein org.mmm.attacks.AttackWindow geonet, das von javax.swing.JFrame
erbt, fuhrt das zu der gleichen Ausnahme. Daran sieht man, dass auch der Zugri auf Oberklassen uberpruft wird. Durch Beerbung von Standardklassen wird der Kontrollmechanismus
also nicht ausgeschaltet.
89

9.1.3 Angri: Onen
einer Netzverbindung
U ber eine Netzverbindung kann mobiler Code sowohl Daten zu einem anderen Rechner senden,
als auch selbst Daten von einem anderen Rechner empfangen. In Abschnitt 7.5, Seite 61 wurde
bereits erlautert, dass Code immer eine spezielle Berechtigung braucht, um eine Netzverbindung
aufbauen zu konnen. Eine solche Berechtigung erhalt nur das Kundenmodul zum Laden des
mobilen Codes aber nicht der mobile Code selbst.
9.1.4 Angri: Zugri auf den Klassenlader
Der von mir geschriebene Klassenlader org.mmm.start.MMMClientLoader muss oentlich sein
und auch oentliche Konstruktoren besitzen, da er andernfalls von der virtuellen Maschine
nicht als Systemklassenlader gestartet werden kann. Er bendet sich im Paket org.mmm.start,
da er gleich nach dem Start der virtuellen Maschine zugreifbar sein muss. Auch die Bereichsmodikatoren der beiden Methoden zum Einfugen und Loschen innerhalb des Suchpfades des
Klassenladers sind public; die Methoden sind damit oentlich zugreifbar. Das ist notwendig,
da die Klasse SQLRequestor, die diese Methoden aufruft, selbst im Paket org.mmm.client ist.
Durch diese Konstellation ware ein Zugri auf den Klassenlader von anderen Paketen { also
auch vom mobilen Code { aus moglich. Eine Referenz auf den Systemklassenlader kann eine
Klasse jederzeit mit Aufruf java.lang.ClassLoader.getSystemClassLoader() bekommen.
Ein bosartiger mobiler Code konnte daruber versuchen, Dateistandorte mit schadlichem Code in den Suchpfad einzufugen oder die Dateistandorte anderer Codes daraus zu loschen. Die
Java-Standardumgebung sieht den Systemklassenlader jedoch bereits als besonders schutzenswerte Klasse an und lasst nur Objekte mit der entsprechenden Berechtigung darauf zugreifen.
Ein Angri der Klasse org.mmm.attacks.ClassLoaderAccessor wird schon beim Versuch, eine Referenz auf den Systemklassenlader zu bekommen, mit einer AccessControlException
abgebrochen.
9.1.5 Angri: Zugri auf Kundenmodulklassen
Der mobile Code braucht fur seine Berechnungen keine Referenzen auf Klassen, die zum Kundenmodul gehoren. Er kann auch keine Referenzen auf laufende Klassen des Kundenmoduls
bekommen, da keine Klasse des Kundenmoduls statische Methoden oder Attribute anbietet.
Da das Kundenmodul der Teil des Programms ist, der die Schnittstelle zum Benutzer darstellt und sicherheitsrelevante Operationen ausfuhrt, sollte dem mobilen Code aber schon
der Versuch, eine Klasse des Kundenmoduls zu instanziieren, untersagt werden. Wie auch
schon bei der Vermeidung des Zugris auf Java-Standardklassen werden der Systemvariablen
package.access die beiden Paketnamen org.mmm.client und org.mmm.start hinzugef
ugt.
Wenn der mobile Code jetzt versucht, eine Klasse aus diesen Paketen zu instanziieren, wird
die Ausfuhrung mit einer Ausnahme abgebrochen. Der mobile Code kann in seinem Binarcode
Klassen innerhalb der Kundmodulpakete denieren. Damit bendet sich die Angrisklasse im
entsprechenden Paket und kann auf nur paketinterne Klassen zugreifen. Um das zu verhindern,
versiegele ich die Kundenmodulpakete beim Erstellen der Java-Archive. Der Versuch, eine Klasse, die in einem Kundenmodulpaket deniert ist aber sich nicht innerhalb des Originalarchivs
bendet, zu laden, fuhrt zu einer Ausnahme wie in Abschnitt 7.8 (Seite 64) dargestellt.
Klassen und Methoden wurden mit dem kleinstmoglichen Bereichsmodikator deniert, damit
sie auch innerhalb des Kundenmoduls nicht von allen Klassen zugreifbar sind. Die Entschlusselungsklasse org.mmm.client.Unsealer ist beispielsweise nur paketintern sichtbar.
9.1.6 Angri: Native Methoden
Der mobile Code kann bosartigen Programme in Form von Bibliotheken mitfuhren, die in einer
anderen Programmiersprache als Java geschrieben wurden; diese Bibliotheken kann er dann
90
uber das Java Native Interface (siehe Abschnitt 7.9 auf Seite 65) einbinden. Meine Angrisklasse org.mmm.attacks.NativeLoader versucht dies. Eine native Bibliothek durchlauft nicht
die Java-Sicherheitsprufungen. Einer nativen Bibliothek kann man nicht einzelne Berechtigungen zuweisen, sondern sie nur vollstandig verbieten oder erlauben. Dem einbindenden Java-Code
muss zum Laden von Bibliotheken die java.lang.RuntimePermission(loadLibrary.libname )
zugewiesen werden. Da der mobile Code aber keine Berechtigungen bekommt und damit insbesondere auch keine Laufzeitberechtigung zum Laden von Bibliotheken, wird die Ausfuhrung
des mobilen Codes schon bei dem Versuch abgebrochen, die Methode zum Laden nativer Bibliotheken (das ist loadLibrary() in java.lang.System) auszufuhren.
9.1.7 Angri: Zugri auf das Dateisystem und andere Ressourcen
Fur jeden Dateizugri benotigt der Javacode eine java.io.FilePermission mit dem Dateistandort als Ziel und eine oder mehrere der Aktionen Lesen, Schreiben, Ausfuhren und Loschen.
Der mobile Code hat keine solche Berechtigung und kann daher keine Dateien erstellen, verandern oder loschen. Ein Angri der Klasse org.mmm.attacks.FileReader, die versucht, Dateien
einzulesen, hat deswegen keinen Erfolg. Das bedeutet insbesondere, dass mobiler Code die Kongurationsdateien des Kundenmoduls und der Java-Umgebung und die Bibliotheken anderer
mobiler Codes nicht verandern kann. Auerdem kann er nicht auf die Schlusselspeicher des
Kunden zugreifen.
Anders sieht es aus bei den Ressourcen Arbeitsspeicher (der virtuellen Maschine) und Prozessor.
Fur sie gibt es keine Einschrankungen. Wie schon bei den Angrien durch endlose Ausgaben
auf dem Ausgabestrom beziehungsweise endlose Threaderzeugung geschildert (siehe Abschnitt
9.1.1), gibt es fur das Kundenmodul oder den Kunden in Java keine Moglichkeit, den mobilen
Code anzuhalten ohne den Java-Prozess zu beenden. Ein weiteres Beispiel fur Ressourcenbesetzung ist der Angri der Klasse org.mmm.attacks.InfiniteLoop, der in einer Endlosschleife
Ausgaben auf die Standardausgabe macht. Deswegen ist es nicht nur zur Verhinderung von
Komplotts (siehe Abschnitt 9.1.8) sinnvoll, fur jeden Anfrage einen eigenen Java-Prozess zu
starten. Durch diese Abtrennung kann ein endlos rechnender mobiler Code beendet werden,
ohne andere mobile Codes in Mitleidenschaft zu ziehen.
Eine elegantere Moglichkeit, die Ressourcennutzung einzelner Codes einzuschranken, ware es,
nicht nur rein qualitative Berechtigungen zu verwenden, sondern das Java-Berechtigungskonzept
um quantitative Berechtigungen zu erweitern und diese auch fur die Arbeitsspeicher- und den
Prozessornutzung einzufuhren.
9.1.8 Angri: Komplott mehrerer mobiler Codes
Eine Kommunikation von mobilen Codes uber das Dateisystem, wie in Abschnitt 6.1.4 (Seite 37) beschrieben, ermoglicht einen Austausch von Daten zwischen Codes, ohne dass sie zur
gleichen Zeit ausgefuhrt werden mussen. Eine solche Kommunikation wird durch die im vorigen
Abschnitt 9.1.7 angesprochenen Mittel verhindert.
Wenn mobile Codes zur selben Zeit ausgefuhrt werden, mussen andere Mittel ergrien werden,
um die Kommunikation zweier Codes zu verhindern. Java bietet zur Zeit keine Moglichkeit,
Schutzbereiche, die sich in derselben virtuellen Maschine benden, voneinander zu isolieren und
so vor Zugrien abzuschotten. Zwei Java-Objekte innerhalb derselben virtuellen Maschine konnen uber statische Methoden eine Referenz aufeinander erhalten und daruber kommunizieren,
wenn beide das Einzelganger-Muster (vgl. Singleton pattern aus [GHJV95], Seite 127) implementieren. Eine einseitige Kommunikation ist schon moglich, wenn nur ein mobiler Code ein
Einzelganger ist und dann von dem anderen aufgerufen wird; wenn die beiden Codes nur Werte
austauschen wollen, reicht es sogar schon, wenn sie Klassen enthalten, die statische Variablen
anbieten. Wenn also zwei Multimediamediator-Anfragen in derselbem virtuellen Maschine gestartet werden und die dazugehorigen mobilen Codes Einzelganger sind, gehoren sie zwar zu

9.2 Angrie Dritter wahrend der Ubertragung
91
unterschiedlichen Schutzbereichen, da sie in unterschiedlichen Verzeichnissen abgelegt werden
und somit ihr Herkunftsort nicht identisch ist, aber sie konnen trotzdem Methoden aufeinander
aufrufen. Als Angrisbeispiel stelle ich die beiden Klassen org.mmm.attacks.BadExtractor
und org.mmm.attacks.BadExtractor2 bereit, in denen der BadExtractor eine Methode vom
BadExtractor2 aufruft, die ihm einen int-Wert zur
uckgibt; die Klasse BadExtractor2 implementiert das Einzelganger-Muster. Auch wenn der Kunde vor dem Start aller mobiler Codes
den Quellcode uberpruft und sich uberzeugt, dass die Klassen fur sich genommen ungefahrlich
sind, konnen durch die Kooperation mehrerer Codes unerwunschte Operationen durchgefuhrt
werden.
Die technisch einfachste Moglichkeit, eine Kooperation mobiler Codes zu verhindern, ist es,
nur eine Anfrage pro Java-Prozess zu starten. Fur eine weitere Anfrage muss auch eine weitere virtuelle Maschine gestartet werden. Die Grenzen virtueller Maschinen konnen Objekte
mit einfachen Methodenaufrufe nicht uberqueren. Jeder neue Java-Prozess bedeutet fur den
Kundenrechner zwar eine zusatzliche Belastung seiner Ressourcen; diese ist aber akzeptabel
um das Ziel der Abschottung von mobilen Codes zu erreichen.
Als Softwarelosung zur Trennung von zwei mobilen Codes aus verschienden Paketen innerhalb
derselben virtuellen Maschine lasst sich die Java-Systemvariable package.access erweitern.
Diese Systemvariable enthalt die Paketnamen, fur die eine Zugrisuberprufung durchgefuhrt
werden soll. An sie konnen zur Laufzeit die Paketnamen der mobilen Codes angehangt werden.
Beispielsweise: Security.setProperty("package.access", "org.mmm.attacks."); Klassen
auerhalb des Paketes mmm.org.attacks { also insbesondere mobile Codes aus anderen Paketen { konnen dann nicht auf Klassen innerhalb dieses Paketes zugreifen, solange ihnen in der
aktuellen Sicherheitsregel nicht explizit die notige Berechtigung zugewiesen wird { das ware in
diesem Fall RuntimePermission("accessClassInPackage.org.mmm.attacks."). Der Nachteil dieses Verfahrens ist, dass der Wert der Systemvariable sehr lang werden kann, weil zur
Laufzeit viele neue Paketnamen angehangt werden. Der Vergleich der Paketnamen dauert dann
langer. Auerdem kann eine Klasse innerhalb des Paketes immer auf alle anderen Klassen dieses Paketes zugreifen. Der Beispielangri, in dem sich die beiden Klassen BadExtractor und
BadExtractor2 innerhalb des Paketes org.mmm.attacks benden, w
urde weiterhin funktionieren.
Technisch wesentlich aufwandiger ware es, die Schutzbereichsisolierung zu implementieren.
Das konnte etwa durch eine Erweiterung des Berechtigungsmechanismus' geschehen. Zunachst
musste man eine neue Berechtigung einfuhren { etwa AccessProtectionDomainPermission {
oder aber fur die bestehende Berechtigungsklasse java.security.RuntimePermission einen
neuen Zielnamen accessProtectionDomain denieren. Bei jeden Zugri auf eine Klasse in einem anderen Schutzbereich musste dann uberpruft werden, ob der Aufrufer dazu berechtigt ist,
die Schutzbereichsgrenze zu uberqueren. Da Schutzbereichsgrenzen in Aufrufketten aber haug
uberschritten werden, wurde diese U berprufung ebenso haug stattnden und die Ausfuhrung
des Java-Programms dadurch langsamer.

9.2 Angrie Dritter wahrend der Ubertragung
Um einem Angri durch Wiedereinspielen einer Antwort durch Dritte (wie in Abschnitt 6.6
auf Seite 47 dargestellt) zu entgehen, erstellt der SQLRequestor eine Seriennummer fur jede
Anfrage. Er benutzt dazu ein Objekt der Klasse java.util.Date, dass die aktuelle Ortszeit
angibt, und hangt dieser Zeitangabe zusatzlich noch eine Zufallszahl an, die mit der Klasse
java.util.Random erzeugt wurde. Der Mediator liest die Seriennummer aus der Anfrage aus
und fugt sie in den mobilen Code ein, bevor er ihn verschlusselt. Nach der Entschlusselung
des mobilen Codes auf dem Kundenrechner vergleicht der SQLRequestor die gespeicherte Seriennummer mit der Seriennummer des mobilen Codes. Falls sie nicht ubereinstimmen, wird
er eine org.mmm.client.WrongTimestampException geworfen. In der Benutzungsschnittstelle
92
wird daraufhin ein Warnhinweis angezeigt und der/die Benutzer(in) kann entscheiden, wie mit
dem Code weiter verfahren werden soll.
Sichere Koprozessoren kann man derzeit fur die Kundenrechner nicht voraussetzen. Es mussten
daher Softwarelosungen fur den Schutz des mobilen Codes eingesetzt werden. Java-Binarcode
kann einfach dekompiliert werden (siehe dazu [Rou03]). Die entschlusselten Objekte, die den
Algebrabaum darstellen, kann der Kunde mit einem veranderten Kundenmodul einsehen. Er
kann die entschlusselten Objekte auch ohne Probleme serialisieren und speichern. Er hat neben
dem Zugri auf das Gesamtantwort auch Zugri auf die Teilantworten.
Mobile Codes konnen keinen Einuss auf andere mobile Codes nehmen, wenn sie in verschiedenen virtuellen Maschinen ausgefuhrt werden. Dieses Verfahren wurde in 9.1.8 dargestellt, um
Komplotte von mobilen Codes zu vermeiden. Die Daten eines mobilen Codes konnen auerdem
nicht von anderen Codes angegrien werden, da jeder Code ein eigenes Arbeitsverzeichnis und
keine Schreibrechte hat.
Ich betrachte im Folgenden nur zwei Angrie eines mobilen Codes auf die Integritat seiner
eigenen Daten.
9.3.1 Angri: Schadliche Operatoren
Der Mediator erstellt die Operatorenklassen und muss dazu das Datenformat seiner Datenquellen kennen. Daher wird ihm kein Geheimnis preisgegeben, wenn er dem mobilen Code
sowohl den Binarcode fur die Operatoren als auch fur das Datenformat hinzufugt. Solange sich
die Teilantworten auf dem Mediator benden, kann er sie nicht verandern, da sie mit dem
Kundenschlussel verschlusselt sind. Allerdings werden die Operatoren auf dem Kundenrechner
auf den unverschlusselten Teilantworten ausgefuhrt. Ein bosartiger Mediator kann Operatoren
schreiben, die die Teilantworten bei der Ausfuhrung verandern. Insbesondere kann die Auswertung eines Operators von Daten in der Teilantwort abhangig gemacht werden. Um bei dem
Beispiel der Kaeetabelle zu bleiben, kann etwa ein bosartiger Selektionsoperator grundsatzlich alle Zeilen eines bestimmten Anbieters herausnehmen. Die U berprufung der semantischen
Korrektheit des Operators kann nicht durch die Java-Sicherheitsmechanismen geleistet werden. Der Kunde muss auf andere Methoden zuruckgreifen, wie sie in Abschnitt 6.7.1 (Seite 49)
vorgeschlagen wurden.

9.3.2 Angri: Uberschreiben
von Binarcodes
Durch das Klassenladerprizip der Programmiersprache Java ergibt sich ein weiteres Problem.
Der Mediator kann neben dem Schreiben von bosartigen Operatoren auch die Klasse fur das
Datenformat neu schreiben und dort schadlichen Code einfugen, der die jeweilige Teilantwort
verandert. Selbst wenn unter der Annahme, dass die Datenquelle vertrauenswurdig ist, der Binarcode fur das Datenformat von den Datenquellen verschlusselt und signiert an ihre Teilantworten gehangt wird und das Kundenmodul ihn von dort auf die Festplatte speichert, der
Kunde also sicher sein kann, dass der Binarcode wirklich von der Datenquelle stammt, ist das
Problem nicht gelost. Die Klassenlader in Java durchlaufen beim Laden einer Klasse ihren
Suchpfad, bis sie den ersten passenden Binarcode gefunden haben. Ein Mediator konnte also
zusatzlich zu den Operatoren in seinem Java-Archiv das Datenformat neu denieren. Wenn der
Dateistandort dieses Java-Archivs vor dem Dateistandort des Archivs mit dem Originalformat
der Datenquelle im Suchpfad liegt, wird dennoch die gefalschte Klasse geladen.
Die Namenskonventionen fur Java-Pakete sehen vor, dass der Firmenname des Herstellers (oder
etwas ahnlich Bezeichnendes) in den Pakete vorkommen. Damit kann die Gefahr des unabsichtlichen U berschreibens zumindest eingeschrankt werden.
93
Das Kundenmodul kann mit einigem Aufwand einen absichtlichen Angri entdecken und verhindern. Es durchlauft vor der Ausfuhrung des mobilen Codes den gesamten Algebrabaum und
vergleicht die dort gefundenen Klassen mit den Eintragen im Java-Archiv des Mediators. Alle
Binarcodes von Klassen, die nicht als Operatoren im Algebrabaum vorkommen, werden aus
dem Archiv entfernt, so dass am Ende nur noch Binarcodes ubrigbleiben, die wirklich benotigt
werden. Da der Baum dazu aber einmal vollstandig durchlaufen werden muss, verdoppelt sich
mit diesem Verfahren die Berechnungszeit des mobilen Codes.
Eine zweite Moglichkeit ware es, fur jedes Archiv, das dem mobilen Code beigefugt ist, einen
eigenen Klassenlader zu instanziieren. Das Kundenmodul muss dann aber auch den Aufbau des
Algebrabaums kennen, denn zum Laden eines Operators oder des Datenformats einer Teilantwort muss dann der richtige Klassenlader angesprochen werden. Fur jeden Operator und jedes
Datenformat musste anhand des Algebrabaums erkenntlich sein, aus welchem Java-Archiv ihr
Klassencode geladen werden soll. Dieses Verfahren wurde viel zusatzliche Rechenzeit fur das
Kundenmodul bedeuten. Mit den derzeit in Java vorhandenen Mitteln lasst es sich auch nicht
umsetzen, da die Teilantworten beim Entschlusseln sofort instanziiert werden { und zwar mit
dem Systemklassenlader und daher mit dem Binarcode der im Suchpfad des Systemklassenladers an erster Stelle steht. Es musste also in der Klasse javax.crypto.SealedObject eine
Moglichkeit geschaen werden, bei der Entschlusselung den Klassenlader anzugeben, der die
Klassen instanziieren soll.
Im U brigen ware das U berschreiben von Klassen auch eine Angrismoglichkeit fur eine Datenquelle: Wenn ihr Java-Archiv zuerst im Suchpfad liegt, kann sie darin die Operatoren des
Mediators und die Datenformate von anderen Teilantworten uberschreiben. Da der Mediator
das Java-Archiv der Datenquelle aber einsehen kann, bevor er es an den mobilen Code hangt
(er kennt die Datenformate der Datenquelle, da er die Operatoren dafur schreibt), kann er
diesem Angri vorbeugen; das wird er tun, wenn er Interesse daran hat, dass sei Code lauahig
ist.
Ich habe ein vereinfachtes Verfahren gewahlt, um uberschriebene Codes zu entdecken: Das
Kundenmodul durchlauft zwar nicht den Algebrabaum und pruft, ob sich Klassen in einem
Java-Archiv benden, die dort nicht benotigt werden, aber die neu eingefuhrte Archivprufmethode SQLRequestor.checkAllJars() sieht sich die Eintrage aller Java-Archive an, die in das
Arbeitsverzeichnis gespeichert wurden. Wenn sie Eintrage in einem Archiv ndet, die Eintrage
anderer Archive uberschreiben, wird die Ausnahme org.mmm.client.DuplicateJarEntry geworfen. U ber eine neues Auswahlfeld in der Benutzungsschnittstelle kann diese Funktionalitat
ein- oder ausgeschaltet werden. Falls die Ausnahme auftritt, wird ein Warnhinweis angezeigt.
Im Terminalfenster wird auerdem ausgegeben, welche Eintrage uberschrieben werden. Dem
oder der Benutzer(in) bleibt es dann uberlassen, von Hand die angegebenen Java-Archive zu
prufen und gegebenenfalls zu andern oder zu entfernen.
94
95
IV.
Erweiterungen
Inhalt
10 Auswirkungen einer Mediatorhierarchie . . . . . . . . . . . . . . . . . . . .
10.1 Technische Anforderungen . . . . . . . . .
10.2 Nachteile fur den Kunden . . . . . . . . .
10.3 Angrie der Teilcodes untereinander . . .
11 Umsetzung der Mediatorhierarchie . . .
11.1 Angrie der Teilcodes untereinander . . .
.
.
.
.
.
.
.
.
.
.
12 Auswahl mehrerer Eigenschaftsnachweise .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13 Umsetzung der Auswahl mehrerer Zertikate .
13.1 Verschlusselung mit mehreren Schlusseln . . . . . .
13.2 Entschlusselung mit mehreren Schlusseln . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
97
97
98
100
102
104
105
105
107
La vulneracion de la conanza tambien es eso: no solo ser indiscreto y
"ocasionar
da~no o perdicion con ello, no solo recurrir a esa arma ilcita cuando
los vientos cambian y se le pone la proa al que conto y dejo ver { ese
que se arrepiente ahora y niega y confunde y enturbia ahora, y quisiera
borrar y calla {, sino sacar ventaja del conocimiento obtenido por debilidad
o descuido o generosidad del otro [...].\
Javier Maras
96
10 Auswirkungen einer Mediatorhierarchie
Als erste Erweiterung dieser Diplomarbeit ist die Weiterleitung von Teilanfragen an andere
Mediatoren vorgesehen. Dabei schickt der Kunde wie bisher seine Anfrage an einen Mediator.
Dieser primare Mediator kann die Anfrage wie gewohnt aufspalten und Teilanfragen an Datenquellen schicken. Er kann aber auch die Anfrage als Ganzes zu einem anderen, sekundaren
Mediator weiterleiten oder aber die Anfrage aufspalten und einige Teilanfragen an Datenquellen und die restlichen Teilanfragen an andere, sekundare Mediatoren schicken. Die sekundaren
Mediatoren konnen wiederum Teilanfragen (oder ihre Gesamtanfrage) an andere Mediatoren
delegieren. Abbildung 24 stellt beispielhaft eine Hierarchie dar.
Mediator 1
Quelle
Hauptcode
Mediator 2b
Mediator 2a
Obercode von 3a
Teilcode von 1
Mediator 3a
Quelle
Quelle
Mediator 3b
Mediator 3c
Teilcode von 2a und 1
Quelle
Quelle Quelle
Quelle
Quelle
Abbildung 24: Hierarchie von Mediatoren
Ein Mediator bekommt von den Mediatoren, an die er Teilanfragen delegiert hat, Teilantworten in Form von mobilen Codes { den sogenannten "Teilcodes\. Der mobile Code des primaren
Mediators ist der "Hauptcode\, der die Teilcodes aller anderen Mediatoren umfasst. In einer
Hierarchie mit mindestens zwei Stufen hat ein Teilcode auch immer noch einen oder mehrere
Obercodes\; das sind die Codes der Mediatoren, die in der Hierarchie uber ihm liegen.
"Durch
die Hierarchisierung ist eine Strukturierung des Systems moglich: es kann Mediatoren
geben, die fur einen bestimmten Themenbereich zustandig sind (vgl. dazu auch [WG97], Seite 45: domain partitioning). Mehrere Mediatoren zusammen konnen dem Kunden auch eine
groere Menge an Informationen liefern und die Mediatoren konnen variabel entscheiden, ob
sie Teilanfragen noch weitersenden oder mit ihren eigenen Datenquellen beantworten. Datenquellen werden nicht nur von den Kunden, sondern auch von den Mediatoren, die sich hoher
in der Hierarchie benden, abgekapselt; sie bleiben auch den meisten Mediatoren gegenuber
anonym (auer gegenuber dem, der sie direkt anspricht). Die Kunden wiederum sind nur dem
primaren Mediator bekannt, bleiben aber Mediatoren tiefer in der Hierarchie gegenuber anonym.
In den folgenden Abschnitten diskutiere ich, welche Auswirkungen die Mediatorhierarchie auf
das Multimediamediator-System hat und welche neuen Sicherheitsrisiken dadurch auftreten.
Eine U bersicht ist in Tabelle 9 zu nden.
10.1 Technische Anforderungen
97
10.1 Technische Anforderungen
Ich halte es fur wichtig, dass der Mediator einen Teilcode moglichst wenig bearbeiten muss und
genauso wie eine Teilantwort von einer Datenquelle als Blatt in seinen Algebrabaum einhangen
kann, ohne den Teilbaum innerhalb des Teilcodes durchlaufen zu mussen. Das spart Zeit bei
der Erstellung der Gesamtantwort und fuhrt bei einem guten Entwurf auch nicht zu einer langeren Berechnungszeit beim Kunden. Durch die Weiterleitung dauert die Beantwortung einer
Anfrage aber wahrscheinlich langer als im einfachen Fall. Im Abschnitt 11 (Seite 100) stelle ich
dar, welche Veranderungen durch den Einbau von Teilcodes in den Antwortbaum an meinem
bisherigen Entwurf notwendig waren.
Technisch sehe ich bei der Hierarchisierung der Mediatoren zudem die Schwierigkeit, dass Kreise
in der Anfrageabfolge auftreten konnen, die im schlechtesten Fall endlos durchlaufen werden;
dann namlich, wenn die beteiligten Mediatoren die Anfrage in jedem Durchlauf des Kreises
vollstandig an denselben Mediator weiterleiten. Dieses musste durch geeignete Verfahren verhindert werden.
Sollte der Fall eintreten, dass eine Datenquelle einen Eigenschaftsnachweis ablehnt, muss dies
dem Kunden mitgeteilt werden. Die Mitteilung muss von der Datenquelle aus uber alle Mediatoren auf dem Weg, den die Teilanfrage genommen hat, zuruckgeleitet werden. Dies kann eine
Anfrage in einer fur den Kunden unakzeptable Weise verlangern. Bei einer Hierarchisierung ist
es daher noch wichtiger als bei der einstugen Mediation, dass der primaren Mediator Informationen uber Zugrisbeschrankungen bereithalt (und diese Informationen auch aktuell halt)
und dem Kunden mitteilen kann, welche Eigenschaftsnachweise benotigt werden.
Generell lasst sich sagen, dass sich das Multimediamediator-System durch die Hierarchisierung
vor dem Hintergrund der in Abschnitt 5 auf Seite 28 vorgestellten Bewertungskriterien verschlechtert. Vor allem in den Punkten "Vermeidung eines verteilten Berechnungszustands\ und
Unabhangigkeit von der Netzverbindung\ gibt es Nachteile, da fur die Kommunikation mit
"den
anderen Mediatoren eine zuverlassige Netzverbindung notwendig ist und mit der Hierarchisierung die Erstellung des Antwortbaums auf mehr Teilnehmer verteilt wird. Wenn auerdem
jeder Mediator seinen eigenen Binarcode in seinen Teilcode einfugt, erhoht sich auch die Datenmenge, die ubertragen wird. Damit erkauft man sich jedoch eine hohere Flexibilitat des
Systems und einen moglichen groeren Informationsgewinn fur den Kunden.
10.2 Nachteile fur den Kunden
Durch die Hierarchisierung der Mediatoren wird das Multimediamediator-System komplexer
und der Weg, den eine Anfrage nimmt, schlechter nachzuvollziehen. Mit mehreren Mediatoren
wird es fur den Kunden schlechter uberprufbar, welche Qualitat die Antwort hat; das heit,
wenn er in einem System mit nur einem Mediator schon kaum feststellen kann, ob die Datenquellen korrekte und aktuelle Daten zuruckgeliefert haben, wird dies mit mehreren Mediatoren
nun noch schwieriger. Nicht einmal die Mediatoren wissen, welche Datenquellen andere Mediatoren in der Hierarchie benutzen. Der Kunde kann nur die Reputation seines primaren
Mediators uberprufen. Der primare Mediator muss dann treuhanderisch fur den Kunden nicht
nur die Qualitatsprufung der direkt von ihm benutzten Datenquellen sondern auch der von ihm
benutzten sekundaren Mediatoren durchfuhren; diese wiederum tragen die Verantwortung fur
die von ihnen benutzten Mediatoren und Datenquellen und so weiter.
Die Gesamtantwort setzt sich aus mehreren mobilen Codes zusammen, die von Mediatoren
stammen, die der Kunde nicht kennt. Da der Kunde seinem primaren Mediator auch nur eingeschranktes Vertrauen entgegenbringt, ist der mobile Code der anderen Mediatoren aber nicht
als potenziell gefahrlicher einzustufen als der des primaren Mediators. Die Mechanismen zum
Schutz des Kundenrechner sind dieselben wie beim Multimediamediator ohne Hierarchie. Signaturen unter den mobilen Codes sind fur den Multimediamediator daher vorwiegend zur
U berprufung der Integritat bei der U bertragung der Teilcodes notwendig. Jedoch kann der
98
Kunde die Signaturen der mobilen Teilcodes eventuell nicht uberprufen (und damit die einzelnen Codehersteller weder authentizieren noch die Integritat des Teilcodes feststellen), weil
der Kunde nicht die oentlichen Schlussel von allen beteiligten Mediatoren hat. Jeder Mediator
kann aber die Integritatsprufung in seiner Stufe der Hierarchie ubernehmen. Zunachst pruft er
die Signaturen der mobilen Codes, die er von den Mediatoren erhalt, an die er direkt Teilanfragen deligiert hat. Wenn er erfolgreich war, signiert er sie mit seinem privaten Schlussel.
Er burgt damit fur die Richtigkeit der vorherigen Signatur und damit der korrekten U bertragung des Code. Unter der Annahme, dass das Signaturverfahren sicher und Signaturen nicht
falschbar sind, konnen Mediatoren mit diesem Verfahren eine Integritatskette uber die ganze
Hierarchie aufbauen. Jeder Mediator benotigt nur die oentlichen Schlussel der Mediatoren,
die er direkt anspricht. Voraussetzung ist, dass die oentlichen Schlussel auf sicherem Weg ausgetauscht werden und ihre Authentizitat sichergestellt ist. Im letzten Schritt pruft der Kunde,
ob die Signatur unter dem Hauptcode, den er vom primaren Mediator erhalt, korrekt ist. Dafur
benotigt der Kunde dann den Schlussel dieses einen Mediators aber keine weiteren.
Beweismitfuhrender Code, der in Abschnitt 6.2.3 auf Seite 41 vorgestellt wurde, eignet sich
auch fur den Schutz des Kundenrechners vor einem hierarchisierten mobilen Code. Allerdings
muss die Beweiserstellung zum gleichen Zeitpunkt wie die Konstruktion des jeweiligen Teilcodes
geschehen und sehr schnell moglich sein, damit keine groen Zeiteinbuen durch die Beweise
auftreten. Wenn der Kunde den Teilbeweis fur jeden Teilcode erhalt, kann er sicher sein, dass
er nicht durch Obercodes verandert wurde und auch nicht bei der Ausfuhrung verandert wird,
wenn der Kunde eine entsprechende Sicherheitsregel deniert hat. Allerdings mussen die Teilbeweise der Teilcodes zusammengesetzt werden konnen, wie es auch schon fur Teilbeweise von
Operatoren moglich sein musste (siehe dazu Abschnitt 6.2.3 auf Seite 41); die Mediatoren in
der Hierarchie mussen deswegen fur ihre Beweise kompatible Beweissprachen verwenden, die
ein Zusammensetzten zulassen.
10.3 Angrie der Teilcodes untereinander
Wenn alle Mediatoren in der Hierarchie ehrlich und nur neugierig sind (vgl. die Angrismodelle
in Abschnitt 3.1 auf Seite 8), konnen sie bei der Erstellung ihres Teilcodes aus den anderen
Teilcodes im Vergleich zum einfachen Modell keine weiteren Informationen ableiten, wenn die
anderen Teilcodes verschlusselt sind. Ein bosartiger Mediator kann, wie er es auch mit Teilantworten von Datenquellen tun kann, die Teilcodes durch willkurliche A nderungen von einzelnen
Teilen des verschlusselten Codes angreifen oder die Teilcodes an der falschen Stelle in seinen Algebrabaum einhangen. Ein bosartiger Mediator kann auch Teilanfragen an qualitativ schlechte
oder parteiische Mediatoren weiterleiten und eventuell andere Mediatoren durch eine Unmenge
von Anfragen blockieren.
Ein groes Risiko ergibt sich nach der Entschlusselung auf dem Kundenrechner. Wenn jeder
Teilcode seinen Binarcode mit sich fuhrt und alle Binarcodes von ein und demselben Klassenlader geladen werden, kann es passieren, dass sich Denitionen von verschiedenen Codes
uberlagern und bei der Ausfuhrung beispielsweise falsche Operatoren benutzt werden. Das
kann zum Einen unbeabsichtigt sein, zum Anderen kann ein bosartiger Mediator auch absichtlich Operatoren mitsenden, die andere Teilcodes verandern. Diese Operatoren werden auf den
entschlusselten Teilcodes und Teilantworten ausgefuhrt und konnen daher Abfragen von Werten enthalten und die Auswertung in Abhangigkeit von diesen Klartextwerten durchfuhren.
Das war auch schon im einfachen Fall mit den Teilantworten der Datenquellen moglich (siehe
Abschnitt 9.3.2 auf Seite 92); nur waren dort solche Angrie einfacher nachzuvollziehen, da die
Datenquellen nur ihr jeweiliges Datenformat liefern sollten und der Mediator die Operatoren.
In einer Hierarchie von Mediatoren liefern aber mehrere Mediatoren Binarcode fur Operatoren
und die Wahrscheinlichkeit des U berschreibens steigt damit. Im einfachen Fall war also "nur\
die Integritat der Daten gefahrdet (vgl. Abschnitt 6.7.1, Seite 48), wahrend im hierarchisierten
Fall auch die Integritat der Codeausfuhrung gefahrdet ist (vgl. Abschnitt 6.7.4, Seite 52).
99
Vorteile
Spezialisierung der Mediatoren auf Themenbereiche
Skalierbarkeit des Informationsgehalts
Anonymitat zwischen Teilnehmern ohne direkten Kontakt
Nachteile
Langere Beantwortungsdauer
Hohere Anfalligkeit gegenuber Verbindungsabbruchen
Mogliche Kreise in der Anfragekette
Schwierigere Qualitatskontrolle
Angrie der Teilcodes untereinander
Tabelle 9: Vor- und Nachteile der Hierarchisierung
Auerdem stehen die Mediatoren in der Hierarchie in einer Art Konkurrenzverhaltnis und
haben damit eventuell ein Interesse daran, die anderen Teilcodes zu kontrollieren. Wenn ein
Teilcode die Namensgebung der Operatoren eines anderen Teilcodes kennt, kann er bosartige
Operatoren mit den gleichen Namen in seinem Binarcode denieren und hoen, dass dieser
Binarcode anstelle des richtigen benutzt wird.
Wenn das Kundenmodul solche Angrie unterbinden will, muss es den Aufbau des Antwortbaumes einsehen und die Teilcodes unterscheiden konnen. Die Losungsmoglichkeiten, die in
Abschnitt 9.3.2 dargelegt wurden, konnen auch in einer Mediatorhierarchie eingesetzt werden.
Das Kundenmodul kann den ganzen Algebrabaum (und damit alle Teilcodes) durchlaufen, feststellen, ob ein U berschreiben stattndet, und gegebenenfalls die uberschreibenden Klassen aus
dem Binarcode loschen. Alternativ kann fur jeden Binarcode (das heit fur jeden Teilcode und
eventuell fur jede Teilantwort in jedem Teilcode) ein eigener Klassenlader erstellt werden, der
die Klassen fur den jeweiligen Teilcode ladt. Die Probleme mit diesen Verfahren sind in der
Hierarchie dieselben wie im einfachen Fall; wegen der groeren Komplexitat des Antwortbaums
ist die Ausfuhrung aber noch zeitraubender.
100
11 Umsetzung der Mediatorhierarchie
Um mein Mediatorsystem so zu erweiteren, dass ein primarer Mediator Teilanfragen an sekundare Mediatoren weiterleiten kann, musste ich zunachst uberlegen, ob A nderungen am Anfrageformat, den RMI-Schnittstellen des Mediators, dem Antwortformat oder dem Kundenmodul
notig waren.
Im unsignierten und unverschlusselten Fall musste das Anfrageformat nicht geandert werden.
Ein Mediator schickt an einen anderen Mediator die Teilanfrage { genauso wie an Datenquellen { in Form eines QueryWithCertificate. Er benutzt dafur dieselbe RMI-Schnittstelle des
Mediatormoduls, die auch der Kunde bei direkten Anfragen verwendet: in beiden Fallen wird
die Methode request() aufgerufen. Das heit auch, dass ein delegierender Mediator die Antwort als ResultExtractor bekommt. Die Klasse ResultExtractor selbst muss dann nur das
Interface AlgebraTreeComponent implementieren, um wie die Klassen ResultOperator und
Result als Knoten in den Antwortbaum eingesetzt werden zu konnen. Das bedeutet, dass im
unverschlusselten Fall auch das Anfrageformat nicht geandert werden musste. Bei der Ausfuhrung des mobilen Codes wird innerhalb des Antwortbaums die calculateResult-Methode des
Teilantwortbaumes aufgerufen. Daher waren auch keine A nderungen am Kundenmodul notig.
Wenn jedoch ein delegierender Mediator die Antworten signiert und verschlusselt von den anderen Mediatoren bekommen will, muss eine Bedingung erfullt sein: Der delegierende Mediator
muss Zugri auf die Signaturprufschlussel der anderen Mediatoren haben. Dieser Austausch
zwischen den Mediatoren muss bereits im Vorhinein auf sicherem Weg stattgefunden haben.
Im mobilen Code, den ein Mediator erstellt, sind Teilantworten und die direkten Teilcodes (die
Teilcodes der Mediatoren, die sich eine Stufe tiefer in der Hierarchie benden) in verschlusselter
Form enthalten. In den direkten Teilcodes sind eventuell weitere verschlusselte Teilantworten
und Teilcodes enthalten. Mediatoren nehmen fur die Verschlusselung ihres eigenen Codes das
Zertikat des Kunden aus der Teilanfrage, die sie erhalten haben, und erstellen damit aus ihrem
Code einen SealedResultExtractor. Es ergibt sich also ein verschlusselter mobiler Code, wie
er in Abbildung 25 zu sehen ist. Jeder verschlusselte Teilcode wird schlielich vom erstellenden
Mediator signiert.
Prog1 Daten1
Prog2a Daten2a
Prog3a Daten3a
Daten3a
Daten2b
Prog2b Daten2b
Prog3b Daten3b
Prog3c Daten3c
Abbildung 25: Verschlusselung eines hierarchisierten Codes
Da ein delegierender Mediator seine Teilcodes nicht entschlusseln kann, wird statt eines Teilcodes ein ResultProxy in den Antwortbaum eingesetzt und der verschlusselte Teilcode (als
ein Objekt vom Typ SealedResultExtractor) der Teilantwortentabelle mit den verschlusselten Teilantworten hinzugefugt. Das Anfrageformat musste dazu nicht verandert werden und
die RMI-Schnittstelle requestSealedAndSigned() wird weiterhin verwendet. Allerdings hat
101
Abbildung 26: Benutzungsschnittstelle des Mediatormoduls mit Hierarchisierung
sich das Antwortformat geandert. Bei der Entschlusselung der Teilantwortentabelle sind nicht
mehr nur Teilantworten (in Form von SealedResults) sondern auch Teilcodes (in Form von
SealedResultExtractors) zu verarbeiten. Die Teilcodes bringen ihren eigenen Binarcode mit;
da die Teilcodes aber nicht nicht die Berechtigung haben, ihre Binarcodes selbst in das Arbeitsverzeichnis des mobilen Codes zu speichern, musste das Kundenmodul an diese Veranderung
angepasst werden. Das Kundenmodul speichert alle Binarcodes, hat aber jetzt nicht nur eine
Stelle im Hauptcode sondern auch mehrere Stellen in den Teilcodes, von denen es Binarcodes herauslesen und speichern muss. Die Entschlusselungsmethode fur Teilantwortentabellen
pruft also, ob es sich bei einem Eintrag in der Teilantwortentabelle um einen Teilcode handelt.
Wenn das der Fall ist, ruft sie die Entschlusselungsmethode fur mobile Codes auf dem Teilcode
auf. Nachdem sie den Teilcode zu einem Teilantwortbaum und dem dazu gehorigen Binarcode
entschlusselt hat, speichert sie den Binarcode als ein oder mehrere Java-Archive in das Arbeitsverzeichnis und ruft anschlieend die Entschlusselungsmethode fur Teilantwortentabellen
auf der Teilantwortentabelle des Teilcodes auf. Am Ende ist der Gesamtantwortbaum inklusive
aller Teilantwortbaume und Teilantworten entschlusselt und alle Binarcodes im Arbeitsverzeichnis gespeichert. Weitere A nderungen waren nicht notwendig, da uber den ResultProxyMechanismus bei der Ausfuhrung des mobilen Codes automatisch die Berechnungsmethode der
Teilantwortbaume aufgerufen wird.
Schlielich musste das Mediatormodul angepasst werden. Bei der Tiefensuche im Stringbaum
muss die Teilanfrage in einem Blatt entweder an eine Datenquelle oder an einen Mediator weitergeleitet werden. Die Schnittstellen fur Mediatoren und Datenquellen sind nicht gleich, da
an einen Mediator nur eine Teilanfrage aber an eine Datenquelle zusatzlich der Datenbankname sowie Benutzerkennung und Passwort gesendet wird. In der Benutzungsschnittstelle des
Mediatormoduls habe ich ein Eingabefeld fur den Namen oder die IP-Adresse des Mediators
eingefugt, an den die Teilanfragen weitergeleitet werden sollen. Der/die Administrator(in) des
Mediatormoduls kann also entscheiden, ob eine Datenquelle oder ein Mediator gefragt wird.
Abbildung 26 zeigt die veranderte Schnittstelle. Weiterhin wird aber allein ein Mediator oder
eine Datenquelle fur die Weiterleitung benutzt, weil der Mediator keinen Algorithmus fur die
Zuweisung von Teilanfragen an unterschiedliche Rechner hat.
102
In den folgenden beiden Abschnitten mochte ich darauf eingehen, inwieweit einzelne Teilcodes
die Moglichkeit haben, andere Teilcodes anzugreifen. Dazu betrachte ich zum Einen die in
Abschnitt 10.3 bereits theoretisch behandelte Gefahr des U berschreibens von Binarcode. Zum
Anderen betrachte ich noch das Java-typische Problem der Referenzen zwischen Teilcodes.

11.1.1 Angri: Uberschreiben
von Binarcodes
Jeder Teilcode enthalt seinen eigenen Binarcode. Er ist in verschlusselter Form neben dem verschlusselten Teilantwortbaum im SealedResultExtractor enthalten. Ein Mediator, der versucht, Binarcodes seiner Teilcodes zu uberschreiben, kann aus den verschlusselten Teilcodes
daher die verwendeten Klassennamen nicht auslesen. Allerdings kann der Mediator an den unverschlusselten Binarcode eines anderen Mediators gelangen, indem er einfach eine Anfrage an
ihn stellt, zu der er die Berechtigung hat. Die Klassen innerhalb dieses Binarcodes kann ein
angreifender Mediator dann neu denieren und in seinen eigenen Binarcode einfugen.
Das Kundenmodul fangt bei der Entschlusselung mit dem Hauptcode an und fugt auch dessen
Binarcode als erstes in den Suchpfad des Multimediamediator-Klassenladers ein. Dann wird
der Teilcode, der als erstes im Hauptcode enthalten ist, entschlusselt und sein Binarcode in
den Suchpfad eingefugt; danach wird dessen erster Teilcode betrachtet und so weiter. Das
Entschlusseln und Hinzufugen ndet, wie der Aufbau des Antwortbaums, in einer Tiefensuche
(genauer: pre-order-Reihenfolge) statt. Fur das Beispiel aus Abbildung 25 gilt also, dass die
Binarcodes in der Reihenfolge 1, 2a, 3a, 2b, 3b und 3c in das Arbeitsverzeichnis gespeichert
und auch in dieser Reihenfolge in den Suchpfad des Klassenladers eingefugt. Damit konnte
der Binarcode eines Teilcodes durch Binarcode von Teilcodes auf gleicher Ebene oder sogar
von Teilcodes aus einer tieferen Ebene uberschrieben werden. 2a konnte 2b, 3a, 3b und 3c
uberschreiben, aber auch 3a konnte 2b, 3b und 3c uberschreiben. Jeder Mediator kann sein
Java-Archiv versiegeln (vgl. dazu Abschnitt 7.8 auf Seite 64). Damit waren die Binarcodes
zumindest paketweise geschutzt. Ein Angreifer musste dann auf jeden Fall alle Klassen, die ein
anderer Teilcode verwendet, in seinem Binarcode uberschreiben.
Auf dem Kundenrechner fallt das U berschreiben der Binarcodes auf, wenn der Kunde die Option zur U berprufung der Java-Archive aktiviert hat. Die in Abschnitt 9.3.2 (Seite 93) erklarte
checkAllJars-Methode ndet die Duplikate in den Archiven und weist den/die Benutzer(in)
darauf hin.
11.1.2 Angri: Referenzen auf Obercodes
Meine erste Idee zur Entschlusselung von hierarchisiertem mobilen Code war es, dass jeder
Teilcode seine verschlusselten Teilantworten an seinen Obercode weitergibt, so dass am Ende
alle verschlusselten Teilantworten im Hauptcode enthalten sind. Der Vorteil dieses Verfahrens
ist, dass die Entschlusselung aller Teilantworten einfach und schnell geht, da Teilantworten in
einem Schritt entschlusselt werden konnen. Allerdings hat dieser Ansatz gravierende Nachteile:
der Hauptcode hat direkten Zugri auf alle entschlusselten Teilantworten wahrend der
Ausfuhrung
alle Teilcodes benotigen eine Referenz auf den Hauptcode, um uber ihn auf ihre Teilantworten zugreifen zu konnen; mit einer solchen Referenz konnten sie versuchen, oentliche
Methoden auf dem Hauptcode aufzurufen.
In dem Hierarchisierungsverfahren, das ich schlielich implementiert habe, sind alle Teilcodes
fur ihre Teilantworten und Teilcodes selbst zustandig. Teilcodes haben keine Referenzen auf den
Hauptcode (oder einen Obercode, in dem sie enthalten sind). Auch Teilcodes in derselben Ebene
der Hierarchie haben keine Referenzen aufeinander. Andersherum hat ein Obercode Referenzen
103
auf die direkten Teilcodes, die ihn ihm enthalten sind, damit die Berechnungsmethode auf
den Teilcodes aufgerufen werden kann. Dass der Obercode den Teilcode bei der Ausfuhrung
verandert oder falsche Ergebnisse berechnet, kann nur mit einer semantischen Prufung der
Operatoren festgestellt werden.
104
12 Auswahl mehrerer Eigenschaftsnachweise
12 Auswahl mehrerer Eigenschaftsnachweise
Eine Anfrage mit mehreren Eigenschaftsnachweisen bundelt die darin nachgewiesenen Eigenschaften. Wenn eine Datenquelle fur einen Datensatz A einen Eigenschaftsnachweis eigA verlangt und fur einen Datensatz B einen Eigenschaftsnachweis eigB , dann muss sie A mit dem
Schlussel aus eigA (das sei keyeigA ) verschlusseln und B mit dem Schlussel aus eigB (also
keyeigB ). Der anfragende Kunde muss im Besitz beider privater Schlussel sein, wenn er beide
Datensatze entschlusseln will.
Schwieriger wird es, wenn die Datenquelle fur einen Datensatz zwei oder mehrere Eigenschaftsnachweise verlangt: die Datenquelle will Eigenschaften UND-verknupfen, die sich uber mehrere
Eigenschaftsnachweise verteilen. Wenn die Datenquelle nachprufen will, ob alle Eigenschaften
zu einer Person gehoren, ist das (unter der Annahme, dass ein Schlussel nur zu genau einer
Person gehort) im einfachsten Fall dadurch moglich, dass die Nachweise denselben oentlichen
Schlussel enthalten. Dann muss die Teilantwort der Datenquelle auch nur einmal mit diesem
Schlussel verschlusselt werden. Die Datenquelle sollte also neben der Prufung der Authentizitat
der Zertikate auch die Gleichheit der Schlussel prufen.
Der Kunde kann aber auch im Besitz mehrerer oentlicher Schlussel sein und in einer Anfrage
Eigenschaftsnachweise mit unterschiedlichen Schlusseln verwenden. Dabei konnen hinter dem
Begri "Kunde\ durchaus mehrere menschliche Benutzer stehen, die eine Anfrage zusammen
stellen. Aus den Eigenschaftsnachweisen kann eine Datenquelle nicht ersehen, ob nur eine Person oder mehrere Personen die Anfrage stellen. Wenn die Datenquelle den Datenzugri von
der Anzahl der anfragenden Personen abhangig macht, braucht sie zusatzlich noch Informationen daruber, wieviele Personen die Anfrage stellen (vgl. [ABFK03], Seite 377). Diesen Fall
mochte ich hier nicht weiter betrachten. Um sicherzustellen, dass der Kunde berechtigt ist,
die Daten zu sehen, verschlusselt die Datenquelle die Teilantwort mit den Schlusseln aus allen
Zertikaten, die die geforderten Eigenschaften nachweisen: Verlangt die Datenquelle fur einen
Datensatz C die Eigenschaftsnachweise eigA und eigB , verschlusselt sie ihn nacheinander mit
den Schlusseln keyeigA und keyeigB . Entschlusseln kann den Datensatz nur jemand, der Zugri
auf alle Entschlusselungsschlussel hat. Wenn mehrere Zertikate denselben Schlussel enthalten,
reicht es, mit diesem Schlussel nur einmal zu verschlusseln.
Eine Menge von Eigenschaften kann zusammen auszeichnend genug sein, um einen Ruckschluss auf die Identitat der Person zuzulassen, die diese Eigenschaften innehat (es gibt also
nur eine Person, die diese Eigenschaften gleichzeitig hat); die Menge ist dann "identizierend\. Seien beispielsweise fA; B; C g eine identizierende Menge und eigA , eigB und eigC die
drei zugehorigen Eigenschaftsnachweise, in denen derselbe Schlussel benutzt wird (also gilt:
keyeigA = keyeigB = keyeigC ). Wenn der Kunde eine Anfrage mit diesen Eigenschaftsnachweisen stellt und man davon ausgeht, dass ein Schlussel nur zu genau einer Person gehort, wei
zumindest der Mediator, welche Person die Anfrage gestellt hat. Um eine Identizierung durch
den Mediator zu erschweren, ist es daher angebracht, fur Eigenschaften aus einer identizierenden Menge niemals dieselben Schlussel in einer Anfrage zu verwenden.
Ein Konikt tritt dann auf, wenn eine Datenquelle alle Eigenschaftsnachweise eigA , eigB und
eigC verlangt und zusatzlich fordert, dass sie von derselben Person stammen (also alle denselben Schlussel enthalten oder durch ein weiteres Zertikat die Zusammengehorigkeit bestatigt
wird). In diesem Fall muss der Kunde entscheiden, ob er seine Identitat preisgeben will.
Eine Auswahl von mehreren Eigenschaftsnachweisen mit unterschiedlichen Schlusseln ist also
wunschenswert, um Gruppen von Personen Anfragen stellen zu lassen und die Identizierung
von einzelnen Anfragestellern zu verhindern. Man benotigt ein Verfahren, mit dem eine Teilantwort mehrfach mit verschiedenen Schlusseln verschlusselt werden kann.
105
13 Umsetzung der Auswahl mehrerer Zertikate
Die Moglichkeit, mehrere Zertikate auszuwahlen, hat auf der Kundenseite hauptsachlich Auswirkungen auf den Entschlusselungsvorgang. Es ist nicht mehr eindeutig, mit welchen der
Schlussel eine Teilantwort verschlusselt wurde; daher muss die Teilantwort eine Angabe uber
die verwendeten Schlussel enthalten. Aber auch das Anfrageformat musste geandert werden,
da es nun mehrere Zertikate enthalten muss. Daher musste zunachst eine neue Anfrageklasse
erstellt werden: org.mmm.core.QueryWithMultCertificates ermoglicht das. Dem/der Benutzer(in) muss in der Benutzungsschnittstelle die Moglichkeit gegeben werden, mehrere Zertikate
auszuwahlen. Dazu habe ich einen dritten Reiter im Kundemodulfenster erstellt, der in Abbildung 27 zu sehen ist.
Abbildung 27: Auswahl mehrerer Zertikate in der Benutzungsschnittstelle des Kunden
Fur den vollstandigen Multimediamediator mit mehrfacher Verschlusselung fehlen noch zwei
entscheidende Funktionen. Zum Einen muss der Mediator eine auf die jeweilige Datenquelle
zugeschnittene Teilmenge der Zertikate bilden. In meinem System sendet das Mediatormodul
alle Zertikate, die es mit der Anfrage bekommen hat, an die Datenquellen und trit keine Auswahl. Zum Anderen muss die Datenquelle die Authentizitat der Eigenschaftsnachweise
uberprufen und dann diejenigen auswahlen, die sie fur die Verschlusselung benutzen will. Das
sollten die Nachweise sein, die Eigenschaften nachweisen, die fur den Zugri auf die angeforderten Informationen notwendig sind. Mein Datenquellenmodul benutzt alle Zertikate zur
Verschlusselung, die in der Teilanfrage als Feld (Certificate[]) vorhanden sind. Es verschlusselt nacheinander die Teilantwort mit allen Zertikaten in der Reihenfolge, in der sie im Feld
vorliegen.
Die Verschlusselung mit mehreren Schlusseln betrit nur die Datenquellen. Mediatoren mussen
ihre mobilen Codes nicht mit mehreren Schlusseln verschlusseln, da eine Berechtigungsprufung
nur auf den Teilantworten durchgefuhrt wird. In den folgenden Abschnitten stelle ich die Verfahren zur Ver- und Entschlusselung mit mehreren Schlusseln vor. Sequenzdiagramme, die das
veranderte Verfahren darstellen, benden sich in den Anhangen D und E auf den Seiten 118
und 119.
13.1 Verschlusselung mit mehreren Schlusseln
Um die Zertikate (und damit die oentlichen asymmetrischen Schlussel) eindeutig auszuzeichnen, erstellte ich die neue Klasse org.mmm.core.CertificateWithSerialNumber. Bei einer An-
106
frage wird fur jedes ausgewahlte Zertikat ein solches Objekt instanziiert. Es weist dem Zertikat eine Seriennummer zu. Die Anfrage und die Zertikate werden in einem Objekt der neu erstellten Anfrageklasse QueryWithMultCertificates zusammengefasst. Das Kundenmodul sendet dieses Anfrageobjekt uber die neue RMI-Methode request(QueryWithMultCertificates
qwc) an den Mediator (requestSealedAndSigned(QueryWithMultCertificates qwc) im verschlusselten und signierten Fall).
Der Mediator spaltet die Anfrage wie bisher auf. Aus einer Teilanfrage und den Zertikaten
aus der Gesamtanfrage erstellt er ein neues QueryWithMultCertificates, das er als Anfrage
an die ausgewahlte Datenquelle (oder den Mediator) sendet. Die Datenquelle fuhrt die Datenbankanfrage aus und erstellt einen symmetrischen Sitzungsschlussel, mit dem sie das Ergebnis
der Datenbankanfrage verschlusselt. Der Sitzungschlussel wird dann mit den oentlichen asymmetrischen Schlusseln aus allen Zertikaten verschlusselt.
Die Klasse org.mmm.core.SealedResult fasst wie bisher die verschlusselten Daten und den
verschlusselten Sitzungsschlussel zusammen. Sie bekam aber als zusatzliches Attribut ein Feld
(das "Seriennummernfeld\), in dem die Seriennummern der verwendeten Zertikate gespeichert
werden. Die Datenquelle fugt bei der Verschlusselung einer Teilantwort nacheinander die Seriennummern der Zertikate in das Seriennummernfeld des neu erstellten SealedResult-Objekts
ein. Die Reihenfolge innerhalb des Feldes gibt die Reihenfolge der verwendeten Zertikate an.
Die oentlichen asymmetrischen Schlussel in den Zertikaten sind RSA-Schlussel und es wird
weiterhin der Bouncy Castle Provider (siehe [BCP]) benutzt. Bei der Programmierung ergab
jedoch sich das Problem, dass der BouncyCastle-RSA-Algorithmus nur Klartexte verschlusselt,
deren Eingabelange kleiner ist als die Lange des Modulus des RSA-Schlussels. Eine Anwendung
des RSA-Algorithmus' produziert aber ein Ergebnis, das die gleiche Lange wie der Modulus des
RSA-Schlussels hat. Wenn man beispielsweise einen TripleDES-Sitzungschlussel der Lange 168
Bit und einen RSA-Schlussel mit einem Modulus der Lange 1024 Bit benutzt, kommt bei der
ersten Verschlusselung ein Schlusseltext der Lange 1024 Bit heraus. Eine weitere Anwendung
des RSA-Algorithmus' auf diesen Schlusseltext ist dann nicht mehr moglich, sondern fuhrt
zu der Fehlermeldung: java.lang.ArrayIndexOutOfBoundsException: too much data for
RSA block.
Ich habe daher einen anderen Weg genommen, um zu uberprufen, ob der Kunde im Besitz aller
Entschlusselungsschlussel ist. Da dabei jedoch mehrere symmetrische Schlussel erstellt werden, benotigte die Klasse SealedResult als weiteres Attribut ein Feld (das Schlusselfeld\),
in dem die verschlusselten Binarreprasentationen der symmetrischen Schlussel" abgespeichert
werden. Die Verschlusselung des Sitzungsschlussels mit mehreren RSA-Schlusseln habe ich mit
folgendem Algorithmus implementiert:
1. Wenn es nur einen RSA-Schlussel public1 gibt, wird nur der Sitzungschlussel secret1
erzeugt (als ein Objekt vom Typ javax.crypto.SecretKey)
(a) Die Binardarstellung von secret1 (das ist bin secret1 ) wird mit public1 verschlusselt
und das Ergebnis als einziger Eintrag in das Schlusselfeld eingefugt
(b) Die Seriennummer serialpublic1 des Zertikats, in dem sich public1 befand, wird als
einziger Eintrag in das Seriennummernfeld eingefugt
2. Wenn es n verschiedene RSA-Schlussel public1 : : : publicn gibt, werden neben dem Sitzungschlussel secret1 noch n 1 weitere symmetrische Schlussel secret2 : : : secretn der
gleichen Lange erzeugt
(a) bin secret1 : : : bin secretn werden bitweise mit exklusivem ODER verknupft:
antival = bin secret1 : : : bin secretn
Das Ergebnis antival wird mit public1 verschlusselt; das Verschlusselungsergebnis
wird als erster Eintrag in das Schlusselfeld eingefugt
(b) serialpublic1 wird als erster Eintrag in das Seriennummernfeld eingefugt
107
13.2 Entschlusselung mit mehreren Schlusseln
(c) fur k = 2 : : : n:
i. bin secretk wird mit publick verschlusselt und das Ergebnis an das Ende des
Schlusselfelds angefugt
ii. serialpublick wird an das Ende des Seriennummernfelds angefugt
U ber die Benutzungsschnittstelle wird die Schlussellange fur die neu zu erzeugenden symmetrischen Schlussel ausgewahlt. Die RSA-Verschlusselungen konnen durchgefuhrt werden, wenn die
ausgewahlte Schlussellange kompatibel mit den oentlichen RSA-Schlusseln aus dem Zertikat
des Kunden ist; das heit, dass die symmetrischen Schlussel kurz genug sein mussen, um mit den
RSA-Schlusseln verschlusselt zu werden. Wenn nur ein RSA-Schlussel zur Verschlusselung vorhanden ist, kann der Sitzungsschlussel ohne Probleme mit diesem RSA-Schlussel verschlusselt
werden. Wenn mehrere RSA-Schlussel vorhanden sind, muss das Problem bei der mehrfachen
RSA-Verschlusselung umgangen werden. Die n 1 symmetrischen Zusatzschlussel werden mit
jeweils einem RSA-Schlussel verschlusselt. Das Ergebnis einer solchen Verschlusselung hat, wie
oben beschrieben, die Lange des Modulus des RSA-Schlussels. Diese Ergebnisse werden aber
nicht erneut verschlusselt, sondern es wird das bitweise exklusive ODER aller Zusatzschlussel
und des Sitzungsschlussels berechnet. Die bitweise Kontravalenz der Zusatzschlussel und des
Sitzungsschlussels hat dieselbe Lange wie die einzelnen Schlussel; auch sie kann daher mit einem der RSA-Schlussel verschlusselt werden.
Die verschlusselte Teilantwort wird wie bisher an den Mediator geschickt. Er erzeugt fur die
Teilantwort einen ResultProxy und fugt ihn in den Antwortbaum ein. Der Mediator verschlusselt seinen Antwortbaum mit dem oentlichen Schlussel aus dem ersten Zertikat des Kunden
in der Anfrage.
13.2 Entschlusselung mit mehreren Schlusseln
Die entscheidende A nderung am Kundenmodul war die Umwandlung des Entschlusselungsobjektes org.mmm.client.Unsealer. Die ursprungliche Klasse konnte nur Entschlusselungen
mit einen Schlussel durchfuhren. Ich habe sie zunachst in org.mmm.client.UnsealerOneKey
umbenannt, um das deutlich zu machen. Danach erstellte ich eine neue Klasse zur Entschlusselung mit mehreren Schlusseln mit dem Namen org.mmm.client.UnsealerMultKeys. Beim
Erstellen einer Anfrage instanziiert das Kundenmodul einen UnsealerMultKeys. Dieser erzeugt fur jedes ausgewahlte Zertikat einen UnsealerOneKey und speichert ihn unter der Seriennummer des Zertikats in einer java.util.Hashtable (der "Entschlusslertabelle\) ab. Die
Antwort des Multimediamediators erfolgt weiterhin in Form eines SealedResultExtractors.
Er wird mit der Entschlusselungsmethode fur mobile Codes (unsealResultExtractor() des
UnsealerMultKeys) zu einem ResultExtractor entschl
usselt, der die Teilantwortentabelle mit
allen verschlusselten direkten Teilantworten in Form von SealedResults und allen verschlusselten direkten Teilcodes in Form von SealedResultExtractors enthalt. Zum Entschlusseln der
Teilantworten und Teilcodes ruft der SQLRequestor die Entschlusselungsmethode fur Teilantworttabellen unsealResults() auf und ubergibt ihr die Teilantwortentabelle. Diese Methode
entschlusselt jede Teilantwort und geht dabei wie folgt vor:
1. Wenn das Seriennummernfeld des SealedResult nur einen Eintrag serial hat:
(a) mit serial wird der passende UnsealerOneKey aus der Entschlusslertabelle geholt
(b) der erste Eintrag aus dem Schlusselfeld wird vom UnsealerOneKey zur Binardarstellung bin secret des Sitzungsschlussels entschlusselt
2. Wenn es n Eintrage serial : : : serialn im Seriennummernfeld gibt:
(a) fur k = 2 : : : n:
1
1
1
1
108
i. der zu serialk gehorende UnsealerOneKey wird aus der Entschlusslertabelle
geholt.
ii. der k-te Eintrag aus dem Schlusselfeld wird vom UnsealerOneKey zu bin secretk
entschlusselt
(b) bin secret2 ; : : : ; bin secretn werden zusammen mit dem ersten Eintrag aus dem
Schlusselfeld bitweise mit exklusivem ODER verknupft; das Ergebnis ist die Binardarstellung des Sitzungsschlussels bin secret1 :
bin secret1 = antival bin secret2 : : : bin secretn
3. bin secret1 wird mittels einer javax.crypto.spec.SecretKeySpec in secret1 (ein Objekt der Klasse javax.crypto.SecretKey) umgewandelt
Der Kunde kann die n 1 Zusatzschlussel nur mit dem jeweils passenden privaten RSA-Schlussel
entschlusseln. Auch die bitweise Kontravalenz der Zusatzschlussel und des Sitzungsschlussels
erhalt er nur mit dem passenden RSA-Schlussel. Den Sitzungsschlussel kann der Kunde nur
ausrechnen, wenn wirklich alle Schlussel und die Kontravalenz entschlusseln konnte. Mit diesem
Verfahren muss der Kunde also im Besitz aller privaten RSA-Schlussel sein, um den Sitzungsschlussel zu erhalten und damit auf die geschutzten Daten zugreifen zu konnen.
Mit dem Sitzungschlussel entschlusselt der UnsealerMultKeys die aktuelle Teilantwort und
fugt sie statt der verschlusselten Teilantwort in die Teilantwortentabelle ein. Ist ein Eintrag in
der Teilantwortentabelle keine Teilantwort sondern ein Teilcode, wird die Entschlusselungsmethode fur mobile Codes (unsealResultExtractor()) aufgerufen. Fur die Teilantwortentabelle
des entschlusselten Teilcodes wird die oben dargestellte Entschlusselungsmethode erneut durchgefuhrt.
109
V.
Resu
age fu
mee und Vorschl
r die Zukunft
Inhalt
14 Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
15 Vorschlage fur die Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
In our country, there are many races living together, but we have not been
"able
to live together in peace because the situation does not exist where we
can trust each other. So trust is a basic element for peace. Unless we can
trust each other, unless we can be sure that we will receive justice, and that
we also have to give justice, we can not achieve peace.\
Daw Aung San Suu Kyi
110
14 Resumee
14 Resumee
Das Konzept der Mediation wurde eingefuhrt, um die Informationssuche in einer Unmenge von
Daten zu erleichtern. Das Multimediamediator-Konzept sieht die drei Teilnehmerrollen Kunde,
Mediator und Datenquelle vor. Vorteilhaft fur alle Teilnehmer ware es, wenn der Mediator
auf die Anfrage eines Kunden eine verschlusselte Gesamtantwort mit relationalen Operatoren
auf verschlusselten Teilantworten der Datenquellen berechnen konnte. In dieser Arbeit wurden
daher zunachst aktuelle Forschungergebnisse aus dem Bereich der Berechnungen auf verschlusselten Daten vorgestellt. Eine Umsetzung auf den Multimediamediator ist jedoch derzeit (oder
vielleicht sogar generell) nicht moglich, selbst dann nicht, wenn die Teilantworten mit nur
einem Schlussel verschlusselt wurden. Das Multimediamediator-System braucht daher eine andere Moglichkeit, dem Kunden die Gesamtantwort zukommen zu lassen, ohne dem Mediator
Informationen uber die Teilantworten und die Gesamtantwort zu enthullen. Das fuhrt dazu,
dass der Kunde im Vergleich zum unverschlusselten Verfahren zusatzliche Aufgaben ubernehmen muss. Nur er kann und darf die Teilantworten entschlusseln und muss danach aus den
Teilantworten die Gesamtantwort berechnen.
Als Berechnungsverfahren wurden die beiden Paradigmen "mobiler Code\ und "mobile Daten\
verglichen. Dabei ergab sich, dass mobiler Code seine Vorteile gegenuber mobilen Daten im
Multimediamediator-Konzept nicht voll ausspielen kann; der Mediator nimmt ihm mogliche
Rationalisierungen durch die Bundelung der Teilantworten schon ab. Mobiler Code ist jedoch
insgesamt exibler als mobile Daten. Die Ausfuhrungsumgebung des mobilen Codes ist klein
und arbeitet mit den allgemeinen Schnittstellen des mobilen Codes, die sich selten andern.
Aktualisierungen der Ausfuhrungumgebung sind daher genauso selten notig. Es werden weniger Daten stationar auf dem Kundenrechner benotigt, denn jeder Code bringt seine aktuellen
Bibliotheken mit. Das vermeidet Inkompatibilitaten, wie sie zwischen Bearbeitungsprogramm
und Datenformat mobiler Daten auftreten konnen. Mobiler Code bringt vielseitige Moglichkeiten zur Erweiterung, da neue Formate und Operatoren zur Laufzeit eingefugt werden konnen.
Diese Punkte wurden als die charakteristischen Vorteile fur ein dynamisches System wie das
des Multimediamediators herausgestellt.
Es wird nicht vorausgesetzt, dass der Kunde dem Mediator als Codehersteller vertraut; der mobile Code konnte den Kunden wahrend der Ausfuhrung auf vielfaltige Weise angreifen. Mogliche
Angrie des Codes wurden umfassend erortert. Als Abwehrmanahmen wurden statische und
dynamische U berprufungen vorgestellt.
Andersherum wurden Angrie des Kunden auf den mobilen Code betrachtet. Wenn der Kunde
Daten oder Programmcode des mobilen Codes verandert, schadet er nur sich selbst. Als besonderes Problem wurde jedoch identiziert, dass Programmcode und Daten des mobilen Codes
von unterschiedlichen Stellen kommen. Aus diesem Grunde konnte der Programmcode innerhalb des mobilen Codes die unverschlusselten Daten auf dem Kundenrechner mit schadlichen
Operatoren angreifen. Dies entspricht jedoch der generellen Frage nach der semantischen Korrektheit des Programmcodes. Der Kunde kann nur mit einer U berprufung des Programmcodes
feststellen, ob der Code falsche Berechnungen auf den Daten ausfuhrt.
Bei einer Hierarchisierung der Mediatoren sind verschiedene Mediatoren Hersteller von Teilcodes. Diese Teilcodes konnen sich wahrend der Ausfuhrung auf dem Kundenrechner sogar
gegenseitig angreifen.
Bei der praktischen Umsetzung wurde fur jede Teilnehmerrolle des Mediatorsystems ein Modul
implementiert: ein Kundenmodul, ein Mediatormodul und ein Datenquellenmodul. Die Kommunikation zwischen den Modulen ndet uber RMI statt. Es wurden als Erweiterungen ein
Verfahren zur mehrfachen Verschlusselung von Teilantworten mit unterschiedlichen oentlichen
Schlusseln umgesetzt und die Grundlage fur eine Hierarchisierung von Mediatoren geschaen.
111
Das Kundenmodul bietet folgende Funktionen:
beliebig viele X.509-Zertikate, die oentliche RSA-Schlussel des Kunden enthalten, konnen aus mehreren Schlusselspeichern ausgewahlt werden
der Signaturprufschlussel des gewunschten Mediators kann aus einem beliebigen Schlusselspeicher ausgewahlt werden
mit einem entsprechenden Kryptographie-Anbieter konnen mobiler Code und Teilantworten, die mit beliebigen Verfahren verschlusselt wurden, wieder entschlusselt werden
der Binarcode eines mobilen Codes wird zur Laufzeit durch einen anwendungsspezischen
Klassenlader geladen; neue Datenformate und Operatoren werden so eingebunden
das Kundenmodul warnt den/die Benutzer(in) bei einer falschen Signatur, einem falschen
Zeitstempel und bei mehrfachen Klassendenitionen im Binarcode des mobilen Codes
Das Mediatormodul bietet folgende Funktionen:
es konnen eine Datenquelle oder ein Mediator gewahlt werden, an die Teilfragen delegiert
werden; zu der Datenquelle kann eine beliebige Datenbank angegeben werden
der Signierschlussel des gewunschten Mediators kann aus einem beliebigen Schlusselspeicher ausgewahlt werden
der symmetrische Verschlusselungsalgorithmus ist mit entsprechendem KryptographieAnbieter frei einstellbar
Das Datenquellenmodul bietet folgende Funktionen:
es konnen ein beliebiger Datenbankserver und ein entsprechender Datenbanktreiber gewahlt werden
Der symmetrische Verschlusselungsalgorithmus ist mit entsprechendem KryptographieAnbieter frei einstellbar
In allen Modulen lassen sich die Einstellungen zur Laufzeit andern. Die Verschlusselungs- und
Signieralgorithmen konnen in jeder Instanz eines Moduls frei gewahlt werden und neue Algorithmen konnen mit einem aktuellen Kryptographie-Anbieter zusatzlich eingefugt werden. Alle
Module enthalten zahlreiche graphische Fehlermeldungen. Es wurden insgesamt 68 Klassendateien mit 9315 Zeilen Code produziert.
Wahrend der Programmierung wurde deutlich, dass der mobile Code vor einem Zugri des
Kunden nicht geschutzt ist. Andersherum kann der Kunde lange und rechenintensive Berechnungen des mobilen Codes mit der Programmiersprache Java nicht einschranken.
Es wurde durch einen entsprechenden Entwurf jedoch erreicht, dass andere Angrie des mobilen Codes abgewehrt werden konnen: Berechtigungen auf dem Kundenrechner werden nur
dem Kundenmodul zugewiesen; der mobile Code braucht keine Berechtigungen. Der Zugri
auf Java-Standardklassen wird fur den mobilen Code eingeschrankt. Um Komplotte von zwei
Codes zu auszuschlieen, mussen mobilen Codes jeweils in einem eigenen Java-Prozess gestartet werden. Das Gleiche gilt, um zu verhindern, dass Ressourcendiebstahl eines Codes andere
Codes in Mitleidenschaft zieht.
112
15 Vorschlage fur die Zukunft
15 Vorschlage fur die Zukunft
In dieser Diplomarbeit ging es vorrangig um die technische Umsetzung und Sicherung auf
Kundenseite. Um den Multimediamediator wirklich einsatzfahig zu machen, muss vor allem
die Zugriskontrolle auf Datenbankseite umgesetzt werden. Die von mir verwendeten X.509Zertikate, in denen der Name des Kunden steht, sollten durch Eigenschaftsnachweise ersetzt
werden, die unabhangig von der Identitat des Kunden nur seine Eigenschaften mit seinem offentlichen Schlussel verbinden.
Ein zweites wichtiges Modul ist ein Algorithmus, der dem Mediator die Zuweisung von Teilanfragen an einzelne Datenbanken und Mediatoren ermoglicht. Fur eine Weiterleitung an Mediatoren muss es moglich sein, komplexere Teilanfragen zu identizieren, die der beauftragte
Mediator zu einem eigenen Algebrabaum weiter aufspalten kann. Zu einer Weiterleitung gehort
es auerdem, eine adaquate Teilmenge der Eigenschaftsnachweise aus der Anfrage zu bilden.
Fur den Mediator gibt es eine Vielzahl von zusatzlichen Diensten, die er ubernehmen kann. Er
konnte etwa Informationen uber die Qualitat der erstellten Antwort mit in die Antwort einfugen. Falls Datenquellen kurzfristig ausfallen, muss er zur Bearbeitungszeit darauf reagieren
und Ersatz-Datenquellen ansprechen. Auerdem konnen die Teilanfragen asynchron und damit
parallel gestellt werden, so dass der Antwortbaum auf dem Mediator schneller erstellt werden
kann.
Das von mir entwickelte System konnte noch um die Signierung der Teilantworten erweitert
werden. Wenn Zertikate mit den entsprechenden Signaturprufschlusseln mit dem mobilen Code an den Kunden geschickt wurden, konnte der Kunde die Integritat der Teilantworten prufen.
Es konnten auerdem Verfahren, die die Korrektheit des Algebrabaums oder die Unschadlichkeit der Operatoren nachweisen, eingehender untersucht werden. In der nachsten Java-Version
1.5 werden voraussichtlich Klassen (im Paket java.lang.management) enthalten sein, die ein
U berwachen eines Programmes wahrend der Ausfuhrung ermoglichen. Es konnten daher auch
Funktionen in das Kundenmodul integriert werden, die die Ausfuhrung des mobilen Codes
uberwachen.
Ein anderer Ansatzpunkt fur weitere Arbeiten ist die Anfrage des Kunden. Es ware zu untersuchen, ob Teile der Anfrage vor dem Mediator verheimlicht werden konnen. Wenn beispielsweise
Datenquellen ausschlielich Teilanfragen der Form "select * from tablename\ erhalten, muss
Vergleichskonstanten enthalten. Spaltendie Anfrage keine Angaben uber Spaltennamen oder
namen und Vergleichskonstanten konnten daher durch Platzhalter ersetzt und erst auf dem
Kundenrechner wieder eingesetzt werden. Zur Zeit stellt der Kunde eine vollstandige SQLAnfrage, in der Attribute und die Namen der Relationen der Datenquellen enthalten sind. Der
Kunde soll jedoch gar nicht so viel uber den Aufbau der Datenbanken der Datenquellen wissen.
Hier muss der Mediator seiner Aufgabe gerecht werden und mit seinem Anwendungsschema
und einem Sichtenmechanismus als Zwischenschicht fungieren. Eine groe Erleichterung fur den
Kunden ware es, wenn er naturlichsprachliche Anfragen losgelost von der Syntax einer Anfragesprache stellen konnte. Der Mediator kann die Anfrage dann mit Hilfe eines Semantik-Modul
interpretieren, das geeignete Ontologien bereitstellt.
Ideal ist und bleibt fur das Multimediamediator-System eine Berechnung des Mediators auf
den verschlusselten Teilantworten. Falls das uberhaupt moglich ist, mussen hierzu jedoch Berechnungsverfahren entwickelt werden, die es ermoglichen, auf Daten zu rechnen, die mit verschiedenen Schlusseln oder sogar mehrfach verschlusselt wurden.
113
VI.
Anhang
Inhalt
A
B
C
D
E
F
G

Ubersicht
der Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Kunde) . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Mediator und Datenquelle) . . . . . . . . .
Sequenzdiagramm erweitert (Kunde) . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm erweitert (Mediator und Datenquelle) . . . . . . .
Verwendete Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
116
117
118
119
120
121
114
115

A Ubersicht
der Pakete
Abbildung 28: Alle Unterpakete von org.mmm
116
B Sequenzdiagramm einfach (Kunde)
B Sequenzdiagramm einfach (Kunde)
Abbildung 29: Sequenzdiagramm des Kundenmoduls ohne Mehrfachverschlusselung
117
C Sequenzdiagramm einfach (Mediator und Datenquelle)
Abbildung 30: Sequenzdiagramm des Mediatormoduls ohne Mehrfachverschlusselung
118
D Sequenzdiagramm erweitert (Kunde)
D Sequenzdiagramm erweitert (Kunde)
Abbildung 31: Sequenzdiagramm des Kundenmoduls mit Mehrfachverschlusselung
119
E Sequenzdiagramm erweitert (Mediator und Datenquelle)
Abbildung 32: Sequenzdiagramm des Mediatormoduls mit Mehrfachverschlusselung
120
F Verwendete Tabellen
F Verwendete Tabellen
mysql> select distinct * from COFFEES;
+--------------------+-------------+-----------+-------+-------+-------+
| COF_NAME
| SUPPLIER_ID | VENDOR_ID | PRICE | SALES | TOTAL |
+--------------------+-------------+-----------+-------+-------+-------+
| Colombian
|
101 |
101 | 7.99 |
0 |
0 |
| French_Roast
|
49 |
101 | 8.99 |
0 |
0 |
| Espresso
|
150 |
150 | 9.99 |
0 |
0 |
| Colombian_Decaf
|
101 |
101 | 8.99 |
0 |
0 |
| French_Roast_Decaf |
49 |
101 | 9.99 |
0 |
0 |
+--------------------+-------------+-----------+-------+-------+-------+
5 rows in set (0.00 sec)
mysql> select distinct * from COFFEESTASTE;
+--------------------+--------+
| COF_NAME
| TASTE |
+--------------------+--------+
| Colombian
| mild |
| French_Roast
| mild |
| Espresso
| sweet |
| Colombian_Decaf
| strong |
| French_Roast_Decaf | strong |
+--------------------+--------+
mysql> select distinct * from SUPPLIERS;
+-------------+----------+
| SUPPLIER_ID | COUNTRY |
+-------------+----------+
|
150 | Colombia |
|
49 | Kenia
|
+-------------+----------+
121
G Datentrager mit Bedienungsanleitung, Programmen und Quellcode
122
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Schema eines Mediatorsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identitats- und Eigenschaftsnachweise . . . . . . . . . . . . . . . . . . . . . . . .
Rechenanbieter fur Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . .
Angrie des Codes auf den Kunden . . . . . . . . . . . . . . . . . . . . . . . . . .
Beweismitfuhrender Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zentrale Position des Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Drei mogliche Angreifer auf die Datenintegritat . . . . . . . . . . . . . . . . . . .
Berechnungen mit verschlusselten Funktionen . . . . . . . . . . . . . . . . . . . .
Standardklassenlader-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufrufkette zwischen verschiedenen Schutzbereichen . . . . . . . . . . . . . . . .
Benutzungsschnittstelle des Datenquellenmoduls . . . . . . . . . . . . . . . . . .
Ablaufschema fur das Datenquellenmodul . . . . . . . . . . . . . . . . . . . . . .
Benutzungsschnittstelle des Mediatormoduls (Datenquellenauswahl) . . . . . . .
U bersetzung einer SQL-Anfrage in einen Stringbaum . . . . . . . . . . . . . . . .
Ablaufschema fur das Mediatormodul . . . . . . . . . . . . . . . . . . . . . . . .
Rekursive Komposition fur den Algebrabaum . . . . . . . . . . . . . . . . . . . .
Relationale Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vergleichsoperatoren fur die Selektion . . . . . . . . . . . . . . . . . . . . . . . .
Benutzungsschnittstelle des Mediatormoduls (Algorithmenauswahl) . . . . . . . .
Benutzungsschnittstelle des Kundenmoduls vor der Anfrage . . . . . . . . . . . .
Benutzungsschnittstelle des Kundenmoduls nach Ausfuhrung des mobilen Codes
MMMClientLoader als Systemklassenlader . . . . . . . . . . . . . . . . . . . . . .
Auszug aus der Berechtigungsdatei des Kundenmoduls . . . . . . . . . . . . . . .
Hierarchie von Mediatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verschlusselung eines hierarchisierten Codes . . . . . . . . . . . . . . . . . . . . .
Benutzungsschnittstelle des Mediatormoduls mit Hierarchisierung . . . . . . . . .
Auswahl mehrerer Zertikate in der Benutzungsschnittstelle des Kunden . . . . .
Alle Unterpakete von org.mmm . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm des Kundenmoduls ohne Mehrfachverschlusselung . . . . . . .
Sequenzdiagramm des Mediatormoduls ohne Mehrfachverschlusselung . . . . . .
Sequenzdiagramm des Kundenmoduls mit Mehrfachverschlusselung . . . . . . . .
Sequenzdiagramm des Mediatormoduls mit Mehrfachverschlusselung . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
4
11
35
42
43
49
52
59
61
67
67
69
70
71
72
73
74
77
78
78
82
86
96
100
101
105
115
116
117
118
119
123
Tabellenverzeichnis
Tabellenverzeichnis
1
2
3
4
5
6
7
8
9
Aufteilung von Entschlusselung und Berechnung zwischen Kunde und Mediator
Schemata der Kommunikation des Mediators mit dem Kunden . . . . . . . . .
Vergleich des mobilen Codes mit mobilen Daten. . . . . . . . . . . . . . . . . .
Angrie des mobilen Codes auf den Kundenrechner . . . . . . . . . . . . . . . .
Angrie des Mediators auf den Kunden . . . . . . . . . . . . . . . . . . . . . .
Verhinderbarkeit von Angrien mit Java . . . . . . . . . . . . . . . . . . . . . .
Laufzeiten der Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Javatypische Angrie des mobilen Codes . . . . . . . . . . . . . . . . . . . . . .
Vor- und Nachteile der Hierarchisierung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
26
32
37
44
54
76
87
99
124
Glossar
Glossar
Antwortbaum
Der Antwortbaum ist ein Teil eines mobilen Codes. Er wird von einem Mediator auf der Basis eines Stringbaums erzeugt. Der Antwortbaum hat denselben Aufbau wie der Stringbaum, aus dem er aufgebaut wird. Der Antwortbaum enthalt jedoch Instanzen von Operatoren (das sind Objekte vom Typ
org.mmm.core.ResultOperator) in den inneren Knoten und vor der Entschlusselung Instanzen von verschlusselten Teilantworten (das sind Objekte
vom Typ org.mmm.core.SealedResult) in den Blattern. Nach der Entschlusselung des Antwortbaumes benden sich die Teilantworten unverschlusselt in
den Blattern (sie sind dann Objekte vom Typ org.mmm.core.Result). Im Falle
einer Hierarchisierung von Mediatoren konnen im verschlusselten Algebrabaum
in den Blattern auch Instanzen von verschlusselten Teilcodes (das sind Objekte
vom Typ org.mmm.core.SealedResultExtractor) vorhanden sein. Nach der
Entschlusselung sind es Objekte vom Typ org.mmm.core.ResultExtractor.
Binarcode
Der Binarcode ist der zweite Teil eines mobilen Codes. Er enthalt Java-Archive
in Form von Byte-Feldern (byte[]). In diesen Archiven sind die Klassendenitionen fur die Operatoren und Teilantworten enthalten, die im Antwortbaum
dieses mobilen Codes benotigt werden.
Gesamtanfrage
Die Gesamtanfrage ist die SQL-Anfrage, die der Kunde an seinen primaren
Mediator stellt.
Gesamtantwort
Die Gesamtantwort auf eine Gesamtanfrage ist die Relation, die der Kunde
nach der Ausfuhrung des mobilen Codes erhalt, den er auf seine Gesamtanfrage
von seinem primaren Mediator bekommen hat.
Hauptcode
Der Hauptcode eines mobilen Codes wird vom primaren Mediator erstellt. Er
enthalt alle Teilcodes des mobilen Codes und ist der Obercode fur alle diese
Teilcodes.
mobiler Code
Ein mobiler Code ist die Antwort eines Mediators auf die Gesamtanfrage eines
Kunden. Er enthalt einen Antwortbaum und den dazugehorigen Binarcode. Der
Kunde fuhrt den mobilen Code aus, um die Gesamtantwort auf seine Anfrage
zu erhalten. Auch jeder Teilcode ist ein mobiler Code.
Obercode
Ein Teilcode, der noch weitere Teilcodes enthalt, ist ein Obercode fur alle
diese Teilcodes. Der Hauptcode ist Obercode fur alle Teilcodes innerhalb eines
mobilen Codes.
primarer Mediator
Der primare Mediator ist der Mediator, an den der Kunde direkt seine Anfrage
stellt. Er liefert den Hauptcode an den Kunden zuruck.
Glossar
125
sekundarer Mediator
Ein sekundarer Mediator ist ein Mediator, an den der primare Mediator Teilanfragen weiterleitet.
Stringbaum
Dieser Baum wird von der SQL2Algebra-Bibliothek aus einer SQL-Anfrage
erstellt. In jedem inneren Knoten des Baumes steht der Name eines relationalen
Operators. In jedem Blatt steht der Name einer Relation; dieser Name wird in
einer Teilanfrage an eine Datenquelle oder einen weiteren Mediator verwendet.
Teilanfrage
Eine Teilanfrage ist eine SQL-Anfrage, die ein Mediator an eine Datenquelle
oder einen anderen Mediator weiterleitet. Da noch kein Algorithmus fur die
Aufspaltung einer Gesamtanfrage in komplexe Teilanfragen besteht, kann nur
eine vollstandig aufgespaltene Anfrage an eine Datenquelle oder an einen Mediator weitergeleitet werden. Teilanfragen an Datenquellen ergeben sich aus
einem Blatt des Stringbaums, den der Mediator erstellt hat. Mit dem Namen
der Relation, der in diesem Blatt des Stringbaums steht, wird die Anfrage
select distinct * from relationenname\ erzeugt und an die Datenquelle
"gestellt.
Teilantwort
Eine Teilantwort ist die Antwort einer Datenquelle auf eine Teilanfrage, die
ihr von einem Mediator gesendet wurde. Die Datenquelle verschlusselt eine
Teilantwort mit einem oder mehreren oentlichen Schlusseln des Kunden, bevor sie sie an den anfragenden Mediator zurucksendet. Der Mediator setzt die
Teilantwort als Blatt in seinen Antwortbaum ein. Nur der Kunde kann die
Teilantwort mit seinen privaten Schlusseln entschlusseln.
Teilantwortentabelle
Ein Antwortbaum enthalt eine Tabelle, in der alle verschlusselten Teilantworten und Teilcodes gespeichert sind. Bei der Entschlusselung auf den Kundenrechner werden die verschlusselten durch die unverschlusselten Teilcodes und
Teilantworten ausgetauscht; der Antwortbaum muss nicht durchlaufen werden,
um Teilantworten oder Teilcodes zu entschlusseln.
Teilcode
Ein Teilcode ist die Antwort eines Mediators auf eine Teilanfrage eines anderen Mediators. Der Teilcode enthalt einen eigenen Antwortbaum und eigenen
Binarcode. Er wird vom Mediator mit einem oentlichen Schlussel des Kunden
verschlusselt, bevor er an den anfragenden Mediator zuruckgesendet wird. Dieser Mediator setzt den Teilcode als Blatt in seinen Antwortbaum ein. Nur der
Kunde kann den Teilcode mit einem seiner privaten Schlusseln entschlusseln.
Ein Teilcode kann andere Teilcodes enthalten. Er ist dann der Obercode fur
diese Teilcodes. Direkte Teilcodes sind fur einen Mediator die Teilcodes, die er
von Mediatoren bekommt, die eine Stufe unter ihm in der Hierarchie liegen.
126
Literatur
Literatur
[ABFK03]
Altenschmidt, Christian, Joachim Biskup, Ulrich Flegel und Y
ucel Karabulut: Se-
cure mediation: requirements, design and architecture.
398, Juni 2003.
[ABK01]
[ACCK01]
[AMP04]
[Auc98]
[Bau00]
[BCP]
[BGI+ 01]
[BGS98]
[Bla03]
[BMW98]
[Bre95]
[BY98]
Journal of Computer Security, 11(3):365{
Altenschmidt, Christian, Joachim Biskup und Y
ucel Karabulut: Security Architechture
of the Multimedia Mediator. In: Data and Application Security: Developments and Directions,
Proceedings of the 14th Annual IFIP WG 11.3 Working Conference on Database Security. Kluwer
Academic Press, 2001.
Algesheimer, Joy, Christian Cachin, Jan Camenisch und G
unther Karjoth: Cryptographic Security for Mobile Code. In: IEEE Symposium on Security and Privacy, Seiten 2{11,
2001. Neuere Version unter: http://www.zurich.ibm.com/~jca/papers/secmob.pdf, Stand:
22. Juni 2009.
Aggarwal, Gagan, Nina Mishra und Benny Pinkas: Secure Computation of the k th-Ranked
Element, Seiten 40{55. Band 3027 der Reihe Cachin, Christian [Cac04], 2004. ISBN-3-54021935-8, Signatur BI-UNIDO: LNCS/3027.
Aucsmith, David (Herausgeber): Second workshop on information hiding, Band 1525 der Reihe Lecture Notes in Computer Science. Portland, Oregon, USA, 1998. ISBN-3-540-65386-4 ,
Signatur BI-UNIDO: 3378/1998.
Baumann, Joachim: Mobile agents: control algorithms, Band 1658 der Reihe Lecture notes
in computer science. Springer, Berlin [u.a.], 2000. ISBN-3-540-41192-5, Signatur BI-UNIDO:
LNCS/1658.
The Legion of the Bouncy Castle. http://www.bouncycastle.org/, Stand: 22. Juni 2009.
Barak, Boaz, Oded Goldreich, Rusell Impagliazzo, Steven Rudich, Amit Sahai,
Salil Vadhan und Ke Yang: On the (Im)possibility of Obfuscating Programs, Seiten 1{19.
Band 2139 der Reihe Kilian, Joe [Kil01], 2001. ISBN-3-540-42456-3, Signatur BI-UNIDO:
LNCS/2139.
Berkovits, Shimshon, Joshua D. Guttman und Vipin Swarup: Authentication for Mobile
Agents, Seiten 115{136. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-54064792-9, Signatur BI-UNIDO: 3378/MOBI.
Blaze, Matt (Herausgeber): Financial Cryptography, Band 2357 der Reihe Lecture notes in
computer science. Springer, Berlin [u.a.], 2003. ISBN-3-540-00646-X, Signatur BI-UNIDO: LNCS/2357.
Biehl, Ingrid, Bernd Meyer und Susanne Wetzel: Ensuring the Integrity of Agent-Based
Computations by Short Proofs, Seiten 183{194. Band 1477 der Reihe Rothermel, Kurt
[Rot98], 1998. ISBN-3-540-64959-X, Signatur BI-UNIDO: 3360/1998.
Breidenbach, Stephan: Mediation { Struktur, Chancen und Risiken von Vermittlung im Konikt. Schmidt, Koln, 1995. ISBN-3-504-06110-3, Signatur ZB-UNIDO: Bg 16501.
Belmon, Stephane G. und Bennet S. Yee: Mobile Agents and Intellectual Property Protection, Seiten 172{182. Band 1477 der Reihe Rothermel, Kurt [Rot98], 1998. ISBN-3-54064959-X, Signatur BI-UNIDO: 3360/1998.
127
Literatur
[Cac04]
[Cas01]
[CCKM00]
Cachin, Christian (Herausgeber): Advances in cryptology, Band 3027 der Reihe Lecture notes
in computer science.
LNCS/3027.
Casati, Fabio
Springer, Berlin [u.a.], 2004. ISBN-3-540-21935-8, Signatur BI-UNIDO:
(Herausgeber): Technologies for E-services, Band 2193 der Reihe Lecture notes
Springer, Berlin [u.a.], 2001. ISBN-3-540-64959-X, Signatur BI-UNIDO:
in computer science.
LNCS/2193.
und Joy Muller: One-Round Secure
Seiten 512{523. Band 1853 der Reihe
Montanari, Ugo [Mon00], 2000. ISBN-3-540-67715-1, Signatur BI-UNIDO: LNCS/1853.
[Che98] Chess, David M.: Security Issues in Mobile Code Systems, Seiten 1{14. Band 1419 der Reihe
Vigna, Giovanni [Vig98], 1998. ISBN-3-540-64792-9, Signatur BI-UNIDO: 3378/MOBI.
[Con96] Connolly, Dan: Mobile Code. http://www.w3.org/MobileCode/, 1996. Stand: 22. Juni 2009.
[Dag95] Dageforde, Mary: The Java Tutorial, Trail: Security in Java 2 SDK 1.2.
http://java.sun.com/docs/books/tutorial/security1.2/, 1995.
c Sun Microsystems,
Inc. 1995-2003, Stand: 22. Juni 2009.
[Den82] Denning, Dorothy Elizabeth Robling: Cryptography and data security. AddisonWesley Publishing Company, Reading, Mass., 1982. ISBN-0-201-10150-5, Signatur BI-UNIDO:
3560/Denn.
[Dit00] Dittmann, Jana: Digitale Wasserzeichen. Springer, Berlin, 2000. ISBN-3-540-66661-3, Signatur ZB-UNIDO: Sn 21444.
[DWK81] Davida, George I., David L. Wells und John B. Kam: A Database Encryption System
with Subkeys. ACM Transactions on Database Systems, 6(2):312{322, Juni 1981.
[ECL]
Eclipse Foundation. http://www.eclipse.org/, Stand: 22. Juni 2009.
[Eng03] Englbrecht, Michael: Entwicklung sicherer Software. Spektrum { akademischer Verlag, Heidelberg, 2003. ISBN-3-8274-1432-6, Signatur ZB-UNIDO: Sn 22453.
[FDS]
Formatted Data Set Java API. http://www.fdsapi.com/. Sourceforge-Projekt, Stand: 22. Juni
2009.
[FNP04] Freedman, Michael J., Kobbi Nissim und Benny Pinkas: Ecient Private Matching and
Set Intersection, Seiten 1{19. Band 3027 der Reihe Cachin, Christian [Cac04], 2004. ISBN3-540-21935-8, Signatur BI-UNIDO: LNCS/3027.
[Fon98] Fong, Philip W.L.: Viewer's Discretion: Host Security in Mobile Code Systems.
[FSW03]
Cachin, Christian, Jan Camenisch, Joe Kilian
Computation and Secure Autonomous Mobile Agents,
http://www.cs.sfu.ca/people/GradStudents/pwfong/personal/Pub/SFU-CMPT-TR-1998-19
.pdf, 1998. Stand: 22. Juni 2009.
Fouque, Pierre-Alain, Jacques Stern und Geert-Jan Wackers: CryptoComputing with
rationals, Seiten 136{146. Band 2357 der Reihe Blaze, Matt [Bla03], 2003. ISBN-3-540-00646-
X, Signatur BI-UNIDO: LNCS/2357.
[GHJV95] Gamma, Erich, Richard Helm, Ralph
und John Vlissides: Design Patterns:
Addison-Wesley Publishing Company, New
York, 1995. ISBN-0-201-63361-2, Signatur ZB-UNIDO: L Sr 441.
c 2001-2004 The GIMP Team, Stand: 22. Juni 2009.
[GIM]
The Gimp. http://www.gimp.org/, [GKCR98] Gray, Robert S., David Kotz, George Cybenko und Daniela Rus: D'Agents: Security
in a Multiple-Language Mobile-Agent System, Seiten 154{187. Band 1419 der Reihe Vigna,
Giovanni [Vig98], 1998. ISBN-3-540-64792-9, Signatur BI-UNIDO: 3378/MOBI.
Johnson
Elements of Reusable Object-Oriented Software.
128
[GMPS97]
[Gol04]
[Gon02]
[HCK95]
[HILM02]
[Hoh98]
[JAA04]
[JAS]
[JAV]
[JCE04]
[KAG98]
[Kar02]
[KE96]
[Kil01]
[KLO98]
[LBR02]
Literatur
Gong, Li, Marianne Mueller, Hemma Prafullchandra und Roland Schemers: Going
Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit
1.2. In: USENIX Symposium on Internet Technologies and Systems, Seiten 103{112, Monterey,
CA, 1997.
Goldreich, Oded: Foundations of Cryptography {Volume II Basic Applications. Cambridge
University Press, 2004. ISBN-0-521-83084-2.
Gong, Li: JavaTM 2 Platform Security Architecture.
http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html,
2002. c Sun Microsystems, Inc. 1997-2002, Stand: 22. Juni 2009.
Harrison, Colin G., David M. Chess und Aaron Kershenbaum: Mobile Agents: Are they
a good idea? http://www.research.ibm.com/massive/mobag.ps, 1995. Stand: 22. Juni 2009.
Hacig
um
us, Hakan, Balakrishna R. Iyer, Chen Li und Sharad Mehrotra: Executing
SQL over Encrypted Data in the Database Service Provider Model. In: SIGMOD Conference,
2002.
Hohl, Fritz: Limited Time Blackbox Security: Protecting Mobile Agents from Malicous Hosts,
Seiten 1{14. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-540-64792-9, Signatur BI-UNIDO: 3378/MOBI.
Java Authentication and Authorization Service (JAAS).
c Sun Microsystems, Inc. 1994-2004, Stand:
http://java.sun.com/products/jaas/, 2004. 22. Juni 2009.
Secure Computing with Java: Now and the Future.
c Sun Microsystems, Inc.
http://java.sun.com/security/javaone97-whitepaper.html. 1994-2004, Stand: 22. Juni 2009.
c Sun Microsystems, Inc. 1994-2004, Stand: 22. Juni
Java Technology. http://java.sun.com/. 2009.
c Sun MiJava Cryptography Extension (JCE). http://java.sun.com/products/jce/, 2004. crosystems, Inc. 1994-2004, Stand: 22. Juni 2009.
Karjoth, G
unther, Nadarajah Asokan und Ceki G
ulc
u: Protecting the Computation
Results of Free-Roaming Agents, Seiten 195{207. Band 1477 der Reihe Rothermel, Kurt
[Rot98], 1998. ISBN-3-540-64959-X, Signatur BI-UNIDO: 3360/1998.
Karabulut, Y
ucel: Secure mediation between strangers in cyberspace. Dissertation, Universitat Dortmund, Fachbereich Informatik, Oktober 2002. Signatur ZB-UNIDO: DissDo 2002/118.
Eickler: Datenbanksysteme { Eine Einfuhrung. Oldenbourg,
Kemper, Alfons und Andre
Munchen, 1996. ISBN-3-486-23008-5, Handapparat des Lehrstuhls 6.
Kilian, Joe (Herausgeber): Advances in cryptology, Band 2139 der Reihe Lecture notes in
computer science. Springer, Berlin [u.a.], 2001. ISBN-3-540-42456-3, Signatur BI-UNIDO: LNCS/2139.
Karjoth, G
unther, Danny B. Lange und Mitsuru Oshima: A Security Model for Aglets,
Seiten 188{205. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-540-64792-9,
Signatur BI-UNIDO: 3378/MOBI.
Loureiro, Sergio, Laurent Bussard und Yves Roudier: Extending Tamper-Proof Hardware Security to Untrusted Execution Environments. In: Proceedings of the Fifth Smart Card Research and Advanced Application Conference, CARDIS 2002, Seiten 111{124, 2002. Auch online
Literatur
129
unter: http://www.usenix.org/events/cardis02/full_papers/loureiro/loureiro_html/,
Stand: 22. Juni 2009.
[Lee97] Lee, Peter: Proof-Carrying Code. http://www-2.cs.cmu.edu/~petel/papers/pcc/pcc.html,
1997. Stand: 22. Juni 2009.
[LM99] Loureiro, Sergio und Refik Molva: Privacy for Mobile Code. In: Proceedings of the workshop
on Distributed Object Security, OOPSLA, Seiten 37{42, 1999.
[LPS04] Lynn, Benjamin, Manoj Prabkaharan und Amit Sahai: Positive Results and Techniques
for Obfuscation, Seiten 20{39. Band 3027 der Reihe Cachin, Christian [Cac04], 2004. ISBN3-540-21935-8, Signatur BI-UNIDO: LNCS/3027.
[Mag98] MageLang Institute: Fundamentals of Java Security.
c Sun
http://java.sun.com/developer/onlineTraining/Security/Fundamentals/, 1998. Microsystems, Inc. 1994-2004, Stand: 22. Juni 2009.
[MF99] McGraw, Gary und Edward Felten: Securing Java. John Wiley and Sons, New York, 1999.
ISBN-0-471-31952-x, Signatur ZB-UNIDO: Sn 20731.
[MIC]
Microsoft Corporation.
c Microsoft Coporation 2004, Stand: 22. Juni 2009.
http://www.microsoft.com/. [MNPS04] Malkhi, Dahlia, Noam Nisan, Benny Pinkas und Yaron Sella: Fairplay { A Secure TwoParty Computation System. In: Proceedings of the 13th USENIX Security Symposium, Seiten
287{302, 2004. Auch online unter: http://www.pinkas.net/, Stand: 22. Juni 2009.
[Mon00] Montanari, Ugo (Herausgeber): Automata, languages and programming, Band 1853 der Reihe
Lecture notes in computer science. Springer, Berlin [u.a.], 2000. ISBN-3-540-67715-1, Signatur
BI-UNIDO: LNCS/1853.
[Nec02] Necula, George C.: Proof-Carrying Code. http://raw.cs.berkeley.edu/pcc.html, 2002.
Stand: 22. Juni 2009.
[NL98]
Necula, George C. und Peter Lee: Safe, Untrusted Agents Using Proof-Carrying Code,
[OLW98] Ousterhout, John K., Jacob Y. Levy und Brent B. Welch: The Safe-Tcl Security Model,
[OPE]
OpenOce.org. http://www.openoffice.org/, Stand: 22. Juni 2009.
[Pai99] Paillier, Pascal: Public-Key Cryptosystems Based on Composite Degree Residuosity Classes,
Seiten 223{238. Band 1592 der Reihe Stern, Jacques [Ste99], 1999. ISBN-3-540-65889-0,
[PAK98] Petitcolas, Fabien A.P., Ross J. Anderson und Markus G. Kuhn: Attacks on Copyright
Marking Systems, Seiten 218{238. Band 1525 der Reihe Aucsmith, David [Auc98], 1998. ISBN3-540-65386-4 , Signatur BI-UNIDO: 3378/1998.
[Pei02]
Peine, Holger: Run-Time Support for Mobile Code. Dissertation, Universitat Kaiserslautern, Fachbereich Informatik, Oktober 2002. ISBN-3-925178-93-7, ISSN-1610-2673, Signatur
ZB-UNIDO: Diss 2002/629.
[Per97] Permissions in the JavaTM 2 SDK.
c Sun
http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html, 1997. Microsystems, Inc. 1997-2000, Stand: 22. Juni 2009.
130
[Pri01]
[Rec03]
[Rot98]
[Rou03]
[RR83]
[RS98]
[RSA]
[SBK01]
[Sch02]
[ST98]
[Ste99]
[SUN]
[SYY99]
[TCG]
[Vck99]
[Vig98]
[VJ99]
Literatur
API for Privileged Blocks.
c Sun
http://java.sun.com/j2se/1.4.2/docs/guide/security/doprivileged.html, 2001. Microsystems, Inc. 1997-2000, Stand: 22. Juni 2009.
Rechenberg, Peter: Technisches Schreiben { (nicht nur) fur Informatiker. Hanser, Munchen,
2003. ISBN-3-446-22472-6, Signatur BI-UNIDO: 3150/Rech.
Rothermel, Kurt (Herausgeber): Mobile agents, Band 1477 der Reihe Lecture notes in computer science. Springer, Berlin [u.a.], 1998. ISBN-3-540-64959-X, Signatur BI-UNIDO: 3360/1998.
Roubtsov, Vladimir: Cracking Java byte-code encryption.
http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html, 2003.
c JavaWorld.com 2004, Stand: 22. Juni 2009.
Rushby, John und Brian Randell: A Distributed Secure System. IEEE Computer, 16(7):55{
67, Juli 1983.
Riordan, James und Bruce Schneier: Environmental Key Generation Towards Clueless
Agents, Seiten 15{24. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-54064792-9, Signatur BI-UNIDO: 3378/MOBI.
RSA Security Inc.
c RSA Security Copyright 2004, Stand: 22. Juni 2009.
Seltzsam, Stefan, Stephan B
orzs
onyi und Alfons Kemper: Security for Distributed EService Composition, Seiten 147{162. Band 2193 der Reihe Casati, Fabio [Cas01], 2001. ISBN3-540-64959-X, Signatur BI-UNIDO: LNCS/2193.
Schneier, Bruce: Angewandte Kryptographie. Addison Wesley, Munchen, 2002. ISBN-3-89319854-7, Signatur ZB-UNIDO: Sn 20503.
Sander, Tomas und Christian F. Tschudin: Protecting Mobile Agents Against Malicious
Hosts, Seiten 44{60. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-540-647929, Signatur BI-UNIDO: 3378/MOBI.
Stern, Jacques (Herausgeber): Advances in cryptology, Band 1592 der Reihe Lecture notes
3560/1999.
Sun Microsystems, Inc.
c Sun Microsystems, Inc 2004, Stand: 22. Juni 2009.
http://www.sun.com/. Sander, Tomas, Adam Young und Moti Yung: Non-Interactive CryptoComputing For NC
1. In: IEEE Symposium on Foundations of Computer Science, Seiten 554{567, 1999.
Trusted Computing Group.
c TCG 2004, Stand: 22. Juni 2009.
https://www.trustedcomputinggroup.org/. Vckovski, Andrej (Herausgeber): Interoperating geographic information systems, Band 1580
der Reihe Lecture notes in computer science. Springer, Berlin [u.a.], 1999. ISBN-3-540-65725-8,
Vigna, Giovanni (Herausgeber): Mobile agents and security, Band 1419 der Reihe Lecture notes
3378/MOBI.
Vitek, Jan und Christian Jensen (Herausgeber): Secure Internet Programming: Security
Issues for Mobile and Distributed Objects, Band 1603 der Reihe Lecture Notes in Computer
Science. Springer, Berlin, 1999. ISBN-3-540-66130-1, Signatur BI-UNIDO: LNCS/1603.
http://www.rsasecurity.com/.
Literatur
[VS98]
[Weg96]
[WG97]
[Wie99]
[Yee99]
[Yel96]
[YT95]
[YY04]
131
Volpano, Dennis und Geoffrey Smith: Language Issues in Mobile Program Security, Seiten
25{43. Band 1419 der Reihe Vigna, Giovanni [Vig98], 1998. ISBN-3-540-64792-9, Signatur
BI-UNIDO: 3378/MOBI.
Wegener, Ingo: Eziente Algorithmen fur grundlegende Funktionen. Teubner, Stuttgart, 1996.
ISBN-3-519-12276-6, Signatur ZB-UNIDO: L Sr 193.
Wiederhold, Gio und Michael Genesereth: The Conceptual Basis for Mediation Services.
IEEE Expert Intelligent Systems and their Applications, 12(5):38{47, 1997.
Wiederhold, Gio: Mediation to Deal with Heterogeneous Data Sources, Seiten 1{16. Band
1580 der Reihe Vckovski, Andrej [Vck99], 1999. ISBN-3-540-65725-8, Signatur BI-UNIDO:
3379/1999.
Yee, Bennet S.: A Sanctuary for Mobile Agents. In: Vitek, Jan und Christian Jensen
[VJ99], Seiten 261{274. ISBN-3-540-66130-1, Signatur BI-UNIDO: LNCS/1603.
Yellin, Frank: Low Level Security in Java. http://java.sun.com/sfaq/verifier.html,
1996. c Sun Microsystems, Inc. 1996, Stand: 22. Juni 2009.
Yee, Bennet und J. D. Tygar: Secure Coprocessors in Electronic Commerce Applications. In:
Proceedings of the First USENIX Workshop of Electronic Commerce., Seiten 155{170, Berkeley,
CA, USA, 1995. USENIX Assoc.
Young, Adam und Moti Yung: Malicious Cryptography { Exposing Cryptovirology. Wiley,
Indianapolis, Ind., 2004. ISBN-0-7645-4975-8, Signatur BI-UNIDO: 3378/Youn.
132
Inhaltsverzeichnis
Inhaltsverzeichnis
Zusammenfassung . . . .
Abstract . . . . . . . . .
Inhaltsubersicht . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I Einleitung
1 Das Konzept der Mediation . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Der Multimediamediator . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Berechnungen des Mediators auf den Teilantworten . . . . . . . . . . . .
3.1 Berechnungen auf verschlusselten Daten . . . . . . . . . . . . . . . . . .
3.2 Auswertung von SQL-Ausdrucken auf verschlusselten Tabellen . . . . .
3.4 Datensatzverschlusselung mit Teilschlusseln . . . . . . . . . . . . . . . .
3.4.1 Umsetzung auf den Multimediamediator . . . . . . . . . . . . . .
3.4.2 Umsetzung der algebraischen Operatoren . . . . . . . . . . . . .
II Diskussion
4.1 Anforderungen und Nachteile . . . . . . . . . . . . . .
4.2 Aufteilung von Entschlusselung und Berechnung . . .
4.3 Kommunikation zwischen Mediator und Kunde . . . .
5 Vor- und Nachteile von mobilem Code . . . . . . . . . .
5.1 Verringerung der ubertragenen Datenmenge . . . . .
5.1.1 Optimierungen der Teilanfragen . . . . . . . .
5.2 Unabhangigkeit von der Netzverbindung . . . . . . .
5.3 Vermeidung eines verteilten Berechnungszustands . .
5.4 Lokalitat von Ressourcen . . . . . . . . . . . . . . . .
5.5 Einfachheit des Empfangersystems . . . . . . . . . . .
5.6 Erweiterbarkeit des Empfangersystems . . . . . . . .
6 Sicherheitsrisiken durch mobilen Code . . . . . . . . . .
6.1 Angrie des mobilen Codes gegen den Kunden . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. i
. iii
. iii
. v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
3
7
8
8
11
12
14
15
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
20
21
23
28
28
29
29
30
30
31
31
34
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
133
Inhaltsverzeichnis
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.1.1 Spionage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Daten- und Programmkorruption . . . . . . . . . . . . . . . . . . .
6.1.3 Ressourcendiebstahl . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.4 Komplott mehrerer Codes . . . . . . . . . . . . . . . . . . . . . . .
6.1.5 Auftreten unter falscher Identitat . . . . . . . . . . . . . . . . . . .
6.1.6 Nachladen von schadlichem Code . . . . . . . . . . . . . . . . . . .
Schutz des Kunden vor Angrien des mobilen Codes . . . . . . . . . . . .
6.2.1 Dynamische Zugriskontrolle . . . . . . . . . . . . . . . . . . . . .
6.2.2 Authentizierung des Codeherstellers . . . . . . . . . . . . . . . .
6.2.3 Programmuberprufung . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4 Sandkasten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Angrie des Mediators gegen den Kunden . . . . . . . . . . . . . . . . .
6.3.1 Korrektheit der Antwort . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Informationelle Selbstbestimmung . . . . . . . . . . . . . . . . . .
6.3.3 Verfugbarkeit des Kundenrechners . . . . . . . . . . . . . . . . . .
Schutz des Kunden vor Angrien des Mediators . . . . . . . . . . . . . .
6.4.1 Informationelle Selbstbestimmung des Kunden . . . . . . . . . . .
6.4.2 Korrektheit der Antwort . . . . . . . . . . . . . . . . . . . . . . . .
Schutz der Teilantworten auf dem Mediator . . . . . . . . . . . . . . . . .
6.5.1 Klartextangri auf den privaten Schlussel . . . . . . . . . . . . . .
6.5.2 Verandern der Teilantwort . . . . . . . . . . . . . . . . . . . . . . .
6.5.3 Informationen aus der verschlusselten Antwort . . . . . . . . . . .
Schutz des mobilen Codes bei der U bertragung . . . . . . . . . . . . . . .
Schutz des mobilen Codes auf dem Kundenrechner . . . . . . . . . . . . .
6.7.1 Datenintegritat wahrend des Aufenthalts auf dem Kundenrechner
6.7.2 Geheimhaltung der Daten nach Auslieferung an den Kunden . . .
6.7.3 Geheimhaltung des Programmcodes auf dem Kundenrechner . . .
6.7.4 Integritat der Codeausfuhrung . . . . . . . . . . . . . . . . . . . .
6.7.5 Sichere Koprozessoren . . . . . . . . . . . . . . . . . . . . . . . . .
Verhinderbarkeit von Angrien mit Java . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
37
38
38
38
39
40
41
43
43
44
44
44
45
45
45
46
46
46
46
47
48
48
50
51
52
52
53
134
III Implementierung
7 Eingesetzte Java-Mechanismen . . . . . . . . . . . . . . . . . . . . .
7.1 Sicherheit auf Binarcode-Ebene . . . . . . . . . . . . . . . . . . .
7.2 Entstehung des Java-Sicherheitskonzepts . . . . . . . . . . . . . .
7.3 Klassenlader-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Das Java-Berechtigungskonzept . . . . . . . . . . . . . . . . . . .
7.5 Beispielhafte Berechtigungen . . . . . . . . . . . . . . . . . . . . .
7.6 Privilegierter Code . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7 Kryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 Schutz von Java-Archiven . . . . . . . . . . . . . . . . . . . . . . .
7.9 JDBC, RMI und JNI . . . . . . . . . . . . . . . . . . . . . . . . .
8 Umsetzung des Multimediamediators mit mobilem Code . . . . . .
8.1 Datenquellenmodul . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Verschlusselung einer Teilantwort . . . . . . . . . . . . . . .
8.1.2 Datenformate . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Mediatormodul . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Aufbau des Algebrabaums . . . . . . . . . . . . . . . . . . .
8.2.2 Teilanfragen . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3 Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.4 Signierung und Verschlusselung des mobilen Codes . . . . .
8.3 Kundenmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Ersetzen des Systemklassenladers . . . . . . . . . . . . . . .
8.3.2 Signaturprufung und Entschlusselung des mobilen Codes . .
8.3.3 Entschlusselung der Teilantworten . . . . . . . . . . . . . .
9 Mogliche Angrie auf das Mediatorsystem . . . . . . . . . . . . . .
9.1 Angrie des mobilen Codes auf den Kunden . . . . . . . . . . . .
9.1.1 Angri: Zugri auf Java-Standardklassen . . . . . . . . . .
9.1.2 Angri: O nen eines Eingabefensters . . . . . . . . . . . . .
9.1.3 Angri: O nen einer Netzverbindung . . . . . . . . . . . . .
9.1.4 Angri: Zugri auf den Klassenlader . . . . . . . . . . . . .
9.1.5 Angri: Zugri auf Kundenmodulklassen . . . . . . . . . .
9.1.6 Angri: Native Methoden . . . . . . . . . . . . . . . . . . .
9.1.7 Angri: Zugri auf das Dateisystem und andere Ressourcen
9.1.8 Angri: Komplott mehrerer mobiler Codes . . . . . . . . .
9.2 Angrie Dritter wahrend der U bertragung . . . . . . . . . . . . .
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
56
56
57
58
58
61
62
62
64
65
66
66
68
68
69
71
72
73
76
78
81
82
83
85
85
87
88
89
89
89
89
90
90
91
135
Inhaltsverzeichnis
9.3 Angrie auf mobilen Code wahrend des Aufenthalts beim Kunden . . . . . . . . . . . . . . . 92
9.3.1 Angri: Schadliche Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3.2 Angri: U berschreiben von Binarcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
IV Erweiterungen
10 Auswirkungen einer Mediatorhierarchie . . . . .
10.1 Technische Anforderungen . . . . . . . . . . .
10.2 Nachteile fur den Kunden . . . . . . . . . . . .
10.3 Angrie der Teilcodes untereinander . . . . . .
11 Umsetzung der Mediatorhierarchie . . . . . . . .
11.1 Angrie der Teilcodes untereinander . . . . . .
11.1.1 Angri: U berschreiben von Binarcodes .
11.1.2 Angri: Referenzen auf Obercodes . . .
12 Auswahl mehrerer Eigenschaftsnachweise . . . .
13 Umsetzung der Auswahl mehrerer Zertikate . .
13.1 Verschlusselung mit mehreren Schlusseln . . .
13.2 Entschlusselung mit mehreren Schlusseln . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
96
97
97
98
100
102
102
102
104
105
105
107
V Resumee und Vorschlage fur die Zukunft
109
14 Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
15 Vorschlage fur die Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
VI
A
B
C
D
E
F
G
Anhang
U bersicht der Pakete . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Kunde) . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm einfach (Mediator und Datenquelle) . . . . . . . .
Sequenzdiagramm erweitert (Kunde) . . . . . . . . . . . . . . . . . .
Sequenzdiagramm erweitert (Mediator und Datenquelle) . . . . . .
Verwendete Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
. 115
. 116
. 117
. 118
. 119
. 120
. 121
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
136
Inhaltsverzeichnis
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Sichere Mediation mit mobilem Code | Implementierung und

Transcription

Similar documents

Vorlesungsfolien ()

Sicherer Dokumentenaustausch auf Basis des World-Wide-Web

www .addertec.com

Google Hacking - DI Andreas Vida

63. Arbeitsbericht

AdderView Installation and Use