Fernwartung und Ferndiagnose eines modernen Kaffeevollautomaten

BACHELORARBEIT Bachelorarbeit von

Bassner, Marcel 1080580

Aufgabenstellung: Prof. Dr. Gabrijela Dreo Rodosek Betreuung: Dipl.-Inf. Frank Eyermann

Universitt der Bundeswehr Mnchen Fakultt fr Informatik Neubiberg 30.12.2010

Eigenstndigkeitserklrung

Hiermit versichere ich, dass ich die vorliegende Arbeit selbststndig angefertigt habe. Die aus fremden Quellen direkt oder indirekt bernommenen Gedanken und Zitate sind als solche kenntlich gemacht. Es wurden keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel benutzt. Die Arbeit wurde weder einer anderen Prfungsbehrde vorgelegt noch verffentlicht.

Neubiberg, den 30.12.10 Datum, Unterschrift

Inhaltsverzeichnis

ii

Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................ ii Abbildungsverzeichnis ....................................................................................... iv Abkrzungsverzeichnis....................................................................................... v 1 Einleitung ......................................................................................................... 1
1.1 Motivation ..................................................................................................................... 2 1.2 Problemstellung ............................................................................................................ 3 1.3 Zielsetzung .................................................................................................................... 4

2 Anforderungsanalyse ...................................................................................... 5
2.1 Nutzungsszenarien ....................................................................................................... 5 2.2 Anforderungen an das System .................................................................................... 7

3 Grundlagen ...................................................................................................... 9
3.1 Authentifizierung ......................................................................................................... 9 3.1.1 Aufweisen von Wissen ........................................................................................ 9 3.1.2 Benutzung eines Besitzes .................................................................................. 10 3.1.3 Biometrische Merkmale .................................................................................... 11 3.2 Digitale Zertifikate ..................................................................................................... 11 3.2.1 Digitale Zertifikate und Certificate Authorities ................................................ 12 3.2.2 Digitale Zertifikate in Java................................................................................ 13 3.3 SNMP........................................................................................................................... 14 3.3.1 SNMP in Java.................................................................................................... 15

4 Design ............................................................................................................. 16
4.1 Statusinformationen und Einstellungen ................................................................... 16 4.1.1 Separat an jedem Automaten ............................................................................ 16 4.1.2 Zentralisierung .................................................................................................. 16 4.1.3 Fazit................................................................................................................... 17 4.2 Internet bertragung ................................................................................................. 18 4.2.1 Entwurf eines eigenen Protokolls ..................................................................... 18 4.2.2 SNMP................................................................................................................ 18 4.2.3 Fazit................................................................................................................... 18 4.3 Autorisierung von Technikern .................................................................................. 19 4.3.1 Passwort ............................................................................................................ 19 4.3.2 Token................................................................................................................. 19

Inhaltsverzeichnis

iii

4.3.3 Fingerabdruck ................................................................................................... 20 4.3.4 Fazit................................................................................................................... 20 4.4 Dokumentation ........................................................................................................... 21 4.5 Verarbeitung von Strungen oder Fehlern .............................................................. 22

5 Implementierung ........................................................................................... 23
5.1 Kaffeeautomat ............................................................................................................ 24 5.1.1 CMaschineAgent und AgentFactory ................................................................. 24 5.1.2 AutoCheck ........................................................................................................ 26 5.2 Wartungs- und Diagnoseeinheit ................................................................................ 26 5.2.1 ClientServerAgent............................................................................................. 26 5.2.2 LocalMaintenance ............................................................................................. 27 5.2.3 ServerTrapReceiver und TrapReceiver ............................................................. 29 5.2.4 AutoMaintenance .............................................................................................. 30 5.3 Leasingfirma ............................................................................................................... 30 5.3.1 LessorTrapReceiver .......................................................................................... 31 5.3.2 TechnicianManagement .................................................................................... 32

6 Fazit ................................................................................................................ 34 Literaturverzeichnis ........................................................................................... vi Anhang ................................................................................................................ ix

Abbildungsverzeichnis

iv

Abbildungsverzeichnis
Abbildung 1: Impressa X9 der Firma Jura [5]............................................................................ 2 Abbildung 2: Use-Case-Diagramm ............................................................................................ 7 Abbildung 3: Smart-Card [10].................................................................................................. 10 Abbildung 4: Direktes Vertrauensmodell [11] .......................................................................... 12 Abbildung 5: Aufbau Zertifikat [8] .......................................................................................... 13 Abbildung 6: Schema SNMP Kommunikation ........................................................................ 15 Abbildung 7: Schema Zentralisierter Einstellungen................................................................. 17 Abbildung 8: Schema RFID-System [19] ................................................................................ 20 Abbildung 9: Fingerprintsensor [20] ........................................................................................ 20 Abbildung 10: Schema Authentifizierung Techniker ............................................................... 21 Abbildung 11: Schema Fehlerverarbeitung .............................................................................. 22 Abbildung 12: Unterteilung Implementierung ......................................................................... 23 Abbildung 13: Pakete der Implementierung............................................................................. 23 Abbildung 14: Frontend ........................................................................................................... 24 Abbildung 15: CMaschineAgent und AgentFactory ................................................................ 25 Abbildung 16: ClientServer ...................................................................................................... 26 Abbildung 17: Pico-c der Firma Super Talent [22] .................................................................. 28 Abbildung 18: LocalMaintenance Konstruktor ........................................................................ 28 Abbildung 19: LocalMaintenanceForm.................................................................................... 29 Abbildung 20: Lessor ............................................................................................................... 30 Abbildung 21: TrapManagement Ansicht ............................................................................. 31 Abbildung 22: ClientVerbindung-Ansicht ............................................................................ 32 Abbildung 23: Neuer Techniker-Ansicht .............................................................................. 33 Abbildung 24: Ausschnitt der MIB-Struktur ............................................................................. xi

Abkrzungsverzeichnis

Abkrzungsverzeichnis
ID ..................................... Identifikator LAN ................................. Local Area Network PIN ................................... Persnliche Identifikationsnummer TAN ................................. Transaction Authentification Numbers RFID ................................ Radio-Frequency Identification RJ-45................................ genormte Steckverbindung fr Telekommunikationsverkabelung UniBwM .......................... Universitt der Bundeswehr Mnchen CA.................................... Cetificate Authority ITU .................................. Internationalen Fernmeldeunion IETF ................................. Internet Engineering Task Force MIB.................................. Management Information Base OID .................................. Object Identifier IP ...................................... Internet Protocol TCP .................................. Transmission Control Protocol DES.................................. Data Encryption Standard AES.................................. Advanced Encryption Standard TLS .................................. Transport Layer Security CRL ................................. Certificate Revocation List SNMP .............................. Simple Network Management Protocol

Kapitel 1: Einleitung

1 Einleitung

Der verlockende Duft von frisch aufgebrhtem Kaffee lsst fr viele Deutsche die kleine Pause zum Erlebnis werden. Zum tglichen Ritual gehrt er unbestritten dazu. So trinkt durchschnittlich jeder Deutsche jhrlich mehr Kaffee als Wasser. Eine Studie besagt, dass der Pro-Kopf-Umsatz von Kaffee im Jahr 2007 bei 146 Litern lag. Der Umsatz von Mineral- bzw. Heilwasser hingegen lag nur bei 130 Liter. [1] Eine Tasse des aromatischen Heigetrnkes bedeutet fr jeden, der ihn mag Genuss und Entspannung. Durch Ausschttung von Dopamin und Adrenalin frdert er die Aufmerksamkeit, Vitalitt und Konzentration. [2] In der Gemeinschaft genossen sorgt er in Bros, kleinen Firmen, Handwerksbetrieben und in den Arbeitsrumen eines Beamten fr Geselligkeit. Die Mglichkeiten der Zubereitung sind durchaus unterschiedlich. In den Pausenrumen werden zumeist handelsbliche Kaffeeautomaten oder Kaffeemaschinen genutzt. Dort treffen sich Kollegen um sich gegenseitig auf den neusten Stand zu bringen. Einzelne ziehen sich mit Snack und Tageszeitung in eine ruhige Ecke zurck. Die Batterien werden wieder aufgeladen. Nach der Pause geht es frisch ans Werk. Der Alltag sieht dagegen oft anders aus. Der durchschnittliche Kaffeetrinker wird allzu oft vor diverse Probleme gestellt. Manchmal fehlen Filtertten, der Kaffee ist abgestanden oder die Kaffeekanne ist leer. Der Mangel an Kleingeld fr den Automaten oder fr die Gemeinschaftskaffeekasse betrbt die Betroffenen sehr. Der Ernst der Lage steigt weiter dramatisch an, wenn der geliebte Kaffeespender nun pltzlich defekt sein sollte. Wer kmmert sich nun darum? Wo liegen entsprechende Zustndigkeiten fr Reparatur und Wartung? Diese Arbeit zeigt mit der Erstellung eines umfangreichen Wartungs- und Diagnosesystems fr alle aufgestellten Kaffeevollautomaten innerhalb einer Firma einen Lsungsweg fr diese Probleme auf.

