Entwicklung einer Abstraktionsschicht für regelbasierte Expertensysteme am CERN Grid-Cluster

Fachbereich Elektrotechnik und Informatik Bachelorarbeit Entwicklung einer Abstraktionsschicht für regelbasierte Expertensysteme am CERN Grid-Cluster Frank Iker 19. September 2008 Betreuer: Prof. Dr. rer. nat. Nikolaus Wulff

Danksagung Mein besonderer Dank gilt Herrn Prof. Dr. rer. nat. Nikolaus Wulff, ohne dessen Unterstützung dieses Projekt nicht zu Stande gekommen wäre. Des Weiteren bedanke ich mich bei Dipl. Physiker Tobias Henß, der mir stets mit konstruktiver Kritik helfend zur Seite stand. Auch möchte ich mich im Besonderen bei meinen Eltern Margarete und Otto Kremer für ihre Unterstützung bedanken. Abschließend danke ich meinem guten Freund Christoph Zuleger für das Korrekturlesen meiner Arbeit. i

Inhaltsverzeichnis Danksagung i 1 Einleitung 2 1.1 Motivation.................................... 2 1.2 Aufbau...................................... 2 1.3 Kontext..................................... 3 1.4 Die Expertensysteme.............................. 5 1.4.1 Pixel Advisor.............................. 5 1.4.2 GridXP................................. 7 2 Aufgabenstellung 8 2.1 Anforderungen................................. 8 3 Grundlagen 10 3.1 Regelbasierte Expertensysteme........................ 10 3.1.1 JBoss Rules/Drools........................... 12 3.2 Sichere Kommunikation im Internet...................... 13 3.2.1 Kryptographische Hashfunktionen................... 14 3.2.2 Asymmetrische Verschlüsselung.................... 14 3.2.3 Zertifikate................................ 15 3.2.4 Der X.509 Standard.......................... 16 3.2.5 Authentisierung und verschlüsselte Kommunikation durch SSL... 17 4 Entwurf 22 4.1 Architektur................................... 22 4.2 Anwendungsfälle und Detailanforderungen.................. 22 5 Implementierung 26 5.1 Die SSL Infrastruktur.............................. 26 5.1.1 Trust- und KeyManager........................ 26 5.2 Das Kommunikationsprotokoll......................... 27 5.2.1 Die Nachrichtenklassen......................... 29 5.3 Der Server.................................... 33 5.3.1 Der ClientHandler........................... 33 ii

5.3.2 Der Sendecache............................. 33 5.4 Der Client.................................... 35 6 Anpassung des GridXP Expertensystems an die UnifiedXP Architektur 36 7 Fazit und Ausblick 39 Eidesstattliche Erklärung Abkürzungsverzeichnis Literaturverzeichnis ii iv vi 1

1 Einleitung Im Rahmen dieser Arbeit wird die Entwicklung einer Client-Server Architektur als Teil eines Expertensystems beschrieben, die eine beidseitige Authentisierung und verschlüsselte Kommunikation bietet. 1.1 Motivation An der Universität Wuppertal wurden die beiden Expertensysteme Pixel Advisor und GridXP zunächst voneinander unabhängig entwickelt. Obwohl deren Einsatzgebiete unterschiedlich sind, gab es einige grundlegende Gemeinsamkeiten, die die Überlegung nahelegten, eine vereinte Softwarebasis für beide Systeme zu entwickeln. Zusammen mit den beiden ursprünglichen Entwicklern arbeiteten mein Kommilitone Dennis Huning und ich an dieser Aufgabe. Während der Schwerpunkt meiner Arbeit in der Entwicklung der Client-Server Architektur und des Netzwerkprotokolls lag, entwickelte Dennis Huning im Rahmen seiner Bachelorarbeit die GUI 1 Applikation, die wiederum meine Client Komponente zur Kommunikation mit dem Server benutzt. 1.2 Aufbau Zunächst folgt eine kurze Einführung in den Kontext, in dem diese Arbeit entstanden ist, sowie eine Beschreibung der Funktionsweise und Einsatzgebiete der beiden Expertensysteme Pixel Advisor und GridXP. Im Kapitel Grundlagen wird die für diese Arbeit wichtige Klasse der regelbasierten Expertensysteme genauer betrachtet. Anschließend wird die Rule Engine JBoss Rules/Drools vorgestellt, die ein wesentlicher Bestandteil der beiden oben genannten Systeme ist. Danach wird dargestellt, wie eine sichere Kommunikation 1 Graphical User Interface 2

zwischen einem Client und Server innerhalb eines Netzwerkes mit Hilfe des SSL Protokolls ermöglicht werden kann. Im Kapitel Entwurf werden die Detailanforderungen an die Softwarekomponenten und der Architekturentwurf beschrieben. Die Umsetzung dessen, sowie eine ausführliche Funktionsbeschreibung der Komponenten folgt im Kapitel Implementierung. Im Anschluss daran wird auf die Anpassung des GridXP an die neuen Softwarekomponenten eingegangen, welches letztlich die Anwendung der erarbeiteten, UnifiedXP genannten, Architektur bedeutet. Der letzte Teil bildet ein persönliches Fazit und ein Ausblick auf mögliche Erweiterungen des Systems. 1.3 Kontext Das in der Nähe von Genf in der Schweiz gelegene, europäische Kernforschungszentrum CERN 1 beschäftigt ca. 2500 Mitarbeiter. Darüber hinaus arbeiten etwa 8000 Gast-Wissenschaftler an den Experimenten zur Erforschung physikalischer Grundlagen. Das CERN besitzt den weltweit größten Teilchenbeschleuniger LHC 2. Er liegt 100 Meter unter der Erde und besteht zum größten Teil aus einem Ring von supraleitenden Magneten. Der Umfang des Ringes beträgt 27 km. Wenn der LHC im September 2008 seinen Betrieb aufnimmt, werden dort entweder Protonen oder Bleikerne auf gegenläufigen Bahnen beschleunigt und nach erreichen einer Energie von 7 TeV bzw. 575 TeV zur Kollision gebracht. An jedem Kollisionspunkt befindet sich ein Detektor, der die durch den Aufprall entstehenden Teilchen registriert. Es gibt vier Hauptdetektoren, ALICE 3, ATLAS 4, CMS 5 und LHCb 6, sowie zwei kleinere, TOTEM 7 und LHCf 8. Der größte Detektor ist ATLAS (Abbildung 1.1). Er ist 45 m lang, 25 m hoch und hat ein Gewicht von 7000 Tonnen.[9] Sein Aufbau besteht im Wesentlichen aus vier Komponenten: Innerer Spurdetektor zur Messung des Impulses geladener Teilchen Kalorimeter zur Messung der Teilchenenergie 1 Conseil Européen pour la Recherche Nucléaire (Europäische Organisation für Kernforschung) 2 Large Hadron Collider 3 A Large Ion Collider Experiment 4 A Toroidal LHC ApparatuS 5 Compact Muon Solenoid 6 Large Hadron Collider beauty 7 TOTal Elastic and diffractive cross section Measurement 8 Large Hadron Collider forward 3

