5 Absicherung von mobilen Agenten gegen betrügerische Hosts

Die Absicherung eines Agenten vor seinem Host, also der Umgebung, in der er ablaufen soll, ist zu vergleichen mit der Absicherung eines Programms gegen seinen Interpreter. Dieses Problem ist schwierig zu lösen, da der Host freien Zugang zu allen Programm- und Datenbereichen des Agenten und zu seinem Ausführungsstatus hat, und sogar die Ausführung des Agenten beeinflussen kann, da er seinen Programmcode interpretiert. In [ChGH95] heißt es : "It is impossible to prevent agent tampering unless trusted (and tamper-resistant) hardware is available in AMPs¹ . Without such hardware, a malicious AMP can always modify/manipulate the agent." ([ChGH95], S.22). Der einzige Bereich in der Informationstechnik, der ähnliche Probleme bereit hält, ist die Absicherung von Software gegen Manipulationen des Benutzers, z.B. gegen unberechtigtes Kopieren ([Hohl97] S. 3). Die bestehenden Sicherheitsmechanismen sind in diesem Fall nur schwer anzuwenden, da alle Sicherungen so vorzunehmen sind, daß der Agent, oder allgemein die Software, selber an die Daten oder Programmbereiche herankommt. Es kann nicht mit normalen kryptographischen Verfahren gearbeitet werden, da der Agent ansonsten den oder die nötigen Schlüssel mit sich führen müßte, und diese vom Host ausgelesen werden könnten.

Wie schon in den vorangegangenen Kapiteln genannt, gibt es Teilbereiche, die sich auch mit herkömmlichen Verfahren absichern lassen, wie Farmer, Guttman und Swarup von der MITRE-Corporation² in ihrem Artikel [FaGS96b] belegen. So kann die Authentizität und die Integrität eines Agenten über digitale Signaturen erreicht werden. Die Übertragung von Agenten zwischen den einzelnen Servern kann über eine asymmetrische Verschlüsselung geschützt werden (vergl. Kapitel 4.3). Durch diese Verfahren läßt sich der Agent jedoch nicht vor dem ausführenden Host schützen.

5.1 Verschiedene Ansätze

Um die Sicherheit von Agenten gegenüber betrügerischen Hosts zu gewährleisten, sind verschiedene Ansätze entwickelt worden. Generell können diese in zwei Gruppen eingeteilt werden. Eine Gruppe von Ansätzen wirkt vorbeugend, indem die Agenten vor Angriffen geschützt werden. Die zweite Gruppe erkennt lediglich im nachhinein einen Angriff. In den nachfolgenden Kapiteln werden diese einzelnen Ansätze genauer vorgestellt, und ihre Vor- und Nachteile untersucht. Dabei wird davon ausgegangen, daß ein Benutzer generell kein Vertrauen in die einzelnen Server hat, die von seinem Agenten besucht werden sollen.

5.1.1 kein Schutz

Die einfachste Art, auf die Möglichkeit von Angriffen durch betrügerische Hosts zu reagieren, ist die, keine Schutzmechanismen zu benutzen, und das Risiko einfach einzugehen, daß ein Host den Agenten manipuliert. Verschiedene Klassen von Berechnungsergebnissen müssen nicht besonders geschützt werden, da die durch die Absicherung entstehenden Kosten in keinem Verhältnis zum Nutzen der Sicherheit stehen würden. Solche Daten sind Ergebnisse, die einfach nachzuweisen sind, wie z.B. die Existenz eines Flugangebotes unter $200 ([Yee97], S. 2) oder Ergebnisse, die keinen großen Wert besitzen, schon gar nicht für einen Angreifer. Der Vorteil bei solchen ungeschützten Agentensystemen besteht darin, daß kein zusätzlicher Aufwand für die Berechnung von Prüfsummen, die Erstellung von Schlüsseln oder das Senden von Protokollen benötigt wird. Für den privaten Benutzer, der überwiegend kleine und unkritische Geschäfte tätigt, wird ein ungeschützter Agent die effizientere Alternative sein.

5.1.2 Gesetze / Verträge

Ein ebenfalls sehr einfacher Ansatz zum Schutz vor betrügerischen Hosts besteht darin, daß die Betreiber der Hosts per Gesetz oder durch entsprechende Verträge versichern, ihre Server vor externen Angreifern zu schützen, und Vertraulichkeit und Integrität der Agenten nicht zu verletzen. Ein solcher Ansatz ist in General Magic’s Telescript-Technologie vorgesehen [TaVa96]. Ein Vorteil dieses Verfahrens ist, daß keine kryptographischen Protokolle benötigt werden und kein Laufzeit-Overhead entsteht. Außerdem umfaßt es alle drei in Kapitel 4.3 genannten Bereiche. Ohne ein zusätzliches erkennendes Verfahren kann eine Verletzung des Vertrages oder des Gesetzes allerdings nicht nachgewiesen werden. Es müßten Manipulationsnachweise aufgezeichnet werden, die vom Betreiber nicht abstreitbar sind. Diese könnten dann bei einem eventuell nötigen Rechtsverfahren als Beweise benutzt werden. Wird ein vertraglicher Schutz festgelegt, so entspricht das theoretisch einer Beschränkung der Marktteilnehmer, zumindest auf Anbieterseite. Dies wäre eine weitere Verletzung der gewünschten Marktoffenheit, die in Kapitel 2.4.1 beschrieben wurde. Im Grunde genommen ändert die Verwendung von Gesetzen oder Verträgen also die gegenwärtige Situation ohne einen Schutz nicht. Es werden lediglich die Folgen für die Betreiber der betrügerischen Server festgelegt, die eintreten wenn deren Angriffe erkannt werden.

5.1.3 Trust

Farmer, Guttman und Swarup, von der MITRE Corporation, stellen in ihrer Arbeit [FaGS96] einen Ansatz vor, der darauf beruht, den kritischen Prozeß der Berechnung der Ergebnisse auf einen Server auszulagern, der das volle Vertrauen des Benutzers besitzt. Es müssen damit nur noch die Daten, die der Agent auf den unbekannten Servern sammelt und mit sich führt, gegen Angriffe abgesichert werden. Das Berechnungsprogramm selbst kann entweder direkt zum Berechnungsserver geschickt werden und dort auf die Ankunft des Agenten warten, oder relativ einfach mit dem öffentlichen Schlüssel des Berechnungsservers verschlüsselt und dem Agenten angehängt werden. Für die Sicherung der gesammelten Daten sehen die Autoren vor, daß deren Integrität vor der Ausführung der Berechnung auf dem vertrauenswürdigen Server geprüft wird. Wie diese Prüfung aussehen soll, wird nicht näher erläutert.

Anstelle eines vertrauenswürdigen Servers, der nur zur Berechnung der Ergebnisse besucht wird, kann theoretisch auch ein vertrauenswürdiger Marktplatz vorausgesetzt werden, auf dem sich Agenten der Anbieter und der Nachfrager treffen und verhandeln. Der Schutz des Programmcodes und des Kontrollflusses wäre dadurch, genau wie beim vorherigen Ansatz, gewährleistet, während der Schutz der Vertraulichkeit und der Integrität der Daten in den Bereich der Absicherung zwischen zwei Agenten fallen würde (Kapitel 4.2.1) und somit einfacher zu realisieren wäre. Ein solches Verfahren ist allerdings nur dann sinnvoll, wenn die Agenten des Anbieters sämtliche benötigten Informationen mit sich führen, da ansonsten eine hoher Verbindungsaufwand zum Server des Anbieters entsteht. Diese Informationen werden in der Regeln zu umfangreich sein, als daß ein Agent sie effizient speichern könnte. Somit wird diese Alternative in der Praxis keinen Einsatz finden.

Das Trust Verfahren fordert von den einzelnen Marktservern keinen zusätzlichen Aufwand. Für die Anwendung wird allerdings vorausgesetzt, daß es einen zusätzlichen Server für die Berechnungen gibt, der das nötige Vertrauen des Benutzers besitzt. Eventuell ist ein solcher Server jedoch nicht gegeben, z.B. bei hochsensitiven Daten. Außerdem müssen unter Umständen große Datenmengen an diesen Server übertragen werden, obwohl das eigentliche Ergebnis sehr kompakt ist (z.B. bei der Filterung von Daten). Der Vorteil der Berechnung "vor Ort" ist durch dieses Verfahren also nicht mehr vorhanden.

