4 Sicherheitsaspekte von mobilen Agentensystemen

Der Begriff Sicherheit impliziert aus sprachlicher Sicht eine gewisse Absolutheit, die in den meisten Fällen nicht gegeben ist ([HePe97] S. 218). Tatsächlich ist der Begriff der Sicherheit eine relative Größe, da es in der Technik allgemein, und in der Computertechnik im speziellen, keine absolute Sicherheit geben kann. Die Aufgabe der Sicherheit besteht vielmehr darin, das Risiko bis auf ein vertretbares Maß zu reduzieren ([LiSK92] S. 369). Generell kann man bei den vielzähligen Definitionen des Sicherheitsbegriffs drei grobe Auffassungen unterscheiden ([LiSK92] S. 368) :

• Sicherheit durch Realisierung von Sicherungsmaßnahmen
• Sicherheit durch Reduzierung von Gefährdungen
• Sicherheit durch Kontrolle von Risiken

Im folgenden wird ausschließlich der für die Softwareentwicklung relevanteste Begriff der Sicherheit durch Realisierung von Sicherungsmaßnahmen betrachtet, da die anderen beiden Begriffe überwiegend im organisatorischen Bereich von Bedeutung sind.

4.1 Klassifikation des Begriffs Sicherheit

Um die oben erwähnten Sicherungsmaßnahmen durchführen zu können, bedarf es zuerst einer Analyse der unterschiedlichen Risiken, denen ein zu entwickelndes Softwaresystem ausgesetzt ist. In ([HePe97] S. 218) werden die Sicherheitsanforderungen zum Schutz vor diesen Risiken aufgezählt und klassifiziert. Abbildung 4.1 zeigt eine graphische Repräsentation dieser Klassifikation.

Auf oberster Ebene kann unterschieden werden, ob es sich bei den Sicherheitsmaßnahmen um Maßnahmen gegen unvorhersehbare Ereignisse (z.B. Naturkatastrophen) oder gegen beabsichtigte oder unbeabsichtigte Störungen (z.B. Abhörangriffe oder Eingabefehler) handelt. Auch der Schutz gegen unvorhergesehene Ereignisse fällt zum großen Teil in den organisatorischen Bereich und soll deshalb im folgenden nicht weiter betrachtet werden. Der Schutz vor beabsichtigten und unbeabsichtigten Störungen richtet sich zum einen gegen die Grundbedrohungen der Verletzung der Verfügbarkeit, der Vertraulichkeit und der Integrität, die später genauer untersucht werden. Zum anderen können gerade auf elektronischen Märkten die Sicherung der Anonymität, der Originalität und der Rechtsverbindlichkeit von großer Bedeutung sein. Im Falle einer Kommunikationsverbindung ist es sinnvoll, die eindeutige Identifizierung des Senders zu ermöglichen, als auch die Kommunikation selbst durch Absende- und Empfangsnachweise belegen zu können.

4.2 Sicherheitsbereiche im Fall von mobilen Agenten

Ein mobiler Agent, welcher auf einer Plattform im Netz läuft, kann mit unterschiedlichen Stellen kommunizieren. Dabei ergeben sich jeweils Anforderungen an die Sicherheit, und, je nach Kommunikationsebene, unterschiedliche Möglichkeiten, diese zu gewährleisten. In ([Hohl97] S. 2) werden vier Sicherheitsbereiche von mobilen Agentensystemen unterschieden :

1. Sicherheit zwischen zwei Agenten
2. Sicherheit zwischen Agent und Host (Ausführungsumgebung)
3. Sicherheit zwischen zwei Hosts
4. Sicherheit zwischen Host und einer unautorisierten dritten Person

Im folgenden wird jeder dieser Sicherheitsbereiche diskutiert, und es werden mögliche Sicherungsmöglichkeiten aufgezählt.

4.2.1 Sicherheit zwischen zwei Agenten

In diesem Bereich sollen Agenten vor anderen betrügerischen Agenten geschützt werden. Diese könnten versuchen den Programmcode oder die Daten ihres Opfers zu lesen oder gar zu manipulieren. Mögliche Angriffe wären dabei

• physikalische Zugriffe auf die Programm- und Datenbereiche des Agenten,
• Maskierung (Vortäuschen einer fremden Identität – Trojanische Pferde),
• Betrug allgemein (z.B. die Benutzung eines Dienstes, ohne ihn zu bezahlen)
• und Denial of Service (Verhindern der Ausführung, z.B. durch Füllen des Nachrichtenpuffers des Hosts)

