11

zwei Agenten explizit aufgebaut. Sobald diese Beziehung besteht, kann dann wie bisher mit Nachrichten und RPC kommuniziert werden, aber die Adressierung ist über den Session- Bezeichner möglich und ein Kontext kann von den Partnern aufgebaut werden,

Der Aufbau der Sitzung wird durch zwei neue Kommandos möglich. Mit PassiveSetUp erklärt ein Partner seine Bereitschaft zum Aufbau einer Interaktionsbeziehung. Dieses Kommando ist nicht-blockierend und vor allem für Agenten vorgesehen, die einen Dienst nach außen anbieten wollen. Mit ActiveSetUp kann ein Agent blockierend versuchen, eine Interaktion aufzubauen. Der jeweilig mögliche Interaktionspartner wird dabei entweder durch die Angabe einer konkreten Agenten-Id spezifiziert oder durch die Angabe eines Badge-Prädikats. Dieses Prädikat erlaubt die (Teil-)Spezifikation der Beschriftung von Badges (Badges sind "Namensschilder", sie wurden kurz im letzten Teilkapitel erläutert). Eine bestehende Interaktionsbeziehung kann unilateral wieder beendet werden.

Anonyme Kommunikation mittels Events

Ist es nicht notwendig, den Kommunikationspartner zu spezifizieren, oder sind zukünftige Kommunikationspartner nicht im Voraus bekannt, wird ein Verfahren benötigt, um anonyme Kommunikation zur ermöglichen. In stationären verteilten Systemen kommen für diesen Zweck normalerweise zwei Verfahren in Frage: TupleSpaces und Eventsysteme. Wir verfolgten den Event-Ansatz weiter, weil es bei TupleSpaces fraglich schien, daß diese für große Zahlen an Teilnehmern und Interaktionen in verteilten Systemen skalieren.

EventManager gibt es bereits als Produkte, etwa im Umfeld von CORBA. Da diese auf stationäre Systeme ausgerichtet sind, ist es notwendig, diese an mobile Teilnehmer anzupassen. Weiterhin sind EventManager so zu modifizieren oder zu konzipieren, daß sie für große Zahlen von Teilnehmern und Events skalieren, weil man annehmen kann, daß ein größeres Agentensystem diese Charakteristiken hat.

Nähere Informationen zum Kommunikationsbereich finden sich in [SBH97].

5.1.3 Finden von Agenten

Interaktionen von Agenten oder dem Agentensystem mit Agenten erfordern (zumindest auf Systemebene) die Kenntnis über den Aufenthaltsort des Agenten, mit dem interagiert werden soll. Dieser Aufenthaltsort ist dabei nicht im Voraus zu bestimmen, da Agenten in Mole keine Restriktionen bezüglich ihrer "Reiseroute" auferlegt bekommen. Das Finden von Agenten ist also eine Vorstufe zur Interaktion mit den Agenten.

Die Probleme, die dabei auftauchen sind: - die Zeit für eine Migration bewegt sich in der Zeit für eine beliebige Nachricht - die minimale Zeit für den Finden-Algorithmus liegt bei einer Nachricht - die minimale Zeit für eine Sequenz aus Finden und Interagieren liegt bei der Zeit für die Übertragung zweier sequentieller Nachrichten - die Zeit, die eine für die Übertragung einer Nachricht gebraucht wird, ist groß in Relation zur Ausführungsgeschwindigkeit von Code, z.B. benötigt eine Nachricht innerhalb - eines Rechners in der Größenordnung von 100ns - eines LANs in der Größenordnung von 10 ms - eines MANs in der Größenordnung von 25ms - eines WANs in der Größenordnung von 250 ms - falls das Auffinden und Interagieren seriell stattfinden, kann es zu veralteten Daten über den Aufenthaltsort kommen

Seite 11: vorherige Seite | nächste Seite | Übersicht

12

Eine Möglichkeit, den Auffinden-Interagieren-Zyklus effektiver zu machen ist daher, beide Aspekte miteinander zu verschmelzen, und bei den Mechanismen, die das Auffinden ermöglichen Parameter vorzusehen, die die Interaktion (z.B. einen Rückkehrbefehl) angeben.

Wenn man sich ansieht, welche Eigenschaften die Informationen über den Aufenthaltsort von Agenten haben, findet man folgendes: - es gibt typischerweise eine Informationsquelle und eventuell mehrere Informationssenken - die Informationsquelle sind nacheinander verschiedene Orte - die Anzahl an Schreibeoperationen ist typischerweise viel größer als die Anzahl an Leseoperationen (d.h. der Agenten bewegt sich öfter als daß eine Entität dessen Aufenthaltsort wissen will)
- die Informationen können im Extremfall nur sehr kurz aktuell sein - die Menge an Aufenthaltsdaten steigt linear mit der Anzahl von Agenten, die gefunden werden können
- die Informationen müssen automatisch aktualisiert werden