Kapitel 1: Einleitung

1.1 Motivation

Der Kaffeevollautomat Impressa X9 der Firma Jura stellt eine hohe Funktionalitt und Bedienerfreundlichkeit bereit. Zustzlich ist er mit einer Tageskapazitt von bis zu 100 Tassen [3] fr eine kommerzielle Nutzung und somit fr den Einsatz in mittleren bis groen Firmen bestens geeignet. [4]

Abbildung 1: Impressa X9 der Firma Jura [5] Um den Funktionsumfang weiter zu erhhen und somit das Einsatzgebiet zu erweitern wurde bereits in der Bachelorarbeit von Stefan Mazur und Marlene Knsel eine Trennung von Maschinensteuerung und Benutzeroberflche umgesetzt. Dies ist notwendig um wichtige Kernfunktionen der Maschine, unabhngig von Modifikationen wie zum Beispiel Abrechnungssystemen und verschiedenen grafischen Oberflchen, sicherzustellen. [6] Im Verlauf wurde der Kaffeeautomat unter anderem um eine Registered Jack 45 (RJ-45) Schnittstelle erweitert und somit der Weg fr eine Einbindung und Kommunikation in einem Local Area Network (LAN) bereitet. Auf Grundlage dieses Konstrukts ist es nun mglich, das Gert fr weitere Anwendungsbereiche zu ffnen und die Kundenfreundlichkeit noch weiter zu steigern.

Kapitel 1: Einleitung

1.2 Problemstellung

Als Ausgangslage ist das System nun fr jegliche Erweiterungen bereit. Um diese Arbeit abzugrenzen werden im Folgenden die Problematiken, zu denen diese Arbeit einen Lsungsweg aufzeigen soll, vorgestellt. 1. Fernwartung und Diagnose Im aktuellen Zustand des Systems knnen Einstellungen nur lokal an einem Gert vorgenommen werden. So muss bei Inbetriebnahme des Systems jedes System einzeln konfiguriert werden. Auch bei einer spteren nderung, wie zum Beispiel der Uhrzeit ist es von Nten das ein Techniker zu jedem Kaffeeautomaten geht und diese Einstellung vornimmt. Dafr wird Zeit oder Personal bentig. Beides kostet den Kunden im Endeffekt mehr Geld, wodurch das Interesse an dem Angebot der Leasingfirma schwinden wrde. Somit muss eine Lsung zum Abrufen und ndern von Einstellung aus der Ferne, ber das Internet, gefunden werden. Damit kann die Leasingfirma der Kaffeeautomaten bei gegebenem Anlass auch ohne groen Aufwand Anpassungen vornehmen. 2. Zugriffskontrolle am Automaten Natrlich mssen Einstellungen auch weiterhin direkt am Gert vorgenommen werden knnen. Jedoch sollte nicht einfach jeder Benutzer wichtige Einstellungen ndern knnen. Es muss unterbunden werden, dass Einstellungen vorgenommen werden die einen Automaten beschdigen oder unerlaubt Leistungen erschlichen werden. Es ist somit einfach zu erkennen dass eine Sicherung notwendig ist, welche den Zugriff auf Einstellungen des Kaffeeautomaten regelt, so dass nur autorisiertes Personal zu nderungen in der Lage ist. 3. Automatisierung von einfachen Aufgaben In einer Firma die 20 Kaffeeautomaten der Leasingfirma nutzt, steht eine Uhrzeitnderung an. Es muss an jedem Automaten die Uhrzeit gendert werden. Dazu ist es entweder notwendig einen Techniker zu beauftragen, der dies an jedem Gert durchfhrt oder die Aktion wird ber die Fernwartung umgesetzt. Doch Beides stellt einen unverhltnismigen Aufwand dar. Es muss eine Mglichkeit geschaffen werden, um einfa-

Kapitel 1: Einleitung

che nderungen zu automatisieren. Dies entlastet die Leasingfirma, da sie im Rahmen desselben Servicepaketes mehr Leistung bieten kann.

1.3 Zielsetzung

Die Erweiterung des Systems kann sehr flexibel umgesetzt werden und es bestehen viele Mglichkeiten Modifikationen durchzufhren, um es an eine bestimmte Anforderung anzupassen. Nachfolgend werden im speziellen jene aufgezhlt, welche in dieser Arbeit bearbeitet werden sollen. 1. Es soll eine System zur Wartung und Diagnose der Kaffeevollautomaten einer Firma realisiert werden.

2. Die Service-Firma wird selbstndig bei auftretenden Fehlern informiert und ist in der Lage remote auf die Einstellungen und Statusmeldungen der Kaffeeautomaten zuzugreifen.

3. Ein Techniker kann vor Ort Diagnose und Wartung vornehmen.

4. Der fr die Erbringung der Serviceleistung notwendige Arbeitsaufwand soll durch Automatisierung minimiert werden.

Kapitel 2: Anforderungsanalyse

2 Anforderungsanalyse

Um eine detaillierte Anforderungsanalyse aufstellen zu knnen, werden im kommenden Abschnitt verschieden Szenarien zur Nutzung des Systems dargestellt. Darauf basierend werden Bedingungen und Anforderungen hergeleitet und formuliert.

2.1 Nutzungsszenarien

Szenario 1: In einer mittelstndischen bis groen Firma sind an verschiedenen Orten Kaffeemaschinen aufgestellt, um das tgliche Bedrfnis der Mitarbeiter an Koffein zu decken. Jedoch sind in letzter Zeit vermehrt Defekte bei diesen Kaffeemaschinen aufgetreten. Statt die defekten Gerte zu ersetzen hat sich der Geschftsfhrer entschlossen, das Angebot einer Leasing-Firma zu nutzen. Diese stellt Kaffeeautomaten bereit, welche in der Firma an verschiedenen Punkten aufgestellt werden knnen. Zustzlich zu den Gerten bernimmt die Leasing-Firma jegliche Serviceleistungen. Um die Kosten zu minimieren, werden die Kaffeeautomaten mit einer Internetverbindung versehen, worber Statusinformationen und Einstellungen direkt von der Leasingfirma abgerufen bzw. gesetzt werden knnen. Des Weiteren wird die Leasing-Firma bei auftretenden Fehlern oder Defekten direkt ber diese Verbindung informiert, um entsprechende Manahmen einleiten zu knnen.

Szenario 2: Bei diesem Szenario handelt es sich um die zuvor beschriebene Firma, welche das Angebot der Leasing-Firma wahrgenommen hat und nun schon seit einigen Monaten von den Vorzgen profitiert. Die Leasing-Firma hat eine Mitteilung ber einen Fehler an einem der Kaffeeautomaten erhalten, bei der Bearbeitung der Meldung wird klar, dass es sich um einen schwerwie-

Kapitel 2: Anforderungsanalyse

genden Defekt handelt. Ein Techniker wird mit der Behebung des Problems beauftragt. Da sich der Grund fr das Problem dem Techniker nicht sofort erschliet, entscheidet er sich die Logdateien des Automaten auf Herkunft zu untersuchen. Nachdem er die Ursache gefunden hat und das defekte Teil ersetzt wurde, meldet sich der Techniker an dem Kaffeeautomaten an. Nun kann er entsprechend notwendige Korrekturen der Einstellungen vornehmen. Um Rckfragen zu ermglichen, wird der Zugriff auf die Einstellungen mit den Daten des Technikers in den Logdateien vermerkt.

Szenario 3: Um die Serviceleistung bei sinkendem Personalbedarf und sinkenden Kosten zu erhhen, sollen verschiedene Vorgnge automatisiert werden. Zur Umsetzung wurde in der oben bereits beschriebenen Firma ein System installiert, welches selbstndig Diagnose- und Wartungsarbeiten der in der Firma aufgestellten Kaffeeautomaten durchfhrt. Das System wurde bei der Aufstellung so konfiguriert, dass Einstellungen fr die Kaffeeautomaten zentral vorgenommen werden knnen und von der Diagnoseeinheit in regelmigen Abstnden berprft werden. Bei Abweichungen werden entsprechend notwendige Manahmen selbstndig vom System ergriffen. Treten schwerwiegende Fehler auf, welche die Wartungs- und Diagnoseeinheit nicht eigenstndig beheben kann, wird die Leasing-Firma informiert. Mit Einfhrung des neuen Systems wurde dem nun notwendigen Techniker die Arbeit erleichtert. Er kann sich durch die zentralisierte Diagnose nun schnellstmglich einen berblick ber das Gesamtsystem verschaffen und Einstellungen fr alle Automaten gleichzeitig ndern. Aus den beschriebenen Nutzungsszenarien wurde ein Use-Case-Diagramm (Abbildung 2) zusammengestellt. Dabei geht hervor, dass der grte Teil der Funktionalitt des Systems bei der Wartungs- und Diagnoseeinheit liegt. Ein Techniker bzw. die Leasing-Firma muss ausschlielich mit dieser kommunizieren, um Einstellungen oder Statusinformationen abzurufen. Das System leitet gettigte nderungen selbstndig an die Kaffeeautomaten weiter.