Diese Angriffe unterscheiden sich nicht von den bekannten Angriffen in verteilten Systemen. Daher kann zu ihrer Bekämpfung auf die Standardverfahren aus diesem Bereich zurückgegriffen werden. Das sind in diesem Fall z.B. :

• Die Benutzung einer Programmiersprache, die keinen Zugriff auf private Speicherbereiche erlaubt
• Isolierte Adressräume für die einzelnen Agenten
• Authentifizierung der Agenten, z.B. mittels digitaler Signaturen
• Benutzung eines Service-Vertragssystems, wie es z.B. in [SaLe95] vorgeschlagen wird

Eine Arbeit, die sich speziell mit der Absicherung der Inter-Agenten-Kommunikation beschäftigt, ist [Vite96]. Dort werden nach dem Prinzip der isolierten Adressräume sogenannte secure object spaces definiert.

4.2.2 Sicherheit zwischen Agent und Host

Der Sicherheitsbereich zwischen Agenten und Hosts läßt sich in zwei Unterbereiche aufteilen :

1. Sicherheit von Hosts gegenüber betrügerischen Agenten
2. Sicherheit von Agenten gegenüber betrügerischen Hosts

Die Angriffe von Agenten gegen Hosts sind dabei dieselben, wie zwischen Agenten untereinander. Der einzige Unterschied ist der größere Einfluß den ein Host hat, da er den Ablauf des Agenten kontrolliert. Er kann verdächtige Agenten sofort in ihrer Ausführung unterbrechen, und sich so vor eventuellen Angriffen schützen. Außerdem hat er ebenfalls die Möglichkeit, sich auf herkömmliche Art zu schützen :

• Benutzung von sicheren Sprachen oder isolierten Adressräumen
• Authentisierung
• Benutzung von Konto- und Vertragssystemen
• Benutzung von Mechanismen zur Ressourcenkontrolle

Die Benutzung von isolierten Adressräumen wird z.B. bei Java Applets benutzt, wo es sich um denselben Sachverhalt handelt, nämlich die lokale Ausführung von unbekannten Programmen. Das in Java als Sandbox Security Model ([FrMu96] S. 4) bezeichnete Verfahren sorgt dafür, daß alle potentiell gefährlichen Prozeduraufrufe von speziellen Sicherheitskontroll-Komponenten überwacht werden. Diese entscheiden, welches Programm welche Prozeduren aufrufen darf, und welche nicht. In [TaVa96] findet sich eine relativ ausführliche Beschreibung des Security-Models der Agentensprache Telescript von General Magic. Neben diesem Modell ist auch die Arbeit von Feigenbaum und Lee [FeLe97] hauptsächlich auf die Absicherung von Hosts gegen betrügerische Agenten ausgerichtet.

Der zweite Bereich der Sicherheit von Agenten gegenüber betrügerischen Hosts stellt ein völlig neues Problem dar, weil der Host für die Ausführung des Agenten zuständig ist und somit jeden Programmschritt beobachten kann. Es gibt in diesem Bereich mehrere Hardware-Ansätze, welche die Laufzeitumgebung des Agenten durch sichere Geräte realisieren. Ein solcher Ansatz ist der von Wilhelm vorgestellte tamper proof environment Ansatz [Wilh97]. Da ein Hardware-Ansatz die geforderte Offenheit des Marktsystems verletzt, sollen sich die Betrachtungen in dieser Arbeit nur auf die Software-Ansätze beschränken. Dieser Bereich der Sicherung wird in Kapitel 5 ausführlich besprochen. Es werden mehrere unterschiedliche Lösungsvorschläge beschrieben, und deren Vor- und Nachteile diskutiert.

4.2.3 Sicherheit zwischen zwei Hosts

Dieser Bereich beschreibt speziell die Absicherung der Kommunikation zwischen zwei Hosts über ein unsicheres Netzwerk, wie z.B. dem Internet. Aspekte wie Maskierung, etc. wurden bereits in den vorhergehenden Kapiteln besprochen. Die möglichen Angriffe, die im Zusammenhang mit einer solchen unsicheren Kommunikation auftauchen können sind :

• passive Angriffe (Abhören)
• aktive Angriffe (Manipulation)

Diese, sowie die dagegenwirkenden Sicherheitsmechanismen, sind ausführlich in [Oppl97] S.313ff. und S. 69ff.) beschrieben. An dieser Stelle soll darauf nicht weiter eingegangen werden.