Weitere Aspekte des Auffindens von Agenten sind: - Die Voraussetzung dafür, einen Agenten aufzufinden, ist die Kenntnis der Existenz eines Agenten, und nicht alle existenten Agenten z.B. einer Anwendung müssen vorher bekannt sein.
- Die "Moving Target"-Problematik, d.h. Agenten können sich eventuell so schnell bewegen, daß die Informationen über den Aufenthaltsort beim Ausliefern der Informationen oder bei der Reaktion veraltet sind.

Wenn man nun, wie geschehen, mehrere Auffindemechanismen untersucht, sind die folgenden Fragen zu beantworten: - Wie verhält sich der Auffindemechanismus bei einer Partitionierung des Netzes? - Wieviel kostet ein Auffindemechanismus? - Wie skalierbar ist der Auffindemechanismus? - Wie hoch ist dessen Antwortzeit? - Wie gut eignet er sich für die Interaktionsintegration? - Wie robust ist er gegen unwillige Agenten oder Agentenserver?

Unter diesen Gesichtspunkten wurden vier Einzelverfahren und ein kombiniertes Verfahren konzipiert bzw. der Literatur entnommen und evaluiert.

Heimatregister
Dieses Verfahren wird bei GSM eingesetzt und bei IPv6 zur Unterstützung mobiler Endgeräte. Es besteht darin, daß jeder Agent ein festes Heimatregister hat, von dem der jeweilige Aufenthaltsort abgefragt werden kann. Bei jeder Migration schicken Sende- und Empfangsknoten eine Nachricht an das Heimatregister. Das Problem ist, daß dieses Verfahren bei "moving targets" ständig veraltete Informationen liefert und daß es nicht zur Interaktionsintegration geeignet ist.

Broadcast
Dieses Verfahren fragt einfach alle Agentenserver per Broadcast. Der Nachteil ist die schlechte Skalierbarkeit bei vielen Anfragen, zudem muß es die Möglichkeit geben, einen schnellen (Netzwerk-)Broadcast durchzuführen.

Energiekonzept
Das Energiekonzept ist eigentlich ein Mittel der Ressourcenkontrolle. Ein Agent bekommt von seinem Eigentümer eine gewisse Menge "Energie" zugeteilt, die vom Agenten durch jede Aktion verbraucht wird. Ist die Energie verbraucht, kann der Agent gelöscht werden. Daher muß

Seite 12: vorherige Seite | nächste Seite | Übersicht

13

sich der Agent vor dem Verbrauch der Energiemenge wieder bei seinem Eigentümer melden, um neue Energie anzufordern. Dieses Verhalten kann man ausnutzen, um beim Eigentümer nach dem Aufenthaltsort des Agenten zu fragen. Da sich der Agent nicht bewegen kann, bis er eine Antwort seines Eigentümers hat, ist diese Information aktuell. Der Nachteil ist, daß im Zweifelsfall auf die Meldung des Agenten gewartet werden muß.

NameService
Hier wird ein bestehender Verzeichnisdienst als Informationsquelle benutzt. Allerdings lassen sich zumindest DNS und X.500 aufgrund ihrer anderen Ausrichtung nicht gut für diesen Zeck einsetzen, und die Implementierung eines eigenen Dienstes ist sehr aufwendig.

Kombination aus Heimatregister und NameService Hier wird angenommen, daß sich das Agentensystem in Regionen partitionieren läßt. Innerhalb der Regionen wird mit Broadcast gesucht, die Region, in der sich der Agent aufhält, wird mithilfe eines Heimatregisterverfahrens ermittelt. Dieses Verfahren funktioniert nur dann besser als z.B. das Heimatregisterverfahren, wenn Migrationen eher "lokal" bezüglich der Region sind.

Tabelle 2 zeigt schematisch die Eigenschaften der Verfahren über den oben aufgeführten Kriterien.

Tabelle 2: Verfahren zum Auffinden von Agenten

Heimatregister Broadcast Energiekonzept NameService HR + NS

Aktualität
des Ergebnisses

bestmöglich
ohne Agenten
anzuhalten

mittel
(schlecht im
Fehlerfall)

sehr gut wie HR + Zugriff auf NS
gut

Verhalten bei
Partitionierung

schlecht, bei
Replikation:
besser

gut schlecht, bei Replikation:
besser

hängt vom NS
ab
schlecht, bei
Replikation:
besser

