Copyright, 2002 © Michael Sonntag WWW: Mag. Dipl.-Ing. Dr. Michael Sonntag Netzwerke und Agenten Kommunikation zwischen Agenten, Sicherheit

Michael Sonntag2 Netzwerke und Agenten Fragen? Bitte gleich stellen! ? ? ? ? ? ?

Michael Sonntag3 Netzwerke und Agenten Inhalt l Kommunikation zwischen Agenten èAllgemeines, Klassifikation, Ontologien èEigentliche Agenten-Kommunikationssprachen »FIPA, KQML èSprachen zur Wissensdarstellung »RDF, (DAML) DAML+OIL »Dublin Core l Sicherheitsaspekte èWer muß wovor geschützt werden, Sicherheitsmodelle èAngriffe auf Agentensysteme èAbwehrmöglichkeiten

Michael Sonntag4 Netzwerke und Agenten Agenten-Kommunikation Allgemeines (1) l Wichtig für Agenten èEine Definition: Kommunikativität ist einziges Merkmal l Problem: Gemeinsames Verständnis èSyntax wichtig, sonst unverständlich »Syntax kann abstrakt beschrieben werden –Meta-Syntax, Meta-Meta-Syntax, … »Meist kein so großes Problem; Konversionen möglich èSemantik muß aber auch festgelegt werden! »Sehr schwer abstrakt zu beschreiben! –Sehr komplex, vielschichtig, Umgebungsabhängig,... »Meist nur eine umgangssprachliche Beschreibung –Für Computer ungeeignet!

Michael Sonntag5 Netzwerke und Agenten Agenten-Kommunikation Allgemeines (2) l Resultat des Semantik-Problems: èMeist genaue Beschreibung der Syntax èZusätzlich Umschreibung der jeweiligen Bedeutung èVersuch, Vor-/Nachbedingungen exakt zu definieren l Beispiele: èHTML/XML/… - Standards »Syntax exakt; Bedeutung in Worten dabei

Michael Sonntag6 Netzwerke und Agenten Agenten-Kommunikation Klassifikation (1) l Eigentliche Agenten-Kommunikationssprachen èEntworfen speziell mit Agenten im Hintergrund èKommen oft aus Entwicklung von Agentensystemen èMeist prozedural èEher Anwendungsbezogen l Sprachen zur Wissensdarstellung èKommen aus dem Bereich der KI èDienen dazu, Wissen auszutauschen/speichern èMeist funktional èEher abstrakt/mathematisch

Michael Sonntag7 Netzwerke und Agenten Agenten-Kommunikation Klassifikation (2) l Gemischtes èAllgemeine Protokolle, die auch von Agenten zur Kommunikation benutzt werden »Feste Anwendungsprotokolle, die auch von Agenten bedient werden; z. B. SMTP, HTTP,... èRahmen-Sprachen »Beschreiben nicht den eigentlichen Inhalt sondern die Art der Kommunikation bzw. den Kommunikationsablauf; z. B. SOAP

Michael Sonntag8 Netzwerke und Agenten Agenten- Kommunikationssprachen l Was ist alles nicht enthalten: èPhysische Übertragung »Protokoll hängt vom Agentensystem ab (idealerweise!) èAdressierung »Namensverzeichnis, …: Agentensystem –Meist wird eine einheitliche eindeutige ID vorausgesetzt èBedeutung (zumindest nicht des Inhalts) »Hängt vom einzelnen Agenten bzw. der Applikation ab »Sollte so allgemein sei, daß alles mitgeteilt werden kann èSchnittstelle »Wie werden Nachrichten abgeschickt?

Michael Sonntag9 Netzwerke und Agenten Agenten- Kommunikationssprachen l Was ist enthalten: èSyntax der Nachrichten »Wie werden Nachrichten ausgebaut, welche Zeichensätze sind erlaubt, wie werden Länge/Ende gekennzeichnet,... èGrundlegende Felder »Zeit, Weg, … enthalten oder muß dies in die Nachrichten hinein? èZusatzfunktionen »Protokollierung, garantierte Zustellung, Wiederholungen, … »Digitale Signaturen, Verschlüsselung èKommunikationsmodell »Synchron oder Asynchron? l Allgemeine Abgrenzung aber schwierig!