Kapitel 2: Anforderungsanalyse

Abbildung 2: Use-Case-Diagramm

2.2 Anforderungen an das System

Durch eine Analyse der Nutzungsszenarien lassen sich an das System gestellte Kernanforderungen herleiten, welche das zu entwickelnde System erfllen muss. 1. Es muss eine Wartungs- und Diagnoseeinheit erstellt werden, welche mit den ihr zugeordneten Kaffeeautomaten kommunizieren kann.

2. Die Einheit muss Statusinformationen und Einstellungen bereitstellen.

a. Diese sollen ber das Internet zur Leasing-Firma bertragen werden und dort gendert werden knnen.

Kapitel 2: Anforderungsanalyse

b. Einstellungen sollen vor Ort von einem Techniker abgerufen und gendert werden knnen. c. nderungen werden automatisiert an die angeschlossenen Kaffeeautomaten bertragen.

3. Der Zugriff auf bereitgestellte Daten muss gesichert werden.

a. Bei der bertragung ber das Internet muss ein Protokoll gewhlt werden, welches eine Verschlsselung zur Verfgung stellt. b. Vor Ort muss sichergestellt werden, dass Einstellungen nur von einem ausgewiesenen Techniker der Leasing-Firma gendert werden drfen.

4. Zu Diagnosezwecken sollen die Ablufe innerhalb der Wartungs- und Diagnoseeinheit dokumentiert und in Logdateien gespeichert werden.

5. Auftretende Fehler mssen gem den Mglichkeiten des Systems verarbeitet werden.

a. Fehler einzelner Kaffeeautomaten werden ber eine Netzwerkverbindung zum Server gesandt. b. Wenn mglich werden Fehler durch die Wartungseinheit behoben. Bei schwerwiegenden Fehlern oder Defekten wird die Fehlermeldung an die Leasing-Firma weitergeleitet.

Kapitel 3: Grundlagen

3 Grundlagen

In diesem Kapitel werden Grundlagen der Arbeit besprochen und verwendete Frameworks, Mechanismen und Protokolle erklrt.

3.1 Authentifizierung

Um die Zugriffkontrolle eines Systems zu bewltigen, ist eine Authentifizierung notwendig. Das bedeutet die sichere Feststellung der Identitt einer Person. Diese Information kann auf verschiedene Weisen sichergestellt werden. Dabei kann es sich um das Aufweisen von Wissen, die Benutzung eines Besitzes oder den Nachweis eines biometrischen Merkmales handeln. In den nchsten Abschnitten werden nun diese Mglichkeiten nher beleuchtet und dargestellt [7].

3.1.1 Aufweisen von Wissen

Dieser Faktor zur Authentifizierung wird meist in Computersystemen verwendet. Der Nachweis von Wissen in Form von Passwrtern, Personal Identification Numbers (PINs) oder Transaction Authentification Numbers (TANs) ist in jeglichen Bereichen zu finden. Dabei ist auch die Kombination von verschiedenem Wissen mglich wie zum Beispiel die Abfrage eines Passwortes in Verbindung mit dem Geburtsdatum. Fr diese Art des Nachweises wird an dem betroffenen System keinerlei spezielle oder zustzliche Hardware bentigt. Die Wissensbertragung kann einfach durch ein Eingabegert wie eine Tastatur oder ein Nummernfeld geschehen. Denkbar ist auch eine Eingabe per Bildschirmtastatur. [8] Nachteil bei der Verwendung von Wissen zur Authentifizierung ist die Mglichkeit zur Vervielfltigung ohne Kenntnisnahme des eigentlichen Eigentmers, mit geringem oder keinem zustzlichen Aufwand. Ein Passwort kann zum Beispiel bei der Eingabe von einem Dritten gesehen oder vom Besitzer selbst verraten werden. [9]

Kapitel 3: Grundlagen

10

3.1.2 Benutzung eines Besitzes

Der Besitz eines bestimmten Gegenstandes ist im Alltag eine weit verbreite Methode zur Zugangsbeschrnkung. Ein Broschlssel ist eines der einfachsten Beispiele um nicht autorisierte Personen vom Zugang zu einem gesonderten Bereich auszuschlieen. Aber auch Schlsselkarten wie Smart-Cards oder Chipkarten zhlen zu diesem Bereich. Objekte zur Authentifizierung werden auch Token genannt. Bei der Benutzung von Token sollte darauf geachtet werden, dass die Erstellung einer Kopie nur schwer oder gar nicht mglich ist. Das wird realisiert indem gezielt Fehler auf dem Datentrger erzeugt werden, welche nicht mit gngigen Mitteln zu reproduzieren sind. Sodass bei der Ausfhrung eines Programmes oder zu Beginn eines Prozesses auf das Vorhandensein dieses Fehlers getestet werden kann. Eine weitere Mglichkeit ist den direkten Zugriff auf den Speicher zu unterbinden, damit kein Kopieren des Inhalts durchfhrbar ist. In Smart-Cards wird das realisiert, indem eine Interaktion mit dem internen Permanentspeicher nur ber den verbauten Prozessor passiert. Der Speicher ist ausbausicher in der Karte untergebracht. [8]

Abbildung 3: Smart-Card [10]

Kapitel 3: Grundlagen

11

3.1.3 Biometrische Merkmale

Bei der Feststellung der Identitt einer Person zur Authentifizierung ist Biometrie eine der sichersten Methoden. Dabei wird ein einzigartiges persnliches Merkmal einer Person gescannt und mit gespeicherten Werten verglichen. Diese Scans mssen exakt und wiederholbar sein, um fr eine Zugriffskontrolle in Frage zu kommen. Zu denen am hufigsten verwendeten Merkmalen zhlen der Fingerabdruck, die Retina bzw. die Iris, die Stimme oder spezielle Gesichtsmerkmale. [7] Ein DNA Scan zu Identifikationszwecken ist in den meisten Fllen nicht praktikabel, da die Authentifizierung innerhalb von wenigen Sekunden ablaufen sollte und nicht wie in diesen Fall eine Woche auf das Ergebnis der Analyse gewartet werden kann. Nachteil dieses Faktors zur Authentifizierung im Vergleich zu den anderen beiden Varianten sind die erheblich hheren Kosten fr die Anschaffung von Scannern. [8] Sowohl Vor- und Nachteil dieser Methode ist, dass keine Mglichkeit zu Weitergabe der Schlsselmerkmale besteht. Wodurch einerseits die Zugangsberechtigung nicht weitergereicht werden kann, andererseits ein Verlieren oder Vergessen ausgeschlossen ist. Der Datensatz jeder berechtigten Person muss in einem zugriffsgeschtzten Gert gespeichert oder von diesem auf einem zentralen Speicher erreichbar sein, wodurch es nicht mglich ist eine dem System unbekannte Person zu berechtigen.

3.2 Digitale Zertifikate

Im digitalen Datenverkehr wird heutzutage fast ausschlielich asynchrone Verschlsselung zur bertragung von sensiblen Daten verwendet. Diese Methode bietet eine Lsung fr die grten Probleme der synchronen Verschlsselung. [11] Bei synchroner Kryptierung muss der Schlssel erst an beide Seiten auf einem bereits gesicherten Weg bertragen werden. Die asynchrone Verschlsselung erlaubt es den Public Key zu verffentlichen. Mit diesem Schlssel knnen nun Nachrichten chiffriert werden, welche nur der Empfnger mit dem passenden privaten Schlssel decodieren kann. Durch die Verbreitung des Public Key entsteht ein anderes Problem. Es kann nicht sichergestellt werden, dass der Herausgeber wirklich die Person oder Institution ist fr die sie gehalten wird. Dieser Problematik wirken Digitale Zertifikate entgegen.

Kapitel 3: Grundlagen

12

3.2.1 Digitale Zertifikate und Certificate Authorities

Ein digitales Zertifikat dient der Bindung eines ffentlichen Schlssels an eine bestimmte Identitt. Eine Institution versichert dabei, dass der Public Key einer Person, dem Zertifikatsbesitzer, zuzuordnen ist. Diese Institution heit Cetificate Authority (CA). Als Voraussetzung muss der Zertifikatsprfer Vertrauen in die CA und deren ffentlichen Schlssel besitzen.

Abbildung 4: Direktes Vertrauensmodell [11] Zur Verwendung bei Public Key Zertifikaten hat sich der Standard X.509 der Internationalen Fernmeldeunion (ITU) durchgesetzt. In der neusten Version X.509 v3 [12] speichert das Zertifikat Informationen wie [7]: Seriennummer Versionsnummer Einzelheiten zur Identitt des Besitzers Details zum verwendeten Verschlsselungsalgorithmus Gltigkeitsdauer Und die digitale Signatur der CA