Kosten des
Mechanismus
2N/Migration *
#Replikate
vielleicht 1N/
Server
skalierbar, Accounting muß
exist.

hängt vom NS
ab
2N/Zonenwechsel *
#Replikate

Skalierbarkeit des
Verfahrens

gut (bis auf #
Nachrichten)
schlecht für
große #
Anfragen/Orte

gut hängt vom NS ab
gut (bis auf #
Nachrichten)

Antwortzeit
des Verfahrens

sehr gut 2N seriell + Ausbreitung
des BC

skalierbar: gutschlecht
hängt vom NS
ab
gut (1N)

Eignung für
Interaktionsintegration

nicht geeignet gut geeignet gut geeignet nicht geeignet geeignet

Robustheit
gegen unwillige Agenten

gut, falls Server
übernimmt
gut gut gut, falls Server übernimmt

gut, falls
Server übernimmt

Robustheit
gegen unwillige Server

nicht robust nicht robust nicht robust nicht robust nicht robust

Seite 13: vorherige Seite | nächste Seite | Übersicht

14

Es zeigt sich, daß eine Kombination aus Heimatregister und NameService geignete Ergebnisse erwarten läßt, allerdings setzt es das Vorhandensein von größeren "Regionen" voraus, die im vorgesehenen Organisationsmodell nicht vorhanden sind. Implementiert wurden daher das Heimatregisterverfahren und das Energieverfahren, allerdings noch ohne Interaktionsintegration.

5.2 Agentenmigration

Migration ist das Kriterium, das mobile von anderen Agenten unterscheidet, und das wesentlich zu den Eigenschaften mobiler Agenten beiträgt.

5.2.1 Agenten als Objektinseln

In herkömmlichen verteilten objektorientierten Systemen interagieren zwei Objekte häufig über ein gemeinsames Objekt, also eines, auf das beide eine Referenz besitzen. Das ist effizient, solange beide alle Objekte im selben Adressraum sitzen und wird schon auf der Programmiersprachenebene unterstützt. Gemeinsame Referenzen sind allerdings ein Problem, sobald eines der Objekte aus dem Adressraum herausmigriert. Ansätze, die dieses Problem angehen, kopieren entweder die referenzierten Objekte beim migrierenden Objekt, oder sie entscheiden pro gemeinsamen Objekt, ob es "mitmigriert" und damit aus dem ursprünglichen Adressraum herausgenommen wird, oder es dort verbleibt. Das Objekt, in dessen Adressraum sich das gemeinsame Objekt nun nicht mehr befindet, hält dann eine ungültige Referenz, was sich im Laufzeitfehlern äußern kann, sofern dieses Objekt über diesen Umstand nicht informiert wird oder sich bei jedem Zugriff von der Gültigkeit der Referenz überzeugt.

Um diese Transparenz der Gültigkeit von Objektreferenzen auch bei Migrationen von anderen Objekten zu erhalten, wurde angedacht, die Idee von Hogg [Hogg91] zu verfolgen, bei der Objekte zu "Inseln" gruppiert sind, und nur Referenzen innerhalb dieser Inseln haben. Die Kommunikation zwischen den Inseln erfolgt über Objekte, die entweder als Kopie übergeben werden oder als "vollständige Übergabe", bei der das übergebende Objekt keine Referenz darauf zurückbehält. Da Agenten sehr gut mit diesen Inseln identifiziert werden konnten, hätte der Einsatz dieses Modells das gewünschte Ziel erreicht.

Leider konnte das Modell bei der Verwendung von Java als Agentensprache nicht zwingend implementiert werden, da dies eine Modifikation der Laufzeitumgebung von Java zur Folge haben würde, was aufgrund der Dynamik der Javaentwicklung als unvorteilhaft angesehen wird. Daher ist das Inselmodell noch Teil des Verarbeitungsmodells, kann aber von zwei kooperierenden Agenten durch Austausch einer gemeinsamen Referenz unterlaufen werden.

5.2.2 Schwache Migration

Ein Agent besteht aus Code und Daten, wobei sich die Daten wiederum aufteilen lassen in "statische" Daten wie globale Variablen und Instanzenvariablen und "dynamische" Daten wie Threads, lokale Variablen sowie Parameter und Rücksprungadressen. Eine Migration, die Code und alle Daten transportiert erlaubt eine transparente, die sogenannte "starke" Migration, bei der das Programm des Agenten mit der nächsten dem Migrationsbefehl folgenden Programmzeile auf dem Migrationsziel fortgesetzt wird. Der Programmierer muß keine weiteren Maßnahmen treffen, um die Migration zu ermöglichen.