Nimmt man an, es gibt einen solchen vertrauenswürdigen Server, so ist zumindest der kritische Teil des Programmcodes und des Kontrollflusses des Agenten vollständig gesichert. Die Daten, die auf den Servern gesammelt werden, sind jedoch ohne weiteres nicht vor Angriffen geschützt. Jeder der später aufgesuchten Server kann die Daten lesen und auch verändern. Dadurch, daß die Verarbeitung der Daten sowieso auf den zusätzlichen Server ausgelagert wird, können die Daten, genau wie der Programmcode, verschlüsselt und vom Marktserver signiert an den Agenten angehängt werden. So wäre auch deren Vertraulichkeit und Integrität gesichert.

Ein großer Vorteil dieses Verfahrens besteht darin, daß Daten wie private Schlüssel und elektronisches Geld für die kritischen Prozesse benutzt werden können. Werden diese mit dem öffentlichen Schlüssel des vertrauenswürdigen Servers verschlüsselt, können sie ohne Gefahr an den Agenten angehängt werden. Auch hier stellt sich jedoch wieder die Frage, ob der Benutzer diesem Server soweit vertraut, daß er ihm seinen privaten Schlüssel übergibt.

5.1.4 Reputation

Rasmusson und Jansson, vom Schwedischen Institute of Computer Science, stellen in ihrer Arbeit [RaJa96] einen Ansatz vor, der darauf basiert, daß Teilnehmer auf einem Markt aufgrund ihres bisherigen Verhaltens einen bestimmten Ruf (Reputation) besitzen. Obwohl die Arbeit sich speziell mit Agenten und deren Reputation befaßt, kann der Ansatz problemlos auf Marktserver übertragen werden.

Die Autoren nennen als Basis ihres Ansatzes social control, einen im Gegensatz zu herkömmlichen Sicherheitsansätzen eher "sanften" (soften) Ansatz. Sie definieren social control als Verhalten einer Gruppe, welches die einzelnen Gruppenmitglieder indirekt dazu zwingt, sich in einer speziellen Art zu verhalten ([RaJa96], S. 5). Als Beispiel aus dem täglichen Leben nennen sie die Einwohner eines kleinen Dorfes, in dem jeder jeden kennt und sich in einer bestimmten - "normalen" - Weise verhält, um nicht aufzufallen. Als Gegensatz dazu wird eine Großstadt genannt, in der alle Einwohner weitgehend anonym handeln können, und somit eher bereit sind, gesetzeswidrig und betrügerisch zu handeln. Das Internet gleicht, aufgrund seiner Offenheit und Anonymität, eher einer Großstadt als einem kleinen Dorf. Läßt man diese Offenheit und Anonymität auf elektronischen Märkten zu, was durchaus gewünscht ist (siehe Kapitel 2.4.1), so bedarf es, nach Rasmusson und Jansson, einer Reihe von Mechanismen, um potentielle Handelspartner auszuwählen, die keine betrügerischen Absichten haben. Solche Mechanismen sind im realen Geschäftsleben Eigenschaften wie Reputation, Stabilität über eine gewisse Zeit und das geschätzte Risiko eines Betruges.

Übertragen auf das Problem betrügerischer Server bedeutet das, daß jeder Server im Laufe seiner Einsatzzeit im Internet eine bestimmte Reputation erlangt. Agenten, welche diesen Server besucht haben und von ihm korrekt ausgeführt wurden, werden ihn an andere Agenten weiterempfehlen, während ein betrügerischer Server fortan gemieden wird. Nach Ansicht der Autoren wird ein solches "tratschen" der Agenten untereinander relativ schnell dafür sorgen, daß ein betrügerischer Server von keinem Agenten mehr aufgesucht wird. Außerdem schlagen sie spezielle reputation agents vor, die, ähnlich wie Restaurantkritiker, die einzelnen Server inkognito besuchen, und Geschäfte auf ihnen durchführen, um so herauszufinden, ob diese betrügerisch handeln oder nicht. Die gesammelten Erfahrungen werden später anderen Agenten gegen eine Gebühr zu Verfügung gestellt.

Rasmusson und Jansson werfen selber einige Fragen zu ihrem Ansatz auf, die sie jedoch nicht konkret beantworten ([RaJa96], S. 7). So ist noch nicht geklärt, wie neue, reputationslose Server in das System eingeführt werden können. Da bei diesen keine Sicherheit gegeben ist, werden sie von keinem Agenten besucht werden. Ebenfalls noch offen ist die Frage, was passiert, wenn ein Server fälschlicherweise einen schlechten Ruf bekommt, und an weiteren Geschäften gehindert wird. Das Verfahren erschwert somit die Situation der einzelnen Server erheblich.

Auf der anderen Seite können betrügerische Server ebenfalls einen falschen Ruf bekommen. Theoretisch kann ein Server über eine gewisse Zeit einen guten Ruf aufbauen, um diesen dann später zum Betrug einzusetzen.

Neben diesen Problemen hat der Reputation-Ansatz noch einen weiteren Nachteil. Es gibt eine gewisse Reaktionszeit, bis ein betrügerischer Server als solcher erkannt wird. In dieser Zeit ist wenigstens ein Agent Opfer dieses Servers geworden. Es ist also keine vollständige Sicherheit gegeben, was das Verfahren für hochsensitive Daten und Programme unbrauchbar macht.

Vorteil des Verfahrens ist, daß kein zusätzlicher Aufwand von den einzelnen Servern gefordert wird. Außerdem werden als Folge eines korrekt funktionierenden Systems betrügerische Server direkt eliminiert.

5.1.5 Detection Objects

Am Naval Research Laboratory der US Navy wird ein Verfahren vorgeschlagen, welches auf der Basis von Detection Objects die Möglichkeit bietet, betrügerische Modifikationen der Daten des Agenten zu erkennen. Diese Detection Objects sind Dummy Daten oder Attribute, die bei einer ordnungsmäßigen Verarbeitung des Agenten nicht benutzt bzw. verändert werden. Sie werden so gewählt, daß weder ein ausführender Host, noch der Agent selber weiß, welche der mitgeführten Daten die Detection Objects sind. Nach Catherine Meadows, die diesen Ansatz in ihrer Arbeit vorstellt [Mead97], kann der Benutzer, wenn er diese Daten bei der Rückkehr des Agenten unverändert vorfindet, "relativ sicher" sein, daß der Agent ordnungsgemäß ausgeführt wurde.

Meadows nennt eine Reihe von Problemen, die gelöst werden müssen, bevor der Ansatz erfolgreich genutzt werden kann ([Mead97], S. 2) :

• Die Technik ist sehr applikationsspezifisch. Detection Objects, die für ein Anwendungsgebiet benutzt werden können, sind für ein anderes Anwendungsgebiet unbrauchbar.
• Die fiktiven Daten müssen plausibel genug sein, um einen potentiellen Angreifer zu täuschen, dürfen jedoch das Ergebnis nicht beeinflussen.
• Die Aufgabe muß so gestellt sein, daß das Detection Object im Ergebnis enthalten ist.
• Das Detection Object muß bei mehreren Anfragen oft erneuert werden, damit es nicht über Ergebnisvergleiche identifiziert werden kann.

Detection Objects sind als Sicherungstechnik also nicht generell einsetzbar. Meadows geht jedoch davon aus, daß eine große Zahl von Anfragen in die nötige Form gebracht werden kann, um diese Technik zu nutzen. Für solche speziellen Anwendungen sind Detection Objects sehr einfach zu nutzen.

Die Vertraulichkeit und die Integrität des Programmcodes sind durch diese Technik in keiner Weise geschützt. Allerdings ist fraglich, ob ein Angriff auf den Programmcode, sei es durch Manipulation oder nur durch Auslesen, in den speziellen Fällen, in denen Detection Objects angewendet werden können, für einen Angreifer von Bedeutung sind. Im Grunde genommen sind nur Sammelanfragen möglich, die alle Angebote sammeln, welche bestimmte Kriterien erfüllen. Eines dieser Angebote wird das Detection Object sein. Eine temporäre Programmanipulation würde dem Angreifer in diesem Fall keinen Nutzen bringen, da die Ergebnisse eindeutige Eigenschaften erfüllen müssen. Eine dauerhafte Veränderung würde dem nächsten Server auffallen, wenn man davon ausgeht, daß der Agent vom Benutzer signiert wurde (vergl. Kapitel 4.3.4).