Die Zertifizierungsinstitution signiert alle zum Zertifikat gehrenden Daten und setzt diese verschlsselte Prfsumme unter das Zertifikat. Dadurch werden die Daten nicht vor einer nderung geschtzt, jedoch wrde eine solche sofort bei berprfung der Signatur auffallen. Somit ist die Integritt der angegebenen Daten durch die CA versichert. [8]

Kapitel 3: Grundlagen

13

Abbildung 5: Aufbau Zertifikat [8]

3.2.2 Digitale Zertifikate in Java

In Bezug auf die Verwendung von Zertifikaten stellt die Security-API der Java SE nur Mglichkeiten der Verwaltung von Schlsseln und das Prfen von Zertifikaten bereit. [13] Um selbstsignierte Zertifikate zu erstellen, muss man auf die Klassen aus dem sun.security.* Paket zurckgreifen. Hier werden mit der Klasse CertAndKeyGen Funktionen bereitgestellt mit welchen sich X.509 v1 und v3 Zertifikate erstellen lassen. Da sich in den mit dieser Methode erstellten Zertifikaten kein spezifischer Public Key einbetten lsst und die Erweiterungsfunktionalitt der X.509 v3 nicht implementiert ist, dienen sie nur der Identifikation einer CA und nicht der nheren Beschreibung eines ffentlichen Schlssels. [14] Um die komplette Spannbreite der Funktionalitt von Zertifikaten auszuschpfen, ist die Verwendung eines Drittanbieter-Pakets vonnten. Dazu wird im Folgenden die Bouncy Castle Crypto API vorgestellt.

Bouncy Castle Crypto API

Die Legion of the Bouncy Castle ist ein Zusammenschluss, welcher seit mehr als 10 Jahren existiert. Sie haben sich zum Ziel gesetzt, Verschlsselung fr Jedermann zur Verfgung zu stellen. Dazu haben sich im Laufe der Zeit Sicherheits-APIs fr die Sprachen C# und Java entwickelt. Dabei hlt die Java Version folgende Funktionalitt bereit: [15] eine leichtgewichtige Kryptografie API einen Provider fr die Java Kryptografie Erweiterung und Architektur eine Bibliothek fr das Schreiben und Einlesen von ASN.1 enkodierten Objekten

Kapitel 3: Grundlagen eine leichtgewichtige Benutzerseiten TLS API Generatoren fr v1 und v3 X.509 Zertifikate, v2 CRLs und PKCS12 Dateien Generatoren fr v2 X.509 Attribut Zertifikate Generatoren / Prozessoren fr S/MIME, CMS, OCSP, TSP und OpenPGP

14

Fr dieses Projekt sind nur die X.509 Zertifikate von Bedeutung.

3.3 SNMP

SNMP steht kurz fr Simple Network Management Protocol. Das Protokoll wurde 1988 von der Internet Engineering Task Force (IETF) verffentlicht. Es dient der zentralen Steuerung und berwachung von Netzwerkkomponenten. Dabei beschreibt es den Aufbau der Datenpakete zum Anfordern und Erhalten von Management-Informationen. Bei der Verwendung des Protokolls wird zwischen Agenten und Managern unterschieden. Agenten sind Softwaresysteme, welche auf SNMP-Anfragen reagieren und somit Status- und Statistikinformationen bereitstellen. Diese Informationen werden in der Management Information Base (MIB) in Form von Managed Objects bereitgestellt. Um die Informationen gezielt abzurufen werden Object Identifier (OID) eingesetzt. Ein OID ist eine Zeichenkette aus Nummern, jede dieser Nummern steht fr ein bestimmtes Level innerhalb eines hierarchischen Baumes. So erreicht man mit dem Ast 1.3.6.1.2.1 die SNMP MIB-2 zum Internetprotokoll (IP) und Transmission Control Protocol (TCP). Dieses MIB-Modul sollte von jeder Netzwerkkomponente umgesetzt werden, wodurch gleiche Informationen durch dieselbe OID zu erreichen sind. Fr diese Arbeit wird ein bereits fr die Universitt der Bundeswehr Mnchen (UniBwM) im globalen Verzeichnis registrierter Zweig verwendet. Seine Bezeichnung ist 1.3.6.1.4.1.24094, sie steht fr iso.org.dod.internet.private.enterprises.UniBwM. Manager sind Anwendungen welche SNMP Agenten verwalten. Dies geschieht durch die Ausstellung von Anfragen, Verarbeiten von Antworten und das Lauschen nach Agenten TRAPs. Eine TRAP ist eine von einem Agenten gesendete Fehlermeldung, welche nur in akuten Notfllen verwendet wird. Die neuste Version v3 des Protokolls bietet im Gegensatz zu den Vorgngern ein Sicherheits- und Administrationsframework. Dazu zhlt unter anderem eine verschlsselte bertragung mit Triple-Data Encryption Standard (DES) oder Advanced Encryption Standard (AES). [16]

Kapitel 3: Grundlagen

15

Abbildung 6: Schema SNMP Kommunikation

3.3.1 SNMP in Java

Java stellt wiederum keine native Lsung fr die Verwendung von SNMP bereit. Um SNMP dennoch zu nutzen, kann das Paket SNMP4J verwendet werden. Frank Fock und Jochen Katz arbeiten seit nun fast sieben Jahren an diesem Projekt. SNMP4J untersttzt die Kommandoerzeugung fr SNMP Manager und das Reagieren auf Kommandos fr Agenten. Es ist ein rein objektorientiertes Paket, welches sich an SNMP++ anlehnt. Das Paket bietet folgende Features: [17] SNMPv3 mit MD5 oder SHA Authentifikation DES und AES 128bit, AES 192bit oder AES 256bit Verschlsselung Vernderbare Nachrichten Verarbeitung fr MPv1,MPv2c und MPv3 Vernderbare Transportprotokolle. UDP und TCP sind bereits enthalten Synchrone und Asynchrone Anfragen Multi-Thread Untersttzung Dokumentation (Logging) mit Log4J

Kapitel 4: Design

16

4 Design

Im folgenden Kapitel wird ein Konzept entworfen welches die Bedingung der Anforderungsanalyse erfllt. Dabei werden verschieden Herangehensweisen betrachtet und anschlieen die zur Erreichung des Ziels beste Methode ausgewhlt.

4.1 Statusinformationen und Einstellungen

Wie in den Anforderungen an das System festgelegt wurde, sollen Statusinformationen und Einstellungen bereitgestellt werden. Bei der Umsetzung gibt es verschiedene Mglichkeiten um dies zu realisieren.

4.1.1 Separat an jedem Automaten

Eine erste Variante wre eine Verwirklichung bei der die Einstellungen an jedem Kaffeeautomaten gettigt werden. Jedes System kann einzeln konfiguriert und genau auf seinen Standort innerhalb einer Firma angepasst werden. Zum Beispiel kann ein Automat in der Kantine fr ein anderes Abrechnungssystem eingestellt werden als ein Automat im Brodistrikt. Die Leasingfirma hat die Mglichkeit auf jedes Gert ber das Internet separat zuzugreifen und Statusinformationen abzurufen oder Einstellungen zu setzen.

4.1.2 Zentralisierung
Einstellungen werden zentral an einem serverartigen System gesetzt, welches die Konfiguration automatisch an alle angeschlossenen Kaffeeautomaten bertrgt. Der Aufwand fr die nderung wird minimiert, da sie nur am Server vorgenommen werden mssen. Anfragen oder Befehle der Leasingfirma werden ber das Internet zu dieser Verwaltungseinheit gesandt und diese kmmert sich selbstndig um die Umsetzung beziehungsweise Durchsetzung. Voraus-

Kapitel 4: Design

17

setzung dabei ist ein gleicher technischer Aufbau der Automaten, damit alle Systeme auf die Einstellungen gleich regieren knnen.

4.1.3 Fazit
Die aufgezeigten Alternativen halten jeweils Vor- und Nachteile bereit. So ist der Aufwand fr die Einstellung an jedem Gert einzeln erheblich grer. Zustzlich stellt der Anschluss jedes Automaten an das Internet zur Kommunikation mit der Leasingfirma eine enorme Sicherheitslcke dar, da entsprechend viele Ports oder IP-Adressen freigegeben werden mssen. Dieses Problem besteht bei einer zentralisierten Verwaltung der Einstellungen nicht. Hier ist es nur von Nten der Servereinheit einen Zugang zum Internet zu ermglichen. Jedoch ist die Mglichkeit zur Konfiguration des Systems auch quivalent niedriger. Fr die Umsetzung in diesem Projekt wird daher eine abgewandelte Version der zentralisierten Verwaltung gewhlt. Es wird ein Serversystem bereitgestellt, welches eine Anbindung zum Internet bekommt, um mit der Leasingfirma kommunizieren zu knnen. Damit das Problem der eingeschrnkten technischen Modifikation behoben wird, bekommt die Verwaltungseinheit Einstellungsstze fr verschiedene Bauweisen der Kaffeeautomaten. Der Server kann nun bei dem Kaffeeautomaten abfragen um welche Konfiguration es sich handelt und die dafr vorgesehenen Einstellungen bertragen. Bei dieser aufgezeigten Realisierung sind Sicherheitslcken und Aufwand minimiert trotz einer insgesamt hohen Flexibilitt der Systemkonfiguration.