Demgegenüber steht die "schwache" Migration, die nur Code und statische Daten transportiert. Da alle die Daten fehlen, die eine Wiederaufnahme des letzten Ausführungszustandes ermöglichen würden, muß der Agent bei einem festen Punkt, etwa durch das Anstoßen einer Startprozedur, wieder gestartet werden, wobei die statischen Daten, die als migrationswürdig deklariert

Seite 14: vorherige Seite | nächste Seite | Übersicht

15

wurden, automatisch mittransferiert werden. Indem man den Ausführungszustand, solange dies durch die Verarbeitung notwendig ist, manuell in den statischen Daten kodiert, läßt sich in der Startprozedur ein gewisser Ausführungszustand wieder restaurieren. Durch die manuelle Kodierung hat der Programmierer außerdem die Kontrolle über den Umfang der Daten, die mittransportiert werden, während bei der transparenten Migration alle Datenelemente, die nicht auf jeden Fall gelöscht weden können (und damit dem Garbage Collector unterliegen), mitgenommen werden müssen.

Obwohl die starke Migration sehr viel komfortabler ist, ist sie wesentlich schwerer zu implementieren, da dafür ein implementierungsunabhängiges Format für den Ausführungszustand konzipiert werden und in die Laufzeitumgebung von Java implementiert werden müsste. Dieses Vorgehen würde aber wiederum die Portierbarkeit des Agentensystem beeinträchtigen und müsste bei jeder neuen Version der Laufzeitumgebung wiedereingebaut werden, da eine entsprechende Funktionalität im Java-System nicht vorhanden ist. Da die schwache Migration höchstens genausoviele Datenelemente transportiert (und damit schneller ist) und die schwache Migration nach unseren Erfahrungen vom Programmierer gut zu beherrschen ist, entschlossen wir uns, keine starke Migration zu implementieren, sondern uns auf die schwache Form zu beschränken, ein Standpunkt, dem auch fast alle anderen Java-basierten Agentensysteme gefolgt sind (bis auf ARA, das allerdings pro Agent eine eigene Laufzeitumgebung einsetzt, und bei dem daher Agentenkommunikation innerhalb eines Platzes auch immer eine Adreßraumgrenze überschreitet). Nähere Informationen zur Migration lassen sich in [RHR97] und [SBH97] finden.

5.2.3 Effiziente Migration von Code

Die Effizienz der Migration eines Agenten ist -aufgrund der Bedeutung dieses Aspektes für mobile Agenten- wesentlich für die Performanz von Anwendungen, die auf mobilen Agenten beruhen. Aus technischer Sicht muß bei einer Migration der Code und die Daten des Agenten transportiert werden. Da die Daten von Agent zu Agent verschieden sind, läßt sich dieser Transport bis auf Datenkompression nicht beschleunigen. Der Transport von Code allerdings läßt sich effizienter gestalten, wenn er aus Teilen besteht, die auch von anderen Agenten verwendet werden. Da auch verschiedene Agententypen zum Teil gleiche Funktionalität benötigen, ist diese Annahme durchaus realistisch. Weiterhin ist zu erwarten, daß mehrere Agenten eines Typs gleichzeitig im Agentensystem arbeiten.

Aus diesen Überlegungen wurde ein Mechanismus konzipiert und implementiert, der aus zwei Teilverfahren besteht, die unterschiedlichen Anforderungen genügen. Dazu wurde das Konzept des Code-Servers eingeführt. Ein Code-Server speichert Programmcode und stellt ihn auf Anfrage zur Verfügung. Das Problem der Codemigration kann vereinfacht auf die Suche nach einem günstigen Code-Server zurückgeführt werden. Das Problem wurde in zwei unterschiedliche Aufgaben aufgeteilt. Ein Basismechanismus garantiert das korrekte Ergebnis der Suche, während ein schneller Dienst nur manche Klassen auffindet, dafür aber besonders schnell arbeitet. Für den Basismechanismus werden eine Reihe von alternativen Algorithmen untersucht und verglichen. Der schnelle Dienst setzt sich aus verschiedenen Konzepten der Kooperation von Servern und dem Agentensystem zusammen. Die Kombination beider Suchmechanismen sorgt für eine zuverlässige und schnelle Codemigration. Das Agentensystem muß die Sicherheit der Agenten gewährleisten, da manipulierte Agenten im Namen ihres Benutzers großen Schaden anrichten können. Das Agentensystem ist dabei darauf angewiesen, daß die Codemigration gegen Manipulationen geschützt wird. Ein Mechanismus zur automatischen Signierung der Klassen ist Teil der Implementierung des Code-Servers.

Seite 15: vorherige Seite | nächste Seite | Übersicht

16

Nähere Informationen zu diesem Thema finden sich in [HKB97].

5.2.4 Performanzmodelle für die Kommunikation/Interaktion