Die Vertraulichkeit der gesammelten Daten ist durch Detection Objects ebenfalls nicht geschützt. Eine Verletzung der Integrität wird erst nach der Rückkehr des Agenten erkannt, und kennzeichnet somit das Ergebnis als unbrauchbar. Diese Integritätsprüfung ist jedoch auch nur "relativ" sicher, d.h. bei einer Anfrage, die zwar nicht besonders vertraulich behandelt werden muß, deren Ergebnis für den Benutzer allerdings von großer Bedeutung ist, wird man dieses Verfahren nicht anwenden.

5.1.6 Tracing

Giovanni Vigna vom Politecnico di Milano stellt in seiner Arbeit [Vign96] ein Protokoll vor, bei dem durch Statusmeldungen und Ausführungsprotokolle eines Agenten jede unrechtmäßige Manipulation identifiziert und einem bestimmten Server zugeordnet werden kann.

Voraussetzung für den Ansatz ist, daß jede involvierte Partei, also Besitzer eines Agenten und Betreiber eines Servers, ein asymmetrisches Schlüsselpaar besitzen, welches zur Verschlüsselung und zur Erstellung von digitalen Signaturen eingesetzt werden kann. Zur einfacheren Notation sei A_p der Public Key und A_s der Secret Key einer Partei A. Über eine geeignete Public Key Infrastruktur kann jede Partei jederzeit den öffentlichen Schlüssel einer anderen Partei bekommen und dessen Integrität überprüfen.

Ein mobiler Agent besteht nach Vigna aus einem Codeteil C und einem Status Sⁱ, welcher zu einem bestimmten Zeitpunkt i der Ausführung des Agenten ermittelt wurde. Es wird angenommen, daß der Status aus globalen Datenstrukturen, einem Call Stack und dem Programmzähler besteht. Der Code sei über die gesamte Lebensdauer des Agenten statisch und bestehe aus einer Folge von Anweisungen (Statements). Dabei sind white statements Operationen, die den Status nur auf Basis von programminternen Variablen verändern (z.B.: x := y + z, wobei x, y und z Programmvariablen sind). Black statements sind dagegen Operationen, die Informationen der externen Ausführungsumgebung benutzen, um den Status zu ändern (z.B. read(x), weist der Variablen x einen Wert zu, der aus einem Terminalfenster gelesen wird).

Eine execution trace (engl. Spur) T_C einer Ausführung des Programms C setzt sich nach Vigna aus einer Reihe von Paaren <n, s> zusammen, wobei n ein eindeutiger Identifikator eines Statements, und s eine digitale Signatur ist. Im Falle eines black statements enthält die Signatur die neuen Werte, welche die internen Variablen durch das Statement angenommen haben. Liest zum Beispiel die Operation read(x) den Wert 3 ein, so enthält die zugehörige Signatur den Ausdruck x := 3. Bei white statements ist die Signatur leer.

Bei der Darstellung seines Ansatzes betrachtet Vigna drei unterschiedliche Arten von Agenten : One-Hop Agents³ oder Remote Code Execution, Two-Hop⁴ oder Boomerang Agents und Multi-Hop Agents⁵. An dieser Stelle sollen nur die Multi-Hop Agents betrachtet werden, da die One-Hop und Two-Hop Agents lediglich vereinfachte Spezialfälle eines Multi-Hop Agents sind, und sich alle anderen vorgestellten Ansätze ebenfalls auf diese Form von Agenten beziehen.

Als Beispiel wird angenommen, daß ein Benutzer A einen Agenten (mit Programmcode C) zu verschiedenen Servern B¹ bis Bⁿ senden will. In einem ersten Schritt sendet A dazu eine Nachricht m_1.0 an den ersten Server B¹, wie in Abbildung 5.1 Teil a dargestellt. Diese Nachricht sieht wie folgt aus :

Abb. 5.1a : 1. Schritt des Tracing-Protokolls

Der erste Teil der Nachricht ist der Name des Absenders A. Der zweite Teil ist der mit dem öffentlichen Schlüssel von B¹ verschlüsselte Agent, bestehend aus dem Programmcode C und dem Anfangsstatus S⁰. Der letzte Teil ist ein von A mit seinem privaten Schlüssel signiertes Dokument, welches die Hash-werte des Programmcodes C und des Anfangsstatus S⁰, den Namen des Empfängers B¹, den Namen einer dritten Partei Y, einen Zeitstempel t_A und einen eindeutigen Identifikator i_A enthält.

Dadurch, daß Programmcode und Anfangsstatus mit dem öffentlichen Schlüssel des Empfängers B¹ verschlüsselt wurden, ist gesichert, daß nur B¹ diese entschlüsseln kann. B¹ benutzt den Namen des Senders A aus dem ersten Teil der Nachricht, um über die vorhandene Public Key Infrastruktur den zugehörigen öffentlichen Schlüssel zu erhalten. Mit diesem kann B¹ den dritten signierten Teil der Nachricht entschlüsseln. Er berechnet selbst den Hashwert H(C) des Programmcodes C, und vergleicht diesen mit dem von A mitgesendeten Hashwert. Wenn die beiden Werte übereinstimmen, weiß B¹, daß die Nachricht wirklich von A stammt, und daß der Code bei der Übertragung nicht verändert wurde. Denselben Vorgang kann B¹ mit dem Anfangsstatus S⁰ wiederholen. Aus dem Wert B¹ im dritten Teil der Nachricht weiß B¹, daß die Nachricht für ihn bestimmt war, was im Grunde genommen schon daraus ersichtlich ist, daß die Nachricht mit seinem öffentlichen Schlüssel verschlüsselt und an ihn gesendet wurde. Eine dritte Person Y ist ein von A ausgewählter Empfänger jedes receipt tokens, welches als Empfangs- oder Sendebestätigung vom Server erzeugt wird. Diese dritte Person kann von Nutzen sein, wenn A nach dem Senden der Nachricht m_1.0 seine Verbindung zum Internet abbrechen möchte, oder wenn er eine Trusted Third Party (z.B. einen digitalen Notar) benötigt. Es ist ebenfalls möglich, daß A sich selbst als Empfänger auswählt (Y = A). Der Identifikator i_A schützt den Server vor Replay Attacken, bei denen immer wieder derselbe Agent an den Server gesendet wird, um diesen z.B. zu überlasten (Denial of Service). Der Server kann durch den Identifikator einen doppelt gesendeten Agenten erkennen, und die Ausführung des Duplikates verweigern.

Nachdem B¹ die Nachricht m_1.0 erhalten und verifiziert hat, sendet er eine Nachricht m_1.1 an Y, die wie folgt aufgebaut ist :

Darin ist im ersten Teil der Name des Servers B¹ enthalten. Im zweiten Teil folgt eine von B¹ signierte Nachricht, die aus dem Namen des Benutzers A und dem, von A signierten, letzten Teil der Nachricht m_1.0 besteht.

Dadurch kann Y überprüfen, daß B¹ einen Agenten von A zum Zeitpunkt t_A bekommen hat, und daß Y von A als dritte Person für den Erhalt der receipt tokens ausgewählt wurde. A kann seinerseits nun jederzeit nachweisen, daß B¹ von ihm einen Agenten C mit Anfangsstatus S⁰ erhalten hat, indem er Y zeigt, daß seine Hashwerte H(C) und H(S⁰) Werte ergeben, die mit den Werten in m_1.1 übereinstimmen.

Nach diesem einleitenden Handshake führt B¹ den Agenten aus, bis dieser zu einem anderen Server B² wandern möchte. B¹ hält den Agenten an, und sendet eine signierte Nachricht m_1.2 an Y (Abbildung 5.1, Teil b) :

Abb. 5.1b : 2. Schritt des Tracing-Protokolls

Dabei steht im ersten Teil der Name des Servers B¹, und im zweiten Teil eine von B¹ signierte Nachricht, die neben dem Namen des nächsten Servers B² einen Hashwert des Endstatus S¹, einen Hashwert der execution trace T¹_C, und den Identifikator i_A enthält.

Danach sendet B¹ eine Nachricht m_2.0 an B² :

Diese enthält den Namen des Senders B¹, den Namen des Benutzers A und den mit dem öffentlichen Schlüssel von B² verschlüsselten Agenten. Dieser besteht diesmal aus dem Programmcode C und dem auf B¹ erreichten Endstatus S¹. Außerdem enthält m_2.0 eine signierte Nachricht, die wiederum den Hashwert des Ausführungsstatus S¹ und den Namen des Empfängers B², sowie eine Kopie des dritten Nachrichtenteils von m_1.0 enthält.

