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

Transkript

1 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

2 10.1 Unsicherheit in Verteilten Systemen In einem verteilten System kann man ohne weitere Maßnahmen nicht sicher sein, ob sich alle Komponenten wie erwartet verhalten werden oder kompromittiert sind: Kompromittierter : Kanal Mögliche Maßnahmen: -Eingaben nie vertrauen und stets prüfen Kompromittierter : Kanal Mögliche Maßnahmen: dienst zertifizieren Kompromittierter Kommunikationskanal: Kanal Mögliche Maßnahmen: Verschlüsselung und Integritätsprüfung gegen Mitlesen und Veränderung 10-2

3 10.2 Sicherer Kommunikationskanal Ein ungeschützter Kommunikationskanal kann an verschiedensten Stellen mitgelesen werden: Auf einem der beteiligten Hosts (durch Administrator) Auf jedem Host, der über denselben Hub angeschlossen ist Auf jedem Router Schutz vor Mitlesen oder Veränderung: Sicherer Kommunikationskanal Verschiedene Realisierungsmöglichkeiten: Absicherung direkt in der Anwendung Transparente Sicherung durch generisches Protokoll Immer bestehendes und geprüftes Verschlüsselungsverfahren verwenden, ungeprüfte Eigenerfindungen haben so gut wie immer Schwächen 10-3

4 10.3 SSL - Secure Sockets Layer Das Secure Sockets Layer-Protokoll stellt einen sicheren Kommunikationskanal bereit, der Vertraulichkeit und Integrität der Daten durch symmetrische Verschlüsselung ermöglicht SSL ist bzgl. des TCP/IP-Stacks ein Anwendungsprotokoll und nutzt TCP Höherwertige Anwendungsprotokolle wie HTTP oder SMTP können über ein SSL-API implementiert werden 1994 von Netscape entwickelt, inzwischen verschiedene Implementierungen der Version 3.0 wie z.b. OpenSSL, Java Cryptography Extensions 10-4

5 10.4 SSL - Funktionsweise Symmetrische Ende-zu-Ende-Verschlüsselung, unterstützt verschiedene Algorithmen wie DES, Triple DES oder AES (Rijndael) Automatische Fragmentierung und optional Komprimierung der Daten Erfordert verlässliches Protokoll als Basis. Zumeist TCP, kann aber auch auf anderen Protokollstapeln laufen Der verwendete symmetrische Schlüssel wird zu Beginn während einer Handshake-Phase ausgetauscht. Unterstützt werden dafür u. a. der Diffie-Hellman Schlüsselaustausch oder asymmetrische RSA-Verschlüsselung Sicherung der Nachrichten-Integrität und Authentizität durch Anhängen eines kombinierten MD5 und SHA Hashwertes 10-5

6 10.5 SSL-Handshake client hello: SSL Version, unterstützte Verschlüsselungen, Zufallsdaten Auth. des Zertifikats Verschlüsselung eines pre master secrets mit public key des s master secret, symmetrischer session key server hello: SSL Version, public key, Verschlüsselung, Zufallsdaten, Zertifikat (optional: Zertifikatanforderung) C(pre master secret), optional: Zertifikat optional: Auth. des Zertifikats Entschlüsselung des pre master secrets master secret, symm. session key Symmetrisch verschlüsselter Kanal 10-6

7 Angriffsszenario: Man in the Middle Angriff client hello server hello Attacker server hello C(pre m secret) C(pre m secret) m secret, key key(daten) m secret, key m secret, key Bei einem Man in the Middle (MITM)-Angriff gibt sich ein bösartiger Prozess als aus, z.b. um ein Passwort abzufangen: 1 Der Angreifer muss den Datenverkehr zum auf sich umleiten (Routing auf ändern, Router übernehmen, ARP-Spoofing, etc.) 2 Angreifer speichert Inhalt der hellos und leitet sie angepasst weiter: Er ersetzt den public key im server hello durch seinen eigenen 3 Der Angreifer kann nun das pre master secret entschlüsseln und an den ursprünglichen weiterleiten (mit dessen key verschlüsselt) 4 Angreifer generiert master secret und den session key kann und die symmetrisch verschlüsselte Nutzdatenübertragung abhören 10-7

8 Authentifizierung durch Zertifikate Zur Vermeidung eines MITM-Angriffes muss der die Manipulation des server hello erkennen server hello enthält ein Zertifikat (üblicherweise X.509) Zertifikate: Besitzen Angaben über Zertifizierten, Herausgeber, Zeitdauer Herausgeber hat das Zertifikat digital mit seinem private key signiert Überprüfung auf Echtheit unter Benutzung des public key aus dem Zertifikat des Herausgebers Verlagerung der Vertrauensfrage auf den Herausgeber Zertifikatsketten möglich, das Zertifikat des Zertifikatherausgebers kann wieder zertifiziert sein Im Internet: Spezielle Unternehmen wie Verisign oder Thawte stellen Zertifikate gegen Gebühr aus 10-8

9 Vermeidung eines MITM-Angriff durch Zertifikate Der Angreifer muss das -Zertifikat ändern, um seinen eigenen public key einzuschreiben bzw ein gänzlich neues Zertifikat erstellen Verlust der Signierung Für den ist keine Manipulation erkennbar, nur, dass das Zertifikat nicht von einer anerkannten Institution signiert ist Im Internet: Webbrowser fragt beim Benutzer nach, ob er das Zertifikat akzeptiert und warnt bei nicht von anerkannten Institutionen signierten Zertifikaten 10-9