IT-Sicherheit für 04INM 5. Transport Layer Security Secure Socket Layer Protocol (SSL)

Transkript

1 IT-Sicherheit für 04INM 5. Transport Layer Security Prof. Dr. Uwe Petermann Dept. of Computer Science University of Applied Sciences Leipzig P.O.B D Leipzig (Germany) May 29, Einordnung in den Protokollstapel OSI-Modell TCP/IP Standards/Protokolle Anwendungsschicht NFS Datendarstellung Anwendung Telnet FTP SMTP DNS SNMP XDR Kommunikationssteuerung Transport Transport SSL ssh TLS PCT SGC TCP UDP Vermittlung Vermittlung IP ICMP IGMP Sicherung Netzwerk- Ethernet Tokenring Bitübertragung zugang... SNMP Simple Network Management Protocoll ICMP Internet Control Message Protocoll ARP Address Resolution Protocoll RARP Reverse Address Resolution Protocoll IGMP Internet Group Management Protocoll U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 1 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 3 IT-Security, 05INM 5. Transport Layer Security Überblick: Literatur: z.b.: [1, 2] 1. Einordnung in den Protokollstapel 2. Secure Socket Layer Protocol (SSL) 3. Secure Shell (ssh) 4. Private Communication Technology (PCT) 5. Transport Layer Security (TLS) 6. Server Gated Cryptography (SGC) 1. Bestandteile: 2 Schichten... Change Handshake- Cipher Spec Alert Protocol Protocol Protocol Record Protocol Transport Layer Handshake: legt Ablauf der gegenseitigen Authentifizierung von Client und Server fest 3. Change-Cipher-Spec: Wechsel zu neuer Verschlüsselungskonfiguration (symm. Verschl.alg. inkl. Schlüssel, Has-Fkt. ) 4. Alert: Fehlermeldungen U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 2 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 4 IT-Security, 05INM

2 Zum Sitzungs-Konzept: Sitzungen (Sessions) vs. Verbindungen Jede Verbindungen gehört zu genau einer Sitzung Jede Sitzung kann mehrere Verbindungen haben weiter zu weiter zu Record-Protocoll empfängerseitig: Entschlüsseln (symm. mit zugehörigen Algorithmus und Schlüssel) für komprimierte Daten wird Hash-Funktion der Session der MAC berechnet und mit empfangenem MAC verglichen Dekompression U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 5 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 7 IT-Security, 05INM Record-Protocoll sichert: Vertraulichkeit, Integrität, Authentizität der zwischen Client und Server ausgetauschten Daten erhält senderseitig Anwendungsdaten oder Kontrollnachrichten der höheren Schicht zur Verarbeitung: Zerlegung in Pakete jedes Paket: Daten werden Komprimiert MAC mittels Hash-Funktion (MD5 oder SHA) komprimierte Daten symm. verschlüsselt (RC2-CBC, RC4, DES-CBC, 3DES-EDE-CBC, Skipjack-CBC) Handshake findet zu Beginn jeder neuen Verbindung statt 1. mögliche Modi der Authentifizierung (a) beidseitige Authentifizierung - anonymer Server kann keine Client-Authentifizierung verlangen - (b) Authentifizierung nur des Servers (c) keine Authentifizierung Man-In-The-Middle-Angriff möglich immerhin: Integrität und Vertraulichkeit der Nachricht gesichert U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 6 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 8 IT-Security, 05INM

3 weiter zu Handshake (2) Aushandlung der Sicherheitsparameter für das Record- Protokoll: symm. Verschlüsselungsalgorithmus und dessen Schlüssel Initialisierungsvektoren (bei blockorientierten Verfahren im CBC-Modus) MAC-Geheimnis (3) Authentifizierung: X.509v3-Zertifikatsketten Authentifizierungsmethoden: asymm. RSA, Diffie- Hellman, Fortezza-KEA (ähnlich DH (NSA 1994)) weiter (3.) zu Handshake (6) Konzept der Cipher-Suite: Kombination aus Schlüsselaustausch-, Verschlüsselungs- und Hash-Algorithmus (7) Schlüsselaustauschmethode bestimmt Authentifizierungsmechanismus und Länge des symm. Schlüssels (8) Client und Server einigen sich im Handshake auf Cipher Suite oder brechen ab U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 9 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 11 IT-Security, 05INM weiter (2.) zu Handshake (4) Client und Server generieren Pre-Master-Secret daraus wird Master-Secret der Session berechnet dieses geht ein in: symm. Schlüssel Initialisierungsverktoren MAC-Geheimnisse (5) Schlüsselaustauschmethoden: asymm. RSA, Diffie-Hellman, Fortezza-KEA (ähnlich DH (NSA 1994)) Ports für SSL 995 : POP3 über SSL (POP3S) 993 : IMAP4 über SSL (IMAPS) 992 : Telnet über SSL (TelnetS) 990 : FTP-Steuerung über SSL (FTPS) 989 : FTP-Daten über SSL (FTPS-Data) 614 : SSL-shell (SShell) 563 : NNTP über SSL (NNTPS) 465 : SMTP über SSL (SMTPS) 443 : HTTP über SSL (HTTPS) 443 : HTTP über SSL (HTTPS) U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 10 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 12 IT-Security, 05INM