Michael Sonntag10 Netzwerke und Agenten Ontologie - Was ist das??? l Basis-Vokabular : Bedeutung der Wörter : Regeln für Bedeutung von Wort-Kombinationen l Ermöglicht Unabhängigkeit von konkreten Systemen, da einmal allgemein definiert èEs existieren aber viele Alternativen zu jedem Gebiet! l Befaßt sich immer nur mit einem relativ kleinen Bereich für eine einzelne Anwendung l Beschreibt die Interpretation einer Nachricht

Michael Sonntag11 Netzwerke und Agenten Ontologie-Beispiel l Ontologie 1 (Beleuchtung): èBirne (=Leuchtkörper) èEinsetzen (=montieren) èBirne einsetzen (=in die Fassung einschrauben; geht nur, wenn Fassung vorhanden ist und keine Strom) l Ontologie 2 (Garten): èBirne (=Obstbaum) èEinsetzen (=pflanzen) èBirne einsetzen (=Baum pflanzen; geht nur zu bestimmter Jahreszeit)

Michael Sonntag12 Netzwerke und Agenten KQML Grundstruktur (1) l Basiert auf performatives: Anweisungen, etwas bestimmtes zu tun èDies sind die erlaubten Einflußmöglichkeiten auf andere Agenten èSprech-Akt-Theorie èUnterteilt in Gruppen l Zur Unterstützung der Zusammenarbeit dienen Facilitators: èVerzeichnis von Agenten èNachrichten-Weiterleitung èFinden von Agenten mit bestimmten Fähigkeiten

Michael Sonntag13 Netzwerke und Agenten KQML Grundstruktur (2) l Basiert auf dem BDI-Modell èPerformatives sollten beliefs oder goals sein l Kann mit jeder Ontologie verwendet werden l Syntax ist ähnlich zu LISP l Protokolle werden NICHT beschrieben, nur die Nachrichten, die verwendet werden èAusnahme: Fehler-Rückmeldung (Nicht verstanden) l Benötigt zusätzlich eine Sprache (Ontologie) für den Anwendungs-Inhalt der Nachrichten èZ. B. KIF (Knowledge Interchange Format)

Michael Sonntag14 Netzwerke und Agenten KQML Grundstruktur (3) l Eigentlicher Nachrichten-Inhalt: Ausdrücke èIn einer nicht näher spezifizierten Sprache, Syntax, Semantik! èOntologie ist explizit bei jeder Nachricht anzugeben l Keine globale Wahrheit èJeder Agent besitzt seine eigene Weltanschauung èDiese kann sich von der anderer Agenten unterscheiden èGegenseitige Beeinflussung durch Mitteilungen »Müssen aber nicht ernstgenommen werden!

Michael Sonntag15 Netzwerke und Agenten KQML Performatives - Gruppen l Discourse èAnfragen: ask-if, ask-one, ask-all,... èMitteilungen: tell, untell, insert, uninsert, … èBefehle: achieve, unachieve, … èEreignisse: advertise, unadvertise, subscribe,... l Intervention and Mechanics èFehler, Warten, Bereit,... l Facilitation and Networking èRegistrieren bei Namensserver (ID + Fähigkeiten) èAnfragen nach passenden Agenten

Michael Sonntag16 Netzwerke und Agenten KQML Einzelne Performatives l ask-if: èFragt den Empfänger ob der Ausdruck für ihn wahr ist èEntweder als Faktum oder mit seinem Wissen beweisbar l tell: èTeilt dem Empfänger mit, daß der Ausdruck für den Sender wahr ist l insert (rein intern): èEmpfänger soll Ausdruck als wahr akzeptieren l achieve (Umgebungs-Beeinflussung): èEmpfänger soll den Ausdruck zu erreichen versuchen