4.2.4 Sicherheit zwischen Host und einer unautorisierten dritten Person

Die Absicherung des Hosts gegen unautorisierte dritte Personen bezieht sich auf den Zugang zu, bzw. den Zugriff auf Systembereiche des Hosts. Hier kommen die gängigen Verfahren zur Authentifizierung und zur Autorisierung zum Einsatz, wie Passwort-Verfahren, digitale Signaturen, oder ähnliche.

4.3 Mögliche Angriffe von Hosts und deren Absicherung

Im folgenden werden die einzelnen Angriffe aufgezählt, die ein Host auf einen Agenten ausüben kann ([Hohl97] S. 5 ff.). Diese lassen sich anhand der Klassifikation des Sicherheitsbegriffs aus Abbildung 4.1 in die drei Kategorien der Grundbedrohungen einteilen. Die ersten drei Angriffe (Kapitel 4.3.1 bis 4.3.3) richten sich gegen die Vertraulichkeit des Programmcodes, der Daten und des Kontrollflusses. Dabei bezieht sich die Vertraulichkeit auf den Schutz vor dem jeweils ausführenden Server. Die Vertraulichkeit beim Übertragen des Agenten zwischen zwei Servern kann durch eine normale asymmetrische Verschlüsselung erreicht werden. Die nächsten drei Angriffe (Kapitel 4.3.4 bis 4.3.6) betreffen die Integrität der drei Bereiche. Auch hier wird wieder speziell der ausführende Server als Angreifer betrachtet. Eine Sicherung der Integrität bei der Übertragung kann durch digitale Signaturen erzielt werden. Der letzte Angriff (Kapitel 4.3.7) betrifft schließlich die Verfügbarkeit des gesamten Agenten. Eine Unterscheidung der drei Teilbereiche ist hier nicht sinnvoll. Auch hier werden keine Übertragungsfehler betrachtet, sondern lediglich die absichtliche Zerstörung durch den ausführenden Host.

4.3.1 Auslesen von Programmcode

Der Programmcode muß generell für den Host lesbar sein, um zu gewährleisten, daß der Host den Agenten ordnungsgemäß ausführen kann. Es besteht jedoch ein Unterschied zwischen dem Wissen, was das Programm als ganzes tut, und dem Wissen, was jede Zeile des Programms bewirkt. Der Interpreter muß im Grunde genommen nur wissen, was jede einzelne Zeile des Programms tut, um das Programm ausführen zu können. Es wäre also theoretisch möglich, den Host nur auf die jeweils nächste Programmzeile zugreifen zu lassen. Das wäre jedoch keine generelle Lösung des Problems, da einige Hosts, aufgrund der Tatsache, daß sie große Teile des Codes ausführen, trotzdem fast den gesamten Code zu sehen bekommen.

Eine in Bezug auf Entwicklungskosten und Entwicklungszeit vorteilhafte Methode des Programmierens ist es, den Agenten aus sogenannten Standard Building Blocks zusammenzusetzen, die für jeden Benutzer zugänglich sind. In diesem Fall sind allerdings die detaillierten Spezifikationen der Building Blocks verfügbar, und somit unter Umständen auch dem Host bekannt. Wenn der Agent also größtenteils aus solchen Building Blocks besteht, und nur wenig Code spezifisch für den einzelnen Agenten geschrieben wurde, kennt der Host den Code evtl. schon bevor der Agent ausgeführt wird.

Schließlich besteht für den Host noch die Möglichkeit, einzelne Programmteile, oder auch den gesamten Agenten einem Black Box Test zu unterziehen. Hierbei wird der untersuchte Code in einer isolierten Laufzeitumgebung mit unterschiedlichen Eingaben getestet. Aus den resultierenden Ausgaben können dann Rückschlüsse auf den Code abgeleitet werden.

Es gibt also mehrere Möglichkeiten für einen Host, an den Code des Agenten zu gelangen. Alle diese Möglichkeiten können mit herkömmlichen Verfahren nicht ausreichend abgesichert werden. Das ist ein großes Problem, da sich aus dem Programmcode viele Eigenschaften des Programms ableiten lassen, wie z.B. die Ausführungsstrategie, die physische Speicherstruktur von Code und Daten, oder Teile der Daten.

4.3.2 Auslesen von Daten

