Die Mobilität von Agenteninstanzen wirft ein weiteres Problem auf. Da jegliche Daten einer Agenteninstanz der Gefahr der illegalen Veränderung ausgesetzt sind, müssen Maßnahmen ergriffen werden, welche die Authentizität dieser Daten sicherstellen können. Dabei meint ``sicherstellen der Authentizität'' nicht, daß die Unveränderlichkeit der Daten garantiert werden kann, sondern daß Veränderungen zuverlässig erkannt werden können.
Dabei genügt es nicht, daß sichere Kanäle zur Kommunikation verwendet werden, da dies nur ein Veränderung durch außenstehende Entitäten ausschließt. Migriert eine Agenteninstanz jedoch auf ein Agentensystem mit feindlichen Absichten, sind ihre Daten immer noch einer ungewollten Veränderung preisgegeben.
Daten einer Agenteninstanz lassen sich in zwei grobe Kategorien
unterscheiden:
Die Authentizität von Daten der ersten Kategorie ist äußerst schwierig zuzusichern, da prinzipiell die Rechenvorschrift bekannt sein müßte, die diese Daten erzeugt haben. Durch Nachvollziehung dieser Berechnungen ließe sich dann die Authentizität der Daten überprüfen. Eine nähere Betrachtung dieser Problematik wäre an dieser Stelle zu umfangreich und muß deshalb unterbleiben. Ein Lösungsansatz findet sich in [NeLe 98].
Die zweite Kategorie von Daten läßt sich aber mit vergleichsweise einfachen Mitteln gegen Veränderungen sichern. Dabei können die Daten durch die Agenteninstanz selbst oder aber auch durch ein Agentensystem oder eine Person erzeugt werden. In den folgenden Abschnitten werden die unveränderlichen Daten weiter kategorisiert und Sicherungsmaßnahmen vorgestellt.
Daten, die einmalig gesetzt und später nur von einem bestimmten ``Empfänger'' gelesen werden sollen, lassen sich in den meisten Fällen sichern.
Hierzu werden die zu sichernden Daten sofort nach ihrer Erzeugung mit dem öffentlichen Schlüssel des Empfängers verschlüsselt, was sicherstellt, daß nur der Empfänger die Daten lesen kann.
Dieses Verfahren ist im Fall von Agentensystemen oder Personen als Empfänger immer anwendbar. Einzig im Fall von Agenteninstanzen als Empfänger kann es nur solange angewendet werden, wie die empfangende Instanz auf jenem Agentensystem verharrt, zu dem sie sich zum Zeitpunkt der Verschlüsselung befand. Der Grund hierfür ist die Tatsache, daß der private Schlüssel der Empfänger-Agenteninstanz nur für die Dauer einer Sitzung Bestand hat, nach einer Migration jedoch nicht mehr verfügbar ist, und somit die Empfänger-Agenteninstanz die Daten nicht mehr entschlüsseln kann.
Um nun auch die Authentizität der Daten gewährleisten zu können, versieht der Erzeuger der Daten diese mittels seines privaten Schlüssels mit einer digitalen Signatur. Wenn ein Agentensystem oder eine Person diese Daten erzeugt hat, ist dieser Vorgang problemlos, da sie über eigene persistente Schlüsselpaare verfügen.
Im Fall von Agenteninstanzen als Erzeuger tritt jedoch wiederum das Problem auf, daß Agenteninstanzen keine persistenten Schlüsselpaare besitzen. Hierzu bieten sich zwei Lösungsmöglichkeiten an:
Äquivalent zum Verfahren zur Authentisierung der Agenteninstanzen kann aber hierfür erneut das Agentensystem herangezogen werden, welches dann stellvertretend für die Instanz die Daten signiert. Bei einer späteren Überprüfung der Signatur muß dann wiederum zuerst über die Vertrauenswürdigkeit des signierenden Agentensystems entschieden werden, bevor nach einer Verifikation der Signatur, die Daten als authentisch angesehen werden können. Dabei tritt dann die Agenteninstanz nur noch durch ihren Identifikator in Erscheinung, da zur Signierung der Schlüssel des Agentensystems benutzt wurde.
Die Agenteninstanz benutzt den zu ihrem Sitzungszertifikat gehörenden privaten Schlüssel um die Daten zu signieren. Voraussetzung für dieses Verfahren ist jedoch die Existenz eines Zertifikatdienstes nach Abschnitt 5.5.5, damit der Empfänger der Daten später das mittlerweile unter Umständen nicht mehr aktuelle Sitzungszertifikat der Agenteninstanz überprüfen kann.
Die erste Lösung hat den Vorteil, daß sie sich auch ohne Zertifikatdienst realisieren läßt, benötigt aber eine weitere Stufe in der Vertrauenskette. Sie sollte also nur umgesetzt werden, wenn keine Zertifikatinfrastruktur vorhanden ist, ansonsten sollte der zweiten Lösung der Vorzug gegeben werden.
Sollen Daten, die eine Agenteninstanz mit sich führt, zwar gegen Veränderungen geschützt sein, die Daten selbst aber beliebig lesbar bleiben, findet das gleiche Verfahren Anwendung wie im vorigen Abschnitt beschrieben, einzig der Schritt der Verschlüsselung unterbleibt dann. Damit bleiben die Daten selbst unverschlüsselt, sind aber mit einer überprüfbaren digitalen Signatur versehen.
Ein spezieller Fall von unveränderlichen Daten stellen Listen dar, deren Einträge jeweils unveränderlich sein sollen, die Liste selbst aber während des Lebenszyklus der Agenteninstanz sukzessive erweitert werden können soll.
Korjoth, Asokan, Gülcü geben in [KAG 98] hierfür Protokolle an, mit deren Hilfe, folgende Eigenschaften einer solchen Liste zugesichert werden können:
In [KAG 98] werden hierfür insgesamt vier Protokolle (genannt P1 bis P4) angegeben, von denen zwei eine vorhandene Public-Key-Infrastruktur zur Voraussetzung haben, und sich damit hervorragend für die Verwendung im Rahmen dieses Konzepts eignen. Neben den oben beschriebenen Eigenschaften, die sie gemeinsam realisieren, unterscheiden sie sich in folgenden Punkten
Zur Zusicherung der Eigenschaften 1 und 2 werden dabei die Signier- und Verschlüsselungsmechanismen der Public-Key-Verfahren benutzt, für die Eigenschaften 3 bis 7 werden Hash-Funktionen benutzt.
Damit ist es möglich, vom Beginn der Liste an, Schritt für Schritt die Integrität der Liste zu überprüfen. Kann dabei ein Schritt nicht erfolgreich überprüft werden, so ist zumindest die Integrität des bis dahin überprüften Teils der Liste noch gewährleistet.
Betrachtet man aus [KAG 98] den Verschlüsselungs-/Signierschritt von KAG-P1
| Listenindex |  |
| Listeneintrag |  |
| Erzeuger des i-ten Eintrags |  |
| Signaturfunktion des Erzeugers |
 |