B² entschlüsselt nach Erhalt der Nachricht den dritten Teil mit seinem privaten Schlüssel, und erhält somit den Agenten, dessen Ausführung auf B² fortgesetzt werden soll. Anschließend holt sich B² die öffentlichen Schlüssel von A und B¹, und entschlüsselt damit die beiden letzten Teile der Nachricht. Aus dem Inhalt des von B¹ signierten vierten Teils der Nachricht erfährt B², daß er der rechtmäßige Empfänger der Nachricht ist, daß die Nachricht tatsächlich von B¹ gesendet wurde und daß der Status S¹ aus dem dritten Nachrichtenteil unverändert ist. Aus dem Inhalt des von A signierten, letzten Nachrichtenteils weiß B², daß der Programmcode aus dem dritten Nachrichtenteil korrekt ist und daß der Agent ursprünglich von A gesendet wurde. Außerdem erfährt B², daß A Y als Empfänger der receipt tokens ausgewählt hat.

Anschließend sendet B² eine Nachricht m_2.1 an Y, die eine signierte Empfangsbestätigung der letzten beiden Teile von m_2.0 enthält :

Dadurch weiß Y, daß B² den Programmcode C und den Status S¹ korrekt erhalten hat.

Dieser zweite Schritt des Protokolls wird für jeden Server Bⁱ wiederholt, bis der letzte Server Bⁿ erreicht wird.

Nachdem der Agent seine Ausführung auf Bⁿ beendet hat, wird er angehalten, und Bⁿ sendet eine Nachricht m_n.2 an Y (Abbildung 5.1 Teil c) :

Abb. 5.1c : 3. Schritt des Tracing-Protokolls

Diese enthält einen Hashwert des endgültigen Status Sⁿ , einen Hashwert der execution trace Tⁿ_C und den Identifikator i_A. Anschließend sendet Bⁿ in einer Nachricht m_n.3 den mit dem Public Key von A verschlüsselten, endgültigen Status des Agenten, zusammen mit dem Identifikator, signiert an A zurück :

Abb. 5.1d : Überprüfung der Ausführung

Wenn A den Verdacht hat, daß einer oder mehrere der besuchten Server betrogen haben, kann er Y bitten, ihm alle erhaltenen receipt token zu senden (siehe Abbildung 5.1 Teil d). Zusätzlich läßt er sich von jedem Server die entsprechenden execution traces senden. A ist nun in der Lage, die Ausführung des Agenten beginnend bei S⁰ zu simulieren, indem er die einzelnen Schritte der execution traces nacheinander ausführt. Die Korrektheit der execution traces kann A anhand der entsprechenden Hashwerte aus den receipt tokens überprüfen. Bei jedem Schritt i sollte der zugehörige Status Sⁱ einen Hashwert ergeben, der mit dem entsprechenden Hashwert aus dem receipt token übereinstimmt. Ist dies nicht der Fall, hat der Server, auf dem der Schritt i ausgeführt wurde, betrogen.

Vigna nennt selbst einige Nachteile, die der Tracing Ansatz hat ([Vign96], S. 11).

Zum einen können die execution traces unter Umständen sehr groß werden, selbst wenn man sie komprimiert. Als Lösungsmöglichkeit schlägt Vigna vor, anstelle von kompletten execution traces, neben den Black Statements, nur die Stellen zu protokollieren, an denen sich der Kontrollfluß des Programms ändert (also Schleifen oder Conditional Statements). Eine andere Lösung besteht darin, daß der Programmierer nur einen bestimmten Bereich von Statements definiert, die protokolliert werden sollen. Zum Beispiel könnte er vorsehen, daß die Werte von bestimmten kritischen Variablen eine Reihe von Bedingungen erfüllen müssen, bevor ein bestimmte Gruppe von Statements protokolliert wird. Nach demselben Prinzip könnte der Programmierer eine Reihe von Statements definieren, die nicht protokolliert werden müssen, und von denen nur der endgültige Wert in eine execution trace aufgenommen wird. Das ist besonders sinnvoll bei der Filterung von Daten, bei der mehrere Datensätze durchlaufen werden und nur ein Teil der Statusänderungen später von Bedeutung ist.

Der zweite Nachteil besteht in der Annahme, daß Agenten keinen gemeinsamen Speicher benutzen und in einzelnen Prozessen ablaufen. Ist diese Voraussetzung nicht gegeben, reicht die alleinige Überwachung der Ausführung eines Agenten nicht aus, sondern es werden vom Benutzer die execution traces aller Agenten zur Überprüfung benötigt, die einen gemeinsamen Speicherbereich genutzt haben. Zusätzlich sollte die zeitliche Abfolge der einzelnen ausgeführten Statements in den execution traces festgehalten werden. Diese zusätzlichen Anforderungen erhöhen den Umfang des Protokolls um ein Vielfaches, so daß es nicht mehr effizient durchzuführen ist.

Eine günstigere Möglichkeit des Tracing Ansatzes, die allerdings im Moment noch in der Entwicklung ist, nennt Yee in seiner Arbeit [Yee97]. Er schlägt die Verwendung von holographic proof checking techniques vor. Im Prinzip könnte dieses sehr theoretische Verfahren zur Lösung des Problems beitragen, die damit verbundenen Kosten sind allerdings noch zu hoch.

Die Idee dieser Technik ist, daß der Server eine execution trace T_Cmit Hilfe der holographic proof function in T'_C verwandelt. Zur Überprüfung eines korrekten Ausführungsverlaufs genügen schon wenige Bits des proof strings T'_C. Trotzdem muß der Server den kompletten String T'_C übertragen, da das Verfahren darauf basiert, daß der überprüfende Benutzer einige zufällige Bits aus dem proof string herausnimmt und verifiziert. Durch das Verfahren wird also keine Bandweite eingespart, es wird lediglich der Prozeß der Überprüfung beschleunigt.

Als bessere Lösung schlägt Yee die Benutzung von computationally sound proofs vor. Die Konstruktion des proof string T'_C geschieht wie bei der holographic proof Methode. Danach wird der String jedoch durch ein Baum-Hashverfahren in einen Hashwert verwandelt. An den Benutzer wird nur die Wurzel des Baumes gesendet, so daß die benötigte Bandweite stark reduziert wird.

Ein großer Vorteil solcher Tracing Verfahren besteht darin, daß durch diese alle Integritätsverletzungen und auch Verletzungen der Verfügbarkeit erkannt, und was noch wichtiger ist, auch einem bestimmten Server zugeordnet werden können. Dadurch unterscheidet sich dieser Ansatz von allen anderen bisher vorgestellten Verfahren. Außerdem ist durch die Verwendung einer Trusted Third Party direkt die Möglichkeit von Kommunikationsnachweisen gegeben, die später für Rechtsfragen herangezogen werden können.

Die Vertraulichkeit der einzelnen Komponenten eines Agenten wird durch Tracing Ansätze nicht geschützt. Außerdem ergibt sich eine große Anzahl von Nachrichten, die ein Server zusammenstellen und senden muß. Daneben benötigen die für eine bestimmte Zeit gespeicherten Execution Traces unter Umständen viel Platz. Die einzelnen Server haben also einen hohen zusätzlichen Aufwand zu bewältigen.

5.1.7 Fault Tolerance

Bennet S. Yee stellt in seinem Artikel [Yee97] einen Ansatz zur Fehlertoleranz von Agentensystemen vor, der an der Cornell University entwickelt wurde [MRSS96]. Diesen Ansatz benutzt Yee, um daraus ein relativ einfaches Sicherungsprotokoll gegen betrügerische Hosts abzuleiten, welches unter bestimmten Voraussetzungen einen Schutz gegen Angreifer gewährleistet.

Yee geht davon aus, daß zwischen den einzelnen Marktservern sichere Kommunikationskanäle existieren, und daß die Benutzer zertifizierte öffentliche Schlüssel besitzen.

Unter diesen Voraussetzungen können "ehrliche" Server feststellen, ob der Code oder der Read-Only Status des Agenten modifiziert wurde, indem der Besitzer des Agenten den Code und den Read-Only Status mit seinem Secret Key signiert, und diese Signatur an den Agenten anhängt (vergl. Kapitel 4.3.4). Abbildung 5.2 zeigt graphisch den resultierenden Aufbau eines in dieser Weise erzeugten Agenten. O_S( ) ist dabei die Signierfunktion des Originators, also des Besitzers bzw. des Erzeugers des Agenten. Die einzelnen Server können dadurch die Herkunft und die Integrität des Agenten überprüfen.

Abb. 5.2 : Aufbau eines Agenten

Als zusätzliche Voraussetzung nimmt Yee an, daß der Originator die Reihenfolge, in welcher die einzelnen Server durchlaufen werden, festlegen kann, bevor er einen Agenten sendet.