Michael Sonntag17 Netzwerke und Agenten KQML Beispiel l Drehzahl neu stellen (Lüfter 1, 3500 U/min) (achieve:senderA :receiverB :in-reply-toid1 :reply-withid2 :languageProlog :ontologymotors :contentspeed(fan1,35) ) l Antwort (nach Vollzug) (tell:senderB :receiverA :in-reply-toid2 :reply-withid3 :languageProlog :ontologymotors :contentspeed(fan1,35) )

Michael Sonntag18 Netzwerke und Agenten FIPA Grundstruktur l FIPA: Umfassende Menge an Spezifikationen èAnalog zu KQML, basiert auch auf performativen èString-Darstellung fast identisch! èDarstellungen in XML, Binärformat, … definiert l Jedoch andere Performative èBedeutung wird auch mathematisch beschrieben (eigenes sematisches Modell) l Grundidee: Agentensystem-Interoperabilität l Namensdienst, etc. erfolgt NICHT über performatives, sondern über das API! »D. h. kein eigener Agent dafür; sondern im System integriert

Michael Sonntag19 Netzwerke und Agenten FIPA Nachrichtenelemente (1) l performative: Zweck/Typ der Nachricht l sender, receiver: Absender, Empfänger èSpezifikation für Agenten-Benennung existiert l reply-to: An wen geantwortet werden soll l content: Eigentlicher Nutzinhalt l language: Sprache des Inhalts èWelcher Parser für den Inhalt benötigt wird (Prolog, …) l encoding: Codierung des Inhalts èWie Inhalt aufgebaut ist: Unicode, Zeichensatz, Binhex,... l ontology: Bedeutungszusammenhang des Inhalts

Michael Sonntag20 Netzwerke und Agenten FIPA Nachrichtenelemente (2) l protocol: Spezifiziert das verwendete Protokoll èz. B. sind bestimmte Auktionen fest definiert l conversation-id: Eindeutige Instanz-Nummer èGleiches Protokoll mit gleichem Agenten: Neue Nummer l reply-with, in-reply-to: Nachrichten-ID für Verkettung èVereinfacht Verfolgung gleichzeitiger Kommunikationen l reply-by: Spätester Zeitpunkt für eine Antwort èSpätere Antworten werden ev. nicht mehr berücksichtigt èZeit aus Sicht des Senders (keine globale Zeit)!

Michael Sonntag21 Netzwerke und Agenten FIPA Nachrichtentypen l Agree: Zustimmung, eine Aktion auszuführen l Call for proposal: Anfrage nach Lösungen für einen Ausdruck (Art öffentl. Ausschreibung) l Confirm: Information, daß ein Ausdruck wahr ist èSender ist überzeugt: Daß es wahr ist, daß Empfänger unsicher, und daß Empfänger akzeptieren sollte l Inform: Ähnlich wie confirm èAber Empfänger-Unsicherheit wird nicht vorausgesetzt l Not understood: Nachricht unverständlich l Request: Bitte zur Ausführung einer Aktion

Michael Sonntag22 Netzwerke und Agenten FIPA Beispiel l Anfrage: Welche Dienste bietet Agent j an? (query-ref:sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content ((all ?x (available-service j ?x)))) l Antwort: Agent j kann Flüge, Zugplätze und Autos reservieren (inform:sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content ((= (all ?x (available-service j ?x)) (set(reserve-ticket train) (reserve-ticket plane) (reserve automobile))))) l Ereignis-Abonnement: (subscribe:sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content ((iota ?x (= ?x (xch-rate EUR USD)))))

Michael Sonntag23 Netzwerke und Agenten l Format für Metadaten èHauptsächlich für WWW gedacht, aber universell einsetzbar; jetzt WWW nur mehr ein kleiner Teil l Hängt stark mit XML zusammen (=Repräsentation) èXML + Schema (Datentypen) + Namespaces l Formale Semantik èErlaubt Einsatz von Inferenz-Regeln (Ableitung neuen Wissens aus Summe von bekanntem) l RDF Schema: KEIN Vokabular! èTypsystem, um Vokabulare zu definieren! RDF Grundstruktur (1)