Myon Detektor zur Identifizierung von Myonen Magnet System zur Krümmung der Teilchenbahnen Abbildung 1.1: Der ATLAS Detektor [1] In unmittelbarer Nähe zum Teilchenstrahl befindet sich ein Halbleiter Pixeldetektor. Er ist 1,3 m lang und hat einen Durchmesser von 30 cm. Der Pixeldetektor wurde maßgeblich an der Universität Wuppertal von der Gruppe Prof. Dr. Mättig entwickelt. Er besteht aus drei tonnenförmigen Lagen um die Strahlachse herum, sowie aus drei Scheiben an beiden Enden senkrecht zur Achse. Auf den Lagen und Scheiben befinden sich Module, die Siliziumsensoren enthalten. Diese Sensoren registrieren durch sie hindurchfliegende geladene Teilchen, wodurch dann deren Flugbahn bestimmt werden kann. Der Detektor besitzt ca. 80 Millionen dieser sogenannten Pixel.[9] Die von den Detektoren erzeugten Datenmengen stellen auf Grund ihrer Größe eine besondere Herausforderung an die Computerinfrastruktur dar. Nach seiner Inbetriebnahme wird der LHC etwa 15 Millionen Gigabyte pro Jahr an Daten erzeugen. Das entspricht einer Menge von 1,7 Millionen DVDs jährlich. Anstatt ein einziges zentrales Rechenzentrum zu verwenden, um diese Daten auszuwerten, wurde beim LHC ein anderer Ansatz gewählt. Bei diesem als Grid-Computing bezeichneten Verfahren werden Großrechner an verschiedenen Orten so verbunden, dass sie von den Benutzern wie ein einziger Supercomputer verwendet werden können. Der Benutzer meldet sich an einem als Interface fungierendem Rechner an und übermittelt an diesen seine Berechnungsaufgaben 1. Der Resource Broker 2 entscheidet 1 Ein einzelner Auftrag für eine Berechnung wird auch mit dem englischen Begriff Job bezeichnet. 2 Der Begriff entspricht dem in der Grid Middleware verwendeten englischen Nomenklatur und wird hier 4

Abbildung 1.2: Der Pixeldetektor [1] dann, wo im Grid Verbund die Berechnungen ausgeführt werden. 1.4 Die Expertensysteme Die für den Pixeldetektor und das LHC Grid entwickelten Expertensysteme wurden in der Programmiersprache Java implementiert. Sie gehören zu den sogenannten regelbasierten Systemen, d.h. ihr Kernbestandteil ist eine Regelmaschine 1, die eingegebene Daten an Hand von Wenn-Dann Regeln verarbeitet. Diese liegen in textueller Form, getrennt vom übrigen Programmcode vor. Beide Systeme verwenden die Open Source Rule Engine JBoss Rules/Drools und besaßen in ihrer ursprünglichen Form nur eine rudimentäre GUI. 1.4.1 Pixel Advisor Pixel Advisor ist das Expertensystem für den ATLAS Pixeldetektor. Die Entscheidung ein Expertensystem zu verwenden wurde auf Grund von zwei Faktoren getroffen: Ein Datenverlust durch Fehler im Detektorsystem ist zu minimieren. Fehler müssen darum möglichst schnell behoben werden. darum nicht übersetzt. 1 englisch Rule Engine 5

Ein auf das jeweilige Fachgebiet spezialisierter Experte ist aber in der Regel nicht schnell verfügbar. Das Expertensystem kann unmittelbar erste Ratschläge und Hilfestellungen zur Ursachenbehebung geben. Abbildung 1.3: Datenquelle Pixel Advisor Automatisch gesteuert und überwacht wird der Detektor durch die auf PVSS 1 basierende Pixel FSM 2. Die Kommunikation zwischen Pixel Advisor und PVSS erfolgt mit dem am CERN entwickelten Netzwerkprotokoll DIM 3, für das auch eine Java Bibliothek (JDIM) existiert. Die Bandbreite an Daten, die über den PVSS-DIM Server ausgetauscht werden können, ist auf ca. 5000 Werte pro Sekunde beschränkt. Das Expertensystem muss sich diese Bandbreite mit anderen Nutzern der DIM Infrastruktur teilen, so dass es nicht möglich ist, gleichzeitig alle, der fast 32000 Parameter des Detektors als Datenquelle zu nutzen. Um den Datenfluss zu minimieren bedient es sich der Tatsache, dass die Bestandteile des Detektors hierarchisch in einer Baumstruktur angeordnet sind. Es überwacht zuerst nur die Zustände der obersten drei Hauptbestandteile. Im Fehlerfall fragt der Pixel Advisor rekursiv die Zustände der darunterliegenden Komponenten ab und traversiert den Baum solange, bis er das Ende eines Pfades erreicht, an dem sich ein Modul befindet, das einen physikalischen Messwert wie z.b. eine Temperatur oder Spannung liefert. Diese Messwerte werden dann wieder vom Expertensystem verarbeitet und als Basis für die an den Benutzer ausgegeben Lösungsvorschläge und Hinweise genutzt. 1 Von der ETM professional control GmbH entwickeltes Prozessvisualisierungs- und Steuerungssystem 2 Finite State Machine 3 Distributed Information Management 6

