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

Größe: px
Ab Seite anzeigen:

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

Transkript

1 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

2 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

3 Inhaltsverzeichnis Danksagung i 1 Einleitung Motivation Aufbau Kontext Die Expertensysteme Pixel Advisor GridXP Aufgabenstellung Anforderungen Grundlagen Regelbasierte Expertensysteme JBoss Rules/Drools Sichere Kommunikation im Internet Kryptographische Hashfunktionen Asymmetrische Verschlüsselung Zertifikate Der X.509 Standard Authentisierung und verschlüsselte Kommunikation durch SSL Entwurf Architektur Anwendungsfälle und Detailanforderungen Implementierung Die SSL Infrastruktur Trust- und KeyManager Das Kommunikationsprotokoll Die Nachrichtenklassen Der Server Der ClientHandler ii

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

5 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

6 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 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

7 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

8 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 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

9 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 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 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

10 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

11 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

12 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 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

13 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

14 Abbildung 3.1: Bestandteile eines regelbasierten Expertensystems 11

15 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

16 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

17 Hashfunktionen, asymmetrische Verschlüsselung mit öffentlichen und privaten Schlüsseln und digitale Zertifikate erklärt. Danach wird die Funktionsweise des SSL 1 Protokolls dargestellt 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) 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

18 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] 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 adresse 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

19 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 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

20 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 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 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

21 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

22 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

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

24 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

25 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

26 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

27 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

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

29 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 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

30 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

31 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

32 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 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

33 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

34 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

35 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

36 5.3 Der Server Abbildung 5.5: UML Server und ClientHandler 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 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

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS Digitale Signatur Digitale Signatur kombiniert Hash Funktion und Signatur M, SIGK(HASH(M)) wichtige Frage: Wie wird der Bithaufen M interpretiert Struktur von M muss klar definiert sein Wie weiss ich,

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Seminar Neue Techologien in Internet und WWW

Seminar Neue Techologien in Internet und WWW Seminar Neue Techologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Christian Raschka chrisra@informatik.uni-jena.de Seminar Neue Internettechnologien

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine)

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine) Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen Vorlesung im Sommersemester 2010 an der Technischen Universität Ilmenau von Privatdozent Dr.-Ing. habil. Jürgen

Mehr

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de 1 SSL/TLS 26.10.2005 Institut für Mathematik, TU Berlin Rosa Freund -- rosa@pool.math.tu-berlin.de 2 Übersicht Einführung SSL vs. TLS SSL: Anwendung und PKI SSL Protokoll: Record Protocol und Handshake

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo Kryptographische Verfahren zur Datenübertragung im Internet Patrick Schmid, Martin Sommer, Elvis Corbo 1. Einführung Übersicht Grundlagen Verschlüsselungsarten Symmetrisch DES, AES Asymmetrisch RSA Hybrid

Mehr

IT-Sicherheit - Sicherheit vernetzter Systeme -

IT-Sicherheit - Sicherheit vernetzter Systeme - IT-Sicherheit - Sicherheit vernetzter Systeme - Kapitel 12: Netzsicherheit - Schicht 4: Transport Layer / TLS 1 Inhalt Transport Layer Funktionen Secure Socket Layer (); Transport Layer Security (TLS)

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Digital Rights Management 4FriendsOnly.com Internet Technologies AG Vorlesung im Sommersemester an der Technischen Universität Ilmenau

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner Adressübersetzung und Tunnelbildung Bastian Görstner Gliederung 1. NAT 1. Was ist ein NAT 2. Kategorisierung 2. VPN 1. Was heißt VPN 2. Varianten 3. Tunneling 4. Security Bastian Görstner 2 NAT = Network

Mehr

Ein Überblick über Security-Setups von E-Banking Websites

Ein Überblick über Security-Setups von E-Banking Websites Ein Überblick über Security-Setups von E-Banking Websites Stefan Huber www.sthu.org Linuxwochen Linz 2015 31. Mai 2015 Basierend auf Testergebnissen vom 28.03.2015 aus https://www.sthu.org/blog/11-tls-dnssec-ebanking/

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

