In diesem Abschnitt wird festgelegt, welche Entitäten des MASA-Modells aus Kapitel 3.1 authentisierbar sind, und von welchen Entitäten dieses durchgeführt wird.
Für eine erfolgreiche Authentisierung muß eine der folgenden Voraussetzungen erfüllt sein:
Alle unmittelbar handelnden Entitäten lassen sich verallgemeinert als Klasse von Subjekten verstehen. Darunter fallen alle Personen, sowie Agenteninstanzen und Agentensysteme. In Anlehnung an die Terminologie des CORBA Security Service werden diese als Principals bezeichnet. Da für ein sicheres SmA alle Handlungen autorisiert werden müssen, folgt daraus unmittelbar, daß es möglich sein muß alle Principals zu authentisieren.
Um die Authentisierung von Principals durchführen zu
können, müssen diese zunächst mit einem eindeutigen Identifikator versehen
werden. Tabelle 3.1 gibt einen solchen
Identifikator bereits für nahezu alle Typen an.
Für die noch ausstehende Klasse der Personen erscheint eine Kombination von Namen und organisatorischer Klassifizierung ausreichend, um diese hinreichend identifizieren zu können. Der Distinguished Name (DNDN!Distinguished Name) des X.500 Standards ([X.500]) gibt ein Beispiel hierfür an.
Neben dem gemeinsamen Attribut Identifikator aller
Principals, müssen die Subtypen Agentensystem und
Agenteninstanz noch mit weiteren Attributen versehen werden, um ihre
Beziehungen zu Personen des Modells herzustellen.
Für Agentensysteme und Agenteninstanzen sind jeweils die Authority und der Implementierer zu betrachten. Dabei kann die Authority einer Agenteninstanz selbst wiederum eine Agenteninstanz, ein Agentensystem oder eine Person, also ein Principal, sein. Die Authority eines Agentensystem kann dagegen nur eine Person sein. Ein Implementierer kann ebenfalls nur vom Typ Person sein.
Um der Mobilität von Agenteninstanzen Rechnung zu tragen, muß die Historie einer Agenteninstanz betrachtet werden. Hierzu muß eine Liste von besuchten Agentensystemen als Attribut einer Agenteninstanz hinzugefügt werden.
In Abbildung 5.5 sind
Klassenbeziehungen und Attribute in einem UML5.1-Diagramm
UML!Unified Modelling Language zusammengefaßt. Es
beschreibt die Klassenhierarchie durch Generalisierungen, sowie die
typisierten Attribute der einzelnen Klassen durch Assoziationen.
Dabei geben die Pfeilspitzen der Assoziationen die Richtung an, in der
diese sichtbar ist. D.h. beispielsweise, daß aus Sicht eines
Agentensystems die Person, die als Authority auftritt, definiert ist.
Aus Sicht der Person aber kann nicht unmittelbar bestimmt werden, für
welche Agentensysteme sie als Authority fungiert.
Agentengattungen sind selbst zwar keine handelnden Entitäten, dennoch muß ihre Unveränderlichkeit sichergestellt werden. Dabei muß auch nachvollziehbar sein, durch welche Person eine Agentengattung erstellt worden ist. Durch den Implementierer einer Gattung läßt sich in der Autorisierung nämlich ableiten, inwieweit man einer Agenteninstanz überhaupt vertrauen kann, weil der Implementierer, als ``Bürge für die Korrektheit'', als vertrauenswürdig eingestuft werden muß (vgl. Abschnitt 5.6).
Erreicht wird die Zuordnung des Implementierers, indem die Daten der Agentengattung durch ihn digital signiert werden.
Applets müssen entweder von Anwendern authentisiert werden, nämlich dann, wenn sie Agenteninstanzen steuern wollen, oder von Agenteninstanzen, wenn eine Aktion im Auftrag eines Applets ausgeführt werden soll.
Anwender können Applets authentisieren, wenn ihr Code digital signiert wurde, man bezeichnet diese dann auch als SignedApplets. Die gängigen Webbrowser bieten hierzu entsprechende Benutzerschnittstellen an. Sieht man Applets als Teil der Agentengattung, sind sie bereits signiert und damit für den Anwender authentisierbar.
Für Agenteninstanzen besteht aber keine Möglichkeit die Authentizität eines Applets zu überprüfen, da
Hieraus resultiert ein zum gegenwärtigen Zeitpunkt nicht lösbares Sicherheitsproblem. Es ist nämlich denkbar, daß beispielsweise ein feindliches Applet auf einem Browser mit Wissen des Anwenders zum Einsatz kommt, welches unerwünschte Aktionen gestattet. Auf diese Problematik wird in Kap. 8 noch eingegangen.
Aus der Sicht des Anwenders ist also die Authentisierung von Applets geklärt. Aus der Sicht von Agenteninstanzen soll sie nicht weiter betrachtet werden. Dies bedeutet jedoch nicht, und das sei hier betont, daß ein Anwender, der ein Applet steuert, ebenfalls nicht authentisiert werden kann. Da dies durch die oben aufgezeigte Authentisierbarkeit von Personen möglich ist, relativiert sich das Problem aus Sicht der Agenteninstanz, weil mit dem Anwender der ursächlich Verantwortliche der durch das Applet übermittelten Aktion, sicher identifiziert werden kann.
Eine ähnliche Situation zeigt sich bei den Endsystemen und den Client-Systemen. Für ein Agentensystem oder eine Agenteninstanz kann keine plattformübergreifende Möglichkeit vorausgesetzt werden, ein entferntes Endsysteme bzw. Client-Systeme direkt zu authentisieren. Die Authentisierung von Endsystemen muß deshalb mittelbar über das entfernte Agentensystem vorgenommen werden. Das entfernte Agentensystem fungiert dann als Stellvertreter für das Endsystem. Diesem Agentensystem muß somit insofern vertraut werden, als das von ihm angegebene Endsystem tatsächlich jenes ist, auf dem das Agentensystem abläuft.
Da auf Client-Systemen keine Entität existiert, die stellvertretend ihre Authentisierung übernehmen könnte, muß diese unterbleiben. Es sei ausdrücklich erwähnt, daß der Webbrowser über keine Möglichkeiten zur Authentisierung seines Client-Systems verfügt. Ebenso sind IP-Adressen keine sicheren Identifikatoren für Client-Systeme, da diese durch Techniken wie Proxies, Firewalls oder Network Address Translation (NATNAT!Network Address Translation) (sogar gewollt) verändert werden können.
Endsysteme und Client-Systeme werden deshalb, ebenso wie Applets, für
die Authentisierung aus der Sicht von entfernten Entitäten nicht
weiter betrachtet.
Somit verbleiben folgende Klassen von Entitäten für die weiteren Betrachtungen: Agenteninstanzen, Agentensysteme und Personen, alle zusammengefaßt unter der Superklasse Principal. Um nun die Authentizität des Identifikators eines Principals belegen zu können bieten sich Public-Key-Verfahren, wie im Folgenden beschrieben, an.
Seien Principals nun mit einem Schlüsselpaar, bestehend aus dem geheimen und dem öffentlichen Schlüssel, ausgestattet.
Nachdem jeder Principal eindeutig identifiziert werden kann und Eigentümer eines Schlüsselpaares ist, kann daraus ein Zertifikat gebildet werden. Dies geschieht, indem die Entität ihren Identifikator mit ihrem geheimen Schlüssel unterzeichnet, woraus eine zugehörige Signatur entsteht. Das 3-Tupel aus Identifikator, Signatur und öffentlichem Schlüssel ist dann das Zertifikat der Entität.
Damit kann ein Kommunikationspartner den ersten Schritt einer Authentisierung durchführen. Bekommt er nämlich den Identifikator, die Signatur des Identifikators und den öffentlichen Schlüssel übermittelt, kann er feststellen ob der Identifikator vom Eigentümer des zum öffentlichen Schlüssel gehörigen privaten Schlüssels unterzeichnet worden ist.
Somit reduziert sich das Problem der Authentisierung auf die Frage, ob das verwendete Schlüsselpaar tatsächlich zu jenem Principal gehört, dessen Identifikator unterschrieben worden ist. Dieses Problem wird durch Zertifikatketten gelöst. Wurde nämlich das Zertifikat des zu überprüfenden Principals durch ein anderes Principal signiert, so steht dieser als Bürge für die Echtheit des fraglichen Zertifikats mit seinem eigenen Zertifikat ein. Da das Zertifikat des Bürgen wiederum signiert sein kann, entsteht eine Zertifikatkette. Vertraut die überprüfende Instanz einem Zertifikat aus dieser Kette, so ist die Authentisierung des fraglichen Principals gelungen.
Um nun alle Principals des Modells authentisieren zu können genügt es also
Damit können dann Agentensysteme, Agenteninstanzen und jegliche Personen auf der Basis von vertrauenswürdigen Zertifikaten authentisiert werden.
Außerdem wurde damit auch eine Voraussetzung für die
abhörgesicherte Kommunikation zwischen Principals
geschaffen, da die Schlüsselpaare der Principals für eine
chiffrierte Kommunikation nach Abschnitt 5.4
verwendet werden können.
Die Ausstellung von Zertifikaten und die Errichtung einer Vertrauensbeziehung darüber ist an zwei Bedingungen gebunden, die zwar einfach zu formulieren, im Fall SmA aber teilweise schwierig zu realisieren sind:
Punkt 1 wird mit den in Abschnitt 5.5.1 vorgestellten Identifikatoren für die Lebensdauer aller Principals gewährleistet.
Punkt 2 ist für den Fall von realen Personen trivial.
Zum Beispiel kann der private Schlüssel mittels eines Paßworts
chiffriert werden, wobei dieses Paßwort dann nur dem Eigentümer des
Schlüssels bekannt ist.
Ebenso kann ein Agentensystem seinen privaten Schlüssel schützen, indem er in einem Bereich abgelegt wird, der für Agenteninstanzen und Personen nicht zugänglich ist. Im wesentlichen ist dieser Fall äquivalent zu einem klassischen Anwendungsprogramm, welches mit kryptographischen Schlüsseln arbeitet.
Für Agenteninstanzen kann Punkt 2 allerdings nicht
gewährleistet werden. Da Agenteninstanzen ohne interaktive Eingriffe von
Personen handlungsfähig sein sollen, ist die Verwendung von
paßwortgeschützter Schlüssel nicht praktikabel. Ebenso kann eine
Agenteninstanz
ihren privaten Schlüssel nicht durch Ablage in einem gesicherten
Bereich schützen, da sie völlig unter der Kontrolle des
Agentensystems steht. Damit hat das Agentensystem aber auch Zugriff
auf den geheimen Schlüssel der Agenteninstanz.
Dies wäre solange unproblematisch, solange die Agenteninstanz auf einem vertrauenswürdigen Agentensystem abläuft. Migriert sie aber auf ein Agentensystem mit feindlichen Absichten, kann dieses den privaten Schlüssel auslesen und für eigene oder fremde Attacken nutzbar machen. So könnten feindliche Entitäten ihre Identität fälschen, oder an Informationen gelangen, die für die Entschlüsselung durch den privaten Schlüssel chiffriert wurden.
Weiterhin macht es keinen Sinn den privaten Schlüssel während einer Migration mit sich zu führen, da dieser ansonsten abgehört werden kann, wenn ein Kanal ungesichert ist.
Aus diesen Gründen muß also für Agenteninstanzen ein Weg gefunden
werden, wie diese mit Schlüsselpaaren versorgt werden, deren
Vertrauenswürdigkeit gewährleistet werden kann.
Hierzu bietet sich das Agentensystem als Indirektionsstufe an. Agentensysteme erfüllen die Punkte 1 und 2. Diese können nun
Um die Vertrauenswürdigkeit des Sitzungszertifikats überprüfen zu können, müssen dann die folgenden Schritte durchgeführt werden:
Mit dem Gelingen von Schritt 3 ist das Sitzungszertifikat einer Agenteninstanz erfolgreich überprüft und damit die Identität der Instanz gesichert, wobei das Agentensystem als Bürge darüber auftritt. Schlägt dagegen einer der genannten Schritte fehl, so kann die Agenteninstanz nicht authentisiert werden, und folglich ist diese als nicht vertrauenswürdig einzustufen, da möglicherweise ein Angriffsversuch vorliegt.
Der Nachteil dieses Verfahrens besteht darin, daß sich, obwohl die Identität einer Agenteninstanz während seines Lebenszyklus unverändert bleibt, das Zertifikat mittels dessen er sich authentisiert sehr wohl verändert, was zu einem erhöhten Aufwand bei der Authentisierung führt.
Ausgehend davon, daß Schlüsselpaare auch zur Chiffrierung auf Kanälen benutzt werden, birgt das vorgestellte Verfahren allerdings auch einen Vorteil. Betritt nämlich eine Agenteninstanz ein bösartiges Agentensystem, welches ihren privaten Schlüssel zum Zweck des Abhörens der Kommunikation preisgibt, so wird zwar jegliche Kommunikation abhörbar, migriert die Instanz aber auf ein anderes, ``gutes'' Agentensystem, ist ihre Kommunikation wieder abhörsicher, da sie dort mit einem neuen Schlüsselpaar versehen wird und somit der alte private Schlüssel wertlos wird. Damit ist die Kommunikation der Agenteninstanz zumindest nur zeitweise ungeschützt.
Unter den oben vorgestellten Randbedingungen wird nun ein Verfahren vorgestellt, wie in einem SmA Zertifikate erstellt, und davon abgeleitet, ihre Vertrauenswürdigkeit überprüft werden kann.
Das Zertifikat für die Authority eines Agentensystems muß ``out of band'' erteilt werden. Dies bedeutet, daß ein solches Zertifikat nicht durch eine Entität des SmA selbst erstellt werden kann. Ein solches Zertifikat könnte beispielsweise durch eine bereits bestehende Zertifizierungshierarchie erstellt werden. In Abb. 5.7 wird dies angenommen.
Die ``out of band''-Verteilung begründet sich damit, daß alle Zertifikate für Agentensysteme und Agenteninstanzen direkt bzw. indirekt auf dem Zertifikat einer Authority eines Agentensystems basieren. Würde das Authority-Zertifikat selbst aus einem Teil des SmA generiert werden, würde es zu einem ``Kreisschluß'' in den Zertifikatketten kommen, womit keinen Vertrauensbeziehungen mehr aufgebaut werden könnten.
Damit kann nun das Zertifikat eines einzelnen Agentensystems erstellt werden:
Die sich aus diesem Verfahren ergebende Zertifikatkette ist in Abb. 5.8 dargestellt. Somit wird die Authority eines Agentensystems immer durch das vorletzte Zertifikat in der Zertifikatkette des Agentensystems definiert.
Wird eine Agenteninstanz auf einem Agentensystem erzeugt, muß ein neues Sitzungszertifikat für die Instanz erstellt werden:
Nun besitzt die Agenteninstanz ein neues Sitzungszertifikat, aus deren zugehöriger Zertifikatkette aus Abb. 5.9 sich die Identitäten
ersehen lassen.
Ebenso wie Zertifikate für die Authority des Agentensystems, werden Zertifikate für Implementierer und Anwender von Agenten nicht von Agentensystemen oder Agenteninstanzen erzeugt, sondern werden in der Regel ``out of band'' von unabhängigen Instanzen generiert und ausgestellt.
Dies kann wiederum durch eine unabhängige Zertifizierungshierarchie geschehen. Während das Zertifikat der Authority des Agentensystems aber nicht von einem Teil des SmA selbst generiert werden kann, ist es für die Zertifikate von Implementierern und Anwendern möglich, eine Zertifizierungshierarchie zu benutzen, die als Dienst im SmA selbst verankert ist (vgl. Abschnitt 5.5.5).
Arbeitet man mit Zertifikaten, stellen sich unmittelbar weitere Fragen, die die Gültigkeit von Zertifikaten betreffen.
Läuft ein Zertifikat ab, benötigt aber der Eigentümer weiterhin ein Zertifikat, muß er von der ausstellenden Entität ein neues, bzw. verlängertes Zertifikat anfordern.
Somit stellt sich die Frage, wie ein solches Zertifikat im SmA widerrufen werden kann. Ein Widerruf durch eine nachträgliche Veränderung der im Zertifikat verzeichneten Gültigkeitsdauer ist ausgeschlossen, da diese selbst Teil des unveränderlichen Zertifikats ist. Somit muß eine Möglichkeit geschaffen werden, wie Listen von nicht mehr vertrauenswürdigen Zertifikaten im SmA verteilt werden. Solche Listen werden als Certificate Revocation List (CRLCRL!Certificate Revocation List) bezeichnet.
Ansätze für die Verteilung von CRLs könnten beispielsweise sein:
Selbstverständlich sind auch Mischformen dieser Ansätze denkbar.
Weiterhin sind im Hinblick von Sicherheitseigenschaften die Frage zu klären, welche Entitäten überhaupt berechtigt sind, ein Zertifikat zu widerrufen, und welche Folgen dies für den Eigentümer des Zertifikats hat. Daß hierüber ebenfalls eine entsprechende Sicherheitsarchitektur zu formulieren ist, wird unmittelbar aus einem Beispiel klar: Durch den unberechtigten Widerruf eines Zertifikats, z.B. eines Agentensystems, kann sehr leicht eine DoS-Attacke durchgeführt werden, da mit dem Widerruf des Zertifikats das Agentensystem nicht mehr authentisiert werden kann.
Die Fragen wie CRLs sinnvoll verteilt werden, die Sicherheitsarchitektur von CRLs, sowie unter welchen Umständen neue Zertifikate erteilt werden, erfordern weitere Untersuchungen, die an dieser Stelle jedoch unterbleiben.
Beispielsweise ist denkbar, daß zum Zweck des Logging die Sitzungszertifikate von Agenteninstanzen in einem zentralen Repository hinterlegt werden.
Dies führt unmittelbar zum Begriff eines Zertifikatservers, der diese
Aufgaben übernehmen kann. Weiterhin könnten dort Schnittstellen zur
Verifikation von Zertifikaten (inklusive eines Abgleichs mit den im
Zertifikatserver ebenfalls verwalteten CRLs), und zur Erstellung von
Personenzertifikaten angeboten werden.
Kombiniert man solche Zertifikatserver führt dies wiederum zu einer klassischen CA-Infrastruktur.
Eine genaue Betrachtung dessen, wie ein solcher
Zertifikatserver aufgebaut sein muß, seiner Sicherheitseigenschaften
und des Aufbaus von CA-Hierarchien oder der Möglichkeit der
Kombination mit bestehenden CA-Infrastrukturen, wird an dieser Stelle
nicht weiter durchgeführt.
Mit den in diesem Abschnitt vorgestellten Verfahren lassen sich alle unmittelbar handelnden Entitäten (Principals) anhand eines Zertifikats authentisieren. Unter Einbeziehung der in den vorangegangenen Abschnitten gewonnenen Erkenntnisse ergibt sich zusammengefaßt das in Tabelle 5.1 dargestellte Bild. Zur Vereinfachung wurde für den Fall, daß Personen als Authentisierende auftreten, diese nicht detailliert aufgelistet, da es dann unerheblich ist, in welcher Rolle eine Person agiert.
Aus Tabelle 5.2 ist ersichtlich, welche Entitäten eigene Zertifikate besitzen und wie diese erhalten werden können. Daraus läßt sich ablesen, daß fundamentale Informationen, wie z.B. die Authority einer Agenteninstanz, nur indirekt über das Agentensystem gewonnen werden können, da diese nur als Attribute einer Klasse verfügbar sind. Entscheidend für die Sicherheit eines SmA ist also die Vertrauenswürdigkeit des Agentensystems.
Zwar kann beispielsweise das Zertifikat der Authority einer Agenteninstanz durch einen Anwender überprüft werden, indem der Anwender manuell in der Zertifikatkette nach für ihn vertrauenswürdigen Unterzeichnern sucht. Dabei muß er aber die Gewißheit haben, daß das Agentensystem das zu untersuchende Zertifikat korrekt übermittelt hat.
|
![\begin{figure}
\centering\includegraphics [width=0.8\textwidth]{principals1_illu_argo}\end{figure}](roel99-img14.gif)
![\begin{figure}
\centering\includegraphics [width=0.8\textwidth]{principals2_illu_argo}\end{figure}](roel99-img15.gif)