Abbildung 7: Schema Zentralisierter Einstellungen

Kapitel 4: Design

18

4.2 Internet bertragung

Damit eine Fernwartung und Diagnose der Kaffeeautomaten mglich ist, muss eine Kommunikation mit der Leasingfirma ber das Internet realisiert werden. Vorrangig werden Einstellungen von der Leasingfirma gesendet oder Statusinformationen des Serversystems abgerufen. Diese bertragungen mssen jedoch gesichert werden da Unbefugte sonst die Mglichkeit htten, Einstellungen des Systems zu ndern und es somit schdigen oder vertrauliche Nutzerdaten entwenden knnten.

4.2.1 Entwurf eines eigenen Protokolls

Fr den Zweck der bertragung besteht die Mglichkeit ein eigenes Transportprotokoll zu entwerfen. Das Protokoll wrde, auf Basis der Transport Layer Security (TLS) zur sicheren bertragung, umgesetzt werden. Bei der Erstellung mssen Funktionen wie das Setzen, sowie Abrufen von Einstellungen, bertragen von Statusinformationen und die Mglichkeit zu Fehlermeldungen realisiert werden.

4.2.2 SNMP
Das Simple Network Management Protocol wurde bereit im Grundlagen Kapitel beschrieben und verfgt durch die Managed Objects ber eine Mglichkeit Informationen und Einstellungen bereit zu stellen, welche wiederum gezielt durch SNMP-Pakete gendert oder abgerufen werden knnen. In der neusten Version v3 stellt es, wie bereits erwhnt, eine Verschlsslung mit Tripple-DES oder AES bereit. [16]

4.2.3 Fazit
Die Entscheidung fr die Wahl einer passenden bertragungsmethode fr das System, fllt leicht. Unbestritten stellt der Entwurf eines eigenen Protokolls einen immensen Aufwand dar, welcher natrlich durch ein perfekt auf das System zugeschnittenes Ergebnis belohnt wird. Im Falle dieses Projektes ist dieser Aufwand jedoch keinesfalls gerechtfertigt, da SNMP alle Notwendigen Anforderungen mehr als ausreichend erfllt. Zustzlich bietet es durch Managed Objects und MIB bereits eine strukturierte Mglichkeit zur Verwaltung und nderung von Einstellungen und Informationen.

Kapitel 4: Design

19

4.3 Autorisierung von Technikern

Der Zugriff auf sensible Informationen und Einstellungen des Systems muss vor unbefugten Vernderungen geschtzt werden. Somit ist eine sichere Authentifizierung eines Technikers von Nten. Die Faktoren der Authentifizierung wurden bereits im Grundlagen Kapitel erklrt. Es werden nun Beispiele fr die Umsetzung dieser Faktoren gewhlt, die fr das Projekt in Frage kommen. Anschlieend wird eine Entscheidung zugunsten der praktikabelsten Lsung getroffen.

4.3.1 Passwort
Passwrter sollten wohl das bekannteste Beispiel fr eine Authentifizierung ber den Nachweis von Wissen sein. Bei der Verwendung von Passwrtern zur Autorisierung eines Technikers gibt es verschiedene Mglichkeiten der Umsetzung. Gemeinsam haben alle Methoden den Vorteil von Passwrtern. Sie sind einfach bei Mensch und Maschine zu realisieren und es wird keine zustzliche Hardware bentigt. [9] Eine Variante wre die Einfhrung eines Administratorpasswortes. Diese kennen alle Techniker und haben somit die Mglichkeit sich Zugang zu dem Wartungs- und Diagnosesystem zu verschaffen. Jedoch ist die Gefhrdung des Systems bei der Benutzung dieser Alternative zu hoch. Ein Unbefugter, der das Passwort erspht, hat sofort Zugriff auf alle Bereiche und es kann nicht nachvollzogen werden wer den Schaden verursacht hat. Die Umsetzung eines Nutzersystems fr Techniker scheint somit sinnvoller, da bei offensichtlich unbefugter Benutzung das Nutzerkonto sofort gesperrt werden kann, bis die Ursache behoben und das Problem geklrt wurde.

4.3.2 Token
Fr eine Authentifizierung ber einen Token ist der Besitz des Token zwingend notwendig. Zum Einsatz in diesem Projekt wird fr jeden Techniker ein Token erstellt, welcher wichtige Informationen zur eindeutigen Identifizierung des Technikers bereithlt. Dabei muss bei der technischen Realisierung darauf geachtet werden, dass der Speicher nicht direkt auslesbar ist um ein Vervielfltigen zu verhindern. [8] Um eine zustzliche Integritt der Daten zu gewhrleisten, werden die Daten des Technikers in ein digitales Zertifikat eingebettet. Bei Verlust kann das entsprechende Zertifikat per Certificate Revocation List (CRL) ber die Serien-

Kapitel 4: Design

20

nummer zurckgerufen werden. [18] Fr die technische Realisierung ist eine Radio Frequency Identification (RFID) denkbar. Radiofrequenz Identifikation ist ein System der berhrungslosen Datenbertragung. Hierbei werden Informationen von einem mobilen Transponder zu einem Lesegert versandt, oder umgekehrt. [19]

Abbildung 8: Schema RFID-System [19]

4.3.3 Fingerabdruck
Zur Identifizierung der Techniker kann an den Wartungs- und Diagnoseeinheiten ein Fingerprintsensor angebracht werden. Dazu werden die entsprechenden Templates bei Einstellung eines Technikers aufgenommen und an die von Ihm zu wartenden Systeme bertragen. Ein Vorteil dieser Methode ist, dass ein Fingerabdruck vom Techniker weder vergessen noch verloren werden kann und er somit keinesfalls durch solche Nichtigkeiten von seiner Arbeit abgehalten wird.

Abbildung 9: Fingerprintsensor [20]

4.3.4 Fazit
Alle drei aufgezeigten Varianten bieten ausgeglichene Vor- und Nachteile und kommen somit fr den Einsatz infrage. Bei genauerer Betrachtung fllt jedoch auf, dass der finanzielle Aufwand der Biometrieerkennung erheblich hher ist, als bei den beiden anderen Alternativen.

Kapitel 4: Design

21

Somit wird diese Methode zurckgestellt. Um einem Sicherheitsverlust durch Verlieren eines Token oder Ersphen eines Passwortes entgegen zu wirken, werden die beiden Methoden kombiniert. Ein bekanntes Passwort oder ein gefundener Token reicht somit fr eine Authentifizierung nicht aus. Um Zugriff zum System zu erlangen muss man ber Beides verfgen. Es wird somit an der Wartungs- und Diagnoseeinheit ein RFID Empfnger installiert. Sobald ein Techniker in das Nahfeld [19] kommt wird er vom System erkannt und zur vollstndigen Authentifizierung nach seinem Passwort gefragt. Bei der Eingabe des Passwortes wird von der Challenge-Response Methode Gebrauch gemacht. Dabei wird nicht das Passwort selbst bertragen sondern nur ein Beweis dafr, dass das Passwort bekannt ist. [8]

Abbildung 10: Schema Authentifizierung Techniker

4.4 Dokumentation

Zugriffe oder nderungen am System sollen zu Diagnosezwecken gespeichert werden. Dazu werden auf der Wartungs- und Diagnoseeinheit rotierende Logdateien angelegt. Diese knnen vor Ort von Technikern oder remote von der Leasingfirma eingesehen werden.

Kapitel 4: Design

22

4.5 Verarbeitung von Strungen oder Fehlern

Auftretende Fehler oder Strungen werden dokumentiert. Hat ein Kaffeeautomat eine Strung, sendet dieser einen Fehlerbericht an die Wartungs- und Diagnoseeinheit. Nun werden alle wichtigen Informationen dazu automatisch geloggt und eine mgliche Lsungsstrategie eingeleitet. Sollte dieser Versuch fehlschlagen und der Fehler weiterhin bestehen, wird die Fehlermeldung von dem Server an die Leasingfirma weitergeleitet. Diese verarbeitet eingehende Fehler in einer Art Ticketsystem. Ein registrierter Fehler wird in eine Datenbank aufgenommen und in der Supportsoftware als ausstehend angezeigt. Sobald ein Techniker begonnen hat diese Strung zu bearbeiten, verschwindet der Fehler aus der Anzeige der ausstehenden Meldungen und andere Techniker haben nur noch begrenzten Zugriff darauf. Der bearbeitende Techniker kann nun Manahmen zur Behebung des Fehlers einleiten oder gegebenenfalls einen Techniker zum Vor-Ort-Service schicken.

Abbildung 11: Schema Fehlerverarbeitung

Kapitel 5: Implementierung

23

5 Implementierung