Michael Sonntag24 Netzwerke und Agenten l Basiert vollkommen auf Tripeln èSubject, Predicate, Object l Subjekt und Objekt werden durch URI identifiziert èURL (Uniform Resource Locator): Webadresse èURI (Uniform Resource Identifier): Kann alles bezeichnen; muß keine Webadresse sein! »Einzelne Knoten können auch unbenannt bleiben l Container: Um mehrere Objekte einfach zusammenzufassen (Bag, Sequence, Alternative) RDF Grundstruktur (2) SubjektObjekt Eigenschaft

Michael Sonntag25 Netzwerke und Agenten l Aufbau von Statements: è ……… l Statements können zusammengefaßt werden èVerkürzung der Schreibweise èKönnen jederzeit wieder expandiert werden RDF Aufbau Subjekt Eigenschaft Objekt

Michael Sonntag26 Netzwerke und Agenten RDF Beispiel Die Resource wurde von der Person mit der Nummer erstellt. Der Name dieser Person ist Michael Sonntag und diese hat die Adresse Michael Sonntag Verkürzte Form: <s:Creator rdf:resource=" v:Name=Michael Sonntag /> S OP O S P

Michael Sonntag27 Netzwerke und Agenten RDF Reification l Statements über Statements: èAussage: Michael hat diese Webseite erstellt èSusi sagt, daß Michael diese Webseite erstellt hat Michael Susi

Michael Sonntag28 Netzwerke und Agenten RDF Schema (1) l Etwas anderes als XML Schema! èSpezifiziert nicht die Struktur, sondern die Bedeutung! l Objektorientierter Aufbau: Klassen und Vererbung èBasis: Resource (ALLES ist eine Ressource) èClass: Eine Klasse »Ableitungen: subClassOf èProperty: Eigenschaften einer Klasse »Spezialisierung: subPropertyOf –Bsp: biologischerVater ist Spezialisierung von biologischemElternteil l Grundsätzlich Mehrfachvererbung möglich

Michael Sonntag29 Netzwerke und Agenten RDF Schema (2) l Einschränkungen (Constraints) èrange: Aus welcher/n Klasse()n die Werte einer Eigenschaft stammen können èdomain: Zu welchen Klassen eine Eigenschaft gehören kann l Kommentare möglich (comment, label) l Modell-Elemente (Reification): èStatement, subject, predicate, object, Container,... l Erweiterungen: Zusätzliche Eigenschaften werden festgelegt èBeispiel: DAML+OIL

Michael Sonntag30 Netzwerke und Agenten RDF Schema Beispiel Klasse: Product An item sold by ACME Widgets Inc. Eigenschaft: Product Number Instanz: Mega Widget V10 08/15

Michael Sonntag31 Netzwerke und Agenten DAML Grundstruktur l DAML = DARPA Agent Markup Language l Erweiterung von XML und RDF l Grundgedanke: Aus einzelnen Fakten und Regeln lassen sich automatisch neue Fakten ableiten èBeispiel (Fakten): MutterVon subpropertyOf ElternteilVon Maria MutterVon Herbert èBeispiel (Resultat): Maria ElternteilVon Herbert l In XML würde dies von der Applikation abhängen und wäre NICHT in XML codiert!

Michael Sonntag32 Netzwerke und Agenten DAML+OIL Was kommt dazu? l OIL = Ontology Inference Layer èKardinalität: Eine Person kann nur einen Vater haben –minCardinality, maxCardinality,... èTransitivität von Eigenschaften (Vorfahre) –TransitiveProperty, UniqueProperty èMehrere Elemente bezeichnen dasselbe »Äquivalente Klassen und äquivalente Instanzen –sameClassAs, samePropertyAs, sameIndividual As èNeue Klassen aus Vereinigung/Schnittmenge von Klassen –unionOf, intersectionOf, complementOf,...

