IT-Sicherheit: Übung 6

Transkript

1 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 Schlüssels ist in der Regel nicht praktikabel.! Gefahr eines Man-in-the-Middle-Angriffs! Wie kann man einen öffentlichen Schlüssel mit der Identität des Besitzers (z.b. Alice) verknüpfen?! Lösung: Ausstellung von Zertifikaten durch eine vertrauenswürdige Partei bzw. Zertifizierungsstelle (Certification Authority, CA) 2

2 Bsp.: X.509 v3-zertifikat & seine CA 3 Noch ein selbstsigniertes Zertifikat 4

3 Sicherheitsprotokolle! Bis jetzt: Kryptographische Grundbausteine! Symmetrische und asymmetrische Verschlüsselung! Hash, MACs, Digitale Signaturen! Zufallswerte, Nonces, Zeitstempel! Sicherheitsprotokolle (security protocols,cryptographic protocols)! basieren auf diesen Grundbausteinen! Verschiedene Arten von Protokollen:! Protokolle zur Authentisierung (z.b. Challenge Response-Protokolle, Kerberos, Needham-Schroeder )! Schlüsselaustauschprotokolle (z.b. IKE, Diffie-Hellman)! E-Commerce-Protokolle (SSL/TLS), E-Government (OSCI in Bremen entwickelt) 5 Grundlegende Notation (1)! Ein Protokoll besteht aus einer Menge von Regeln, die den Zustand des Nachrichtenaustauschs zwischen zwei oder mehreren Kommunikationsteilnehmern beschreiben:! Kommunikationsteilnehmer: Benutzer, Prozesse, Rechner,...! auch Principals genannt (s. zweite Vorlesung)! Protokollschritte n : A! B : M! A sendet M an B gemäß dem n-ten Protokollschritt. A, B Principals, M Nachricht! Nachrichten können strukturiert sein: M = M 1,..., M n 6

4 Grundlegende Notation (2)! Ein Protokoll ist eine Folge von Protokollschritten: 1 : A 1! B 1 : M 1 2 : A 2! B 2 : M 2..! Protokolldurchläufe! Berücksichtigung einer feindlichen Umgebung: Fehler, Verlust von Vertraulichkeit/Datenintegrität! Angreifer beherrscht Kommunikationskanal, kann aber nicht die zugrundeliegenden kryptographischen Verfahren brechen (Dolev-Yao-Modell, 1981) 7 Transport Layer Security: SSL/TLS! Entwickelt von Netscape für E-Commerce im Web! Online-Shops: Schutz von persönlichen Daten, Kreditkartennummern etc.! HTTPS = HTTP über TLS! Secure Sockets Layer (SSL)! letzte Version unter dem Namen SSL: 3.0! SSL 2.0 war unsicher! Transport Layer Security (TLS, RFC ): leicht abgewandelter Nachfolger von SSL (= SSL 3.1)! Allgemein verwendbar, nicht nur HTTPS (z.b. POP3, IMAP)! Literatur: E. Rescorla, SSL and TLS Designing and Building Secure Systems, Addison-Wesley,

5 SSL/TLS: grundlegende Idee! Hauptziele:! Vertraulichkeit (Secrecy) zwischen dem Kunden (Web-Browser) einem Web-Server! Authentisierung (des Web-Servers)! Integrität der übertragenen Daten! Authentisierung des Clients laut Spezifikation auch möglich, wird aber selten genutzt. (Warum?)! SSL/TLS nutzt hybrides Verschlüsselungsverfahren:! Schlüsselaustausch mit Public-Key-Verfahren! Öffentlicher Schlüssel des Web-Servers wird dem Web-Browser per X.509-Zertifikat bekannt gemacht! Anschließend: symmetrisches Verfahren zum Datenaustausch 9 SSL/TLS: Teilprotokolle! SSL/TLS Teilprotokolle:! Handshake-Protokoll (Schlüsselaustausch)! Record-Protokoll (verschlüsselte Daten, Bildung von MACs)! Alert-Protokoll (aufgetretene Fehler während des Protokollaufes)! Wir betrachten das Handshake-Protokoll in zwei Varianten! Auf RSA basierender Schlüsselausstausch! Diffie-Hellman-Schlüsselvereinbarung 10

6 SSL/TLS-Handshake mit RSA: Voraussetzungen! Vorausgesetzte Notationen, Bezeichnungen! Kommunikationspartner C (client) and S (server)! C#, S# (serielle Transaktionsnummern für C und S)! CS: Serverzertifikat CS = Cert CA (S) ={S, K ES, T, L} KD CA (nächste Folie)! Client unterstützt i.d.r. versch. kryptographische Verfahren (Suiten); (übernächste Folie)! Vorbemerkung: Es wird eine vereinfachte Fassung des Handshake-Protokolls vorgestellt. 11 Serverzertifikat! Bindet den Public Key des Servers an DNS- Namen des Servers 12