Das folgende Kapitel beschreibt einen Prototyp des Gesamtsystems zu Wartung und Diagnose. Dabei werden Konzepte verwendet die im vorherigen Abschnitt dieses Dokumentes herausgearbeitet wurden. Bei der Umsetzung traten neue Probleme auf, die in der Konzeption nicht bedacht werden konnten. Auf diese wird gezielt eingegangen. Die Implementierung des Systems teilt sich in verschiedene Abschnitte:

Abbildung 12: Unterteilung Implementierung Wie anhand des Design-Kapitels ersichtlich ist, wird ein Groteil der Funktionalitt bei der Wartungs- und Diagnoseeinheit liegen, welche in der Implementierung ClientServer genannt wurde. Fr die Umsetzung wurden zwei Pakete erstellt:

Abbildung 13: Pakete der Implementierung Auf den Inhalt der Pakete wird in den folgenden Abschnitten genauer eingegangen.

Kapitel 5: Implementierung

24

5.1 Kaffeeautomat

Wie bereits in der Einleitung erwhnt, wurden durch die Teilung in Front- und Backend die Kernfunktionen des Kaffeeautomaten von den Zusatzfunktionen getrennt. Dadurch ist fr die Implementierung von Wartungs- und Diagnosemechanismen nur das Frontend relevant. Das Frontend stellt in Bezug auf Einstellungen und Statusinformationen einen SNMP Agenten dar. Es erhlt Befehle oder Anforderungen vom ClientServer, auf welche es reagieren muss. Zustzlich sollte es ermglicht werden, Traps zu senden. Da derzeit keine Fehlermeldungen des Kaffeeautomaten bekannt sind, welche den Einsatz eines Technikers erfordern, wurde die Funktion nicht implementiert.

Abbildung 14: Frontend

5.1.1 CMaschineAgent und AgentFactory

Das Frontend instanziiert mit der Klasse CMaschineAgent einen SNMP Agenten. Diese Klasse erbt direkt von AgentFactory, ein Grundbaustein fr die bentigten SNMP Agenten in diesem Projekt. Die AgentFactory erweitert die Klasse org.snmp4j.agent.BaseAgent. Dabei werden mit der Funktion addViews(vacm) im Projekt standardisierte Zugriffsfreigaben gesetzt. Die Funktionen moreViews(vacm), addCommunities(communityMIB) und buildMO() sind in der Klasse AgentFactory standartmig leer. Sie knnen spter von erbenden Klassen berschrieben werden, um den Agenten weiter anzupassen. Unter setUp(name) mssen geforderte SNMP Variablen der SNMP MIB-2 registriert werden. Exemplarisch hierfr wurde unter der OID 1.3.6.1.2.1.1.1.0 die Systembeschreibung mit dem Inhalt des Strings name gesetzt. Um einen Agenten zu erzeugen wird die Funktion getInstance(name) verwendet. Diese liefert eine fertig konfigurierte Instanz eines SNMP Agenten.

Kapitel 5: Implementierung

25

Abbildung 15: CMaschineAgent und AgentFactory

Die Klasse CMaschineAgent berschreibt einige der AgentFactory Prozeduren. In moreViews() und addCommunities() wird der Agent fr das SNMPv2c Security Modell vorbereitet. Dies ist notwendig, da die vom ClientServer verwendete Broadcast Detection keine Authentifizierung per Nutzername und Passwort untersttzt. GetInstance() wurde berschrieben um einen Logger fr den Agenten zu initialisieren. Zum Loggen findet das Paket log4j innerhalb des Paketes Anwendung. Mittels Konfigurator knnen die Formatierung und das Ziel der Ausgabe bestimmt werden. In diesem Fall wird eine rotierende Logdatei mit dem Namen, der bei der Instanziierung angegeben wurde, im Ordner logs erstellt. Die Methode buildMO() registriert die Managed Objects des Agenten. Hier wurden alle Variablen umgesetzt, die ein Kaffeeautomat bereitstellt. Dazu gehren unter anderem: 1.3.6.1.4.1.24094.1.2.1 : Aktueller Status 1.3.6.1.4.1.24094.1.2.2 : Fehlercode (falls eine Strung vorliegt) 1.3.6.1.4.1.24094.1.2.3 : Zhler der Maschine, als Tabelle 1.3.6.1.4.1.24094.1.2.4 : Zeit zum Einschalten des Automaten 1.3.6.1.4.1.24094.1.2.5 : Zeit zum Ausschalten 1.3.6.1.4.1.24094.1.2.6 : Einzuschaltende Tage , als Tabelle

Kapitel 5: Implementierung

26

Fr die Erstellung von Tabellen wurde die Klasse MOTableBuilder genutzt und fr Skalare MOScalarFactory erweitert. [21]

5.1.2 AutoCheck
AutoCheck ist ein Thread, der die Verbindung zwischen den Managed Object des Agenten und den Einstellungen des Backend herstellen soll. Bei der Bearbeitung des Projekts wurde keine Mglichkeit gefunden, direkt auf den Empfang eines SNMP SET Befehls zu reagieren. Somit kann keine sofortige bertragung der Einstellungen zum Backend stattfinden. AutoCheck prft in regelmigen Zeitintervallen ob nderungen vorgenommen wurden. Wenn dies der Fall ist, wird die bertragung zum Backend gestartet.

5.2 Wartungs- und Diagnoseeinheit

Die Wartungs- und Diagnoseeinheit stellt den grten Teil der Funktionalitt bereit. In der Implementierung wird sie durch den ClientServer reprsentiert. Nach dem Start des Servers wird die IP-Adresse der Leasingfirma abgefragt. Nachdem diese eingegeben wurde, wird die Initialisierung fortgesetzt. Geloggt werden die Ablufe innerhalb des ClientServers wiederum mit dem log4j Paket und rotierenden Logdateien.

Abbildung 16: ClientServer

5.2.1 ClientServerAgent
Wie auch schon bei der Klasse CMaschineAgent erbt der ClientServerAgent von AgentFactory und berschreibt Methoden. Hiervon sind nur die getInstance(name), welche wiederum einen Logger initialisiert, und die buildMO(), betroffen. Hier werden diesmal die Variablen

Kapitel 5: Implementierung

27

des Servers registriert. Unter den verwalteten Objekten befinden sich Informationen wie Status (1.3.6.1.4.1.24094.1.1.2) und Fehlercode (1.3.6.1.4.1.24094.1.1.3), darber hinaus auch die Einstellungen zu den verschiedenen Konfigurationen der Kaffeeautomaten, wie im Konzept beschrieben. Zu Demonstrationszwecken wurde in diesem Prototyp jedoch nur eine Konfiguration implementiert. Diese ist unter der OID 1.3.6.1.4.1.24094.1.1.1 zu finden und beinhaltet beispielsweise folgende Einstellungen: 1.3.6.1.4.1.24094.1.1.1.1 : Zeit zum Einschalten der Automaten 1.3.6.1.4.1.24094.1.1.1.2 : Zeit zum Ausschalten 1.3.6.1.4.1.24094.1.1.1.3 : Einzuschaltende Tage , als Tabelle 1.3.6.1.4.1.24094.1.1.1.4 : Zeit nach der die Automaten in den Standby wechseln Die Leasingfirma kann ber SNMP Befehle auf die Informationen und Einstellungen dieses Agenten zugreifen. Fr die bertragung werden eine MD5-Authentifizierung, DESVerschlsselung und ein Standardbenutzername sowie ein Standardpasswort verwendet. Die Nutzerdaten knnen fr das Endprodukt entsprechend angepasst werden. Es ist auch mglich verschiedene Nutzer mit unterschiedlichen Zugriffsrechten anzulegen.

5.2.2 LocalMaintenance
Die Klasse LocalMaintenance ist ein Thread, welcher die Authentifizierung von Technikern bernimmt. Aus finanziellen Grnden wurde das RFID System, welches in der Designphase beschrieben wurde, durch ein USB-Dongle ersetzt. Dabei handelt es sich wiederum aus Kostengrnden, um einen einfachen USB-Stick mit sehr kleinen Ausmaen. Im Endprodukt sollte dieser jedoch mindestens durch einen nicht kopierbaren Token ersetzt werden. Fr den Einsatz in diesem Prototyp reicht der Pico-c der Firma Super Talent aus. Er zeichnet sich durch seine kleine Bauweise aus. Durch die an ihm befestigte Kette kann er ohne Probleme durch einen Techniker mitgefhrt werden.

Kapitel 5: Implementierung

28

Abbildung 17: Pico-c der Firma Super Talent [22] Sobald der USB-Stick an den Server angeschlossen wird, erkennt ihn das System. Da Java ein begrenztes Spektrum an Hardware Untersttzung beinhaltet, muss die Erkennung fr jedes Betriebssystem des Servers extra implementiert werden. Fr die, mit dem Prototyp entwickelte Windowsversion (WinCertHandle), muss der USB-Stick als USBDONGLE benannt sein. Jegliche Aktivitten, die mit diesem USB-Dongle oder der Authentifizierung zu tun haben, sind in der abstrakten Klasse CertHandle zusammen gefasst. Um ein anders Betriebssystem zu untersttzen, muss eine neue Klasse geschrieben werden, die von CertHandle erbt und die Funktionen getPath() und isConnected() entsprechend berschreibt. Anschlieend muss der Aufruf des Konstruktors von LocalMaintenance mit der neuen Klasse angepasst werden.