Michael Sonntag33 Netzwerke und Agenten DAML+OIL Datentypen (1) l Basis: Thing èJedes Objekt ist davon abgeleitet (Ur-Basisklasse) l Eigentliche Datentypen werden nicht definiert; XML-Schema hierzu verwenden èSowie zusätzlich die selbst definierten! l Beispiel oben (RDF): Produktnummer könnte beliebiger String sein; sollte aber Nummer sein! è Product Number

Michael Sonntag34 Netzwerke und Agenten DAML+OIL Datentypen (2) l Enumeration: Verfügbarbeit ist entweder InStock, BackOrdered oder SpecialOrder, aber nichts anderes! In stock Back ordered Special order

Michael Sonntag35 Netzwerke und Agenten DAML+OIL Klassen Erweiterungen (1) l Klassen haben hier wenig mit Objektorientierung zu tun; sie sind vielmehr ähnlich der Mengenlehre! èEs gibt Vererbung (oben nach unten; Spezialisierung) »Agent; Subklassen: LokalerAgent, MobilerAgent »Acess; Subklassen: HardwareAccess, LimitedAccess, NoAccess èEs gibt aber auch Aggregation (unten nach oben)! »HardwareInterface = LokalerAgent UND HardwareAccess l Mehrfachvererbung möglich und wichtig! »LokalerAgent Subklasse von Agent und (ev.) von HardwareInterface

Michael Sonntag36 Netzwerke und Agenten DAML+OIL Klassen Erweiterungen (2) l Disjoint Classes (Klassen mit getrennten Instanzen) èEin Agent ist entweder lokal oder mobil, aber niemals beides! Agent An software agent in our agentsystem. Mobile agent An agent able to move between agentsystems. Local agent An immobile agent, which always stays within the same agentsystem

Michael Sonntag37 Netzwerke und Agenten DAML+OIL Klassen Erweiterungen (3) l Unions (Vereinigungen): èEin Objekt gehört einer Klasse an, wenn es entweder der einen oder der anderen Klasse angehört »TrustedAgent = LokalerAgent unionOf CertificateChecked l Intersection (Schnittmenge): èEin Objekt gehört genau dann einer Klasse an, wenn es allen Teilklassen zugehört »HardwareInterface = LokalerAgent intersectionOf HardwareAccess

Michael Sonntag38 Netzwerke und Agenten DAML+OIL Eigenschaften Erweiterungen l Inverse Properties: èNur eines muß spezifiziert (bei Instanzen) werden, das andere wird automatisch abgeleitet »ElternteilVon inversePropertyOf KindVon l Transitive Properties: èGilt über mehrere Stufen (wie subclassOf) »P MitgliedVon VereinA, VereinA MitgliedVon VereinB »Daher ist P MitgliedVon VereinB l Restrictions (besser: Klassifizierungen): èAlle Objekte mit best. Eigenschaften gehören zu Klasse »Alles was das Attribut hasGUI hat und bei dem dieser Wert true ist, gehört zur (jetzt definierten) Klasse interactive

Michael Sonntag39 Netzwerke und Agenten OWL: Nachfolger von DAML+OIL l OWL Web Ontology Language l Bisher nur Entwurf l Sehr ähnlich zu DAML+OIL èNur leichte Änderungen l Vereinfachte Version (OWL Lite) existiert zur leichteren Implementierung èBeschwerden über zu hohe Komplexität von DAML+OIL, die Implementierungen sehr schwer macht!

Michael Sonntag40 Netzwerke und Agenten Dublin Core Grundstruktur l Webbasierte Beschreibung von Dokumenten èMetadaten über Dokumente; im Web suchbar èDie Dokumente selbst müssen NICHT im Web sein! l Besteht aus 15 Elementen mit definierter Semantik l Web-Dokumente: Oft als META Tag im Header èOder als eigene XML-Dateien l Unabhängig von RDF èKönnen aber gemeinsam verwendet werden l Spezialisierungen für einige Elemente möglich èz. B. Description: TableOfContents, Abstract èz. B. Date: Created, Valid, Available, Issued, Modified