7 Kryptographische Suiten 13 SSL/TLS: Handshake mit RSA (1) 1. C! S: C, C#, N C, Supported_Ciphers! Supported_Ciphers sind die Cipher-Suites, die der Client unterstützt! können im Mozilla-Browser ausgewählt werden (vgl. vorherige Folie)! Bsp.: TLS_RSA_WITH_3DES_EDE_CBC_SHA! N C wird später bei der Schlüsselerzeugung benötigt; verhindert Replay-Angriffe (Wiedereinspielen von alten Nachrichten)! C# zeigt an, dass in einer Folgeverbindung die gleiche Grundlage zur Berechnung des Schlüsselmaterials verwendet wird (Premaster Secret, Master Secret, Erklärung s.u.) 14

8 SSL/TLS: Handshake mit RSA (2) 2. S! C: S, S#, N S,CS, Chosen_Cipher! Chosen_Cipher: Server wählt immer stärkeres Verfahren (128 Bit RC4 wird also 40 Bit RC4 vorgezogen)! Auswahl aus Supported_Ciphers! CS (Server-Zertifikat): K E S (RSA-Key)! N S : wie N C zusätzlicher Schutz vor Replay-Angriffen, wenn der Client-Rechner z.b. von einem Trojanischen Pferd befallen ist. 15 SSL/TLS: Handshake mit RSA (3) 3. C! S: {K 0 } KE S K 0 Premaster Secret: 48 Bytes lang! Berechnung des Master Secrets aus K 0 (von beiden Kommunikationspartnern unabhängig voneinander): K 1 = PRF(K 0, master_secret, N c N s ) PRF Pseudo Random Function zur Erzeugung von diversen Schlüsseln! N c und N s verhindern Replay-Angriffe (s.o.)! S und C können dann aus dem Master Secret K 1 Schlüsselmaterial berechnen! Verwendung von PRF zur Berechnung des Schlüsselmaterials (nächste Folie) 16

9 Einschub: PRF! Basiert auf HMAC unter Verwendung von SHA_1 und MD5! Berechnet verschiedenes Schlüsselmaterial; es wird pro Kommunikationsrichtung jeweils ein Schlüssel berechnet:! für die symmetrische Verschlüsselung (K CS, K SC ),! für MACs! für IVs (z.b. für CBC-Mode)! PRF liefert diese sechs Schlüssel in einem Schlüsselblock zurück! PRF(secret,label,seed) Beispielaufrufe: keyblock=prf(k 1, key_expansion, N S N c ) K 1 =PRF(K 0, master_secret, N C N S ) 17 SSL/TLS mit RSA: Handshake (4) 4. C! S: {finished, MAC(K 1, alle bisher gesendeten Nachrichten)} K CS! finished bestätigt das Ende des Handshake-Vorganges des Clients 5. S! C: {finished, MAC(K 1, alle bisher gesendeten Nachrichten)} KSC! finished bestätigt das Ende des Handshake-Vorganges des Servers! Warum Verschlüsselung der Nachrichten 4. und 5.?! Erst nach dieser Nachricht können verschlüsselte und durch einen MAC gesicherte Daten gesendet werden wie z.b. Kreditkartennummern (Record- Protokoll) 18

10 SSL/TLS-Handshake mit DH: Voraussetzungen! Schlüsselvereinbarung nach Diffie und Hellman (Wiederholung auf den folgenden Folien)! Verwendung von DSA zum digitalen Signieren! Ansonsten: ähnliche Voraussetzungen wie bei der RSA- Variante 19 Diskreter Logarithmus: Primitivwurzel! Vorausgesetzte Begrifflichkeit: Primitivwurzel (Generator) mod p erzeugt alle von 0 verschiedenen Zahlen mod p. Beispiel: p=7. Dann ist g=5 eine Primitivwurzel mod 7. Denn: 5 1 = 5 mod = 25 = 4 mod = 4x5 = 6 mod = 6x5 = 2 mod = 2x5 = 3 mod = 3x5 = 1 mod 7 20

11 Problem des diskreten Logarithmus! Gegeben p Primzahl, g! p"1, und y. Bestimme die eindeutige Zahl k (1! k! p"1) so, dass y = g k mod p.! Diskreter Logarithmus als Umkehrung der Potenzierung, ganzzahliges Problem ( diskret ).! Potenzierung (auch für große p) relativ effizient durchführbar! Bestimmung des diskreten Logarithmus aber nicht (nur Inspektion), Problem aus NP! f: x! g x (mod p) ist eine Einweg-Funktion mit Falltür 21 Schlüsselvereinbarung nach Diffie und Hellman (1)! Ziel: Vereinbarung eines gemeinsamen geheimen Schlüssels, ohne diesen auszutauschen (z.b. für eine symmetrische Verschlüsselung)! Achtung: Diffie-Hellman allein liefert keine Verschlüsselung, keine Authentisierung der Partner!! Einsatz u.a. in SSL/TLS, Kerberos, IPsec-Protokollen! basiert auf dem Problem des diskreten Logarithmus! (EIGamal-Verfahren basiert auf der gleichen Idee) 22