Im Verarbeitungsmodell von Mole hat ein Agent grundsätzlich immer die Wahl, entweder zu einem anderen Agenten hinzumigrieren und lokal zu kommunizieren oder nicht zu migrieren und entfernt zu kommunizieren, falls er mit einem Agenten auf einem anderen Platz interagieren will. Diese Entscheidung kann der Agent selbst treffen, falls er alle notwendigen Parameter wie z.B. die aktuelle Übertragungslatenz zu dem anderen Knoten kennt, aber die Berechnung ist aufwendig und verlangt u.U. Code, der komplexer ist, als die eigentliche Verarbeitung.

Daher ist es sinnvoll, dem Agenten die Berechnung dieser Entscheidung als Systemmechanismus anzubieten. Zur Berechnung dieser Enscheidung ist ein Performanzmodell notwendig, das die folgenden Parameter berücksichtigt:

- Netzwerkverzögerung - Übertragungsrate zwischen den zwei Knoten - Dauer des Marshallings von Daten über der Größe der Daten - Größe des Agenten bei der Migration - Größe der Parameter der Interaktion - Größe der Resultate der Interaktion - Selektivität der Verarbeitung, d.h. Größe des Verhältnisses von Resultaten zu Daten, die vom Agenten weiterverarbeitet werden Die letzten drei Parameter lassen sich nicht einfach vom System messen, man kann entweder versuchen, diese statistisch aus der bisherigen Verarbeitung vorherzusagen, oder man überlässt dem Agenten (bzw. dessen Programmierer) die Angabe dieser Werte.

Ein Modell, das diese Parameter berücksichtigt, kann eine Entscheidung entweder nur im Hinblick auf eine Interaktion betrachten, oder sogar über einer Folge von Interaktionen Aussagen treffen, wobei das Problem ist, daß diese Folge nicht unabhängig voneinander sein muß.

Eine Messung des Performanzmodells in Mole unter vereinfachenden Annahmen (eine Interaktion) in einem kleineren Szenario aus drei Rechnerknoten in Deutschland und Schweden ergab, daß ein solcher Systemdienst meist die richtige Entscheidung empfiehlt. Eine Erweiterung des Modells auf mehrere Interaktionen erscheint dagegen zum jetzigen Zeitpunkt zu komplex zu sein. Nähere Informationen zum Performanzmodell lassen sich in [SS97] finden.

6 Sicherheitsaspekte

Der Aspekt der Sicherheit in Mobile-Agenten-Systemen ist nicht nur extrem wichtig für viele der für diese Technik vorgesehenen Einsatzgebiete wie z.B. Electronic Commerce, er ist auch von großem Interesse für die Forschung, weil durch die Mobilität und durch die Tatsache, daß eine Partei eine andere ausführt, neue Aspekte vorliegen. Dieses Kapitel schlägt zuerst eine Strukturierung des Sicherheitsgebietes vor und identifiziert Aufgaben, die in jedem Teilgebiet gelöst werden müssen. Anschließend werden daraus Anforderungen an Komponenten eines zu erstellenden Sicherheits-Rahmenwerks erarbeitet. Schließlich werden zwei verschiedene Sicherheitsmodelle auf ihre Eignung für dieses Rahmenwerk hin untersucht. Weitere Informationen zu diesem Aspekt lassen sich in [Hoh97] finden.

Seite 16: vorherige Seite | nächste Seite | Übersicht

17

6.1 Strukturierung des Gebiets

Der Bereich Sicherheit läßt sich nach zwei Aspekten strukturieren: nach Interaktionsbereichen und nach den funktionalen Komponenten, die benötigt werden. Die Interaktionsbereiche von Agenten, Interpreter und dritten Parteien in einem Mobile-Agenten-System sind:

1. Sicherheit zwischen Agenten 2. Sicherheit zwischen Agent und Interpreter a. Sicherheit von Agenten gegenüber böswilligen Interpretern b. Sicherheit von Interpretern gegenüber böswilligen Agenten 3. Sicherheit zwischen Interpretern 4. Sicherheit zwischen Interpreter und unauthorisierten dritten Parteien

6.1.1 Sicherheit zwischen Agenten

Dieser Bereich umfasst alle Angriffe, die zwischen zwei Agenten in derselben oder einer anderen Kaufzeitumgebung möglich sind. Einige dieser Angriffe lauten:

- (Physische) Manipulation des anderen Agenten - Verschleierung der Identität eines Agenten (Maskierung) - Betrug bei der Inanspruchnahme bzw. dem Anbieten von Diensten - "Denial-of-Service"-Attacken