Auf jedem "ehrlichen" Server wird der Programmcode und der Read-Only Status des Agenten bei seiner Ankunft überprüft. Ein betrügerischer Server, welcher den Code oder den Read-Only Status eines Agenten manipuliert, kann diesen somit nicht mehr erfolgreich an einen "ehrlichen" Server senden. Der variable Status des Agenten wird über eine authentische und sichere Verbindung zwischen zwei Servern übertragen, so daß nur der beabsichtigte Zielserver den Agenten empfangen kann, falls dieser von einem "ehrlichen" Server gesendet wird. Ein betrügerischer Server kann einen so gesendeten Agenten nicht abfangen.

Auf jedem besuchten Server kann der Agent dessen Identität abfragen. Die Authentizität kann z.B. über eine Kette von Public Key Zertifikaten erreicht werden, deren Wurzelzertifikat im Read-Only Status des Agenten enthalten ist. Die Benutzung solcher kryptographischen Verfahren zur Authentifizierung ist im Falle von Agenten jedoch nicht sicher, da der Server den Kontrollfluß des Agenten verändern kann, indem er z.B. einfach den Befehlszähler weitersetzt, bis der Programmablauf die Identitätsabfrage passiert hat.

Yee konfiguriert für seinen Ansatz nun zwei Softwareagenten A¹ und A² so, daß sie entlang einer Reihe B von Servern B¹ bis Bⁿ wandern. Dabei durchläuft A¹ die Reihe B vom ersten bis zum letzten, und A² vom letzten bis zum ersten Server. Abbildung 5.3 zeigt die Migrationsgraphen der beiden Agenten. Yee geht davon aus, daß zumindest ein betrügerischer Server existiert (der Fall daß alle Server "ehrlich" sind ist trivial). Im folgenden betrachtet er jedoch immer nur genau einen solchen Server. Dafür kann ohne eine Verletzung der Allgemeinheit gesagt werden, daß Server Bⁱ betrügerisch ist, und daß Server B^j der Server mit dem billigsten Angebot ist.

Abb. 5.3 : Migrationsgraph der beiden Agenten A¹ und A²

Yee setzt voraus, daß der betrügerische Server Bⁱ keinen Denial of Service Angriff durchführt.

Nach dem vorgegebenen Migrationsplan erreicht A² den Server mit dem billigsten Angebot B^j zuerst. Wenn er bei Bⁱ ankommt, kann dieser den Speicherbereich, in dem dieses Angebot steht, verändern. Wenn A² mit dem Ergebnis beim Originator ankommt, meldet er entweder Bⁱ als billigsten Server, oder einen von den Servern B¹ bis Bⁱ-1, wenn dieser einen noch niedrigeren Preis genannt hat. A¹ erreicht dagegen zuerst den betrügerischen Server Bⁱ und erst danach B^j. Er wird also den korrekten minimalen Preis als Ergebnis präsentieren und der Benutzer ist somit in der Lage, aus den beiden Ergebnissen von A¹ und A², den richtigen minimalen Preis zu erkennen.

Im Falle, daß der betrügerische Server gleichzeitig der Server ist, der das günstigste Angebot hat, kann er seinen Preis minimal unter dem bisher besten Preis ansetzen, und gewinnt so die Differenz zu seinem tatsächlichen Preis. Dieser Angriff kann durch den Fault Tolerance Ansatz nicht erkannt werden. Eine von Yee genannte Lösung für dieses Problem sind signierte, und für den Benutzer verschlüsselte Nachrichten. Bei diesen signiert der Server eine Aussage der Form "Dies ist das beste Angebot, welches der Agent A auf diesem Server B zum Zeitpunkt t gefunden hat." und hängt sie an den Agenten an. Dadurch wird der Agent jedoch mit jedem Server größer. Das Verfahren ist also bei vielen Marktservern nicht effizient genug.

Der Ansatz nach Yee bietet eine Möglichkeit, Agenten vor betrügerischen Servern zu schützen, wenn man annimmt, daß es höchstens einen betrügerischen Server gibt, der keinen Denial of Service Angriff durchführt. Selbst in diesem Fall kann man den Agenten jedoch nicht vor dem Auslesen seiner bisherigen Ergebnisse, und somit vor einem dementsprechenden Anpassen des niedrigsten Preises schützen. Außerdem ist die Annahme der festen Reihenfolge nicht immer gewünscht. Es könnte zum Beispiel sein, daß ein Agent sich die zu besuchenden Server erst von einem oder mehreren Informationsagenten oder entsprechenden Informationsservern besorgt. Fällt einer der beiden Agenten aus, so kann man keine Aussage über die Korrektheit des übriggebliebenen Ergebnisses treffen.

Geht man davon aus, daß es nicht nur einen betrügerischen Agenten gibt, was bei der Größe des Internet sehr wahrscheinlich erscheint, so funktioniert dieser Ansatz nicht. Liegt das günstigste Angebot zwischen zwei betrügerischen Hosts, so kommen beide Agenten, nachdem sie das richtige Angebot erhalten haben, jeweils noch an einem betrügerischen Server vorbei, welcher die Daten manipulieren kann.

5.1.8 Code Mess Up

Hohl argumentiert in dem von ihm vorgestellten Ansatz [Hohl97], der am Institut für Parallele- und Verteilte Höchstleistungsrechner (IPVR) der Universität Stuttgart entwickelt wurde, daß ein Angreifer eine gewisse Zeit braucht, um die Daten und den Programmcode zu lesen und zu verstehen, bevor er eine gezielte Manipulation des Agenten vornehmen kann. Der Code Mess Up Ansatz versucht, diese Zeitspanne zu maximieren, indem der Programmcode so umgewandelt wird, daß er für einen Angreifer extrem schwer zu analysieren ist. Zusätzlich werden sicherheitssensitive Daten mit einem Ablaufdatum (expiration date) versehen, so daß sie nach dieser Zeitspanne nicht mehr gebraucht werden können.

Für die Anwendung dieses Verfahrens sind folgende Voraussetzungen nötig ([Hohl97], S. 8) :

• Es läßt sich eine minimale Zeit finden, die ein Angreifer braucht, um den neuen Programmcode und die Daten zu analysieren
• Das expiration date der sicherheitssensitiven Datenelemente wird auf diese Zeitdauer gesetzt
• Der Agent kann innerhalb dieser Zeitspanne einen Großteil seiner Arbeit erledigen
• Es kann periodisch neuer Code erzeugt werden, der die folgenden drei Eigenschaften erfüllt :
• Er kann automatisch erzeugt werden
• Er tut dasselbe wie der alte Code
• Er ist nur schwer zu analysieren
• Es gibt sehr viele verschiedene Variationen eines solchen Codes
• Der Gebrauch von expiration dates für die Daten schränkt die Applikation nicht zu sehr ein

Wenn diese Voraussetzungen erfüllt sind, läßt sich ein Agentensystem entwickeln, bei dem Agenten vor dem Auslesen und der zielgerichteten Manipulation von Programmcode, sensitiven Daten und Kontrollfluß vor dem expiration date, und vor zielgerichteter unkorrekter Ausführung des Programmcodes geschützt sind. Nach dem expiration date ist der Agent in keiner Weise mehr geschützt, und kann von einem Angreifer beliebig verändert werden. Es darf also kein Server des gesamten Systems einen "abgelaufenen" Agenten akzeptieren, da die Integrität des Programmcodes und der Daten nicht mehr gewährleistet ist.

Um einen völlig unstrukturierten und unleserlichen Programmcode zu generieren, bedient sich Hohl der Methoden, die im Bereich des Software Engineering entwickelt wurden, um lesbaren Code zu erstellen, und dreht diese um ([Hohl97], S. 8). Es werden einfache Regeln invertiert, wie :

• Benutzung von "sprechenden" Variablennamen
• Modularisierung und Benutzung von Subroutinen
• Benutzung einer möglichst simplen Datenrepräsentation

Als Beispiel nennt Hohl einen Mechanismus, den er als variable recomposition bezeichnet. Dieser Mechanismus nimmt die vorhandenen Variablen, mischt deren Inhalte und erstellt neue Variablen, welche einige Bits der Daten verschiedener Originalvariablen enthalten. Zusätzlich werden Konvertierungsfunktionen im neuen Programmcode implementiert, welche aus den neuen Variablen wieder die alten Inhalte herauslesen. Abbildung 5.4 zeigt ein Beispiel für diese Methode.