1.4.2 GridXP GridXP ist das Expertensystem für das LHC Grid. Es dient dazu, dem Grid Benutzer Informationen über nicht erfolgreich beendete Jobs zu liefern. Ohne GridXP erhält der Benutzer keine näheren Anhaltspunkte vom Grid Interface, warum ein Job fehlschlägt. GridXP hingegen kann Gründe für das Fehlschlagen benennen, Fehlermeldungen erklären, Ratschläge erteilen und Lösungsvorschläge bieten. Als Datenquelle dient die R-GMA 1 Datenbank. Das ist eine verteilte Datenbank, die von dem ebenfalls an der Universität Wuppertal entwickelten Job Execution Monitor (JEM) befüllt wird. Der in der Programmiersprache Python geschriebene JEM ersetzt dazu den ursprünglichen Job durch einen Wrapper. Dieser führt dann den eigentlichen, in der Regel aus einem Bash- oder Python-Skript bestehenden Job zeilenweise aus. JEM kann dadurch als Zwischenschicht zwischen der WorkerNode 2 und Job fungieren und hat dadurch die Möglichkeit, detailliert dessen Ausführung hinsichtlich gesetzter Umgebungsvariablen, der Rückgabewerte einzelner Befehle und des verfügbaren Speichers etc. zu protokollieren. Neben den vom JEM gelieferten Daten kann GridXP zusätzlich die zentrale SAM 3 Datenbank am CERN abfragen und sich Informationen über die im Grid angebotenen Dienste verschaffen. Abbildung 1.4: Datenquellen GridXP 1 Relational Grid Monitoring Architecture 2 Bezeichnung für einen einzelnen Rechner im Cluster-Verbund 3 Service Availability Monitoring 7

2 Aufgabenstellung Hauptziel ist, das durch die Verwendung einer gemeinsamen Softwarebasis beide Systeme langfristig profitieren werden. Die Wartung wird erheblich vereinfacht, da mit der Einarbeitung in die Funktionsweise eines der Expertensysteme auch schon Kenntnis über selbige des anderen erlangt wird. Außerdem wirkt sich eine Erweiterung des Funktionsumfanges auf beide Systeme aus. 2.1 Anforderungen Einige der Anforderungen an die Client/Server-Komponenten ergeben sich aus dem Funktionsumfang und Eigenschaften der ursprünglichen Expertensysteme. Diese müssen natürlich auch nach der Umstellung auf die neue Softwarearchitektur gewährleistet sein. Zusätzliche Funktionalität wird einerseits durch die Anforderungen der neuen GUI, andererseits durch den hinzugekommenen und vorher nicht vorgesehen Sicherheitsaspekt bestimmt. Dieser fordert eine sichere Identifikation des Servers und der Clients (bzw. Benutzer). Ausserdem ist eine verschlüsselte Kommunikation erforderlich. Architektur Die Serverkomponente muss so modular aufgebaut sein, das ein Austausch der Daten entnehmenden Komponente einfach möglich ist. Dadurch ist eine universelle Nutzung für verschiedene Expertensysteme gewährleistet. Das Netzwerkprotokoll und dessen Verarbeitung ist so zu gestalten, das zukünftige Erweiterungen der Funktionalität einfach zu realisieren sind. 8

Produktfunktionen Sicherheit: Gegenseitige Authentisierung von Client und Server, sowie Verschlüsselung der Kommunikation. Benutzergruppen: Erweiterte Funktionalität für Administratoren. Netzwerkbasierte Wartungs- und Steuerungsfunktionen. Technische Produktumgebung Software: Installierte Java 5 (oder höher) Laufzeitumgebung. Produktschnittstellen: X.509 Zertifikate und Schlüsseldateien im PEM Dateiformat. Werden Client- und Serverkomponente auf verschiedenen Rechnern betrieben, dann ist für den Server eine Netzwerkverbindung mit einem freien Port für eingehende TCP Verbindungen, für den Client eine Netzwerkverbindung für ausgehende TCP Verbindungen erforderlich. Entwicklungsumgebung Java JDK 5 oder höher Eclipse 3.3.2 mit SVN PlugIn OpenSSL (Für die Erzeugung von Test-Zertifikaten) Benutzungsoberfläche Für die Serverkomponente ist keine GUI vorgesehen, sie wird über die Kommandozeile gestartet. Die Clientkomponente ist keine eigenständige Software, sondern wird von der separat entwickelten GUI Applikation verwendet. 9

3 Grundlagen 3.1 Regelbasierte Expertensysteme Ein Expertensystem ist eine Software die versucht, das Wissen und die Erfahrung eines Experten zur Verfügung zu stellen. Das Expertensystem soll dem Anwender bei der Lösung konkreter Probleme oder der Einschätzung einer Situation helfen. Dabei ist die Kompetenz der Software, genauso wie die eines menschlichen Experten, auf eine bestimmte Wissensdomäne eingeschränkt. Die Hauptprobleme bei der Realisierung der Software liegen in der Akquirierung und Formalisierung des Wissens, so das es durch Softwarealgorithmen repräsentiert werden kann. Zur Modellierung des Expertenwissens können dabei verschiedene Ansätze gewählt werden. Etwa in Form einer Falldatenbank. Das System versucht dabei, ein dem Problem möglichst ähnlichen Fall auszuwählen und eine Lösung abzuleiten. Eine weitere Möglichkeit wäre die Repräsentation des Wissens als Entscheidungsbaum. Durch die Beantwortung von Fragen zum vorliegenden Problem, durchläuft das Programm einen Pfad des Baumes und gelangt schliesslich zu einem Endknoten, der dem aktuellen Fall entspricht. Eine weitere große Klasse, zu denen auch Pixel Advisor und GridXP gehören, bilden die regelbasierten Expertensysteme. Abbildung 3.1 zeigt die Bestandteile eines solchen Systems, dessen Kern die Inferenzmaschine 1 bildet. Die Datennahme liefert eine Beschreibung des zu lösenden Problems bzw. der aktuellen Situation in Form von, als Fakten bezeichnete Daten. Diese werden mit Hilfe der Regelbasis, die das Expertenwissen als sogenannte Produktionsoder Geschäftsregeln formuliert enthält, verarbeitet. Die Inferenzmaschine versucht zu einer Schlussfolgerung zu gelangen, die schließlich dem Anwender von der Benutzerschnittstelle präsentiert wird. 1 Inferenz [(lat. infero; hineintragen, folgern, schließen); (engl. inference; Rückschluss, Folgerung)] 10

Abbildung 3.1: Bestandteile eines regelbasierten Expertensystems 11