Michael Sonntag41 Netzwerke und Agenten Dublin Core Elemente (1) l Title: Offizielle Benennung der Ressource l Creator: Person, die hauptsächlich für die Erstellung verantwortlich war l Subject: Inhalt der Ressource (Schlüsselwörter) l Description: Beschreibung des Inhalts l Publisher: Verantwortlich für Zugänglichmachung l Contributor: Wer Beiträge zum Inhalt geliefert hat l Date: Datum im Lebenszyklus der Ressource èIn der Regel das Erstellungsdatum èFormat nach ISO 8601 (YYYY-MM-DD)

Michael Sonntag42 Netzwerke und Agenten Dublin Core Elemente (2) l Type: Software, Text, Audio, … l Format: Medientyp, Abmessungen, … (z. B. MIME-Typ) l Identifier: Eindeutige Referenz (z. B. URI) in Kontext èKontext selbst wird aber nicht spezifiziert! l Source: Wovon die Res. abgeleitet ist (Vorversion) l Language: Sprache (z. B. de-at) l Relation: Verwandte (wie auch immer) Ressource l Coverage: Gültigkeitsbereich è Geograph. Bereich, Zeitperiode, Zuständigkeit,... l Rights: IPR, Copyright, DRMS,...

Michael Sonntag43 Netzwerke und Agenten Dublin Core Beispiel (1) Metadaten zum WeLearn-System auf den FIM-Webseiten: <rdf:RDF xmlns:rdf=" xmlns:dc=" WeLearn - Web Environment for Learning The WeLearn Team Online learning platform, E-Learning An online platform for learning. Handling is similar to webpages. Contains mainly resources and communication elements (e. g. forums) InteractiveResource de-at

Michael Sonntag44 Netzwerke und Agenten Dublin Core Beispiel (2) l Probleme erkennbar am obigen Beispiel: èNur ein Creator möglich èWas bedeutet das Datum? l Spezialisierung könnte helfen èDeren Codierung ist aber noch nicht spezifiziert! èVorschlag dafür existiert »Ausgiebige Verwendung von RDF; recht komplex l Sonstige Probleme: èWie bringen wir das ins Web? »Als Meta-Tags in der Webseite: Wartung? »Eigene Datei: Webseite abfragen und dann erst Verweis auf Metadaten erhältlich (Verweis ist selbst Meta-Tag) èTeile der Daten stehen auch so ev. bereits auf Webseite!

Michael Sonntag45 Netzwerke und Agenten Sicherheitaspekte: Mobilität (1) Ê Schutz des Rechners vor Agenten èSandbox, Code-Verifikation Ë Schutz der Agenten vor dem Rechner èSEHR schwierig; derzeit keine Lösungen »Ansätze: Verschleierung des Programms, spätere Nachprüfung Mobilität bedeutet Gefahren für beteiltigte Komponenten:

Michael Sonntag46 Netzwerke und Agenten Sicherheitaspekte: Mobilität (2) Ì Schutz der Agenten voreinander èMeist kein Problem; ergibt sich aus Rechnerschutz Í Schutz einer Gruppe von Rechnern èAngriffe: z. B. Ressource-Exhaustion èAbhilfe: Verzeichnisdienste und übergreifende Kontrolle Î Schutz von Rechnern untereinander èKein Agenten-spezifisches Problem; Agentensystem / Kommunikation kann aber weiterer Angriffspunkt sein! Ï Schutz einer Gruppe von Agenten èAngriffe: Diskriminierung (einzelnen Verzögern) èErkennung: Kommunikation zwischen den Agenten

Michael Sonntag47 Netzwerke und Agenten Angriffsarten: Bereicherung/Schädigung l Bereicherung (Rationale Angreifer; Diebe) èRückabwicklung eventuell möglich èKosten des Angriffs wichtig èErkennung oft ausreichend èSicherung relativ einfach ( Angriff verteuern) l Schädigung (Irrationale Angreifer; Terroristen) èRückabwicklung unmöglich èAngriffskosten großteils egal èEchte Vorbeugung/Verhinderung erforderlich èSicherung sehr schwer ( Jede Lücke stopfen) l Praxis: Abschätzung Gefahr / Kosten