Der erste Angriff läßt sich durch eine geeignete Wahl der Agentensprache lösen, die eine solche Manipulation z.B. über Zeiger nicht zulassen darf. Das ist z.B. bei allen Systemen der Fall, die Java verwenden, also auch in Mole. Daneben darf es im System auch keine Sicherheitslö- cher geben, die einen solchen Zugriff ermöglichen. Es ist generell unmöglich, die Existenz solcher Löcher bei einer bestimmten Implementierung auszuschließen, und auch bei einigen Java- Versionen sind Zugriffe dieser Art durch das Ausnutzen von Implementierungsfehlern möglich gewesen. Der zweite Angriff verlangt nach einem Authentifizierungskonzept für Agenten, das vom Agentensystem, oder wenn diesem nicht vertraut werden kann, vom anderen Agenten selbst durchgeführt werden muß. Falls der Agent selbst die Identität eines anderen Agenten prüft, muß sichergestellt werden, daß das Agentensystem diesen Agenten nicht so manipulieren kann, daß die Authentifizierung unterlaufen werden kann. Der dritte Angriff verlangt nach einem Dienstinanspruchnahmemodell, das für beide Parteien, Anbieter und Benutzer, sicherstellt, daß für Leistungen Gegenleistungen erbracht werden und daß es Mittel gibt, die Fakten einer Dienstnutzung so aufzuzeichnen, daß sie bei Streitigkeiten nachvollziehbar sind. Solche Dienstemodelle gibt es, siehe z.B. [SL95]. "Denial-of-Service"-Attacken schließlich sind auch

Interpreter

Ag Ag

Interpreter

Ag Ag

Unauthorisierte dritte Parteien

4

3

2
2

1 1

2a 2b

4

Schaubild 4: Interaktionsbereiche

Seite 17: vorherige Seite | nächste Seite | Übersicht

18

in existierenden verteilten Systemen kaum von vornherein auszuschließen geschweige denn einfach zu verhindern. Immerhin benötigt hier die Mobilität der Agenten keine neuen Mechanismen, so daß Gegenmaßnahmen, so sie denn existieren, auch hier angewandt werden können.

6.1.2 Sicherheit zwischen Interpretern

Dieser Bereich umfasst alle Angriffe, die zwischen zwei Interpretern möglich sind. Dazu gehö- ren: Maskierung, "Denial-of-Service"-Attacken u.a. Da Interpreter nicht mobil sind und durch das bisherige Modell verteilter Systeme abgedeckt sind, kommt an dieser Stelle nichts Neues hinzu. Immerhin verlangt die Möglichkeit eines Maskierungsangriffes die Authentifizierung von Interpretern durch einen anderen Interpreter.

6.1.3 Sicherheit zwischen Interpretern und unauthorisierten dritten Parteien

Dieser Bereich umfasst alle Angriffe, die von dritten Parteien gegen Interpreter gerichtet sind (Agenten sind nur über den Umweg Interpreter anzugreifen). Dazu gehört auch hier die Maskierung in dem Sinne, daß sich dritte Parteien für authorisierte Interpretern ausgeben sowie die Möglichkeit, die Kommunikation zwischen zwei Interpretern abzuhören oder zu manipulieren. Wie im letzten Abschnitt wird auch dieser Bereich von den bisherigen verteilten Systemen abgedeckt. Aus der Möglichkeit des Angriffes auf die Kommunikation folgt nicht nur wieder die Notwendigkeit der Authentifizierung von Interpretern, sondern auch die der Verschlüsselung der Kommunikation. Diese Notwendigkeit wiederum impliziert das Vorhandensein einer Schlüsselverteilstruktur im gesamten Agentensystem, so daß Verschlüsselung (und auch Authentifizierung jenseits von ebenso unpraktikablen wie unsicheren Passwortverfahren) überhaupt möglich wird.

6.1.4 Sicherheit von Interpretern vor böswilligen Agenten

Dieser eine Teil des Bereiches der Sicherheit zwischen Interpreter und Agenten umfasst die möglichen Angriffe von Agenten gegenüber dem Interpreter. Diese Angriffe sind u.a.:

- unauthorisiertes Verbrauchen von Ressourcen des Interpreters (CPU, Speicher usw.) - unauthorisierter lesender/schreibender/modifizierender/benutzender Zugriff auf Ressourcen des Interpreters - Verschleierung der Identität eines Agenten (Maskierung) - Mißbrauchen der Identität des Interpreters (Trojanisches Pferd) - usw.