3.1.1 JBoss Rules/Drools JBoss Rules/Drools ist eine in Java geschriebene und unter der Apache Software License veröffentlichte Rule Engine, deren Architektur in Abbildung 3.2 dargestellt ist: RuleBase: Enthält die Regeln. WorkingMemory: Speichert die Fakten. PatternMatcher: Überprüft die gespeicherten Fakten auf Übereinstimmung mit den Bedingungsteilen der Regeln. Activation: Komposition aus zutreffender Regel und den dafür verantwortlichen Fakten. Agenda: Enthält die Liste der Activations und entscheidet über deren Ausführungsreihenfolge. Abbildung 3.2: Die JBoss Rules/Drools Architektur Im Folgenden soll die Benutzung der Rule Engine JBoss Rules/Drools veranschaulicht werden. Abbildung 3.3 zeigt den Inhalt der verwendeten Regeldatei rules.drl, die für dieses einfache Beispiel nur eine Regel enthält, sowie das Klassendiagramm der als Fakt benutzten Klasse. Damit die Rule Engine Fakten verarbeiten kann, müssen deren Klassen die Java Beans Spezifikation bezüglich der Getter und Setter Methoden erfüllen. Zuerst liest der PackageBuilder die Regeln aus der Datei: PackageBuilder b u i l d e r = new PackageBuilder ( ) ; b u i l d e r. addpackagefromdrl (new FileReader ( "rules.drl" ) ) ; Es wird eine neue Regelbasis erzeugt und die zuvor gelesenen Regeln werden hinzugefügt: RuleBase rulebase = RuleBaseFactory. newrulebase ( ) ; rulebase. addpackage ( b u i l d e r. getpackage ( ) ) ; 12

Die StatefulSession 1 bildet das Interface zum WorkingMemory. Jetzt können beliebig Fakten hinzugefügt, entfernt, oder das Feuern der Regeln ausgelöst werden: S t a t e f u l S e s s i o n workingmemory = rulebase. n e w S t a t e f u l S e s s i o n ( ) ; workingmemory. i n s e r t (new Fact ( 0, "abc" ) ) ; workingmemory. i n s e r t (new Fact ( 1, "def" ) ) ; workingmemory. i n s e r t (new Fact ( 2, "ghi" ) ) ; workingmemory. f i r e A l l R u l e s ( ) ; Wie erwartet haben zwei Fakten den Bedingungsteil der Regel erfüllt und der Java Programmcode wird für beide ausgeführt. Die Ausgabe lautet: number = 1 number = 0 t e x t = def t e x t = abc Abbildung 3.3: Beispiel für eine Regeldatei und UML Diagramm der verwendeten Klasse Eine ausführliche Dokumentation über die Rule Engine findet sich unter [4]. 3.2 Sichere Kommunikation im Internet Im Folgenden werden einige Grundlagen und Verfahren erklärt, die eine sichere Kommunikation in Computer-Netzwerken ermöglichen. Sicherheit umfasst hierbei eine gegenseitige Authentisierung der Kommunikationspartner und Erhaltung der Vertraulichkeit und Integrität der übermittelten Nachrichten. Zunächst werden die Eigenschaften kryptographischer 1 Alternativ lässt sich auch eine StatelessSession erzeugen, der alle Fakten auf einmal in Form einer Collection übergeben werden. Das Einfügen und Feuern der Regeln wird dann nacheinander für jedes Element ausgeführt. Nach Abarbeitung der Liste bleiben keine Referenzen auf die Fakten zurück. Eine StatelessSession hat also im Gegensatz zur StatefulSession kein Gedächtnis. 13

Hashfunktionen, asymmetrische Verschlüsselung mit öffentlichen und privaten Schlüsseln und digitale Zertifikate erklärt. Danach wird die Funktionsweise des SSL 1 Protokolls dargestellt. 3.2.1 Kryptographische Hashfunktionen Eine Hashfunktion h(x) ist ein Abbildung, die Informationen beliebiger Länge einen Wert fester Länge zuordnet. An eine kryptographische Hashfunktion werden dabei zusätzliche Anforderungen gestellt: 1. Einwegeigenschaft: Zu gegebenem h(x) ist es unmöglich 2 ein x zu finden, so dass gilt: h(x) = h(x ) 2. Einwegeigenschaft: Zu gegebenen x darf kein x x gefunden werden können, so dass gilt: h(x) = h(x ) Kollisionsfreiheit: Es ist unmöglich zwei beliebige x und x mit x x zu finden, so dass gilt: h(x) = h(x ) Bekannte und häufig verwendete kryptographische Hashfunktionen sind z.b. MD5 3 (Hashwertlänge 128 Bit) und SHA-1 4 (Hashwertlänge 160 Bit). 3.2.2 Asymmetrische Verschlüsselung Im Gegensatz zu symmetrischen Verschlüsselungsverfahren, bei denen beide Kommunikationspartner den gleichen geheimen Schlüssel benutzen um eine Nachricht zu ver- und entschlüsseln, kommen beim asymmetrischen Verfahren verschiedene Schlüsselpaare zum Einsatz. Beide Kommunikationspartner besitzen ein eigenes Schlüsselpaar, das aus einem privaten (Private Key) und einem öffentlichen Schlüssel (Public Key) besteht. Der öffentliche Schlüssel darf jedem zugänglich gemacht werden, der dem Besitzer des privaten Schlüssels eine verschlüsselte Nachricht schicken möchte. Die Nachricht wird mit diesem öffentlichen 1 Secure Sockets Layer 2 Unmöglich bedeutet hierbei, das es in der Praxis unmöglich ist, d.h. die Wahrscheinlichkeit eine Lösung zu erraten ist vernachlässigbar klein bzw. der Rechenaufwand alle Möglichkeiten auszuprobieren ist zu groß. 3 Message-Digest Algorithm 5 4 Secure Hash Algorithm-1 14