Das Auslesen von Daten aus einem Agenten ist in sofern sehr kritisch, als es keine Spuren hinterläßt. Das Wissen, welches sich der angreifende Host dadurch aneignet, kann unter Umständen erst viel später zu Konsequenzen führen, so daß der Agent und besonders sein Besitzer zunächst nichts von dem Angriff merken. Dieses Problem ist besonders wichtig, wenn es sich bei den Daten um geheime Schlüssel oder elektronisches Geld handelt. Ein Verlust solcher Daten läßt sich nicht ohne weiteres beheben und hat meist erhebliche Konsequenzen für den Besitzer.

Es können jedoch auch andere Datenklassen für einen wirkungsvollen Angriff eines Hosts benutzt werden. Die Kenntnis des bisher besten Angebotes im Beispiel aus Kapitel 3.4 kann dazu führen, daß ein Host einen minimal niedrigeren Preis nennt, obwohl sein richtiger Preis in Wirklichkeit noch niedriger ist (Preisanpassungsbetrug).

Generell müssen beim Auslesen von Daten drei Fälle unterschieden werden :

• Die Kenntnis darüber, welche Datenelemente überhaupt existieren
• Die Kenntnis der Inhalte dieser Datenelemente
• Die Kenntnis über die Speicheradressen dieser Datenelemente

Auch hier kann die Existenz der einzelnen Datenelemente gegenüber dem ausführenden Host nicht verborgen bleiben. Um so mehr muß dafür gesorgt werden, daß der Host die Inhalte dieser Elemente nicht erfährt, oder zumindest nichts damit anfangen kann. Diese Forderung kann von einer zeitunabhängigen Forderung auf eine bestimmte Zeitspanne reduziert werden, indem zu jedem sicherheitssensitiven Datenelement eine Ablauffrist (expiration date) zugeordnet wird, nach welcher dieses Element nicht mehr benutzt werden kann. Nähere Erklärungen dazu folgen in Kapitel 5.1.9.

Somit können also drei Klassen von Datenelementen unterschieden werden :

• Datenelemente, welche nicht gegen Leseangriffe geschützt werden müssen (öffentliche Daten)
• Datenelemente, welche nur während der Ausführungszeit des Agenten geschützt werden müssen (temporär private Daten)
• Datenelemente, welche vor dem Angreifer völlig geheim gehalten werden müssen (private Daten)

4.3.3 Auslesen des Kontrollflusses

Wenn der Host den Programmcode und die Daten eines Agenten ausgelesen hat, kann er zu jeder Zeit den nächsten Programmschritt bestimmen. Selbst wenn es gelingt, die benutzten Daten vor dem Host zu verbergen, ist es immer noch schwierig, die Informationen über den eigentlichen Kontrollfluß des Agenten zu schützen. Der Kontrollfluß stellt gewissermaßen die tatsächliche Abfolge von Programmschritten dar, ohne Conditional Statements wie IF-THEN-Konstrukte und WHILE-Schleifen. Diese Informationen, zusammen mit dem Code, erlauben es einem Host, Informationen über den Ausführungsstatus des Agenten herzuleiten. Es ist dadurch z.B. möglich zu ermitteln, ob ein Angebot besser oder schlechter als das gespeicherte Angebot des Agenten ist, ohne etwas über den Inhalt der einzelnen Variablen zu wissen.

Zu unterscheiden sind :

• Der aktuelle Kontrollfluß nach der Ausführung eines Programmschritts
• Die Relation zwischen Kontrollfluß und Ausführungssemantik

Dabei kann der aktuelle Kontrollfluß nicht vor dem Host verborgen werden, da der Host diesen quasi erzeugt. Wenn es jedoch möglich ist, die Relation zwischen Kontrollfluß und Ausführungssemantik zu schützen oder zu verbergen, weiß der Host nicht, was ein vorgefundener Kontrollfluß bedeutet, und kann somit z.B. nichts über ein gestelltes Angebot oder sonstige Daten aussagen.

4.3.4 Manipulation von Programmcode

Kann ein Host den Programmcode eines Agenten lesen, und hat er Zugang zu den Speicherbereichen, in denen der Code abgelegt ist, so kann er diesen auch verändern. Dies kann in der Form einer permanenten Änderung (durch Einfügen eines Virus oder eines trojanischen Pferdes) oder einer temporären Änderung, die sich nur auf den aktuellen Host bezieht, geschehen. Der Vorteil der temporären Änderung ist, daß der nachfolgende Host die Manipulation nicht feststellen kann.