12 Schlüsselvereinbarung nach Diffie und Hellman (2)! Funktionsweise! Wähle große Primzahl p (allen Teilnehmern bekannt);! Wähle einen allen Teilnehmern bekannten Wert g, der primitive Wurzel von p ist. Es gilt also: {g 1,..., g p-2, g p-1 }={1, 2,..., p-2, p-1}. 23 Schlüsselvereinbarung nach Diffie und Hellman (3) Alice Bob Wählt zufällig eine Zahl a. Berechnet ":=g a mod p. "! Wählt zufällig eine Zahl b. Berechnet!:= g b mod p. Berechnet! a mod p Berechnet " b mod p K AB =! a mod p = (g b ) a mod p = g ba mod p = g ab mod p = (g a ) b mod p = " b mod p 24

13 SSL/TLS:Handshake mit DH (1) 1. C! S: C, C#, N C, Supported_Ciphers! Wie bei der RSA-Variante 2. S! C: S, S#, N S,CS, Chosen_Cipher, {p,g, "} K -1 S! Ähnlich wie bei RSA-Variante! Aber: CS enthält jetzt den Public Key von S zur Signatur- Verifikation (DSA)! Mit DSA digital signierter DH-Public Key (vgl. letzte Folie) : {p,g, "} K -1 S 25 SSL/TLS:Handshake mit DH (2) 3. C! S:!! a mod p = " b mod p = K 0 Premaster Secret; Aus K 0 kann das Master Secret berechnet werden (wie im RSA-Fall):! K 1 =PRF(K 0, master_secret, N c N s )!... 26

14 SSL/TLS: Handshake mit DH (3) 4. C! S: {finished, MAC(K 1, alle bisher gesendeten Nachrichten)} K CS 5. S! C: {finished, MAC(K 1, alle bisher gesendeten Nachrichten)} KSC! Erst nach dieser Nachricht können verschlüsselte und durch einen MAC gesicherte Daten gesendet werden wie z.b. Kreditkartennummern (Record-Protokoll) 27 SSL/TLS:Record-Protokoll! Nach erfolgreichem Handshake können die Daten verschlüsselt und durch einen MAC (mittels HMAC) gesichert gesendet werden! z.b. Kreditkartennummern! Aufspaltung der Nachricht in Blöcke! Unverschlüsselte Header-Informationen pro Block! Bei Blockchiffren evtl. Padding erforderlich! Verschlüsselung und Sicherung durch MAC pro Block C! S: {data, MAC(K CS_MAC, data)} KCS 28

15 SSL/TLS: Alert-Protokoll! Ziel: den Kommunikationspartner über Ausnahmebedingungen informieren, z.b.:! Handshake failure! Unkown CA! Certificate expired! Certificate unknown! No certificate! Unterscheidung zwischen Warn- und Fehlermeldungen! Fehlermeldungen führen immer zum Verbindungsabbruch. 29 SSL/TLS: Bewertung! In SSL 3.0 bzw. TLS 1.0 wurden bislang keine ernsthaften Schwächen gefunden:! auch bei Analyse mit formalen Methoden! Wer hier grundsätzliche Fehler findet, wird berühmt und verursacht einen entsprechenden Ärger "! Wohl aber in SSL 2.0 (folgende Folien)! Problem bei SSL/TLS: schützt nur die Kommunikation, nicht aber die Daten auf dem Server! Performanceprobleme: Public-Key-Entschlüsselung auf dem Server! Server trägt also die Last (häufiges Abstellen von SSL) 30

16 Schwächen in SSL 2.0 (1)! SSL 2.0 (vereinfacht): 1. C! S: C, C#, N C, Supported_Ciphers 2. S! C: S, S#, N S,CS, Chosen_Cipher 3. C! S: {K 0 } KE S Aus K 0 kann Schlüssel K berechnet werden.! Was ist das Problem? Keine kryptographische Sicherung der ausgetauschten Nachrichten:! Ciphersuite Rollback-Attack (Unterschieben einer schwachen Cipher- Suite) Keine finished-nachricht! Truncation-Attack (Angreifer kann TCP FIN fälschen) 31 Schwächen in SSL 2.0 (2)! Verwendung des gleichen Schlüssels für MACs und für Verschlüsselung! Folge: Bei Verwendung von RC4 im Exportmodus (40 Bit) besteht der MAC nur aus 40 Bit und ist angreifbar (obwohl für MACs keine Exportbeschränkungen galten)! In SSL 3.0 werden die Teilschlüssel aus einem entsprechend großen Master Secret gebildet (kein Rückschluss auf Master Secret möglich). 32

17 Schwächen in SSL 2.0 (3)! Implementierungsfehler im Netscape-Browser: Schlechter Zufallsgenerator zur Erzeugung des PreMasterSecrets:! Im Wesentlichen nur Uhrzeit und Prozess-ID berücksichtigt! In weniger als einer Stunde konnte das PreMasterSecret ermittelt werden (Durchprobieren aller möglichen Werte)! Premaster Secret (oder Master Secret) dem Angreifer bekannt: # 33 Nächste Termine Do, Uhr: Vertiefung Sicherheitsprotokolle (insbesondere Schwächen), Authentisierung Übungsblatt 7 auf Stud.IP, s.: 34