Structure dissolving ist eine andere Familie von Methoden, die zum Code Mess Up herangezogen werden können. Methoden dieser Art versuchen, Strukturelemente, wie Blöcke oder Prozeduren zu eliminieren, und durch Code ohne innere Struktur zu ersetzen. Einige Beispiele solcher Mechanismen sind :

• Umwandeln von Variablen mit kleinen Gültigkeitsbereichen in globale Variablen
• Ersetzen von Prozeduraufrufen durch den Code der Prozedur
• Auflösen von Blöcken mit Hilfe von goto-Anweisungen

Abb. 5.4 : Variable recomposition ([Hohl97] S. 9)

Ein letzter von Hohl aufgezählter Mechanismus, wird von ihm conversion of compile-time control flow elements into run-time data depended jumps genannt. Dieser Mechanismus versucht, Kontrollflußelemente wie if- und while-Anweisungen in eine Form zu konvertieren, die von Variableninhalten abhängig ist. Dadurch soll vermieden werden, daß der Kontrollfluß zur Kompilierzeit einfach erkannt werden kann.

In den Voraussetzungen zur Verwendung des Code Mess Up Ansatzes wurde gefordert, daß eine große Zahl an verschiedenen Variationen eines Programmcodes gebildet werden kann. Ist dies nicht der Fall, und geht man davon aus, daß die verschiedenen Agenten aus Standard Building Blocks zusammengesetzt sein könnten, wie schon in Kapitel 4.3.1 genannt, so könnte ein Angreifer verschiedene Variationen im Voraus berechnen und bräuchte dann den ankommenden Agenten nur mit diesen Variationen vergleichen. Es läßt sich jedoch feststellen, daß alle Mechanismen die Anforderung erfüllen, die numerisch bezeichnete Argumente benutzen. Außerdem ist die Anzahl der verschiedenen Mischungen bei der variable recomposition nicht klein genug, als daß ein Angreifer ein solches "dictionary of versions" bilden könnte.

Abb. 5.5 : Token Struktur

Der zweite Teil des Code Mess Up Ansatzes befaßt sich mit der Limitierung der Lebenszeit des Programmcodes und der Daten durch expiration dates. Um diese dates fälschungssicher zu realisieren, schlägt Hohl die Verwendung von digitalen Signaturen vor, um die einzelnen Datenelemente mit den zugehörigen expiration dates zu verbinden ([Hohl97], S. 11). Er sagt, daß nur ein Teil der Daten in dieser Weise geschützt werden muß, nämlich die Elemente, die in sich abgeschlossen sind und gegen andere Güter oder Dienstleistungen getauscht werden können (Zahlungsmittel), oder die eine Identität nachweisen (Zertifikate). Diese Datenelemente werden von ihm als token bezeichnet. Abbildung 5.5 zeigt den Aufbau eines solchen tokens. Er besteht aus den Originaldaten (Body), einem Identifikator für den Erzeuger (Issuer) und dem expiration date. Beispiele für solche token sind :

• Elektronisches Geld : Nach dem expiration date wird niemand dieses Geld akzeptieren. Das führt dazu, daß die Person, die das gültige Geld rechtmäßig erhält, es vor dem expiration date zu einer Vertrauensperson (z.B. eine Bank) bringen muß, was Probleme bei Netzwerk- oder Übertragungsfehlern aufwerfen kann.
• Kryptographische Schlüssel : In der Art eines Session Keys (vergl. [Oppl97], S. 139) wird dieser nach Ablauf des expiration dates unbrauchbar. Hohl erwähnt hierbei, daß Public Keys keine token sind, es reicht zu wissen, daß der Host diese nicht während des geschützten Zeitintervalls modifiziert. Für die Kommunikation zwischen Agenten wird mit Hilfe der Public Keys ein Session Key ausgetauscht, über welchen die Kommunikation dann ausschließlich abgesichert wird. Dieser Session Key ist dann wiederum ein token, und hat ein expiration date.
• komplette Agenten : Als Hauptziel eines angreifenden Hosts hat auch ein Agent selber ein expiration date. Kein Host und keine andere Person sollte "abgelaufene" Agenten akzeptieren, und auch keine Interaktion mit ihnen tätigen, da sie von einem betrügerischen Host gesteuert sein könnten.

Alle Informationselemente die keine token sind, brauchen nicht über expiration dates geschützt zu werden. Es genügt zu wissen, daß ein betrügerischer Host diese während des geschützten Zeitintervalls, also bis zum Ablaufzeitpunkt des gesamten Agenten, nicht in Erfahrung bringen bzw. verändern kann.

Der Code Mess Up Ansatz bietet einen temporären Schutz vor den ersten sechs Angriffsarten, die in Kapitel 4.3 aufgeführt sind. Ein angreifender Host kann während des geschützten Zeitintervalls weder den Programmcode, noch die Daten oder den Kontrollfluß lesen und verstehen. Daher hat er auch keine Möglichkeit, gezielte Veränderungen dieser drei Bereiche vorzunehmen. Weil Programmcode und Kontrollfluß geschützt sind, kann der Angreifer den Agenten auch nicht bewußt unkorrekt ausführen. Da der Agent somit für einen bestimmten Zeitraum autonom ist, also nicht vom Server beeinflußt werden kann, hat er die Möglichkeit, den Server z.B. mittels eines Zero-Knowledge Verfahrens auf Basis einer asymmetrischen Verschlüsselung, zu authentifizieren ([Oppl97], S. 190). Eine Maskierung des Servers ist somit ebenfalls ausgeschlossen.

Dem Angreifer bleibt jedoch weiterhin die Möglichkeit, durch wahlloses Verändern von Programmcode, Daten oder Kontrollfluß, oder durch die einfache Verweigerung der Ausführung, einen Denial of Service Angriff durchzuführen, der den Agenten zerstört, oder außer Betrieb setzt. Nach Hohl ist dieser Angriff jedoch eng mit dem Problemfeld eines unsicheren Netzwerks verbunden, und kann mit den dort üblichen Methoden relativ einfach behoben werden.

Als weitere Möglichkeit steht dem Angreifer ein Black Box Test zur Verfügung. Er kann den Agenten immer wieder mit unterschiedlichen Input-Parametern (Bspw. Unterschiedlichen Angeboten) ausführen, und die Ergebnisse vergleichen (vergl. Kapitel 4.3.1). Hohl schlägt dazu vor, die zu schnelle Ausführung von Agenten über Kontrollinteraktionen mit einer Trusted Third Party zu verhindern ([Hohl97], S. 12).

Da der Schutz auf eine bestimmte Zeit beschränkt ist, können keine Daten benutzt werden, die generell geheimzuhalten sind. Ein über den Code Mess Up Ansatz geschützter Agent kann also keine privaten Schlüssel mit sich führen.

Als offene Frage bleibt bestehen, wie Hohl die expiration dates bestimmt. Tut er dies indem er vor dem Senden festlegt bis zu welchem realen Zeitpunkt (Uhrzeit, Datum) der Agent seine Aufgaben auf dem Zielserver erledigt haben muß, so können sich Probleme bei Netzwerkausfällen ergeben. Außerdem sorgen unterschiedliche Zeitzonen oder einfach falsch eingestellte Systemuhren für Differenzen in der Zeitspanne. Legt Hohl das expiration date als maximale Ausführungsdauer nach dem Eintreffen auf dem Zielserver fest, was wahrscheinlicher erscheint, so hat der Server die Möglichkeit, den Agenten nicht sofort auszuführen, sondern zunächst zu analysieren. Den Zeitpunkt des Eintreffens kann der angehaltene Agent selbst nicht überprüfen. Er erkennt erst den Zeitpunkt, an dem er seine Ausführung wieder fortsetzt.

5.1.9 Computing encrypted functions

Einen Ansatz, der vom Prinzip her ähnlich dem vorangegangenen Code Mess Up Ansatz ist, stellen Tomas Sander und Christian F. Tschudin vom International Computer Science Institute der Universität von Berkeley, Kalifornien in ihren Arbeiten [SaTs97] und [SaTs98] vor. Dabei sehen sie den hauptsächlichen Nachteil bei den verschiedenen Code Mess Up Verfahren darin, daß ihre Sicherheit nicht mathematisch nachgewiesen werden kann ([SaTs98], S. 3). Im Gegensatz dazu wollen sie die Möglichkeit schaffen, verschlüsselte Programme auszuführen, ohne diese dafür entschlüsseln zu müssen.

Sie betrachten in ihrer Arbeit hauptsächlich drei Problembereiche ([SaTs98], S. 2) :