Emailverschlüsselung mit Thunderbird

Emailverschlüsselung mit Thunderbird Emailverschlüsselung mit Thunderbird mit einer kurzen Einführung zu PGP und S/MIME Helmut Schweinzer 3.11.12 6. Erlanger Linuxtag Übersicht Warum Signieren/Verschlüsseln Email-Transport Verschlüsselung

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Hacken von implementierungsspezifischen! SSL-Schwachstellen

Hacken von implementierungsspezifischen! SSL-Schwachstellen Hacken von implementierungsspezifischen! SSL-Schwachstellen Basic-Constraints-Schwachstelle Null-Präfix-Attacke Thomas Konrad, FH St. Pölten, Studiengang IT Security, is072033@fhstp.ac.at Wozu SSL? Authentizität

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Vortrag Keysigning Party

Vortrag Keysigning Party Vortrag Keysigning Party Benjamin Bratkus Fingerprint: 3F67 365D EA64 7774 EA09 245B 53E8 534B 0BEA 0A13 (Certifcation Key) Fingerprint: A7C3 5294 E25B B860 DD3A B65A DE85 E555 101F 5FB6 (Working Key)

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover Sicherheitstage WS 04/05 Birgit Gersbeck-Schierholz, RRZN Einleitung und Überblick Warum werden digitale Signaturen

Mehr

Terravis - Hinweise zur Implementierung der SSL-Verbindung

Terravis - Hinweise zur Implementierung der SSL-Verbindung Terravis - Hinweise zur Implementierung der -Verbindung Version: 1.0 Datum: 19.04.2013 Autoren: Claude Eisenhut -Hinweise.docx 19.04.2013 Seite 1/8 Verzeichnis: Einführung... 3 Kontaktpersonen 3 Allgemeines...

Mehr

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

> Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012

> Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012 > Verteilte Systeme Übung 10 Deadlocks, Fehler, Security Philipp Kegel Sommersemester 2012 Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster

Mehr

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt April 2011 Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt 1. Einleitung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen Netze leicht mitlesen oder verändern.

Mehr

Digitale Unterschriften Grundlagen der digitalen Unterschriften Hash-Then-Sign Unterschriften Public-Key Infrastrukturen (PKI) Digitale Signaturen

Digitale Unterschriften Grundlagen der digitalen Unterschriften Hash-Then-Sign Unterschriften Public-Key Infrastrukturen (PKI) Digitale Signaturen Sommersemester 2008 Digitale Unterschriften Unterschrift von Hand : Physikalische Verbindung mit dem unterschriebenen Dokument (beides steht auf dem gleichen Blatt). Fälschen erfordert einiges Geschick

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003 Page 1 of 23 SSL Aktivierung für OWA 2003 Kategorie : Exchange Server 2003 Veröffentlicht von webmaster am 20.05.2005 Die Aktivierung von SSL, für Outlook Web Access 2003 (OWA), kann mit einem selbst ausgestellten

Mehr

Vorlesung Kryptographie

Vorlesung Kryptographie Vorlesung Kryptographie Teil 2 Dr. Jan Vorbrüggen Übersicht Teil 1 (Nicht-) Ziele Steganographie vs. Kryptographie Historie Annahmen Diffie-Hellman Angriffe Teil 2 Symmetrische Verfahren Asymmetrische

Mehr

Die Idee des Jahres 2013: Kommunikation verschlüsseln

Die Idee des Jahres 2013: Kommunikation verschlüsseln Die Idee des Jahres 2013: Kommunikation verschlüsseln Kommunikationsschema bei Email MailServer MailServer Internet PC PC Sender Empfänger Verschlüsselung ist... immer eine Vereinbarung zwischen zwei Kommunikationspartnern:

Mehr

Netzwerksicherheit Übung 5 Transport Layer Security

Netzwerksicherheit Übung 5 Transport Layer Security Netzwerksicherheit Übung 5 Transport Layer Security Tobias Limmer, Christoph Sommer, David Eckhoff Computer Networks and Communication Systems Dept. of Computer Science, University of Erlangen-Nuremberg,

