Da MASA in der Programmiersprache Java implementiert ist, muß zunächst ein Blick auf die in Java bereits vorhandenen Sicherheitsmechanismen geworfen werden.
Diese Mechanismen gliedern sich in jene, die durch
Das Design der Sprache Java realisiert bereits einige Mechanismen, die geeignet sind, Sicherheitseigenschaften zu gewährleisten.
Die Basis aller Sicherheitseigenschaften in Java wird durch das
Fehlen jeglicher Zeigerarithmetik in der Programmiersprache gebildet.
Es ist nicht möglich, einen Zeiger auf primitive Datentypen zu erzeugen (in C++ mit dem & Operator). Objektdatentypen werden immer über Referenzen angesprochen. Diese können nicht explizit dereferenziert werden (* und - Operator in C++), und es sind keine arithmetische Operationen auf Referenzen definiert (in C++ können die Operatoren + - * / auch auf Zeiger angewandt werden). Dadurch wird garantiert, daß willkürliche Speicherzugriffe, und damit auch jene in ``fremde'' Speicherbereiche innerhalb der JVM, ausgeschlossen sind.
Weiterhin garantiert Java eine strikte Typüberprüfung, die nicht nur zur Compilezeit, sondern auch zur Laufzeit durchgesetzt wird. Illegale Veränderungen von Werten durch Typumwandlungen (type casts) sind somit in Java ausgeschlossen.
Durch die fehlende Zeigerarithmetik und die stringente Typüberprüfung realisiert Java einen strikten Speicherschutz. In der Folge heißt dies, daß ein Objekt definitiv nur dann verändert werden kann, wenn eine Referenz auf dieses Objekt regulär erhalten wurde.
Eine erste fallweise Differenzierung des Zugriffs auf Daten wird durch
Visibilitätsmodifikatoren realisiert, die anwendbar auf Klassen, ihre
Attribute und ihre Methoden sind.
Um diese erläutern zu können muß zunächst noch eine weiteres Konzept der Java Sprache betrachtet werden. Alle Klassen der Sprache werden bei ihrer Deklaration in einen hierarchischen Namensraum, in sog. Packages, eingeordnet. Diese werden nach Konvention durch den komponentenweise rückwärts geschriebenen DNS-Namen der implemtierenden Instanz gebildet. Beispielsweise würde eine Klasse, die von der Firma Sun implementiert wird in das Package com.sun. eingeordnet. Damit wird eine hierarchische Gliederung aller in Java deklarierten Klassen erreicht.
Für Klassen stehen in Java zwei Visibilitätsmodifikatoren zu Verfügung:
Die Visibilitätsmodifikatoren von Attributen und Methoden sind:
Zur Kennzeichnung der Klassen, Attribute und Methoden sind in der Java-Syntax die Schlüsselworte public, protected und private definiert. Für ``package'' existiert kein eigenes Schlüsselwort. Wird keines der drei definierten Visibilitätsmodifikatoren explizit angegeben, wird implizit ``package''-Sichtbarkeit angenommen.
Neben den Visibilitätsmodifikatoren gibt es noch einige weitere Modifikatoren für Klassen bzw. Attribute und Methoden, wovon hier noch der final-Modifikator beschrieben sei. Dieser Modifikator, angewendet auf Klassen und Methoden, garantiert, daß eine Klasse nicht abgeleitet, bzw. eine Methode nicht überladen werden kann. Auf Attribute angewandt bedeutet es, daß ein in einem Konstruktor initial zugewiesene Wert des Attributs nicht mehr verändert werden kann.
Die Einhaltung der durch die Modifikatoren zugesicherten Eigenschaften wird vom Java-Compiler bei der Übersetzung überprüft. D.h. beispielsweise, wenn in einer Klasse versucht wird, auf ein als privat deklariertes Attribut einer anderen Klasse zuzugreifen, so wird dies durch den Compiler als Fehler gemeldet und der Übersetzungsvorgang wird abgebrochen.
Nun mag man einwenden, daß es aber während der Laufzeit auch möglich wäre diesen Schutz zu umgehen, indem man das Reflection-API ([JDK1.2-SDK]) benutzt, um Zugriff auf ein solches Attribut zu erlangen. Das Attribut bzw. der Methodenzugriff wird jedoch während der Laufzeit durch die JVM überprüft, und gegebenenfalls eine Ausnahmebehandlung eingeleitet.
Mit vorgestellten Modifikatoren lassen sich also bereits auf Ebene der
Programmiersprache Java statisch Zugriffseigenschaften
sicherstellen. Diese Modifikatoren können in MASA nun dazu benutzt
werden, um alle statischen Zusicherungen von Zugriffsstrukturen zu
implementieren. Ihre Überwachung und Durchsetztung wird dabei vom
Seiten des Compilers bzw. der JVM übernommen, weshalb es diesen von
seiten des Implementierungskonzepts keiner weiteren Aufmerksamkeit
bedarf.
Für die Sicherung der Schnittstelle zum Endsystem, welche durch das Java-API dargestellt wird, bietet sich die Nutzung der bereits im Java-API vorgesehenen Sicherheitsmechanismen an.
An dieser Stelle wird nur ein kurzer Überblick geboten, ausführliche Informationen zum Sicherheitsmodell finden sich in [JCA 98] und [Gon 98], die Anwendung des Security-API wird [Oaks 98] detailliert beschreiben.
![\includegraphics [width=0.7\textwidth]{sec_arch_1_1}](roel99-img36.gif)
|
Dabei ist Code, der vom lokalen Dateisystem geladen wird, immer vertrauenswürdig, ebenso wie entfernter Code (z.B. von einem Webserver), der von einer beliebigen Person signiert wurde und dessen Zertifikat überprüft werden kann.
Die Durchsetzung der Sicherheitseigenschaften in der Sandbox wird dabei durch den sog. Security Manager realisiert. Dieser muß individuell vom Implementierer entsprechend der Bedürfnisse der Anwendung entwickelt werden und in Form einer Klasse, die von java.lang.SecurityManager abgeleitet wird, implementiert werden. Dabei werden durch das API keine Mechanismen bereitgestellt, die es ermöglichen eine weitere Differenzierung (z.B. nach dem Unterzeichner) des Codes vorzunehmen, um damit beispielsweise auf einfache Weise mehrere Sandboxes mit unterschiedlichen Rechten zu realisieren. Deshalb können die im Sicherheitsmodell aufgestellten Forderungen mit JDK 1.1 nicht realisiert werden.
![\includegraphics [width=0.7\textwidth]{sec_arch_1_2}](roel99-img37.gif)
|
Jede Sandbox wird durch eine Protection Domain repräsentiert, der Identifikator einer Protection Domain ist die Code Source. Einer Protection Domain wiederum sind Permissions zugeordnet, die die Rechte einer Protection Domain bestimmen. Die Zuteilung des Codes zu einer Protection Domain wird durch eine Security Policy bestimmt, ebenso die zugehörigen Permissions.
![\includegraphics [width=0.7\textwidth]{code_dom_perm}](roel99-img38.gif)
|
Permissions sind dabei für alle Aktionen vordefiniert, die vormals in JDK 1.1 durch den Security Manager manuell überprüfbar waren. Weiterhin lassen sich anwendungsspezifische Permissions definieren, die ebenfalls in der Security Policy verwendet werden können.
Durch die Security Policy, die in einer Datei festgelegt wird und den (erweiterbaren) Permissions, ist es in JDK 1.2 möglich, ein vergleichsweise feingranulares und ohne Programmieraufwand konfigurierbares Sicherheitsmodell zu implementieren, welches auf die Bedürfnisse der Anwendung zugeschnitten ist.
Mit dem JCE-API ([JCE 99]) steht ein umfangreiches Werkzeug für die Nutzung kryptographischer Basistechniken zur Verfügung. Es enthält in Form von Klassen beispielsweise Datenstrukturen und Funktionen für:
Eine auch nur einführende Behandlung von JCE würde an dieser Stelle zu weit führen, hierfür sei auf [JCE 99], [JCA 98] und [Oaks 98] verwiesen. Zusammengefaßt stellt JCE eine standardisierte Schnittstelle für eine Reihe von Basisfunktionalitäten dar, wie sie für die Implementierung von kryptographiegestützter Anwendungen notwendig ist.
Das in [FKK 96] definierte Protokoll SSL V3.0 realisiert einige grundlegende Mechanismen zur Kanalsicherung.
Obwohl [FKK 96] nie als offizieller Standard verabschiedet wurde, hat es sich zu einem de-facto Standard in Internet-Anwendungen entwickelt. Alle namhaften Webbrowser unterstützen dieses Protokoll. Im RFC-Dokument [DiAl 99] wird TLS, der Nachfolger von SSL V3.0 beschrieben. Da TLS unmittelbar auf [FKK 96] basiert, es im wesentlichen SSL V3.0 entspricht und noch nicht weit verbreitet ist, wird im Folgenden SSL V3.0 kurz betrachtet.
SSL bietet sichere Verbindungen zwischen zwei Kommunikationspartnern. Es baut auf ein beliebiges, verläßliches Transportprotokoll auf. Auf der anderen Seite agiert es transparent für die Anwendungsschicht. Beispielsweise läßt sich SSL zwischen die Protokolle HTTP (Anwendungsprotokoll) und TCP/IP (Transportprotokoll) ``dazwischenschieben'', ohne daß eines der beide Protokolle geändert werden muß. Trotzdem sind die durch HTTP übertragenen Daten ab der TCP/IP-Schicht und darunter gesichert.
Folgende sicherheitsrelevante Eigenschaften werden von SSL unterstützt:
Die konkreten Parameter einer SSL-Verbindung, wie z.B. Schlüssellängen und die zu verwendende Verschlüsselungsalgorithmen, können individuell zwischen den beiden Kommunikationspartnern über ein Handshake-Protokoll vereinbart werden, das ebenfalls Teil der SSL-Spezifikation ist.
Eine ausführliche Untersuchung der Sicherheitseigenschaften von SSL findet sich in [WaSc 96]. Zusammenfassend läßt sich sagen, daß SSL auf einfachem Weg die Möglichkeit bietet, bestehende, auf TCP/IP basierende Protokolle gegen Angriffe zu schützen. Somit lassen sich auch die in MASA verwendeten CORBA/IIOP- und HTTP-Kanäle mit SSL gegen die in 2.3 skizzierten Angriffe absichern. Zusätzlich werden Kommunikationspartner und ausgetauschte Daten authentisiert.