Schlüssel verschlüsselt und nur der Besitzer des privaten Schlüssels kann die Nachricht wieder entschlüsseln. Dabei Verhalten sich die Schlüssel eines Schlüsselpaares symmetrisch zu einander: Ebenso kann eine mit dem privaten Schlüssel verschlüsselte Nachricht nur mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsselt werden. Im Bereich der Internet-Security spielt das, nach seinen Entwicklern Ron Rivest, Adi Shamir und Leonard Adleman benannte, asymmetrische Verschlüsselungsverfahren RSA eine wichtige Rolle.[10] 3.2.3 Zertifikate Im Zusammenhang mit asymmetrischer Verschlüsselung und Authentisierung dienen Zertifikate dazu, einen öffentlichen Schlüssel eindeutig einem Eigentümer zu zuordnen. Der Eigentümer wird mit seinem sogenannten DN 1 identifiziert, der aus Angaben wie dem Namen, Land, Organisation (Firma) oder Emailadresse besteht. Die Zuordnung wird von einer dritten vertrauenswürdigen Instanz zertifiziert. Dazu nimmt die Zertifizierungsinstanz, auch CA 2 genannt, den öffentlichen Schlüssel des Eigentümers, den zu diesem Schlüssel zu zuordnenden DN, sowie weitere verfahrenstechnische Angaben und errechnet den Hashwert aller Daten. Dieser Hashwert wird dann von der CA mit ihrem privaten Schlüssel verschlüsselt. Der verschlüsselte Hashwert bildet damit eine sogenannte digitale Signatur. Die ursprünglichen Daten und die Signatur werden in der Zertifikatsdatei gespeichert und können an die Kommunikationspartner weitergegeben werden. Zur Verifikation entschlüsselt der Kommunikationspartner die Signatur mit dem öffentlichen Schlüssel der CA und gelangt damit an den ursprünglichen Hashwert. Danach errechnet er selbst den Hashwert dieser Daten und vergleicht, ob beide Werte übereinstimmen. Abbbildung 3.4 macht den Vorgang etwas anschaulicher und zeigt, wie das von der Certificate Authority für Kommunikationspartner A erstellte Zertifikat durch B verifiziert wird. Eine CA übernimmt damit eine Aufgabe, vergleichbar mit einer Behörde, die Ausweise ausstellt. Die zu signierenden Daten entsprechen den persönlichen Daten des Ausweisinhabers, seinem Foto und seiner Unterschrift. Die Signatur wäre in diesem Fall der Stempel der Behörde. Ein Zertifikat kann auch nacheinander von verschiedenen Stellen signiert werden. Jede zusätzliche Signatur bestätigt die Authentizität der direkt vorherigen. Dadurch entsteht ei- 1 Distinguished Name 2 Certificate Authority 15

Abbildung 3.4: Verifizierung eines Zertifikats ne sogenannte Zertifikatskette (Certificate Chain). Entscheidend ist, das am Ende der Kette eine vertrauenswürdige Instanz steht. Zur Authentifizierung der ursprünglichen Daten ist es notwendig, alle Signaturen dieser Kette in umgekehrter Reihenfolge zu verifizieren. Da das CA Zertifikat am Ende der Kette steht, ist es von der CA selbst signiert. Die besondere Funktion der CA Zertifikate macht es wichtig, diese auf einem sicheren Weg zu erhalten. Zertifikate bekannter kommerzieller CAs wie z.b. Thawte oder VeriSign sind in den Installationsdateien SSL fähiger Applikationen wie z.b. Internetbrowser enthalten. 3.2.4 Der X.509 Standard X.509 ist ein von der ITU-T 1 entwickelter Standard, der eine Infrastruktur zur Ausstellung, Verteilung und Prüfung digitaler Zertifikate beschreibt. Außerdem spezifiziert er einige Standard Zertifikatsformate. Für den Austausch der Zertifikate gibt es wiederum verschiedene Dateiformate. Abbildung 3.5 zeigt ein Zertifikat im PEM 2 Format, in dem sich alle im vorherigen Abschnitt angesprochenen Elemente wiederfinden: Der DN wird in einem X.509 Zertifikat mit Subject bezeichnet, der öffentliche Schlüssel folgt auf die Bezeichnung Subject Public Key Info und die Signatur der CA befindet sich zwischen den Markern BEGIN CERTIFICATE und END CERTIFICATE. Sie ist Base64 codiert. Base64 dient dazu, binäre Daten in sicher druckbaren Zeichen zu übertragen. Dazu werden jeweils drei Bytes nebeneinander zusammengefasst und in vier Einheiten zu 1 International Telecommunication Union - Telecommunication Standardization Sector 2 Privacy Enhanced Mail 16

je sechs Bits aufgeteilt. Dann wird jeder dieser Einheiten einer von 64 möglichen ASCII 1 Zeichen zugeordnet. Ein weiterer bekannter und von dem gleichnamigen Programm verwendeter Zertifikatsstandard ist PGP 2. Er wird vor allem in der E-Mail Kommunikation genutzt. Im Gegensatz zum X.509 Standard, bei der die Vertrauenswürdigkeit eines Zertifikates auf einer streng hierarchischen Struktur mit einer zentralen Zertifizierungsinstanz basiert, benutzt PGP das Prinzip des Web of Trust, also ein Netz von sich gegenseitig vertrauenden Instanzen. Jeder Knoten des Netzes besitzt einige wenige andere, denen er direkt vertraut. Indirektes Vertrauen zu allen restlichen Knoten entsteht dadurch, das er diese auf einem Pfad von sich direkt vertrauenden Knoten erreichen kann. 3.2.5 Authentisierung und verschlüsselte Kommunikation durch SSL Das 1995 von der Netscape Communications Corporation eingeführte Sicherheitsprotokoll SSL dient dazu, eine sichere Verbindung zwischen zwei Endpunkten im Internet herzustellen.[8] Häufig werden die Begriffe TLS 3 und SSL synonym verwendet, tatsächlich ist TLS aber eine Weiterentwicklung des älteren SSL Protokolls. Beide erfüllen folgende Merkmale: 1. Parameterabsprache zwischen Client und Server 2. Gegenseitige Authentisierung durch X.509 Zertifikate 3. Geheime Kommunikation durch symmetrische Verschlüsselung 4. Schutz der Daten vor Manipulation durch Bildung kryptographischer Hashwerte Wie man in Abbildung 3.6 sieht, ist SSL innerhalb des Internet Schichtenmodells zwischen der Anwendungs- und Transportschicht einzuordnen 4. Die Authentisierung des Clients ist optional und wird häufig nicht verwendet oder über andere Methoden wie etwa Passworteingaben realisiert. Meistens möchte man nur sicherstellen, das eine im Internetbrowser aufgerufene URL auch tatsächlich dem erwarteten Eigentümer gehört. Da innerhalb der UnifiedXP Architektur die Identifizierung und Authentisierung des Benutzers ebenfalls über Zertifikate erfolgt, seien im Folgenden die Vorgänge während eines SSL Handshake 1 American Standard Code for Information Interchange 2 Pretty Good Privacy 3 Transport Layer Security 4 Für gewöhnlich besteht das Internet Schichtenmodel nur aus der Anwendungs-, Transport-, Internetund Netzzugangsschicht. Manche Darstellungen lassen auch letztere weg. In diesem Fall wurde die Sicherheitschicht nur der Übersicht wegen zusätzlich eingefügt. 17