Mehr

Was ist Kryptographie

Was ist Kryptographie Was ist Kryptographie Kryptographie Die Wissenschaft, mit mathematischen Methoden Informationen zu verschlüsseln und zu entschlüsseln. Eine Methode des sicheren Senden von Informationen über unsichere

Mehr

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Sicherheitskonzept und Sicherheitspru fung Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Einführung Die Firma MVZ Labor PD Dr. Volkmann und Kollegen GbR, nachstehend als Labor

Mehr

Dateien und EMails verschlüsseln mit GPG

Dateien und EMails verschlüsseln mit GPG Dateien und EMails verschlüsseln mit GPG Linuxwochen Linz 2013 Mario Koppensteiner June 16, 2013 Table of contents Theorie Software was man braucht Schlüssel erstellen Schlüsselserver Beispiele Fragen

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

E-Mails versenden aber sicher!

E-Mails versenden aber sicher! E-Mails versenden aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 mit den eingetragenen Materialnummern Inhalt Inhalt... 2 1 Vorwort... 3 2 Allgemeines zur Verschlüsselung...

Mehr

Secure Socket Layer (SSL) - Zertifikate

Secure Socket Layer (SSL) - Zertifikate e Einführung Zur Übertragung sensibler Daten über das Internet wurde das SSL-Protokoll entwickelt. SSL steht für Secure Socket Layer (dt. "sichere Sockelschicht") das von der Firma Netscape und RSA Data

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Rechneranmeldung mit Smartcard oder USB-Token

Rechneranmeldung mit Smartcard oder USB-Token Rechneranmeldung mit Smartcard oder USB-Token Verfahren zur Authentifizierung am Rechnersystem und angebotenen Diensten, SS2005 1 Inhalt: 1. Systemanmeldung 2. Grundlagen 3. Technik (letzte Woche) 4. Standards

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Verschlüsselungsverfahren

Verschlüsselungsverfahren Verschlüsselungsverfahren Herrn Breder hat es nach dem Studium nach München verschlagen. Seine Studienkollegin Frau Ahrend wohnt in Heidelberg. Da beide beruflich sehr stark einspannt sind, gibt es keine

Mehr

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase Verteilte Systeme Sicherheit Prof. Dr. Oliver Haase 1 Einführung weitere Anforderung neben Verlässlichkeit (zur Erinnerung: Verfügbarkeit, Zuverlässigkeit, Funktionssicherheit (Safety) und Wartbarkeit)

Mehr

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 4: SSL/TLS Dr. Erwin Hoffmann

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 4: SSL/TLS Dr. Erwin Hoffmann Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 4: SSL/TLS Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de Secure Socket Layer (SSL) Tranport Layser Security (TLS)

Mehr

1 Was ist SSL? 3 1.1 SSL im OSI-Modell... 3 1.2 Der SSL-Verbindungsaufbau... 3

1 Was ist SSL? 3 1.1 SSL im OSI-Modell... 3 1.2 Der SSL-Verbindungsaufbau... 3 SSL und Zertifikate INHALTSVERZEICHNIS INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Was ist SSL? 3 1.1 SSL im OSI-Modell.................................... 3 1.2 Der SSL-Verbindungsaufbau...............................

Mehr

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden Vorwort In unserem elektronischen Zeitalter erfolgt der Austausch von Informationen mehr und mehr über elektronische Medien wie zum Beispiel

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

IT-Sicherheit: Übung 6

IT-Sicherheit: Übung 6 IT-Sicherheit: Übung 6 Zertifikate, Kryptographie (Diffie-Hellman), Sicherheitsprotokolle (SSL/TLS) Zertifikate! Problem: Woher weiß Bob, dass K E Alice zu Alice gehört?! Persönlicher Austausch des öffentlichen

Mehr

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat?

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? 1 / 32 Veranstaltungsreihe Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? Veranstalter sind: 15. Mai bis 3. Juli 2008 der Arbeitskreis Vorratsdatenspeicherung