• Schutz des Agenten vor Veränderungen durch einen betrügerischen Host (code and execution integrity)
• Verbergen des Programms (code privacy)
• Signieren von Dokumenten in einer unsicheren Umgebung (computing with secrets in public)

Gibt es die Möglichkeit verschlüsselte Programme auszuführen ohne diese zu entschlüsseln, so ist dadurch automatisch der zweite Bereiche realisiert. Daraus folgt, daß auch der erste Bereich geschützt ist, da eine gezielte Veränderung des Programmcodes nicht mehr möglich ist.

Sander und Tschudin benutzen für ihren Ansatz ein 1990 von Abadi und Feigenbaum veröffentlichtes Protokoll zur Verarbeitung von verschlüsselten Daten (computing with encrypted data) [AbFe90]. Dieses Protokoll würde jedoch eine sehr starke Interaktion von Benutzer und Marktserver erfordern, welche die geforderte Eigenschaft der Autonomie des Agenten verletzt.

Aus diesem Grund entwickeln Sander und Tschudin daraus ein Protokoll zur "nicht-interaktiven Verarbeitung von verschlüsselten Funktionen" (non-interactive computing with encrypted functions - CEF). Zur Erklärung der Funktionsweise ihres Protokolls benutzen Sander und Tschudin folgendes Beispiel ([SaTs98], S. 6) :

Alice besitzt eine Funktion f. Bob hat einen Wert x und ist bereit f(x) für Alice zu berechnen. Alice möchte jedoch nicht, daß Bob etwas über f erfährt. Zusätzlich soll Bob, während der Berechnung von f(x), nicht mit Alice kommunizieren müssen.

Die Autoren setzen nun voraus, daß f in eine andere Funktion E(f) umgewandelt (verschlüsselt) werden kann. Zusätzlich dazu gibt es ein Programm P(E(f)), welches diese verschlüsselte Funktion ausführen kann, aber nichts über sie verrät. Bob kennt nur das Programm P(E(f)), welches er mit seinem Wert x verwendet, und das Ergebnis dieser Berechnung, welches er zurück an Alice sendet. Das einfache Protokoll zur nicht-interaktiven Verarbeitung von verschlüsselten Funktionen ist in Abbildung 5.6 dargestellt.

Abb. 5.6 : nicht-interaktive Verarbeitung von verschlüsselten Funktionen [SaTs97]

Die einzelnen Schritte lauten ([SaTs97], S. 6) :

1. Alice verschlüsselt f -> E(f)
2. Alice erzeugt ein Programm P(E(f)), welches E(f) ausführen kann
3. Alice sendet P(E(f)) an Bob
4. Bob berechnet P(E(f))(x)
5. Bob sendet P(E(f))(x) an Alice
6. Alice entschlüsselt P(E(f))(x) und erhält f(x)

Zum Zeitpunkt ihrer Arbeit konnten Sander und Tschudin noch nicht mit Sicherheit sagen, ob es möglich ist, ein solches Verschlüsselungsschema für beliebige Funktionen zu entwickeln. In einem ersten Schritt haben sie spezifische Klassen von Funktionen definiert, für die ein solches Schema gefunden werden kann. Eine solche Klasse, die Sander und Tschudin in ihrer Arbeit näher untersuchen, sind Polynome und rationale Funktionen. Auch für diese Klasse haben sie noch keine Lösung für alle Polynome gefunden, aber für eine eingeschränkte Menge von Polynomen und rationalen Funktionen gibt es erste positive Ergebnisse ([SaTs98], S. 8).

Nimmt man an, daß es eine Möglichkeit gibt, Funktionen gleichzeitig auszuführen und zu verbergen, so besteht dadurch die Möglichkeit, in einer unsicheren Umgebung über eine Funktion s eine digitale Signatur zu erzeugen, wobei die Funktion s selbst geheim bleibt. Ein Problem dabei ist, daß diese Funktion s, obwohl ihre Funktionsweise unbekannt ist, von einem Angreifer benutzt werden kann, um beliebige Dokumente zu signieren. Es wird also eine feste Verbindung zwischen dem Signaturprozeß und der Funktion f, die das zu signierende Ergebnis erzeugt, benötigt.

Sander und Tschudin schlagen zur Lösung dieses Problems ein Verfahren vor, welches eine solche Verbindung herstellt ([SaTs98], S. 13).

Ist s eine Funktion, die von Alice benutzt wird, um die digitale Signatur s(m) einer Nachricht m zu erzeugen, und ist die Nachricht m das Ergebnis einer Funktion f mit dem Parameter x, dann soll die Funktion s nur in der Form s(f(x)) verwendet werden können. Um zu überprüfen, ob z eine gültig digitale Signatur zur Nachricht m ist, wird eine Verifikationsfunktion v von Alice veröffentlicht, so daß z nur dann gültig ist, wenn v(z)=m ist. Damit ihr mobiler Agent eine mit f untrennbar verknüpfte Signatur erzeugen kann, berechnet Alice f_signed als Verknüpfung von s und f (f_signed := s ° f). Anschließend sendet sie f und f_signed an Bob, der sowohl f(x) als auch f_signed(x)=z berechnet. Mit Hilfe der Verifikationsfunktion v kann nun jeder überprüfen, daß f(x)=m ein gültiges Ergebnis von f ist. Wenn Bob behaupten möchte, daß eine Nachricht n ein gültiges Ergebnis von Alice’s Funktion f ist, so muß er dafür s(n) vorweisen, was er nicht kann.

Die Autoren geben vier mögliche Angriffe an, gegen die ein solches Verfahren, welches in dieser Form für rationale Funktionen entwickelt wurde, keinen Schutz bietet :

• Left decomposition attack : Wenn ein Angreifer zusätzlich zur bekannten Funktion f(x) eine Funktion h := s ° f findet, so kann er s herleiten.
• Interpolation attack I : Ein Angreifer kann mit Hilfe der öffentlichen Funktion v eine Reihe von Paaren (z, v(z)) berechnen. Da s eine rationale Funktion ist, ist es möglich s durch Interpolation zu ermitteln.
• Interpolation attack II : Ein Angreifer kann Paare (l, s(l)) berechnen, wobei er verschiedene l als Ergebnis der Funktion f erhält. Auch hier ist eine Interpolation möglich.
• Inversion attack : Wenn Bob einen Parameter x zu einer Nachricht n findet, so daß f(x)=n ist, so kann er eine gültige Signatur von n erzeugen, indem er f_signed(x)=z berechnet.

Um auch diese Schwachstellen zu eliminieren, benutzen Sander und Tschudin ein Idee von Shamir [Sham93]. Alice veröffentlicht dabei nicht ihren kompletten Public Key in der Verifikationsfunktion v, sondern behält einen kleinen Teil geheim. Außerdem benutzt sie eine rationale Funktion r, um die Verknüpfung von f und s zu berechnen. Diese Funktion r ist ebenfalls geheim. Für eine genauere Ausführung dieser Idee wird an dieser Stelle auf die Arbeiten [SaTs97] und [SaTs98] verwiesen.

Wenn das CEF Verfahren in dieser Form funktioniert, hat es den großen Vorteil, daß es mathematisch nachweisbar sicher ist. Außerdem verlangt es keinen zusätzlichen Aufwand von den einzelnen Servern. Allerdings kann dieses Verfahren bis jetzt noch nicht angewandt werden, so daß für aktuelle Anwendungen auf die anderen Verfahren zurückgegriffen werden muß.

5.2 Vergleich der Ansätze

Generell läßt sich feststellen, daß sich keiner der vorgestellten Ansätze gegen einen Black Box Test richtet. Alle Verfahren gehen davon aus, daß der Agent direkt nach seiner Ankunft auf dem Server von diesem ausgeführt wird. Theoretisch hat der Server jedoch die Möglichkeit, den Agenten beliebig zu kopieren, und diese Kopien durchzutesten, bevor er den eigentlichen Agenten ausführt. Durch solche Tests lassen sich Rückschlüsse auf die gespeicherten Daten, den Programmcode und auch den Kontrollfluß ableiten. In einem solchen Fall wäre ein teuer aufgebauter Schutz wirkungslos.

Auch in Bezug auf andere Angriffe gibt es Unterschiede bei den Ansätzen. In Abbildung 5.7 werden diese, in Bezug auf deren Absicherung der in Kapitel 4.3 unterschiedenen Angriffsarten, zum Vergleich gegenübergestellt. Es läßt sich so leicht erkennen, wo diese Unterschiede liegen, und in welchem Fall welche Ansätze eingesetzt werden können. Zu erwähnen ist dabei, daß mit den betrachteten Daten hier jeweils die auf vorherigen Servern gesammelten Anfrageergebnisse gemeint sind.