mit gegenseitiger Authentisierung beschrieben. Dazu lässt sich ein SSL Handshake grob in vier Phasen unterteilen: Phase 1 - Festlegung der Sicherheitsparameter Client und Server verhandeln untereinander die zu verwendenden kryptographischen Algorithmen. Die Menge der Algorithmen wird mit dem engl. Begriff Cipher Suite bezeichnet. Der Client schickt zuerst eine ClientHello Nachricht mit folgendem Inhalt: SSL Versionsnummer, vom Client unterstützte Cipher Suites, eine Session ID und eine Zufallszahl RNC 1, die sich aus einem 32-Bit-Wert für Zeit und Datum nach UNIX-Format und einem 28-Byte- Zufallswert zusammensetzt. Der Server antwortet mit einer ServerHello Nachricht. Diese beinhaltet: Die höchste von Client und Server unterstützte SSL Versionsnummer, vom Server gewählte Cipher Suite, eine Session ID und eine Zufallszahl RNS 2, analog der vom Client generierten. Phase 2 - Server Authentifizierung und Schlüsselaustausch Der Server schickt sein Zertifikat an den Client und verlangt von diesem mit einer CertificateRequest Nachricht ebenfalls die Zusendung des Client Zertifikats. Der Client verifiziert, ob das Serverzertifikat von einer von ihm akzeptierten CA ausgestellt wurde. Eine Server- HelloDone Nachricht des Servers schließt diese Phase ab. Phase 3 - Client Authentifizierung und Schlüsselaustausch Der Client schickt sein Zertifikate, welches vom Server verifiziert wird. Dieses Zertifikat wird nochmal vom Client signiert geschickt. Dadurch kann der Server nachprüfen, das der Client auch im Besitz des zugehörigen privaten Schlüssels ist. Schließlich generiert der Client eine weitere Zufallszahl, das sogenannte Pre-Master-Secret (PMS). Es wird mit dem öffentlichen Schlüssel des Server verschlüsselt und zu diesem gesendet. Aus dem Pre- Master-Secret und den vorher ausgetauschten Zufallszahlen berechnen Client und Server das Master-Secret (MS). Es bildet den gemeinsamen Schlüssel für die darauffolgende symmetrisch verschlüsselte Kommunikation. 1 Random Number Client 2 Random Number Server 18

Phase 4 - Beendigung des Handshake Abschließend senden beide Parteien eine ChangeCipherSpec und Finished Nachricht. Damit signalisieren sie sich gegenseitig, das sie jetzt auf symmetrische Verschlüsselung wechseln. Die Finished Nachrichten sind verschlüsselt und enthalten die in vorherigen Nachrichten ausgetauschten MACs 1, sowie einen Hashwert. Nach der Entschlüsselung können die Hashwerte jeweils vom Client und Server verifiziert werden. 1 Message Authentication Code 19

Abbildung 3.5: Beispiel eines X.509 Zertifikats im PEM Dateiformat 20

Schicht Anwendung Sicherheit Transport Internet Netzzugang Protokoll HTTP, FTP, DNS SSL TCP IPv4, IPv6 Ethernet Abbildung 3.6: SSL im Internet Protokollstapel Abbildung 3.7: SSL Handshake mit Client- und Server-Authentifizierung [11] 21

4 Entwurf 4.1 Architektur Jedes Expertensystem benutzt eigene Klassen zur Repräsentation der Fakten. Um eine universelle Basis zu schaffen, wurde die Klasse StoreableObject eingeführt, von denen sich diese Klassen ableiten müssen. Diese Abstraktion ist notwendig, da außer der Daten erzeugenden Komponente (innerhalb der UnifiedXP Architektur DataTaking genannt) und der Rule Engine, alle anderen Systembestandteile (inkl. der GUI) keine Kenntnis über faktenspezifische Eigenschaften besitzen. Zu den gemeinsamen Eigenschaften aller Fakten zählen: Zugehörigkeit zu einem bestimmten Benutzer Zeitstempel, der den Zeitpunkt der Erzeugung festhält eindeutiger, systeminterner Bezeichner boolescher Wert, der festlegt, ob das Objekt innerhalb der GUI angezeigt wird Bezeichnung des Objekts innerhalb der GUI Als Bindeglied zwischen DataTaking und Rule Engine dient eine Instanz der als Singleton implementierten StoreableObjectsSet Klasse. Sie besitzt einen eigenen Speicher, um zusätzlich benötigte Funktionalität zu ermöglichen. Dazu gehört z.b. das Selektieren aller StoreableObjects eines Benutzers. Zwischen dem StoreableObjectsSet und der Rule Engine besteht eine bidirektionale Verbindung: Einerseits werden Objekte von dem Set in das WorkingMemory eingefügt oder entfernt, andererseits können Regeln neue Objekte erzeugen, die zum Set hinzugefügt werden müssen. 4.2 Anwendungsfälle und Detailanforderungen Für die Netzwerkkommunikation wird das SSL Protokoll mit gegenseitiger Authentisierung durch Zertifikatsdateien benutzt. 22

Abbildung 4.1: Die UnifiedXP Architektur Client und Server akzeptieren nur Verbindungen mit Zertifikaten, die von einer ihnen vertrauenswürdigen Zertifizierungsstellen signiert worden sind. Die zur Überprüfung notwendigen Zertifikate der Zertifizierungstellen müssen sich in einem, in den Konfigurationsdateien festgelegtem Verzeichnis befinden. Zur Identifikation der Benutzer wird der in den Zertifikaten eingetragene DN genutzt. Zur Unterstützung des Login Mechanismus der GUI stellt der Client Funktionen bereit, um den DN eines Zertifikats auszulesen und um das Passwort einer privaten Schlüsseldatei zu überprüfen. Es gibt eine als Administratoren ausgezeichnete Benutzergruppe, für die die GUI zusätzliche Funktionen bietet. Ein Benutzer wird vom System als Administrator erkannt, wenn der DN seines Zertifikates in der Liste der Administratoren in der Serverkonfigurationsdatei eingetragen ist. Es können aber nicht mehrere Benutzer gleichzeitig als Administrator mit dem System verbunden sein. Ist schon ein Benutzer als Administrator angemeldet, so werden alle weiteren als normale Benutzer behandelt. Werden von der Daten liefernden Komponente neue Fakten zur Faktenbasis der Rule 23

