3.3 Transportschicht

Transkript

1 3.3 Transportschicht Sichere Transportdienste typischerweise auf TCP aufgesetzt d.h. als zusätzliche Schicht (5/6 nach OSI-Terminologie) oberhalb der Systemschnittstelle (d.h. Bibliotheksroutinen, die auf TCP-Sockets aufsetzen) Aktuelle Dienste/Protokolle: SSL - Secure Socket Layer TLS - Transport Layer Security SSH - Secure Shell NS-3.3 1

2 Pro: Ende-zu-Ende-Sicherheit zwischen Anwendungsprozessen, unabhängig von allem, was im Netz oder in den Endsystemen passiert. Lediglich Vertrauen in die verwendete Bibliothek erforderlich. Authentisierung von Prozessen/Personen (nicht nur Systemen). Contra: Kein Schutz vor Angriffen gegen die Netz-Infrastruktur Kein Schutz vor Verkehrsanalysen Kein Schutz vor IP Spoofing NS-3.3 2

3 3.3.1 Secure Socket Layer - SSL/TLS SSL - ursprünglich entwickelt von Netscape für https - weiterentwickelt in verschiedenen Versionen ( - prominent verwendet für https (Port 443), aber auch ftps (Port 990), ssmtp (Port 456),... - standardisiert als TLS: TLS - Transport Layer Security - mit einigen kleinen Veränderungen gegenüber SSL 3.1 NS-3.3 3

4 SSL erlaubt TCP-Verbindung mit Datenkompression, falls gewünscht Authentisierung des Servers ( + Klient, falls gewünscht) Unversehrtheit der übertragenen Daten Vertraulichkeit der übertragenen Daten, falls gewünscht Genauer: Unter dem Dach einer SSL-Sitzung (session) können mehrere TCP-Verbindungen gefahren werden, entweder gleichzeitig ("duplication" of SSL session) oder nacheinander ("resumption" of SSL session) NS-3.3 4

5 Sichere Datenübertragung Vor.: SSL-Sitzung ist bereits eingerichtet ( ) - und damit liegt der zu verwendende kryptographische Kontext vor: - Verschlüsselungsverfahren mit symmetrischen Schlüsseln K, jeweils für Klient und Anbieter (!) - MAC-Verfahren H (z.b. MD5 oder SHA) mit MAC-Schlüsseln MACsecret für Klient und Anbieter TCP-Verbindung existiert NS-3.3 5

6 Record Protocol regelt die Sicherung: 0. Daten werden in Fragmente (records) von max. 16 KB aufgeteilt. Jedes Fragment wird separat wie folgt behandelt: 1. Kompression (falls gewünscht): data = compressornot(record) 2. Obligatorische MAC-Berechnung mit Schlüssel MACsecret: mac = H[ MACsecret, padding2, H[MACsecret, padding1, seqno, length, data]] 3. Verschlüsselung (falls gewünscht) mit symmetrischem Schlüssel K: encrypted = E K [data, mac] 4. encrypted (bzw. unverschlüsselt data,mac) über TCP übertragen (Komma bedeutet Konkatenation) NS-3.3 6

7 Im Bild: Fragment [komprimiert] um MAC erweitert [verschlüsselt] NS-3.3 7

8 Im Bild: Fragment [komprimiert] um MAC erweitert [verschlüsselt] mit SSL Record Header type major version # minor version # length NS-3.3 8

9 Einrichtung einer SSL-Sitzung Das Record Protocol wird von 4 höheren SSL-Protokollen benutzt: type Protokoll Zweck 20 Change Cipher Spec Wechsel des kryptogr. Kontextes 21 Alert Warnungs- oder Fehlermeldung 22 Handshake Einrichtung einer SSL-Sitzung 23 Application Data Nutzdatenübertragung (direkter Durchgriff auf Record Protocol) NS-3.3 9

10 Handshake Protocol regelt die Einrichtung einer Sitzung: Klient ergreift die Initiative, wendet sich an einen Anbieter Authentisierung des Anbieters [evtl. auch des Klienten] Vereinbarung eines Pre-Master Secret, aus dem beide Partner jeweils lokal weitere gemeinsame Schlüssel generieren NS

11 Handshake Protocol für neue Sitzung: Klient Anbieter ClientHello: Protokollversion, Zufallszahl cr, Sitzungs-ID (=0), cipher suites, compression algs ServerHello: Protokollversion, Zufallszahl sr, Sitzungs-ID, cipher suite, compression alg [ServerCertificate] [CertificateRequest] [ServerKeyExchange] ServerHelloDone NS

12 Klient Anbieter [ClientCertificate] ClientKeyExchange [CertificateVerify] ChangeCipherSpec Finished (Protokoll beendet) ChangeCipherSpec Finished Anwendungsdaten NS

13 Handshake Protocol, verkürzt, für neue Verbindung (duplication/res.), Authentisierung entfällt, Master Secret wird übernommen! Klient Anbieter ClientHello: Protokollversion, Zufallszahl cr, Sitzungs-ID ( 0), cipher suites, compression algs ChangeCipherSpec Finished ServerHello: Protokollversion, Zufallszahl sr, Sitzungs-ID, cipher suite, compression alg ChangeCipherSpec Finished NS

14 Erläuterungen: "Zufallszahl": dient als Nonce (s.u. Schlüsselgenerierung) "Sitzungs-ID": wird benötigt bei mehreren koexistierenden Sitzungen: bei Neueinrichtung einer Sitzung sendet der Klient 0; (ID 0 vom Klienten kennzeichnet die Wiederaufnahme von ID); eine 0 vom Anbieter bedeutet, dass der Anbieter nicht willens/in der Lage ist, die Sitzung für mehrere Verbindungen (gleichzeitig oder nacheinander) aufrechtzuerhalten. NS

15 "cipher suite": eine Kombinationen kryptographischer Verfahren, ausgewählt aus einer vorgegebenen Palette von cipher suites: Nummer Verfahren für Pre-Master Secret, Verschlüsselung, MAC 0 NULL with NULL NULL 1 RSA with NULL MD5 2 RSA with NULL SHA... 9 RSA with DES CBC SHA DH DSS with 3DES EDE CBC SHA Fortezza DMS with Fortezza CBC SHA NS

16 Verwendung von Zertifikaten: Die Übermittlung des Anbieter-Zertifikats an den Klienten garantiert per se noch nicht die Authentizität des Anbieters! Die anschließende Benutzung von dessen öffentlichem Schlüssel (s.u.) durch den Klienten erlaubt aber nur dem authentischen Anbieter den erfolgreichen Abschluss des Handshake! Wenn der Anbieter auf einer Authentisierung des Klienten besteht, sendet er einen CertificateRequest mit Angaben über die von ihm akzeptierten Zertifizierungsstellen. Die Antwort des Klienten muss dann ein passendes ClientCertificate enthalten und zusätzlich ein CertificateVerify: das sind mit dem privaten Schlüssel des Klienten signierte MACs (MD5 und SHA) mit dem Master Secret über alle zuvor ausgetauschten Daten. NS

17 "Finished": Wiederum zwei MACs (MD5 und SHA) mit dem Master Secret über alle zuvor ausgetauschten Daten Schutz des Handshake vor Integritätsverletzungen "ChangeCipherSpec": Bestätigung des Wechsels zu den ausgehandelten Sicherungsverfahren. (Vgl. Change Cipher Spec Protocol auf S. 8) NS

18 Generierung von Schlüsseln: Ausgangspunkt ist das Pre-Master Secret PMS, für dessen Vereinbarung drei Varianten vorgesehen sind: - RSA: Klient erzeugt PMS = Zufallszahl, und schickt sie - verschlüsselt mit dem öffentlichen Schlüssel des Anbieters - an den Anbieter (ClientKeyExchange). - DH: Mit Diffie-Hellman-Verfahren wird PMS = c ab erzeugt (ServerKeyExchange = c a, ClientKeyExchange = c b ). - Fortezza: geheimes Verfahren der US-amerikanischen NSA, erlaubt treuhänderische Schlüssel (key escrow), d.h. Brechen des Codes auf richterlichen Beschluss. NS

19 Ableitung eines Master Secret MS aus dem Pre-Master Secret: MS = MD5[PMS, SHA['A', PMS, cr, sr]], MD5[PMS, SHA['BB', PMS, cr, sr]], MD5[PMS, SHA['CCC', PMS, cr, sr]] (3*128 Bits = 48 Bytes) Warum doppeltes Hashing mit MD5 und SHA? Sicherung gegen eventuelle Schwächen von MD5 oder SHA! Damit Erzeugung eines Key Block kb, aus dem schließlich die gemäß ausgehandelter cipher suite benötigten Schlüssel gewonnen werden: kb = MD5[MS, SHA['A', MS, cr, sr]], MD5[MS, SHA['BB', MS, cr, sr]], MD5[MS, SHA['CCC', MS, cr, sr]],... usf. bis hinreichend viele Bits vorhanden NS

20 kb MACsecrets Symmetrische Schlüssel Anfangswerte... jeweils zwei - für Klient und Anbieter... jeweils in gleicher Weise auf Klienten- und Anbieterseite ermittelt NS

21 Verwendete Zustandsdaten für Sitzungen bzw. Verbindungen (auf beiden Seiten): Sitzung: - Sitzungs-ID, vom Server festgelegt - [Zertifikat der Gegenseite, X.509v3] - Kompressionsverfahren - CipherSpec, spezifiziert die verwendete cipher suite - Master Secret Verbindung: - cr, sr - MACsecrets des Klienten und des Anbieters - symmetrische Schlüssel K,K' des Klienten und des A. - Initialisierungswert - Folgenummer seqno (s.s. 5), bei ChangeCipherSpec auf 0 gesetzt NS

22 SSL-Bibliotheken für C in Unix: 3ssl basiert auf Ein/Ausgabe-Abstraktion BIO (basic I/O) Beispiel: BIO_new_ssl_connect() für Java: javax.net.ssl Die meisten Klassen sind abstrakt, außer SSLContext mit Methoden SSLSocketFactory getsocketfactory() SSLEngine createsslengine()... NS

23 3.3.2 Secure Shell - SSH (Port 22) ursprünglich entwickelt für sichere Fernbenutzung (remote login) (anstelle der unsicheren telnet, rlogin, rsh,...) als Open Source von Tatu Ylönen (SSH1); Weiterentwicklung und Kommerzialisierung (SSH2): Weiterentwicklung OpenSSH: heute auch eingesetzt für Dateiübertragung (scp, sftp) u.a. ähnlicher Ansatz wie SSL/TLS, zuzüglich Anwendungsdienste NS

24 SSH-Transportprotokoll (SSH Transport Layer Protocol) ist das Äquivalent zu SSL Record Protocol + Server-Authentisierung SSH-Authentisierungsprotokoll (SSH Authentication Prot.) ist zuständig für Klienten-Authentisierung SSH-Verbindungsprotokoll (SSH Connection Protocol) ist zuständig für die Einrichtung von TCP-Verbindungen innerhalb einer SSH-Sitzung (vgl. verkürztes SSL Handshake Protocol) NS

25 SSH-Transportprotokoll ist zuständig für Einrichtung einer Sitzung mit Authentisierung des Anbieter-Systems (!) [Kompression der Nutzdaten, wahlweise] [Verschlüsselung der Nutzdaten, wahlweise] Integritätssicherung der Nutzdaten NS

26 Integritätssicherung der (eventuell komprimierten) Nutzdaten data mit Geheimnis s(ecret): mac = H[ s, padding2, H[s, padding1, seqno, data] ] mit Hashfunktion MD5 oder SHA Verschlüsselung der (eventuell komprimierten) Nutzdaten data mit Sitzungsschlüssel k: encrypted = E k [data] mit DES oder 3DES oder... Übertragen wird (encrypted, mac) bzw. (data, mac) (vgl. SSL, 3.3.1, Seite 6) NS

27 Im Bild: Fragment [komprimiert] [verschlüsselt, mit padding] + MAC + Längenangaben length pad length (vgl. SSL, 3.3.1, Seite 8) NS

28 Einrichtung einer Sitzung: - Authentisierung des Anbieter-Systems (!), - Aushandlung der Verfahren zur Kompression, Verschlüsselung, Authentisierung von Nachrichten, - Schlüsselgenerierung, ausgehend von Diffie-Hellman NS

29 Einrichtung einer Sitzung: - Authentisierung des Anbieter-Systems (!), - Aushandlung der Verfahren zur Kompression, Verschlüsselung, Authentisierung von Nachrichten, - Schlüsselgenerierung, ausgehend von Diffie-Hellman K lient kexinit (key exchange initialization) mit Verfahrensvorschlägen, z.b. a,f,b,c A nbieter kexinit z.b. b,c,g,f beide entscheiden (lokal) zugunsten des vom Klienten bevorzugten gemeinsamen Verfahrens - hier f NS

30 K lient Zufallszahl a c a A nbieter Zufallszahl b c b E A authentisch?* x = E A [D A [h]] h' = H[v K, v A, kexinit K,...]? h'=x? h = H[v K, v A, kexinit K, kexinit A, E A, c a, c b, c ab ] (E A, c b, D A [h]) c=2, Arithmetik modulo p =... v K, v A = Versionsnummern * Zertifikat (oder lokal bekannt) NS

31 Generierung von diversen Schlüsseln aus C= c ab und h, jeweils lokal bei Klient und Anbieter: für Verschlüsselung: für MAC: k K = H[C, h, 'C', sid] k A = H[C, h, 'D', sid] s K = H[C, h, 'E', sid] s A = H[C, h, 'F', sid] oder wenn für ein k (bzw. s) mehr Bits benötigt werden: k 0 = H[C, h,..., sid] wie oben k 1 = H[C, h, k 0 ] k 2 = H[C, h, k 0, k 1 ]... und aus k 0 k 1... die benötigten Bits gewinnen NS

32 SSH-Authentisierungsprotokoll - wird eingesetzt, wenn auch der Klient authentisiert werden soll, - benutzt das SSH-Transportprotokoll; - 3 Varianten: Passwort, typischerweise mit verschlüsseltem Transport Digitale Unterschrift mit privatem Schlüssel des Klienten gemäß bestimmtem Public-Key-Verfahren Digitale Unterschrift mit privatem Schlüssel des Klienten- Systems (!) NS

33 SSH-Verbindungsprotokoll regelt die folgenden Dienste: interaktive Fernbenutzung eines Systems Fernausführung einzelner Befehle Kapselung/Weiterleitung von X11-Verbindungen Kapselung/Weiterleitung von TCP-Verbindungen über virtuelle Kanäle der Art "session", "X11" usf., NS

34 Beispiel Fernbenutzung: Klient SSHMsgChannelOpen: "session", chid K, credit K, maxsize K SSHMsgChannelRequest: chid A, "pty-req", false,... Anbieter SSHMsgChannelOpenConfirm: chid K, chid A, credit A, maxsize A SSHMsgChannelRequest: chid A, "env", false, "home", "/usr/lohr" SSHMsgChannelRequest: chid A, "shell", true,... SHMsgChannelSuccess: chid = lokale (!) channel id credit für gleitendes Fenster maxsize = maximale Paketgröße chid K NS

35 SSH Client (Unix) ssh mit tausend Optionen zur Steuerung der Protokolle scp für Dateiübertragung ssh-keygen für Schlüsselerzeugung und -verwaltung... Wichtige Dateien: $HOME/.ssh/known_hosts Namen, öffentliche Schlüssel,... aller bereits besuchten Rechner $HOME/.ssh/identity $HOME/.ssh/identity.pub.. private und öffentliche Schlüssel des Benutzers... und /etc-dateien. NS

36 Bemerkung: nur wenige Systeme verfügen über ein Zertifikat - daher: $ ssh localhost The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is 1d:71:15:06:be:b7:85:e3:e2:51:78:44:3f:fa:82:36. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. $ ssh localhost The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is 1d:71:15:06:be:b7:85:e3:e2:51:78:44:3f:fa:82:36. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Password: Last login: Mon Jun 12 14:30: Welcome to Darwin! $ NS