Da auf elektronischen Märkten generell ein Grundbedürfnis an Sicherheit gegeben ist, kann der erste Ansatz (kein Schutz) vernachlässigt werden. Er ist nur aus Gründen der Vollständigkeit aufgeführt. Die Sicherung über Gesetze und Verträge stellt, wie bereits in Kapitel 5.1.2 beschrieben, ohne ein entsprechendes Verfahren zur Erkennung von Angriffen, keine Veränderung der gegebenen Situation dar. Eine solche Verpflichtung sollte vielmehr neben einem anderen Verfahren angewandt werden, um eine Rechtsgrundlage für entsprechende Streitfälle zu bilden.

Abb. 5.7 : Vergleich der Ansätze

Wie schon in der Einleitung des vorherigen Kapitels erwähnt, lassen sich die restlichen vorgestellten Ansätze in zwei Gruppen einteilen :

• Ansätze, die eine Verletzung der Sicherheitsanforderungen lediglich im Nachhinein erkennen
• Ansätze, die einer Verletzung der Anforderungen entgegenwirken und diese vorbeugend schützen

Es läßt sich leicht erkennen, daß der Detection Objects Ansatz, sowie der Tracing Ansatz nur erkennende Verfahren sind, während alle anderen Ansätze zumindest einen teilweisen Schutz vor Angriffen gewährleisten. Eine Ausnahme stellt dabei das Fault-Tolerance Verfahren dar, welches im Falle von genau einem Angreifer nicht nur den Angriff erkennt, sondern ihn auch korrigieren kann, und dadurch trotzdem das korrekte Ergebnis garantiert. Man kann jedoch davon ausgehen, daß auf einem elektronischen Markt eine Vielzahl von potentiellen Angreifern zu finden ist, so daß die Wahrscheinlichkeit, bei einem Geschäft auf mehr als einen betrügerischen Server zu treffen, nicht vernachlässigt werden kann. Daher läßt sich dieses Verfahren auf einem elektronischen Markt nicht einsetzen.

Generell sind Ansätze die einen Angriff lediglich erkennen auf elektronischen Märkten schlechter zu bewerten, da der Benutzer einen zusätzlichen Aufwand betreiben muß, um auf einen durchgeführten Angriff zu reagieren. Dieser Aufwand kann darin bestehen, ein Suchergebnis zu verwerfen und eine erneute Suche durchzuführen, oder ein betrügerisches Geschäft vor einer Rechtsinstanz nachzuweisen.

Der Ansatz der Detection Objects kann neben diesem generellen Nachteil nur eine Verletzung der Integrität erkennen, und selbst diese nicht mit völliger Sicherheit. Somit kann dieses Verfahren nur schlecht auf elektronischen Märkten eingesetzt werden.

Der Tracing Ansatz ist auch bei mehreren Angreifern ausreichend sicher, und bietet außerdem die Möglichkeit, über eine Trusted Third Party gleichzeitig einen nicht abstreitbaren Kommunikationsnachweis, sowohl für Absender als auch für Empfänger, zu liefern. Dadurch lassen sich nachgewiesene Angriffe (auch Denial of Service Angriffe) einem bestimmten Server zuordnen. Der Nachteil, den dieses Verfahren hat, liegt in der hohen Anzahl an notwendigen Nachrichtenübertragungen, die den Vorteil von mobilen Agenten eliminieren.

Als umfassendstes und somit sicherstes der vorbeugenden Verfahren erweist sich der Computing with encrypted functions Ansatz (CEF). Dieser deckt alle Bereiche der Vertraulichkeit und der Integrität ab, und er läßt außerdem das Ausstellen von digitalen Signaturen sowie das Mitführen von elektronischem Geld zu. Dadurch ergibt sich die Möglichkeit, rechtsverbindliche Geschäfte oder Aktionen durchzuführen. Kommunikationsnachweise, zumindest im Falle von Absende- und Empfangsnachweisen, müssen allerdings durch zusätzliche Verfahren realisiert werden. Da der CEF Ansatz zur Zeit noch nicht in einer allgemein gebräuchlichen Form realisiert werden kann, muß für aktuelle Systeme auf die anderen Verfahren zurückgegriffen werden.

Ein Ansatz, der ähnlich umfassend wirkt, ist der Code Mess Up Ansatz. Dieser hat allerdings den Nachteil, daß der realisierte Schutz nur für eine bestimmte Zeitspanne gegeben ist. Danach wird der Agent ungültig und verliert seinen Wert. Für Anwendungsgebiete, bei denen Agenten nur eine kurze Durchführungsdauer haben und keine dauerhaft vertraulichen Daten wie private Schlüssel benötigen, läßt sich dieses Verfahren jedoch einsetzen. Nachteil dieses Ansatzes ist die komplexe Umsetzung, für die der Benutzer spezielle Codierungsverfahren installieren muß, und die mangelnde Rechtsverbindlichkeit, die sich durch den zeitlich begrenzten Schutz nicht realisieren läßt.

Der Trust Ansatz bietet einen gleichermaßen umfassenden, und vor allen Dingen leicht zu realisierenden Schutz. Voraussetzung ist allerdings, daß ein ausreichend vertrauenswürdiger Server gefunden werden kann. Wenn dieser Server das nötige Maß an Vertrauen des Benutzers besitzt, kann der Agent sogar eine digitale Signatur im Namen seines Benutzers ausstellen. Nachteil des Trust Ansatzes ist, daß eine Berechnung "vor Ort" nicht durchgeführt wird. Bei der Filterung von großen Datenmengen führt das zu einem stark erhöhten Übertragungsaufwand, da die Daten gesammelt und auf den vertrauenswürdigen Server übertragen werden müssen, bevor der Filterprozeß einsetzt. Die "vor Ort" Berechnung stellt einen bedeutenden Vorteil von mobilen Agenten dar, der somit verloren geht.

Der Reputation Ansatz, der theoretisch die Integrität der einzelnen Agentenbereiche schützt, hat den Nachteil, daß er wegen seiner nicht zu eliminierenden Reaktionszeit keinen vollständigen Schutz bietet. Somit läßt sich dieses Verfahren nur für Anwendungsgebiete einsetzen, deren Sicherheit gewünscht, aber nicht zwingend notwendig ist. Ein elektronischer Markt zählt in der Regel nicht dazu.

Generell läßt sich sagen, daß die vorgestellten Verfahren, abgesehen vom CEF Ansatz, der noch nicht benutzt werden kann, keine ausreichende Sicherheit bieten, um in der Vereinbarungs- oder der Abwicklungsphase auf einem elektronischen Markt eingesetzt werden zu können. Hier werden höhere Anforderungen an die Sicherheit gestellt, die, wenn überhaupt, nur das CEF Verfahren erfüllen könnte. Auch bei diesem besteht jedoch die Möglichkeit, daß der Angreifer den Agenten vor seiner Ausführung durchtestet, und somit an Informationen über den Agenten gelangt, die er für einen erfolgreichen Angriff einsetzen kann.

In der Informationsphase können dagegen einige der vorgestellten Ansätze eingesetzt werden, da die Anforderungen an die Sicherheit in dieser Phase noch nicht so hoch sind, wie in den nachfolgenden Phasen. Welches Verfahren eingesetzt wird hängt von der Art des Anwendungsgebietes und den anfallenden Daten ab. Ist die Menge der zu sammelnden und auszuwertenden Daten klein, und läßt sich ein Server finden, der das nötige Vertrauen des Benutzers besitzt, so kann der Trust Ansatz gut eingesetzt werden. Braucht der Agent nur wenig Zeit, um eine Auswertung der Daten auf den einzelnen Servern durchzuführen, und werden keine dauerhaft zu schützenden Daten benötigt, so bietet sich der Code Mess Up Ansatz an. Reicht ein bloße Erkennung einer Veränderung im nachhinein aus, so stellt das Tracing Verfahren die beste Wahl dar. Hierbei muß jedoch erwähnt werden, daß eine Erkennung von Integritätsverletzungen in der Informationsphase eines elektronischen Marktes in der Regel nicht ausreichen wird. Durch das Auslesen von Daten und Programmcode, welches von einem solchen Verfahren nicht erkannt wird, hat ein Angreifer eine Vielzahl an Möglichkeiten, den Agenten und damit seinen Benutzer zu betrügen.

Inhaltsverzeichnis Sicherheitsaspekte von mobilen Agentensystemen Zusammenfassung