Um diese sehr zahlreichen Arten des Angriffs auszuschließen und um nicht in Gefahr zu laufen, daß Agenten Löcher in Subsystemen des Interpreters ausnutzen (z.B. beim Betriebssystem), kann man als Basis einen Mechanismus verwenden, der auch in anderen Mobile-Code- Systemen verwendet wird, da diese mit denselben Problemen zu kämpfen haben. Dieser Mechanismus nennt sich "Sandbox" und baut auf dem Umstand auf, daß einige Mobile-Code- Systeme sehr restriktiv mit dem sein können, was den mobilen Programmen erlaubt wird. So können Java Applets in vielen Browsern nicht auf das Dateisystem zugreifen, Systemprogramme oder Bibliotheken benutzen und dürfen meist auch nur zu bestimmten Rechnern Netzwerkverbindungen aufbauen. Was sie dürfen, ist rechnen, solange keine externen Ressourcen (Plattenplatz, netzwerk) benötigt werden, und das Öffnen von Fenstern samt dem dazugehöhrenden Benutzungsdialog.

Bei mobilen Agenten hingegen muß dieser Mechanismus zum einen restriktiver, und zum anderen freizügiger sein. Restringiert werden muß der unkontrollierte Zugriff auf interne Res-

Seite 18: vorherige Seite | nächste Seite | Übersicht

19

sourcen (CPU, Speicher), der bei Applets kaum ein Problem darstellt, da diese unter der "Aufsicht" des Benutzers ablaufen. Dagegen müssen viele Agenten Zugriff auf externe Ressourcen bekommen, da ein Agent, der z.B. keine Datenbanken abfragen kann, nur in wenigen Anwendungsfeldern Verwendung finden kann. Daher muß also zum einen ein Abrechnungs- und Kontrollsystem für den quantitativen Verbrauch von Ressourcen durch den Agenten geschaffen werden (wie das z.T. in Telescript der Fall ist, wo Ressourcenverbrauch 'Ticks' kostet), zum anderen muß ein Authorisierungsmechanismus authorisierten Agenten Zugang zu Systemressourcen geben. Für letzteres bieten sich in großen Agentensystemen eher Ausweise (Capabilities) als Zugriffskontrollisten an, da die Zahl der Subjekte, also der Agenten, sehr groß sein kann.

6.1.5 Sicherheit von Agenten gegenüber böswilligen Interpretern

Dies ist der andere Teibereich der Sicherheit zwischen Agent und Interpreter. In ihn fallen alle Angriffe, die ein Interpreter gegen einen Agenten ausführen kann. Dies sind:

- lesen/kopieren von Agentendaten - lesen des Agentencodes - modifizieren von Daten - modifizieren von Code (Viren, Würmer, trojanische Pferde) - ?denial of correct execution? - maskieren von Interpretern

Die Modifikation von Code läßt sich dadurch verhindern, daß der Autor des Codes diesen digital signiert (auch dafür werden kryptographische Schlüssel benötigt). Dies geht solange der Code sich durch die Ausführung nicht ändert (kein selbstmodifizierender Code). Das Signieren von Codeteilen ist z.B. in der Sprache Java als Teil der Standardbibliotheken möglich (da auch dieser Aspekt bei Applets von Bedeutung ist).

Falls Daten oder Code eines Agenten auf einem Interpreter nicht benötigt werden, kann man sie durch Verschlüsselung unlesbar machen, falls sie konstant sind, signieren, um so zumindest die Modifikation zu verhindern, aber alle Teile, die von der Anwendung auf diesem Interpreter verändert werden können, können mit dieser Technik nicht geschützt werden.

Das unauthorisierte Modifizieren von Daten durch den Interpreter läßt sich u.U. nachweisen (siehe [Vig97]), wenn auch andere Angriffe mit diesem Ansatz nicht nachgewiesen oder gar abgewehrt werden können.

Es gibt aber derzeit keine Ansätze, die restlichen Angriffe zu verhindern, außer man benutzt spezielle, "vertrauenswürdige" Hardware, wie im CITADEL-Projekt [Pal94], wo gegen Manipulation geschützte Komponenten eingesetzt werden, die einen Prozessor und zumindest einen geheimen Schlüssel enthalten. Der Ansatz, für mobile Agenten auf den Interpretern spezielle Hardware einzusetzen ist allerdings sehr unattraktiv, umso mehr, als die gesamte Technik noch nicht sehr weit verbreitet ist.

Es gibt einige Ansätze, die Möglichkeit von Angriffen des Interpreters dadurch zu umgehen, daß Agenten nur auf vertrauenswürdige Interpretern migrieren, die per definitionem nicht angreifen werden. Diese Ansätze ([FGS97a],[FGS97b],[Ord96]) haben den Nachteil, daß Vertrauen entweder ein zu grobes Maß ist (weil z.B. einem Lufthansa-Interpreter dann nicht vertraut werden kann, wenn es um das Vergleichen von Flugpreisen geht), oder die Zahl der Interpreter, die benutzt werden können, so gering ist, daß einige der Vorteile mobiler Agenten, wie z.B. der der effizienten Interkation mit einem Server, nicht genutzt werden können. Eine Variante dieses Ansatzes ist es, das Agentensystem nicht-offen bezüglich des Einbringens von