Abbildung 18: LocalMaintenance Konstruktor Der Anschluss des USB-Dongles wird geloggt und danach die Authentifizierung initialisiert. Hierzu wird der Techniker zunchst nach seinem Passwort gefragt. Das Passwort entschlsselt einen PrivateKey, der auf dem Stick in der Datei technician.prk gespeichert ist. Anschlieend wird mit der Challenge-Response Methode berprft, ob dieser PrivatKey zu dem im Zertifikat enthaltenen PublicKey gehrt. Das Zertifikat des Technikers befindet sich in der Datei technician.cert. Der Techniker hat drei Versuche um das Passwort richtig einzugeben, jeder Fehlversuch wird ebenfalls geloggt. Nach dem dritten Fehlversuch wird automatisch eine Meldung mit den Daten des Technikers an die Leasingfirma gesandt und das System fr zehn Minuten gesperrt. Dies gibt der Leasingfirma genug Zeit, um auf einen eventuellen unbefugten Zugriffsversuch entsprechend zu reagieren. Wenn die Verifizierung jedoch erfolgreich war, ffnet sich dem Techniker das LocalMaintenanceForm (Abbildung 19). Hier

Kapitel 5: Implementierung

29

werden grundstzliche Informationen angezeigt und die Einstellungen der Kaffeeautomaten knnen gendert werden.

Abbildung 19: LocalMaintenanceForm Nach Schlieen des Formulars wird dokumentiert, welcher Techniker nderungen vorgenommen hat und das System wiederum eineinhalb Minuten gesperrt. Somit hat der Server Zeit, die Einstellungen an die angeschlossenen Kaffeeautomaten zu bertragen. Fr die zu bertragenden Einstellungen wurden exemplarisch die Ein- und Ausschaltzeit sowie die einzuschaltenden Tage implementiert.

5.2.3 ServerTrapReceiver und TrapReceiver

TrapReceiver ist eine abstrakte Klasse zum Empfangen von Traps. Sie basiert auf der Beispielimplementierung MultiThreadedTrapReceiver des SNMP4J Projekts und implementiert das Interface org.snmp4j.CommandResponder. Die Klasse ServerTrapReceiver erbt von TrapReceiver und berschreibt die Funktion processPdu(event). Mit dieser Methode wird die Reaktion auf eingehende Traps festgelegt. Da ein Kaffeeautomat nur einen Trap sendet, wenn ein uerst schwerwiegender Fehler vorliegt, werden die ankommenden Traps von der Klasse ServerTrapReceiver direkt an die Leasingfirma weitergeleitet. Hier kann im Endprodukt jedoch eine differenziertere Verarbeitung der Traps umgesetzt werden.

Kapitel 5: Implementierung

30

5.2.4 AutoMaintenance
Die AutoMaintenance stellt das sptere Kernstck der Wartungs- und Diagnoseeinheit dar. Die Aufgabe der Klasse liegt darin, Fehlercodes oder Strungen der Kaffeeautomaten zu erkennen und entsprechende Gegenmanahmen einzuleiten. Aufgrund von mangelnden Kenntnissen ber die Strungsmeldungen der Kaffeeautomaten, sind in diesem Prototyp keine Fehlercodes implementiert wurden. Somit nimmt die AutoMaintenance einen abgespeckten Aufgabenbereich wahr. In regelmigen Zeitintervallen wird die Netzwerkadresse des Servers ermittelt und anschlieend eine SNMP Anfrage ber die Broadcastadresse versandt. Der Server registriert alle eingehenden Antworten und filtert ber den Inhalt, nicht zur Leasingfirma gehrende Gerte, heraus. Bei den Verbleibenden handelt es sich um die gesuchten Kaffeeautomaten. Die IP-Adressen der Automaten werden in eine Liste aufgenommen, aus welcher die Anzahl der angeschlossenen Clients ermittelt wird. Danach wird der Status eines jeden Gertes geprft. Wenn ein Fehlerstatus entdeckt wird, dokumentiert diesen das System sofort. In jedem fnften Intervall werden die zentralen Einstellungen an alle Adressen in der Liste bermittelt. Somit knnen auch neue, nicht konfigurierte Kaffeeautomaten sofort in das System integriert werden.

5.3 Leasingfirma

Im Endprodukt wird dieser Teil der Implementierung den wahrscheinlich grten Umfang besitzen. Wie bereits im Design beschrieben, sollte an dieser Stelle eine ausfhrliche Technikerverwaltung mit CRL und ein weitreichendes Ticketsystem fr eingehende Traps zu finden sein. Da das Hauptaugenmerkt dieser Arbeit nicht auf diesen Verwaltungsmechanismen liegt, wurden nur die Kernfunktionen der Leasingfirma umgesetzt. In der Implementierung wird die Leasingfirma durch die Klasse Lessor reprsentiert.

Abbildung 20: Lessor

Kapitel 5: Implementierung

31

5.3.1 LessorTrapReceiver
Wie auch der ServerTrapReceiver, erweitert der LessorTrapReceiver die Klasse TrapReceiver und berschreibt die Funktion processPdu(event). Der Empfang eines Traps wird dokumentiert, und anschlieend in ein stark vereinfachtes Ticketsystem bernommen. Wenn der Nutzer nicht das TrapManagement geffnet hat, wird er mit einer Meldung ber den Eingang informiert.

Abbildung 21: TrapManagement Ansicht

Da eingegangene Traps sofort in einer Ini-Datei gespeichert werden, kann auch nach Schlieen und erneutem ffnen des Programms auf alte Traps zugegriffen werden. ber den Button Lschen kann die Ausgewhlte Meldung permanent gelscht werden. Bei einem Klick auf den Button Zum Client verbinden wird die Ansicht ClientVerbindung(Abbildung 22) geladen. Die Ziel IP-Adresse wird automatisch bernommen. In dieser Ansicht knnen SNMP Befehle gesendet und Antworten empfangen werden. Mit der Auswahl der Methode GET oder SET wird die Ansicht entsprechend angepasst. Wenn eine Anfrage durch Hinzufgen von OID mit einer eventuellen Zuweisung Erstellt wurde, kann die Anfrage bertragen werden. Antworten, die das System daraufhin erhlt, werden simultan in die OID Liste (Abbildung 22, rechts) bernommen und knnen direkt fr weiter Anfragen verwendet werden.

Kapitel 5: Implementierung

32

Abbildung 22: ClientVerbindung-Ansicht

5.3.2 TechnicianManagement
Diese Klasse bernimmt die Aufgabe einer CA. TechnicianManagement ist eine abstrakte Klasse, welche auf die Funktionen eines CertHandle zurckgreift und somit auf das verwendete Betriebssystem beim Aufruf des Konstruktors angepasst werden muss. Bei einer Umsetzung muss die Methode saveTech(tech) berschrieben werden. Diese dient der Speicherung und Verwaltung erstellter Techniker. Der Prototyp verwendet die Implementierung NoSaveTMan, welche keine Speicherung oder Verwaltung von Technikern vorsieht. Das Programm stellt zum TechnicianManagement drei Ansichten bereit, welche die entsprechenden Funktionen verfgbar machen. Bei der Erstinbetriebnahme muss ein neues Firmenzertifikat erstellt werden. Wenn keine Key-Dateien gefunden werden knnen, weist das System auf eine Neuerstellung hin. Dazu gibt man in der Neues Firmenzertifikat Ansicht das Land und den Namen der Firma ein. Bei Klick auf den Button, werden nun vom TechnicianManagement ein zuflliger PublicKey, der dazu passende PrivateKey erstellt und die Firmendaten in der Datei TManagementSettings.ini gespeichert. Die Datei ca.puk muss nun auf alle Kaffeeautomaten der Leasingfirma bertragen werden. Dies geschieht am besten direkt bei der Fertigung. Nun knnen mit der Neuer Techniker-Ansicht, neue Techniker-Zertifikate erstellt werden.

Kapitel 5: Implementierung

33

Abbildung 23: Neuer Techniker-Ansicht Hier werden Name, Passwort und gegebenenfalls eine Unterorganisation des Technikers eingegeben. Mit Klick auf den Button Techniker erstellen wird, falls ein USB-Dongle angeschlossen ist, ein Technikerzertifikat erstellt und anschlieend mit dem verschlsselten PrivateKey auf den USB-Stick bertragen. Das erstellte Zertifikat besitzt eine festgelegt Gltigkeitsdauer von einem Jahr. Der Vorgang wird abgebrochen und der Nutzer darauf hingewiesen, falls kein USB-Dongle erkannt wurde. In der Ansicht Techniker bearbeiten kann ein bereits erstellter Techniker bearbeitet werden oder die Gltigkeit seines Zertifikates erneut auf ein Jahr gesetzt werden. Wenn ein USB-Dongle angeschlossen ist, werden die darauf befindlichen Daten des Technikers automatisch in die Anzeige geladen. Dies kann jedoch aufgrund der Komplexitt asynchroner Verschlsselung einen Moment dauern. Wenn der Nutzer einen Techniker bearbeiten mchte, obwohl kein USB-Dongle angeschlossen ist, wird er ebenfalls darauf hingewiesen.