4 Probleme (a) aktuelle Version SSLv3 behebt viele Schwächen von SSLv2 (b) im Interesse der Sicherheit Abwärtskompatibilität abschalten! (c) SSL kann nach Versenden der letzten Handshake- Nachricht mit Datenübertragung beginnen ohne Antwort abzuwarten Angriffsmöglichkeit:... siehe unten... Probleme (2. Forts.) (a) Keine klare trennung zwischen Auth. und Schlüsselaustauschalgorithmus (b) SHA1-Hash-Fkt. wird als SHA bezeichnet (c) Spez. erläutert anonyme Session mit RSA für Schlüsselaustausch, ohne dass entsprechende Cipher-Suite def. ist (d) Widersprüchliche Aussagen zum Zeitpunkt des Beginns der Kompression U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 13 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 15 IT-Security, 05INM Probleme (Forts.) Angriffsmöglichkeit: (a) Angreifer bewirkt Auswahl schwächerer Cipher- Suite als vom Angegriffenen geplant, indem Client-Hello abgeändert wird. (b) Bei fehlender Client-Authentifizierung: Client beendet Handshake mit Finished-Nachricht. (c) Bevor Server Unterschied des Hash-Wert in Finished- Nachricht vom von ihm berechneten Hash-Wert bemerkt und Client warnen kann, sendet Client bereits ungesicherte Daten Secure Shell (ssh) 1. ersetzt Berkeley-r-Tools (rlogin, rsh, rcp) sowie telnet 2. Authentifizierung, Verschlüsselung des Datenkanals 3. Tunnelung anderer Protokolle mittels Port-Umleitung in den verschlüsselten Kanal (z.b.: ssh -X HOST) 4. Authentifizierung der Maschinen der Kommunikationspartner 5. nutzt generisches Protokoll der Transport Layer Security über Port 22 (IANA-offizieller Port für ssh) 6. Host- u. Nutzerauthentifizierung, Datenkompression, Vertraulichkeit und Integrität der Daten U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 14 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 16 IT-Security, 05INM

5 5. 3 Secure Shell (ssh) (1. Forts.) (7) Nachteil: Public-Keys müssen manuell verteilt werden (8) Session-Keys mittels RSA-Mechanismus ausgetauscht (9) eigentliche Verschlüsselung symmetrisch stündliche Wechsel der Schlüssel Schlüssel niemals auf der Platte gespeichert (10) 5. 4 Private Communication Technology (PCT) cont. 1. Nachrichten kürzer und einfacher 2. für Auth. und Ver-/Entschlüsseln verschiedene Schlüssel möglich U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 17 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 19 IT-Security, 05INM 5. 4 Private Communication Technology (PCT) 1. von MS entwickeltes Protokoll, sollte Schwächen von SSLv2 abhelfen 2. basiert auf Transportprotokoll, z.b. TCP, unabhängig von Anwendungsschicht 3.(a) Record-Protokoll kompatibel zu SSL (b) Handshake-Protokoll: i. Client Server: Client-Hello ii. Client Server: Server-Hello iii. Client Server: Client-Master-Key-Message iv. Client Server: Server-Verify-Message 5. 5 Transport Layer Security (TSL) 1. Ausgangspunkte: SSLv3, PCT V.1, ssh V Ziele: Kryptographiesicherheit, Interoperabilität, Erweiterbarkeit, Effizienz 3. Aufbau: (a) Record- Protokoll Abhörsicherheit: symm. Verschlüsselung (DES, RC4) Zuverlässigkeit: MAC (SHA, MD5) (b) Handshake-Protokoll 4. Unterschiede zu SSL: u.a.: nichtkommerziell, Fortezza nicht unterstützt U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 18 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 20 IT-Security, 05INM

6 References [1] S. Fischer, C. Rensing, and U. Rödig. Open Internet Security. Springer-Verlag, Berlin Germany, [2] A. J. A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone. Handbook of applied cryptography. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL , USA, [3] M. Schumacher, U. Rödig, and M.-L. Moschgatj. Hacker Contest. Springer, References [1] S. Fischer, C. Rensing, and U. Rödig. Open Internet Security. Springer-Verlag, Berlin Germany, [2] A. J. A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone. Handbook of applied cryptography. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL , USA, [3] M. Schumacher, U. Rödig, and M.-L. Moschgatj. Hacker Contest. Springer, U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 21 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 23 IT-Security, 05INM 5. 6 Server Gated Cryptography (SGC) 1. sollte Finanzdienstleistern 128Bit-Verschlüsselung ermöglichen 2. entsprechende Erweiterung von SSL, welche Exportprobleme umgeht U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 22 IT-Security, 05INM