Engine hinzugefügt, so informiert der Server die Clients darüber. Dabei wird zwischen Fakten unterschieden, die für alle Clients bestimmt sind, und solchen, die nur an den jeweils betroffenen Client geschickt werden dürfen. Lösen Fakten die Aktivierung einer Regel aus, dann werden die Clients ebenfalls darüber informiert. Der Client kann vom Server die aktuelle Regelbasis anfordern. Der Client kann dem Server eine neue Regelbasis schicken und veranlassen, das diese gegen die alte ausgetauscht wird. Das Sequenzdiagramm in Abbildung 4.3 zeigt die dazu nötigen Vorgänge aus Sicht des Servers. Der Client kann den Server veranlassen, sich zu beenden. Abbildung 4.2: Sequenzdiagramm zum Senden einer Nachricht 24

Abbildung 4.3: Sequenzdiagramm zum Austausch der Regelbasis aus Sicht des Servers 25

5 Implementierung Die UnifiedXP Implementierung besteht aus zwei getrennten Softwarekomponenten: Zum einen dem Server, der mit dem Daten liefernden Modul und der Rule Engine den eigentlichen Kern der Anwendung bildet, und zum anderen aus dem Client, der von der GUI Applikation für die Kommunikation mit dem Server genutzt wird. Diese stellt die Benutzerschnittstelle dar. 5.1 Die SSL Infrastruktur Zu den Elementen einer auf SSL basierten Kommunikation, gehören neben dem eigentlichen Kommunikationsprotokoll auch die zur Authentisierung notwendigen Zertifikate und privaten Schlüssel. Die Trust- und KeyManager Klassen bilden die Schnittstelle zu den Zertifikats- und Schlüsseldaten. 5.1.1 Trust- und KeyManager Standardmäßig nutzt Java zur Speicherung der Zertifikate und privaten Schlüssel jeweils ein eigenes Dateiformat. Die vertrauenswürdigen Zertifikate werden aus der als TrustStore bezeichneten Datei gelesen, das eigene Zertifikat und der dazugehörige private Schlüssel sind in der sogenannten KeyStore Datei hinterlegt. Um die Nutzung von Zertifikats- und Schlüsseldateien im PEM Dateiformat zu ermöglichen, war es notwendig eigene Implementierungen des Trust- und KeyStore zu verwenden. Die Klasse, die die Verwaltung der vertrauenswürdigen Zertifikate übernimmt, muss dazu das X509TrustManager Interface implementieren. Für die Bereitstellung der privaten Schlüsseldaten ist das X509KeyManager Interface verantwortlich. Für das Lesen der PEM Dateien habe ich die unter einer Public Domain Lizenz veröffentlichte Bouncy Castle Crypto Library verwendet.[5] Das ist eine in Java und C# geschriebene Bibliothek, die neben der eigenen Implementierung verschiedenster kryptographischer Algorithmen, zusätzlich Unterstützung bei der Erzeugung 26

Abbildung 5.1: Die Trust- und KeyManager Klassen und Verarbeitung von X.509 Zertifikaten bietet. In Javas Kryptographie Architektur werden diese Algorithmen in einem Cryptographic Service Provider zusammengefasst und zur Verfügung gestellt. Die Bouncy Castle Crypto Library macht von der Möglichkeit Gebrauch, den Standard Service Provider gegen eine eigene Implementierung auszutauschen. Dazu sind aber einige Konfigurationen in der Java Installation vorzunehmen, für die der Nutzer der UnifiedXP Architektur möglicherweise nicht die nötigen Rechte besitzt. Da die PEMReader Klasse den eigenen Provider nutzt, war es notwending, eine in diesem Punkt veränderte Version zu implementieren, die auf den Java Standard Provider zurückgreift. 5.2 Das Kommunikationsprotokoll Um ein Netzwerkprotokoll zu implementieren gibt es vielfältige Möglichkeiten. Die Programmiersprache Java bietet dazu mit seinen Systembibliotheken Unterstützung auf verschiedenen Abstraktionsleveln. Im folgenden Abschnitt werden zunächst mögliche Alternativen dargestellt, um dann die tatsächliche Realisierung zu beschreiben. Wenn die Anforderungen ein möglichst kompaktes Format erfordern, bei dem zur Strukturierung der Nutzdaten nur wenige zusätzliche Bytes erforderlich sind, dann bietet sich die 27

Codierung im TLV 1 Format an. Dabei wird zuerst eine konstante Anzahl Bytes übertragen, die den Typ und die Länge der nachfolgenden Daten angeben, gefolgt von einer variablen Anzahl Bytes, die die eigentlichen Nutzdaten beinhalten. Die Java Input-/OutputStream Klassen bieten dafür Methoden, mit denen Bytearrays direkt gelesen bzw. geschrieben werden können. Dieses Format ist sehr einfach zu parsen und lässt sich auch problemlos erweitern. Nicht benötigte oder unbekannte Datenblocktypen können mit Hilfe der Angaben in den Längenfeldern sehr einfach übersprungen werden. Ein Nachteil ist, das dieser Parser selbst implementiert werden muss. Ausserdem ist dieses Format für Menschen nicht leicht zu lesen, was im Fall der Fehlersuche ein weiter Nachteil ist. Dazu müssten dann zusätzliche Debuggingtools geschrieben werden, etwa in Form von PlugIns für den Netzwerk Protokoll Analyzer Wireshark. Abbildung 5.2: TLV Dateiformat Ist die Optimierung des Verhältnisses von Nutz- zu Gesamtdaten kein primäres Ziel und steht die Lesbarkeit der übertragenen Daten im Vordergrund, so bietet sich das XML 2 Format an. Abbildung 5.3 zeigt ein Beispiel für eine solche Datei. Java unterstützt dieses Format mit den DocumentBuilder und Document Klassen aus dem javax.xml.parsers und org.w3c.dom Packages. XML Dateien werden durch Instanzen der Document Klasse repräsentiert, die ein komfortables Auslesen und Manipulieren der Datenstruktur ermöglicht. Zum Lesen der Daten, aus dem Netzwerk oder einer Datei, kann der parse() Methode der DocumentBuilder Klasse eine InputStream Instanz übergeben werden. Zurückgeliefert wird ein Document Objekt im XML Format. Für das Serialisieren und Schreiben in einen OutputStream sorgt die XMLSerializer Klasse. XML zur Strukturierung der Daten eines Netzwerkprotokolls zu verwenden ist sicherlich eine gute Wahl, wenn es eine enge Verzahnung zwischen der Netzwerkkommunikation und Dateiaustausch mit anderen Programmen gibt. XML ist ein häufig genutzter Industriestandard für den es viele Tools zur Dateierzeugung und Verarbeitung gibt. Die einfachste und letztendlich gewählte Methode, Netzwerkkommunikation in den Pro- 1 Type Length Value 2 extensible Markup Language 28