Kapitel 6: Fazit

34

6 Fazit

Durch die Entwicklung eines Systems zur Wartung und Diagnose konnte das Einsatzgebiet der Impressa X9 erheblich erweitert werden. Als Gesamtkonstrukt ist nun auch der Weg fr die Verwendung in groen Firmen mit vielen Kunden geebnet. Die Schaffung einer Wartungsund Diagnoseeinheit bildet die Grundlage fr zuknftige Erweiterungen des Systems, da nun Module wie eine Nutzerverwaltung bequem eingerichtet werden knnen. Darber hinaus knnen sie durch die Option der Fernwartung, verwaltet werden. Aufgrund der hohen Komplexitt der verwendeten Technologien, konnten nicht alle Konzepte der Designphase eins zu eins umgesetzt werden. Jedoch stellen die vorgenommenen Anpassungen nur eine geringfgige Einschrnkung der Funktionalitt dar. Der innerhalb dieser Arbeit entworfene Prototyp, ist keinesfalls vollstndig und dient nur dem Proof of Concept. Trotz kleiner Einschrnkungen durch den gegebenen finanziellen, beziehungsweise zeitlichen Rahmen, konnten die Ziele die zu Beginn der Arbeit erstellt wurden, zufriedenstellend erreicht werden.

Literaturverzeichnis

vi

Literaturverzeichnis
[1] Euro-Informationen, Berlin : EU-Info.Deutschland - Deutsche trinken mehr Kaffee als Wasser. http://www.eu-info.de/deutsche-europapolitik/Umfragen-StatistikenDeutschland/kaffee/, Stand: Dezember 2010 [2] Drr, Dr. Ingolf : Deutsches Grnes Kreuz e. V. - Kaffee: Wirkung auf die Gesundheit. http://www.dgk.de/fileadmin/user_upload/Fachleute_pdf/kaffee-publikumsbrosch_st.pdf, Stand: Dezember 2010 [3] JURA Elektroapparate AG: Technische Daten IMPRESSA X9 Win. http://www.jura.com/de/home_x/products_commercial_use2/technical_data_jura_impre ssa_x9win_eu-int.pdf, Stand: November 2010 [4] JURA Elektroapparate AG: Das Buch zur IMPRESSA X9 Win. http://www.jura.com/de/home_x/service_support/manual_home/manualmachines/download_manual_jura_impressa_x9win_deutsch.pdf, Stand: November 2010 [5] JURA Gastro Vertriebs-GmbH : JURA Gastro Vertriebs-GmbH Grainau. http://www.juraworldgastro.de/IMPRESSA-X9-Win-p19.html, Stand: Dezember 2010 [6] Knsel, Marlene und Stefan Mazur, Bachelorarbeit "Design und Implementierung eines Multimedia- und Kommunikationsrechners fr moderne Kaffeemaschinen", 2010. [7] Tsolkas, Alexander und Klaus Schmidt, "Zugriffskontrolle ber Authentifizierung" in Rollen und Berechtigungskonzepte. Wiesbaden, Deutschland: Vieweg+Teubner Verlag / Springer Fachmedien Wiesbaden GmbH, 2010, Kap. 7, S. 127-157. [8] Kappes, Martin , "Authentifikation" in Netzwerk- und Datensicherheit. Wiesbaden, Deutschland: B.G. Teubner Verlag / GWV Fachverlage GmbH, 2007, Kap. 3, S. 39-68. [9] Maus, Thomas , "Das Passwort ist tot lang lebe das Passwort!" Datenschutz und Datensicherheit - DuD, Vol. 32, Nr. 8, S. 537-542, 2008. [10] IGEL Technology: Smart Card thin Client: Flexible thin clients with smart card readers. http://smartcardthinclient.com/, Stand: Dezember 2010

Literaturverzeichnis

vii

[11] Bless, Roland and Mink, Stefan and Conrad, Michael and Kutzner, Kendy and Bla, Erik-Oliver and Hof, Hans-Joachim and Schller, Marcus , "Digitale Zertifikate, PKI und PMI" in Sichere Netzwerkkommunikation.: Springer Berlin Heidelberg, 2005, S. 349-395. [12] Cooper, D. : Internet X.509 Public Key http://tools.ietf.org/html/rfc5280, Stand: Mai 2008 Infrastructure Certificate.

[13] Ullenboom, Christian : Java ist auch eine Insel (8. Auflage). http://www.iks.hsmerseburg.de/~uschroet/Literatur/Java_Lit/JAVA_Insel/javainsel_26_001.htm#mjc78fb 10cd3a6d5dc3e8d94d0d6162423, Stand: Dezember 2010 [14] Mansfeld, Adam : coffeehaus.de / Notizen / X509 Zertifikate mit Java erstellen. http://coffeehaus.de/Notizen/X509ZertifikateMitJavaErstellen, Stand: Dezember 2010 [15] Bouncy Castle, Legion of the : bouncycastle.org. http://www.bouncycastle.org/, Stand: Dezember 2010 [16] SNMP Research International, Inc. : Simple Network Management Protocol FAQ. http://www.snmp.com/FAQs/, Stand: Dezember 2010 [17] Fock, Frank : SNMP4J - Free Open Source http://www.snmp4j.org/index.html, Stand: Dezember 2010 SNMP API for Java.

[18] Wlfl, Thomas , "Rckruf von Zertifikaten" in Formale Modellierung von Authentifizierung und Authorisierung infrastrukturen, DUV, Ed., 2006, Kap. 4, S. 4356. [19] Brooks Automation (Germany) GmbH - RFID Division: RFID - Erklrung der Funktionsweise. http://www.brooks-rfid.com/de/rfid-grundlagen/rfid-technik.html, Stand: Dezember 2010 [20] SecureNet Solutions. Stand: Dezember 2010 http://www.securenetsol.com/catalog/images/image009.jpg,

[21] Rask, Johan : Introducing to snmp4j Jayway Team Blog. http://blog.jayway.com/2010/05/21/introduction-to-snmp4j/, Stand: Dezember 2010

Literaturverzeichnis

viii

[22] Amazon.com, Inc. oder Tochtergesellschaften : Super Talent STU4GPCN Pico-C 4GB Speicherstick USB 2.0. http://www.amazon.de/Talent-STU4GPCN-Pico-CSpeicherstick-nickel/dp/B001MF9TC2/ref=sr_1_7?ie=UTF8&qid=1293572533&sr=87, Stand: Dezember 2010

Anhang

ix

Anhang
Ausschnitt der im Projekt verwendeten MIB

CoffeeMLessorMIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32 FROM SNMPv2-SMI ; UniBwM MODULE-IDENTITY LAST-UPDATED "200201300000Z" ORGANIZATION "Universitaet der Bundeswehr Muenchen" CONTACT-INFO "postal:Kai Freytag email:kai.freytag&unibw.de" DESCRIPTION "MIB structure used by UniBwM" REVISION DESCRIPTION "Kaffeeautomat" ::= { enterprises 24094} --CoffeeMLessor ClientServer CMaschine UserManagement OBJECT IDENTIFIER ::= {UniBwM 1} OBJECT IDENTIFIER ::= {CoffeeMLessor 1} OBJECT IDENTIFIER ::= {CoffeeMLessor 2} OBJECT IDENTIFIER ::= {CoffeeMLessor 3} Net-SNMP enterprise-specific management objects "200201300000Z"

cMaschine

OBJECT IDENTIFIER ::= {ClientServer 1}

Status OBJECT-TYPE

Anhang
SYNTAX MAX-ACCESS STATUS Integer32 read-only

current

DESCRIPTION "Status of the Server. 1 -> OK ; 0 -> see ErrorCode" ::= {ClientServer 2 }

ErrorCode OBJECT-TYPE SYNTAX MAX-ACCESS STATUS Integer32 read-only

current

DESCRIPTION "If State is 0 here can be found the ErrorCode" ::= {ClientServer 3 }

NOClients OBJECT-TYPE SYNTAX MAX-ACCESS STATUS Integer32 read-only

current

DESCRIPTION "Number of connected Clients" ::= { ClientServer 4 }

trapOn OBJECT-TYPE SYNTAX MAX-ACCESS STATUS Integer32 read-write

current

DESCRIPTION "If it is 1 the Server will send TrapMessages" ::= { ClientServer 5 }

Anhang

xi

Struktur-Ausschnitt der im Projekt verwendeten MIB

Abbildung 24: Ausschnitt der MIB-Struktur

Anhang

xii

CD-Rom

Inhalt:
Source-Code, inklusive des Originalcodes, im Verzeichnis src/ JavaDoc im Verzeichnis doc/ Digitale Kopie dieser Bachelorarbeit