Michael Sonntag48 Netzwerke und Agenten Angriffsarten: Extern / Intern l Extern: èKein Vertrauen gegenüber dem Angreifer èErringen neuer Rechte èIdentifikation schwer èKein Zugriff auf die Person l Intern: èDem Angreifer wird vertraut èAusnützen/erweitern bestehender Rechte èIdentifikation eher einfach èHaftung aus bestehendem Verhältnis (z. B. Arbeitsvertrag) èTypisch: Mitarbeiter

Michael Sonntag49 Netzwerke und Agenten Angriffsarten: Datenveränderung l Mit Datenveränderung èPrüfsummen/Signaturen zur Erkennung »Einfach bei statischen Daten (Programmcode, Initialisierung) »Schwierig bei dynamischen Daten (Agenten-Zustand) èNachweis oft einfach èSchwierigkeit bei mobilen Agenten: Urheber »Hand-off von Agenten l Ohne Datenveränderung èBeispiel: Zeitverzögerung, Ausspähen, Agenten-Kopien, Kommunikationsunterbrechung,... èErkennung sehr schwer èNachweis oft fast unmöglich

Michael Sonntag50 Netzwerke und Agenten Angriffsarten: Kurzfristig / Langfristig l Kurzfristige Angriffe èAbhilfe: Anomalitäten erkennen »Schwierig, da keine Historie vorhanden! »Insgesamt leichter, da meist große Anomalitäten nötig èMeist eher mit Gewalt oder recht offensichtlich l Langfristige Angriffe èZuerst Vertrauen erreichen, dann zuschlagen èVersuchen, Spuren zu verwischen èAbhilfe: Anomalitäten erkennen »Leichter, da viel Historie vorhanden »Trotzdem viel schwerer erkennbar als oben, da genau geplant und meist nur kleine Anomalitäten erforderlich

Michael Sonntag51 Netzwerke und Agenten Angriffsarten: Einzeln- / Gruppenangriffe èSowohl bezüglich Agenten als auch Rechner! l Einzelangriffe èEinfach; klassischer Fall èEinmaliger Fehler kann auch echter Fehler sein l Gruppenangriffe èKeine Fluchtmöglichkeiten, keine Vergleichswerte »Auf allen Rechnern gleich; alle Agenten agieren gleich èKomplex zu bewerkstelligen èGehäuftes Fehlverhalten fällt leichter auf »Aber bei vielen Mitwirkenden reichen geringe Fehler

Michael Sonntag52 Netzwerke und Agenten Sicherheitaspekte: Ausgewählte Angriffe (1) l Abhören des Agenten-Transfers èAgent inaktiv; auf Agentensystem angewiesen èAbhilfe: Verschlüsselung der Übertragung »Problem: Man-in-the-middle Angriff: Gegenstelle erkennen l Kopieren von Agenten èDurch externen Angreifer (Replay) »Seriennummern in Übertragung einbauen »Verschlüsselung èDurch Agentensystem »Wie Veränderungen des Agenten selbst »Erlaubt spätere Analyse und nachspielen/experimentieren

Michael Sonntag53 Netzwerke und Agenten Sicherheitaspekte: Ausgewählte Angriffe (2) l Behinderung / Denial of Service èDerzeit keine Ressourcen verfügbar »Praktisch nicht zu erkennen! èGefahr besonders bei Zeitlimits: Verzögern èVorteil von mobilen Agenten: Ausweichen ev. möglich l In-/Output Modifikation èFür Agenten nur zu erkennen, wenn von wirklicher Quelle signiert èBehinderung: Eigenen Output verschlüsseln/signieren »Rechner muß zuerst den Schlüssel aus dem Programmcode extrahieren bevor er fälschen kann! èVor-Filterungs Agenten sorgfältig auswählen!