Abbildung 5.3: Beispiel XML Datei grammfluss zu integrieren, bieten die Klassen ObjectOutputStream und ObjectInputStream. Sie sorgen für die Serialisierung bzw. Deserialisierung eines Java Objektes, wodurch dieses direkt geschrieben bzw. gelesen werden kann. Einzige Anforderung an das Objekt ist, das seine Klasse und rekursiv alle Klassen der Membervariablen das Marker-Interface Serializable implementieren. 5.2.1 Die Nachrichtenklassen Die Oberklasse aller Netzwerknachrichten ist die Message Klasse. Sie ist sehr einfach gehalten und enthält als Membervariablen nur einen String und den Aufzählungstypen Command. Letzterer gibt die Semantik der Nachricht an, an Hand dessen im Programmfluss entschieden werden muss, ob auf eine Unterklasse zu casten ist. Die Klassenhierarchie ist in Abbildung 5.4 dargestellt. 29

Abbildung 5.4: UML Klassenhierarchie Messages Im Folgenden werden alle Nachrichtenklassen mit ihren möglichen Command Werten aufgelistet und die daraus resultierende Bedeutung und Verwendungszweck erklärt: 30

Message INFO CONNECTED AS ADMIN INFO CONNECTED AS USER SHUTDOWN SERVER CLIENT DISCONNECT SERVER DISCONNECT GET EDITED RULES GET ACTIVATIONS GET UPDATE ALL GET UPDATE GET RULE BASE RESET Informiert den Client, das er als Admin verbunden ist. Der Server vergleicht dazu, ob der DN des Clients in der Konfigurationsdatei in der Liste der Admins steht. Außerdem darf nicht schon ein anderer als Admin angemeldet sein. Sollte das der Fall sein, so wird er als normaler Benutzer behandelt. Informiert den Client, das er als normaler Benutzer verbunden ist. Wird vom Client (Admin) gesendet, um den Server herunterzufahren. Client hat die Verbindung getrennt. Ist eine interne Nachricht, die nicht über das Netzwerk geschickt wird. Server hat die Verbindung getrennt. Ist eine interne Nachricht, die nicht über das Netzwerk geschickt wird. Client (Admin) fordert alle editierten Regeln an. Client fordert alle Aktivierungen an. Diese Nachricht wird nach der Anmeldung oder einem Server-Reset vom Client geschickt. Damit signalisiert er, das er alle bis dahin gesammelten Daten geschickt bekommen möchte. Nach einer GET UPDATE ALL Nachricht werden hiermit alle neuen Daten angefordert. Sie wird regelmäßig vom Client geschickt. Client (Admin) fordert die aktuelle Regel Basis an. Mit dieser Nachricht informiert der Server die Clients darüber, das sich etwas substanziell wichtiges geändert hat, wie etwa die Regel Basis. Alle Clients müssen dann nochmal die selbe Prozedur wie bei einer Anmeldung durchlaufen. 31

ActivationsMessage ACTIVATIONS Antwort des Servers auf eine GET ACTIVATIONS Nachricht. Enthält alle Aktivierungen in Form einer Liste von SimpleActivationAbstraction Objekten. DataMessage UPDATE ALL Antwort des Servers auf eine GET UPDATE ALL Nachricht. Enthält Daten in Form eines StoreableObject Vektor. UPDATE Antwort des Servers auf eine GET UPDATE Nachricht. Enthält Daten in Form eines StoreableObject Vektor. RulesMessage Nicht verwendet. Dient als Basisklasse für EditedRulesMessage, EditedRule- BaseMessage und RuleBaseMessage. Enthält eine Liste von SimpleRuleAbstraction Objekten. EditedRulesMessage EDITED RULES Wird vom Server und Client benutzt, um editierte Regeln zu senden. EditedRuleBaseMessage EDITED RULE BASE Client (Admin) sendet die editierte Regel Basis. RuleBaseMessage RULE BASE Server sendet die aktuelle Regel Basis. Enthält zusätzlich die Regeln separiert nach WENN und DANN Teil (LHS-/RHS Statements). SalienceMessage UPDATE SALIENCE Wird vom Client (Admin) an den Server geschickt. Enthält den neuen Salience Wert für eine Regel. 32

5.3 Der Server Abbildung 5.5: UML Server und ClientHandler 5.3.1 Der ClientHandler Die ClientHandler Klasse repräsentiert jeweils eine bestehende Verbindung zu einem Client. Über sie werden Nachrichten zum Server geschickt und empfangen. Das Empfangen der Nachrichten geschieht dabei in einem eigenen Thread. 5.3.2 Der Sendecache Im Zusammenspiel mit der GUI ergab sich beim Pixel Advisor das Problem, das zu viele neue Daten vom Server geschickt wurden, bevor die alten von der GUI verarbeitet und dargestellt waren. Es wurde erforderlich, von einer asynchronen auf eine synchrone Sendestrategie zu wechseln. Der Server schickt neue Daten nur, wenn der Client diese explizit anfordert. Zusätzlich wurde der Datenverkehr reduziert. Der Sendecache wird von der MessageSendQueue Klasse realisiert. Grundsätzlich besteht sie aus einer, in einem eigenen Thread laufenden run() Methode und den Listen der zu sendenden Nachrichten. Es gibt zwei Arten von Listen: Eine für die Update Nachrichten (das sind DataMessage Objekte mit Command Attribut auf UPDATE gesetzt) und eine 33