| Verschlüsselungsfunktion für den Empfänger |
 |
| Wert des Listeneintrags |  |
| Zufallswert |  |
| Hash-Funktion |  |
| Hash-Vorschrift |
 |
| Fortschreibungsvorschrift |
 |
läßt sich durch Entfernen der Verschlüsselung
der modifizierte
Schritt
gewinnen. Unter Beibehaltung der Hash- und Fortschreibungsvorschrift erhält man damit das neue Protokoll KAG-P1a, welches alle Eigenschaften von KAG-P1 umfaßt, jedoch die Listeneinträge öffentlich lesbar bleiben.
Der Beweis über die Korrektheit und die Eigenschaftszusicherung erfolgt dabei äquivalent wie in [KAG 98] für das KAG-P1 ausgeführt und soll hier nicht wiederholt werden.
Um nun die Authentizität der in den vorangegangenen Abschnitten definierten Attribute einer Agenteninstanz sicherstellen zu können, müssen nur noch die eben definierten Verfahren auf die einzelnen Attribute angewendet werden:
Die Historie der besuchten Agentensysteme kann mittels KAG-P1a gesichert werden. Authority, Implementierer und Agentengattung sind typische Vertreter von Daten, die einmalig gesetzt werden, und zwar bei der Erzeugung der Agenteninstanz, und deren Unveränderlichkeit für den Rest des Lebenszyklus der Instanz sichergestellt werden muß. Dies kann nach Abschnitt 5.7.2 erfolgen, indem das Agentensystem, auf dem die Instanz erzeugt wird, diese Werte mit einer Signatur versieht. Dabei kann die Identität des Agentensystems, bei einer späteren Überprüfung der Signatur, aus dem ersten Eintrag der Historie gewonnen werden.
Damit ist die Authentizität aller Attribute einer Agenteninstanz auf eine Signatur durch das erzeugende Agentensystem zurückgeführt. Somit ist es einem Angreifer nicht mehr möglich Attribute zu verändern. Ebenfalls geschützt ist die Historie der Agentensysteme. Durch KAG-P1a ist es einem feindliches Agentensystem nicht möglich die Historie partiell zu verändern. Es kann auch nicht unterlassen, sich selbst in die Liste einzutragen. Dies würde nämlich auf dem nächsten Agentensystem, auf das die Instanz migriert, bemerkt werden, da die Integrität der Liste dann nicht mehr intakt wäre.
Unter Benutzung der oben beschriebenen Verfahren ist es
selbstverständlich auch möglich und angebracht, die für eine
Agenteninstanz individuellen Attribute und Daten zu sichern, solange
diese keinen nachträglichen Veränderungen unterworfen sind.
Beispielsweise könnte ein Management-Agent, der von seiner Authority beauftragt wurde QoS-Daten auf konkurrierenden Endsystemen zu messen, die auf jedem Endsystem anfallenden Daten einzeln nach Abschnitt 5.7.1 mit dem öffentlichen Schlüssel seiner Authority chiffrieren und dann selbst signieren. Damit sind die Meßwerte vor Ausspähen durch andere Endsysteme (``Wie gut ist die Konkurrenz?'') und vor Veränderungen geschützt.