Mehr

Beweisbar sichere Verschlüsselung

Beweisbar sichere Verschlüsselung Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 12

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

IT-Security on Cloud Computing

IT-Security on Cloud Computing Abbildung 1: IT-Sicherheit des Cloud Computing Name, Vorname: Ebert, Philipp Geb.: 23.06.1993 Studiengang: Angewandte Informatik, 3. FS Beruf: IT-Systemelektroniker Abgabedatum: 08.12.2014 Kurzfassung

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

Mehr

SSL/TLS: Ein Überblick

SSL/TLS: Ein Überblick SSL/TLS: Ein Überblick Wie funktioniert das sichere Internet? Dirk Geschke Linux User Group Erding 28. März 2012 Dirk Geschke (LUG-Erding) SSL/TLS 28. März 2012 1 / 26 Gliederung 1 Einleitunng 2 Verschlüsselung

Mehr

Dokumentation Mail-Test

Dokumentation Mail-Test Dokumentation Mail-Test 1. Verschicken vordefinierter E-Mails... 1 Zweck des Testmailservice... 1 Fingerprint... 2 Explizit/Implizit Signed Mails... 2 Attachment... 3 "A mail with a signed attachment -

Mehr

S Kreis- und Stadtsparkasse

S Kreis- und Stadtsparkasse S Kreis- und Stadtsparkasse Kaufbeuren im September 2011 Informationen zum sicheren E-Mailverkehr Mit diesem Schreiben wollen wir Ihnen Inhalt: 1. die Gründe für die Einführung von Sichere E-Mail näher

Mehr

SSL-Zertifikate. Dr. Christopher Kunz

SSL-Zertifikate. Dr. Christopher Kunz SSL-Zertifikate Dr. Christopher Kunz Ihr Referent _ Dr. Christopher Kunz _ CEO Hosting filoo GmbH / TK AG _ Promotion IT Security _ X.509 / SSL _ Vorträge auf Konferenzen _ OSDC 2012: SSL-Hacks _ OSDC

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

IT-Sicherheit: Kryptographie. Asymmetrische Kryptographie

IT-Sicherheit: Kryptographie. Asymmetrische Kryptographie IT-Sicherheit: Kryptographie Asymmetrische Kryptographie Fragen zur Übung 5 C oder Java? Ja (gerne auch Python); Tips waren allerdings nur für C Wie ist das mit der nonce? Genau! (Die Erkennung und geeignete

Mehr

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein VoIP-Verschlüsselung Verschlüsselung im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein Einordnung VoIP in DFNFernsprechen VoIP seit 5 Jahren im DFN verfügbar VoIP ist Teil des Fernsprechdienstes DFNFernsprechen

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/ Einführung in OpenSSL und X.509-Zertifikate Martin Kaiser http://www.kaiser.cx/ Über mich Elektrotechnik-Studium Uni Karlsruhe System-Ingenieur UNIX und IP-Netze (2001-2003) Embedded Software-Entwicklung

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen Fabian Pretsch Ziel Implementierung von XML Encryption/Signature in Java Testen der Implementierung auf

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr

Online Banking. de Lorenzo, Hopfgartner, Leupold. February 13, 2011. de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29

Online Banking. de Lorenzo, Hopfgartner, Leupold. February 13, 2011. de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29 Online Banking de Lorenzo, Hopfgartner, Leupold February 13, 2011 de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29 Übersicht Geschichte Bedenken Verschlüsselungsarten Netzwerkarchitektur

Mehr

Ausarbeitung zum Vortrag. Secure Socket Layer. von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof.

Ausarbeitung zum Vortrag. Secure Socket Layer. von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof. Ausarbeitung zum Vortrag Secure Socket Layer von Jelle Hellmann im Rahmen der Vorlesung Sicherheit in Datennetzen von Herrn Prof. Schäfer an der im WS 2004/2005 Inhaltsverzeichnis: INHALTSVERZEICHNIS:...

Mehr