Seite 19: vorherige Seite | nächste Seite | Übersicht

20

Interpretern zu gestalten, sondern den Bentrieb des Agentensystems in die Hände "vertrauenswürdiger" Firmen wie AT&T zu legen. Diese in dieser Hinsicht geschlossenen Systeme benö- tigen allerdings einen immensen initalen Aufwand, um ein erstes Agentensystem zu installieren, und für einige Anwendungen kann das Vertrauen in die Betreiberfirmen wie gezeigt, sehr klein sein.

Obwohl die meisten der oben erwähnten Angriffe also mit existierenden Ansätzen nicht verhindert werden können, ist dieser Teilbereich für viele Anwendungsgebiete emminent wichtig. Falls diese Angriffe nicht verhindert werden können, kann z.B. ein kryptographischer Schlüssel offenbar werden, elektronisches Geld kann kopiert und ausgegeben werden, die Funktion des Agenten kann durch falsches Ausführen des Codes unterlaufen werden usw. Daneben ist es auch für andere Teilbereiche der Sicherheit wichtig, daß der Interpreter den Agenten nicht völlig kontrollieren kann. Wenn z.B. der Interpreter die Daten eines Agenten lesen kann und dessen Code kennt, kann er verhindern, daß die falsche Identität eines anderen Agenten entlarvt werden kann, weil der Interpreter das entscheidende "if" falsch ausführt.

Blackbox Security - ein neuer Lösungsansatz

Im Rahmen des AIDA-Projekts wurde ein neuer Ansatz erarbeitet, der dieses Problem zum großen Teil lösen kann. Er beruht auf der Beobachtung, daß obwohl ein Interpreter jedes Byte des Speichers und jede Zeile des Quellcodes lesen und manipulieren kann, er u.U. Zeit dafür benötigt herauszufinden, was dieses Byte eigentlich enthält und welchen Beitrag die Programmzeile zur Anwendung beisteuert. Damit diese Analyse nicht vor dem Eintreffen eines Agenten vorgenommen werden kann, ist es daher notwendig, daß jeder Agent eine andere Struktur hat, anders "aussieht", auch wenn er dasselbe wie ein anderer Agent leistet. Diese Aufgabe wollen "Verwürfelungsalgorithmen" leisten, die einen Originalagenten, d.h. dessen Code und Daten, in eine neue Form bringen, eben "verwürfeln", wobei die neue Form dasselbe wie die alte leistet. Dieser Schutz, der den Agenten eine Zeitlang wie eine "Blackbox" aussehen läßt, ermöglicht es dem Agenten zwar nicht, für immer unanalysierbar zu sein, erlaubt ihm aber zumindest ein Zeitintervall, in der man davon ausgehen kann, daß der Agent -wenn er ausgeführt wird- nicht durch einen lesend oder manipulierend angegriffen werden kann. Dieses "Schutzintervall" hat zur Folge, daß der Agent ein "Verfallsdatum" trägt, nach dem er weder von anderen Interpretern angenommen wird oder er mit anderen Agenten oder Interpretern interagieren kann.

Da man also davon ausgehen muß, daß ein Agent nach dem Schutzintervall angreifbar ist, müssen auch die Daten, die er mit sich trägt, und die aus sich heraus einen Wert darstellen, dieses Verfallsdatum tragen, nach dessen Ablauf sie nicht mehr verwendet werden können. Ein Beispiel für diese Art von Daten sind elektronische Geldscheine oder geheime Schlüssel, während Daten, die nur für den Agenten von Bedeutung sind, nicht in dieser Art geschützt werden müssen. Der beschriebene Ansatz lässt hoffen, daß das Problem der böswilligen Interpreter im wesentlichen gelöst werden kann. Daher soll er weiter verfeinert werden, eine Implementierung soll die Machbarkeit zeigen und Messungen ermöglichen.

Nähere Informationen zu diesem Ansatz lassen sich in [Hoh97] finden.

6.1.6 Benötigte Komponenten und Anforderungen

Nachdem die Interaktionsbereiche identifiziert wurden, sollen jetzt die Komponenten benannt werden, die ein Rahmenwerk benötigt, das Sicherheit in einem Mobile-Agenten-System gewährleisten soll. Weiter sollen diese Komponenten grob skizziert werden.

Seite 20: vorherige Seite | nächste Seite | Übersicht