Michael Sonntag54 Netzwerke und Agenten Abwehrmöglichkeiten: Sichere Hardware l Tamper-proof box: Sehr selten, extrem teuer èWird beim öffnen zerstört (zumindest Teile davon) l In praktisch keinem Rechner vorhanden l Einziger wirkliche Schutz von Agenten vor Rechner »Aber nicht gegen Ein-/Ausgabe-Modifikation! l Besseres Software-Äquivalent: èAgenten nur auf solche Rechner verlagern lassen, deren Besitzern vertraut wird! »Zertifikate sagen idR über so ein Vertrauen NICHTS aus! èDann sind fast keine Sicherheitsvorkehrungen mehr nötig »Die Vorhandenen sind dann meistens eher Schutz vor Fehlern!

Michael Sonntag55 Netzwerke und Agenten Abwehrmöglichkeiten: Time-limited security l Programmcode und/oder Daten werden verschleiert (Obfuscation) l Bei bestimmter Rechnerleistung kann meist eine Untergrenze angegeben werden, die für die Entschlüsselung mindestens nötig ist l Bis dahin ist der Agent sicher èSpätestens hier muß er von dem Server wegwandern l Probleme: èUm so öfter verwendet, desto kürzer! èKeine Implementierung bekannt èKein Schutz geheimer Daten (später IST Lesen möglich!)

Michael Sonntag56 Netzwerke und Agenten Abwehrmöglichkeiten: Übetragungs-Verschlüsselung l Für Kommunikation und Agenten-Transfer l Meist kann eigener Transfer nicht überwacht werden èVertrauen in Agentensystem nötig! l Man-in-the-middle Angriffe beachten! èZertifikate austauschen, diese überprüfen èKenntnis des privaten Schlüssels prüfen èGemeinsamen Schlüssel berechnen (z. B. Diffie-Hellman) èAgent transferieren l Problem: Was, wenn Empfänger nicht verschlüsseln kann/will? èDem Agenten bleibt nur mehr die Heimkehr!

Michael Sonntag57 Netzwerke und Agenten Abwehrmöglichkeiten: Code-Signaturen l Code kann signiert werden: Feststellung, vom wem èWird das Besitzer-Zertifikat mitsigniert, so kann auf Übereinstimmung geprüft werden »Vor-/Nachteil: Jeder kann sich selbst zum Signator machen! èFunktioniert auch für Initialisierungs-Daten l Überprüfung muß durch Agentensystem erfolgen l Problem bei Laufzeit-Daten (bzw. Ergebnissen) »Privater Schlüssel müßte mitgeführt werden: SEHR gefährlich! èHand-off: Agentensystem signiert Daten beim Verlassen èSpätere Änderungen nicht möglich, nur Hinzufügen èFeststellung möglich, wo Fehler/Modifikation passiert ist

Michael Sonntag58 Netzwerke und Agenten Abwehrmöglichkeiten: Sandbox l Analog zu Java Sandbox »Und vielfach darauf basierend! l Möglichkeiten an Aktionen für Agenten werden stark eingeschränkt èz. B. kein ungeprüfter Datei-/Netzwerkszugriff èVerlassen des Sandbox für Agenten selbst unmöglich l Können recht sicher erstellt werden (da rel. klein) l Problem: Vieles benötigt dennoch Sonderrechte èWie überprüfe man, wem man Rechte gibt? èWer bekommt welche Rechte? èWie können diese Rechte auf Teile beschränkt werden?

Michael Sonntag59 Netzwerke und Agenten Sicherheitaspekte: Zusammenfassung l Sandbox + Kommunikations-Verschlüsselung + Partner-Identifikation = Ausreichend für Rechner èEventuell: Code-Signaturen + Hand-off zusätzlich l Vertrauenswürdiger Recher = Meist ausreichende Sicherheit für Agenten l Erforderlich: èPKI (um Zertifikate prüfen zu können) èSandbox (muß Teil des Betriebssystems oder der Sprache sein) èVerschlüsselungs-/Signatur Software èVertrauens-Informationen