Die permanente Veränderung des Programmcodes kann durch eine digitale Signatur verhindert werden, wenn sich der Programmcode über die gesamte Lebensdauer des Agenten nicht verändert. Ändert sich jedoch der Code zur Laufzeit, müssen andere kryptographische Verfahren angewandt werden, die sich allerdings negativ auf die Performance und die Effizienz auswirken.

Eine sinnvolle Manipulation des Programmcodes ist nur dann durchführbar, wenn der Angreifer weiß, was jede einzelne Zeile des Programms genau tut, und wo sie gespeichert ist. Gelingt es diese Informationen vor einem Angreifer zu verbergen, so wird damit auch eine temporäre Manipulation verhindert. Es können zwar noch willkürliche Änderungen am Code vorgenommen werden, jedoch kann der Angreifer nicht mehr vorhersagen, wie sich das Programm dann verhält. Diese Möglichkeit eignet sich also nur zur absichtlichen Zerstörung des Programms. Ein solcher Angriff entspricht einer Verhinderung der Ausführung (Denial of Service) und wird in Kapitel 4.3.7 diskutiert.

4.3.5 Manipulation von Daten

Kennt der Host den physischen Speicherplatz der Daten und deren Semantik, so kann er diese ebenfalls verändern. Er könnte z.B. die nachfolgenden Hosts aus der Liste der zu besuchenden Hosts streichen, nachdem er seinen Preis als besten eingetragen hat. Das würde dazu führen, daß der Agent die gesuchte Ware bei diesem Host kauft, und keine anderen mehr besucht.

Um diese Angriffe zu verhindern, lassen sich die einzelnen Datenelemente zunächst in zwei Gruppen aufteilen :

• Daten, die durch korrekt ausgeführten Code während des Besuchs eines Hosts verändert werden (variabler Status)
• Daten, die nicht verändert werden (Read-Only Status)

Die Datenelemente aus der zweiten Gruppe können digital signiert und somit geschützt werden. Datenelemente aus der ersten Gruppe können ebenfalls geschützt werden, wenn es gelingt, die Zuordnung im Speicher vor einem angreifenden Host verborgen zu halten.

4.3.6 Manipulation des Kontrollflusses

Selbst wenn der Host keinen Zugang zu den Daten des Agenten hat, kann er doch sein Verhalten beeinflussen, indem er den Kontrollfluß des Agenten manipuliert. Er kann Bedingungen in Conditional Statements falsch interpretieren, oder ganze Programmteile (bspw. Sicherheitsüberprüfungen) überspringen. Dadurch können Absicherungen umgangen oder außer Kraft gesetzt werden. Besonders kritisch ist dabei die Tatsache, daß eine Veränderung des Kontrollflusses nicht über Checksummen , wie z.B. Hashwerte, überprüft werden kann.

Wie bereits in den vorangegangenen Kapiteln erwähnt, kann der Kontrollfluß vor Manipulationen geschützt werden, indem die Relation zwischen Kontrollfluß und Ausführungssemantik vor dem Host verborgen gehalten wird.

4.3.7 Denial of Service Angriff

Die einfachste Möglichkeit für den Host, die Ausführung des Agenten zu beeinflussen ist, ihn einfach nicht auszuführen, oder durch Zerstörung die Ausführung zu verhindern. Dies läßt sich durch kein Verfahren absichern, da der Host frei entscheiden kann, ob er den Agenten ausführt oder nicht.

Wenn man durch organisatorische Maßnahmen (z.B. durch Protokolle) den Host dazu zwingt, die korrekte Ausführung eines Agenten später nachzuweisen, so kann man jedoch angreifende Hosts identifizieren und als "betrügerisch" markieren. Daraus würde dann folgen, daß dieser Host nicht mehr von Agenten aufgesucht würde.

Der Denial of Service Angriff kann in der Regel schlecht von evtl. Ausfällen oder "unbeabsichtigten" Fehlern eines Hosts unterschieden werden. Somit ist eine generelle Verurteilung bei unkorrekter Ausführung nicht so einfach möglich.

Im folgenden Kapitel werden verschiedene Ansätze vorgestellt, die sich jeweils gegen mehrere der oben aufgeführten Angriffe richten. Im zweiten Teil des Kapitels folgt ein Vergleich dieser Ansätze. Dieser konzentriert sich auf die vorgestellten Angriffsarten, betrachtet jedoch auch zusätzlich gegebene Sicherheitsanforderungen aus Kapitel 4.1, wie z.B. Kommunikationsnachweise.

Inhaltsverzeichnis Elektronische Agenten Absicherung von mobilen Agenten gegen betrügerische Hosts