5.6 Der Code einer Agentengattung

Für die Realisierung eines sicheren SmA können grundsätzlich zwei verschiedene Vertrauensbeziehungen zu Agenten unterschieden werden:

• Der Code eines Agenten, die Agentengattung, ist vertrauenswürdig. D.h. man vertraut dem Implementierer des Codes, daß die für die Gattung angegebene Semantik korrekt implementiert wurde und z.B. kein Trojanisches Pferd enthält.

• Die Daten einer Agenteninstanz sind vertrauenswürdig. D.h. die aktuelle Belegung aller Attribute einer Agenteninstanz ist insofern korrekt, daß unter Verwendung von vertrauenswürdigem Code alle Aktionen eines Agenten sich im Rahmen der Semantik des Agenten bewegen.

Entsprechend dieser Unterscheidung muß in einem Sicherheitsmodell die Behandlung von Agentengattung und Agenteninstanz getrennt betrachtet werden.

Am Beispiel des folgenden Szenarios läßt sich die Notwendigkeit dieser Unterscheidung unmittelbar erkennen: Ein Implementierer (Hersteller) I erstellt eine Agenteninstanz. Dann wird diese von zwei völlig verschiedenen Anwendern (aus unterschiedlichen Firmen) eingesetzt. Nun ist es vorstellbar, daß, obwohl I prinzipiell vertrauenswürdig ist, man der Authority (der eine Anwender) der einen Instanz vertraut (weil dieser z.B. aus der gleicher Firma ist), man jedoch der Authority (der andere Anwender) der anderen Instanz nicht vertrauen kann (da dieser z.B. für einen Konkurrenten tätig ist).

Aber auch für den Aufbau einer Vertrauensbeziehung zu einer Agentengattung ist die Trennung sinnvoll. So kann beispielsweise Code, der von einem Ort geladen wird, der als sicher vor Manipulationen angesehen werden kann, leichter als vertrauenswürdig eingestuft werden, als solcher der von einer unbekannten Quelle stammt.

Für die persistente Speicherung von Agenteninstanzen sollten demnach eigens dafür vorgesehene Datenbasen verwendet werden. Eine solche Datenbasis wird im Folgenden als Code Repository bezeichnet.

Wird nun eine neue Agenteninstanz erzeugt oder migriert eine bestehende Agenteninstanz, so stellt sich die Frage, wie ein Agentensystem an den zur Ausführung des Agenten notwendigen Code gelangt.

Für den Fall der Erzeugung einer neuen Instanz macht die MASIF-Spezifikation hierzu keine näheren Angaben, während für eine Migration durchwegs von einem Modell ausgegangen wird, in welchem Code, der zur Ausführung einer Agenteninstanz benötigt wird, früher oder später vom zuletzt besuchten Quellagentensystem der Migration geladen wird. Die Möglichkeit, daß Agentensysteme eigene Datenbasen für Code besitzen wird nicht betrachtet.

Kombiniert man nun Code Repositories mit dem in MASIF vorgestellten Konzept, ergibt sich ein mehrstufiges Verfahren zum Laden von Code:

• Der Code wird aus einem Code Repository geladen. Dabei kann ein Agentensystem eine Liste vertrauenswürdiger Code Repositories besitzen und diese nacheinander abfragen.

• Schlägt der erste Schritt fehl, so wird der Code von dem zuletzt besuchten Quellagentensystem geladen.

Die Vorteile dieses kombinierten Konzepts bestehen darin, daß

• Agentengattung und Agenteninstanz unabhängig voneinander authentisiert werden können.

• das Vertrauen zu Agentengattungen in Abhängigkeit des Speicherorts der Gattungsdaten formuliert werden kann.

• die Konformität zum MASIF-Standard gewahrt bleibt.