Wie funktionieren Sicherheitsprotokolle?

IT-Sicherheit: Sicherheitsprotokolle Zurück zur Theorie: Wie funktionieren Sicherheitsprotokolle?

Das Needham-Schroeder- Protokoll! Roger Needham, Michael Schroeder (1978)! Schlüsselaustausch-Protokoll: Kommunikationspartner A und B vereinbaren mit Hilfe des Protokolls einen gemeinsamen Schlüssel K AB, ohne ein Public-Key-Verfahren zu verwenden.! Vertrauenswürdige dritte Instanz S (trusted third party), Authentisierungsserver! Voraussetzung:! A und B besitzen mit S jeweils einen gemeinsamen Schlüssel: K AS und K BS 3 Die Schritte des Needham- Schroeder-Protokolls (1) 1. A! S : A, B, N A! A fragt S nach einem gemeinsamen geheimen Schlüssel K AB für die Kommunikation mit B. 2. S! A : {N A, B, K AB, {K AB,A} KBS } KAS! S antwortet mit dem geheimen Schlüssel K AB, der mittels K AS verschlüsselt ist! das Nonce N A verhindert einen Replay-Angriff! Nachricht enthält ferner ein Zertifikat für B mit dem gemeinsamen geheimen Schlüssel K AB 4

Die Schritte des Needham- Schroeder-Protokolls (2) 3. A! B :, {K AB,A} KBS! A sendet das von S ausgestellte Zertifikat an B, d.h. B kennt nun den gemeinsamen Schlüssel K AB 4. B! A : {N B } KAB 5. A! B : {N B -1} KAB! Die Schritte 4. und 5. stellen eine Art Challenge-Response dar: B überprüft, dass A wirklich mit B kommunizieren will. 5 Sicherheitsproblem des Needham-Schroeder Protokolls! Subtiles Sicherheitsproblem: B nimmt an, dass der Schlüssel K AB aktuell von S stammt (vgl. Nachricht 3): 3. S! A : {N A, B, K AB, {K AB,A} KBS } KAS! Wiedereinspielungen mit geknacktem K AB sind möglich.! Bei Kompromittierung von K AS kann sich der Angreifer sogar auf Vorrat Schlüssel K AX für verschiedene Kommunikationsteilnehmer X besorgen (nicht nur für B). Selbst wenn A erkennt, dass K AS gebrochen ist, werden dadurch die Schlüssel K AX nicht automatisch ungültig.! Lösung: Nachrichten mit Zeitstempel versehen. 6

Design-Prinzipien für Sicherheitsprotokolle (1)! M. Abadi, R. Needham: Prudent Engineering Practice for Cryptographic Protocols, IEEE Transactions on Software Engineering, Vol.23, No.3, März 1997 (auch DEC SRC- 125, Juni 1994)! Regel 1: Vollständige Information: Alle relevanten Informationen (z.b. Namen der Partner) sollten in einer Protokollnachricht kodiert werden.! vgl. Schwäche in Denning-Sacco bzw. im Mutual Challenge- Response-Protokoll 7 Design-Prinzipien für Sicherheitsprotokolle (2)! Regel 2: Verschlüsselungszweck klären:! Gewährleisten der Vertraulichkeit,! Nachweis der Authentizität des Absenders! Verknüpfung unterschiedlicher Nachrichten-Bestandteile Bemerkung: unterschiedliche Schlüssel für unterschiedliche Zwecke verwenden, z.b. Signieren, Verschlüsseln! Regel 3: Vorsicht bei Doppelverschlüsselung Redundanz verursacht unnötige Kosten, ggf. sogar Lücken 8

Design-Prinzipien für Sicherheitsprotokolle (3)! Regel 4: Digitale Signaturen: Erst Signieren (nach dem Hashen), dann Verschlüsseln! Regel 5: frischer Schlüssel Frischenachweis über Zeitstempel oder Nonces (vgl. Problem bei Needham-Schroeder Protokoll) 9 Kerberos (1)! Weit verbreitete Weiterentwicklung des Needham-Schroeder Protokolls! Name: gr. Mythologie: 3-köpfiger Hund, der den Eingang zum Hades bewacht.! 1983 im Athena Projekt am MIT entwickelt (+ IBM, DEC)! Version 4 (nur TCP/IP, einige Sicherheits-Probleme)! Version 5 (RFC 1510, September 1993)! Ziele von Kerberos:! Authentisierung von Subjekten (Principals): u.a. Benutzer, PC/Laptop, Server! Austausch von Sitzungs-Schlüsseln für Principals! Single-Sign-on für Dienste in einer administrativen Domäne! Beispiele für Dienste: Drucker, NFS, DB 10

Kerberos (2)! Im Gegensatz zum Needham-Schroeder-Protokoll zwei Server:! Authentisierungsserver (AS)! Ticket-Granting Server (S)! AS und S werden oft zusammen KDC genannt (Key Distribution Center)! Idee: Trennung von Authentisierung (zentral beim KDC) und Überprüfung (dezentral bei den einzelnen Dienst-Servern)! Vorgehen:! Client C besitzt Passwort für Authentisierungsserver AS! C fordert einen Schlüssel K CS für den Ticket-Granting Server S von AS an! K CS ist verschlüsselt mit dem Passwort von C (Kerberos v4)! v5: Wörterbuchangriffe durch verschlüsselte Anfragen verhindern! Client führt korrigierte Variante von Needham-Schroeder mit Hilfe von S und dem Dienst -Server B durch 11 Kerberos-Architektur Key Distribution Center KDC Benutzer Alice Client C 1. 2. 3. Schlüsseldatenbank AS 5. 6. 4. Ticket-Granting-Server S DB Drucken... NFS Server Server Server 12

Kerberos: Protokollschritte! Schritte 1. und 2.: Aushandlung des gemeinsamen Schlüssel K CS für den Client C und den Ticket-Granting-Server S! Hier nur das abgewandelte Needham-Schroeder-Protokoll: 3. C! S : C, B 4. S! C : {T S, L, K CB, B, {T S, L, K CB,C} K BS } KCS (T Zeitstempel, L Gültigkeitsdauer) 5. C! B :, {T S, L, K CB,C} KBS, {C,T C } KCB 6. B! C : {T S +1} KCB! {T S, L, K CB,C} KBS ist das Ticket für den Zugriff auf den Server! {C,T C } KCB der Authentikator 13 Sicherheitsprotokolle auf den unteren Schichten: IPsec (unter Nutzung von Material von Prof. Gollmann, TU-Hamburg Harburg, das wiederum auf Material von Kenny Paterson, Royal Holloway, basiert)

Sicherer Kanal (Secure Channel)! Schutzziele: Vertraulichkeit, Authentizität und Integrität über unsichere Netze! Nicht notwendigerweise nur für das Internet: auch LANs, WANs! Typische Anwendungen:! Vernetzung von Zweigstellen eines Unternehmens! Entfernte Kommunikation mit Geschäftspartnern! Entfernter Zugriff für Angestellte! Schutz von Kreditkartennummern bei Online-Transaktionen... 15 Sicherer Kanal (Secure Channel)! Oft nicht ganz klar: Was genau wird authentisiert?! Maschine, OS?! Anwendung?! Benutzer?! Nicht-Ziele: Nichtabstreitbarkeit Schutz lokaler Daten 16

Schritte zu einem sicheren Kanal! Ein sicherer Kanal wird üblicherweise in folgenden Schritten erzeugt:! Authentisierter Schlüsselaustausch! Eine oder beide Parteien werden authentisiert! Ein frisches gemeinsames Geheimnis wird erzeugt! Ableitung von Schlüsselinformationen aus dem gemeinsamen Geheimnis! MAC! Verschlüsselung! Schutz des Datenverkehrs mit MACs und durch Verschlüsselung! Nützlich: Wiederverwendung von Schlüsseln; schnelles Aushandeln neuer Schlüssel (rekeying) 17 IPsec grundlegende Merkmale (1)! Vorbemerkung: IPsec wird aus RN1 vorausgesetzt; Schwerpunkt hier: Schlüsselaustausch mit IKE-Protokoll! Bereitstellen eines sicheren Kanals auf der Vermittlungsschicht:! Alle IP-Datagramme werden behandelt! Anwendungen müssen nicht angepasst werden! Transparent für den Nutzer! Verpflichtend für IPv6, optional für IPv4! RFC 2401 2412 18

IPsec grundlegende Merkmale (2)! Zwei Modi:! Transport -Modus:! Schutz für Pakete höherer Schichten (TCP, UDP, ICMP)! Schutz der IP-Daten (und ausgewählter Headerinformationen)! Ende-zu-Ende-Sicherheit (zwischen den Endpunkten eines sicheren Kanals)! Tunnel =Modus:! Kann auch von Gateways (z.b. Firewalls) aus aufgebaut werden! stellt Authentizität und/oder Vertraulichkeit sicher.! Protokolle: AH (Authentication Header) und ESP (Encapsulated Security Payload)! Flexible Möglichkeiten für den Schlüsselaustausch:! IKE, IKEv2 19 Transportmodus IP datagram IP datagram Header Payload Header Payload Network 20

Tunnelmodus (1)! Kann als Technik zum Aufbau eines VPN (virtual private network) verwendet werden! Das gesamte IP-Paket (inkl. IP-Header) wird in ein neues IP-Paket eingkapselt! Voranstellung eines neuen IP-Headers mit den Adressen der Gateways! Schutz des gesamten inneren IP-Paketes! Security Gateways:! Gateway kann eine Firewall oder ein Router sein.! Gateway-zu-Gateway versus Ende-zu-Ende Sicherheit! Hosts brauchen nicht notwendigerweise IPsec zu verstehen.! Inneres IP-Paket ist nicht sichtbar für intermediäre Router:! Nicht einmal die Quell- und Zieladresse der Hosts sichtbar. 21 Tunnelmodus (2) Inner IP datagram Header Payload Security Gateway Network Inner IP datagram Header Payload Security Gateway Outer Header Inner IP datagram Header Payload Outer Header Inner IP datagram Header Payload 22

IPsec-Teilprotokoll: AH! AH = Authentication Header (RFC 2402)! Authentisierung der Herkunft und Integrität (Authentizität)! AH authentisiert die Daten und den größten Teil des Headers eines IP-Paketes! Abwehr von IP Address Spoofing! Quell-Adresse wird authentisiert! Zustandsbehafteter Informationskanal Abgesagt! Laufnummern! Abwehr von Replay-Angriffen! AH-Laufnummer wird mitauthentisiert! Einsatz von MACs und geheimen Schlüsseln 23 Grundlegende IPsec- Teilprotokolle: ESP! ESP = Encapsulating Security Payload (RFC 2406)! Stellt eines oder beide der folgenden Schutzziele sicher:! Vertraulichkeit der Daten! Authentizität der (gekapselten) Daten; aber nicht des Headers! Im Tunnelmodus sogar Vertraulichkeit des Verkehrsflusses! Einsatz von symmetrischer Verschlüsselung und MACs! Ursprüngliche Trennung von AH und ESP aus technischen und politischen Gründen 24

Security Association (SA)! Woher wissen die Kommunikationspartner, welche Parameter für ESP bzw. AH gewählt sollen?! Konzept der Security Association (SA).! Unidirektional gültig! Stellt eine Art Abkommen zwischen den Kommunikationspartnern für die Verbindung dar! Eine SA enthält u.a.:! Informationen über Authentisierungsverfahren, Modi und die Schlüssel für AH! Informationen über Authentisierungsverfahren, Modi und die Schlüssel für ESP! Initialisierungsvektoren! Lebensdauer von Schlüsseln! Sequenznummern... 25 SA Database! Alle aktiven SAs! Zieladresse, Protokoll, SPI (Security Parameter Index)! Parameter:! Authentication algorithm and keys! Encryption algorithm and keys! Lifetime! Security Protocol Mode (tunnel or transport)! Anti-replay service! Link with an associated policy in the SPD 26

Security Policy Database (SPD)! Für welche Pakete ist IPsec erforderlich! Kommende Pakete ohne AH/ESP werden verworfen! Gehende Pakete werden in AH/ESP verpackt! Bei Bedarf SA mit IKE erzeugen! Selektoren! Destination IP Address, Source IP Address! Name (z.b. User ID!)! Transport Layer Protocol (protocol number)! Source and Destination Ports! Policy! Discard the packet, bypass or process IPsec; falls ja:! Security Protocol and Mode! Enabled Services (anti-replay, authentication, encryption)! Algorithms (for authentication and/or encryption)! Link to an active SA in the SAD (if it exists) 27 Schlüsselmanagement von IPsec! Extensive Verwendung von symmetrischen Schlüsseln in IPsec! Für jede SA ein Schlüssel! Je zwei Schlüssel für ESP und AH (beide Richtungen)! Zwei Arten für die Schlüsselverwaltung:! manuell.! Nur für eine kleine Anzahl von Knoten geeignet! IKE: Internet Key Exchange, RFC 2409.! IKE ist eine Anpassung der allgemeineren Protokolle Oakley and ISAKMP! Diese Protokolle haben viele Optionen und Parameter. 28

Sicherheitsziele von IKE (1)! IKE (Oakley) beruht auf Diffie-Hellman-Schlüsselvereinbarung! Diffie-Hellmann allein reicht nicht:! Gefahr von Man-in-the-Middle-Angriffen! Diffie-Hellman-Algorithmus ist rechenintensiv (modulare Potenzierung ist aufwendig):! Gefahr von Denial-of-Service-Angriffen:! Verstopfungsangriff mit gefälschten Adressen und Ports: Angreifer verlangt eine große Anzahl von Schlüsseln 29 Sicherheitsziele von IKE (2)! Authentisierung der Kommunikationspartner (gegen Man-in-the-Middle-Angriff)! Vereinbarung eines frischen, gemeinsamen Geheimnisses! Zur Ableitung weiterer Schlüssel (ähnlich wie bei TLS/SSL)! Zur Sicherstellung der Vertraulichkeit und der Authentizität des IKE Kommunikationskanals (nicht des IPsec-Kommunikationskanals!)! Abwehr von DoS-Angriffen! Durch Cookie-Mechanismus (nächste Folien)! Sichere Aushandlung der Algorithmen:! Methode zur Authentisierung, Methode für den Schlüsselaustausch, Gruppe, Algorithmen zur Verschlüsselung und zur Bildung von MACs, Hash-Algorithmen 30

Cookie-Mechanismus (1)! Vorgeschlagen in Photuris, RFC 2522! Anti-Clogging Token (ACT)! Prinzip:! Jeder Kommunikationspartner sendet eine Pseudozufallszahl (Cookie)! Dieser Cookie muss von der Gegenseite bestätigt, d.h. zurückgesendet werden 31 Cookie-Mechanismus (2)! Drei grundlegende Anforderungen an Cookies:! Cookie muss von den Kommunikationspartnern abhängen (wie z.b. Quellund Zieladresse und Quell- und Zielports enthalten)! gegen Fälschen von Adressen und Ports! Nur der ausgebende Kommunikationsteilnehmer kann den Cookie erzeugen (und verifizieren)! Sender des Cookies muss also einen lokal vorhandenen geheimen Wert besitzen! Das Verfahren zum Erzeugen und Überprüfen der Cookies muss schnell durchführbar sein, um Verstopfungsangriffe zu verhindern! Kein Verfahren vorgeschrieben, aber empfohlen:! Hash (Quell- und Zieladresse, Quell- und Zielport, lokales Geheimnis)! Hashverfahren z.b. MD5 32

Die Phasen von IKE! Zwei Phasen:! Phase 1: Einrichten einer SA und eines sicheren Kanals für die Kommunikation in Phase 2! Bidirektional (!)! Authentisierung und Schlüsselaustausch! Richtet einen ISAKMP-Kanal ein (IPsec key management protocol) sicherer Kanal für Phase 2! Phase 2: Aushandlung der SAs für die eigentliche Kommunikation:! Schnellere Aushandlung als in Phase 1 ( quick mode ); nutzt den in Phase 1 etablierten Kanal! Mehrere Durchläufe der Phase 2 möglich! PFS (erneuter DH fuer IPsec-SAs) optional 33 Perfect Forward Secrecy! Szenario:! Angreifer hört Kommunikation ab! Kann sie nicht entschlüsseln, speichert sie daher nur! Später kompromittiert Angreifer einen Partner! Perfect Forward Secrecy:! Auch mit den Schlüsseln eines Partners läßt sich Sitzungsschlüssel (und damit die Kommunikation) nicht rekonstruieren! Lösung: authentisierter Diffie-Hellman! Statt verschlüsselt übertragenen Sitzungsschlüsseln 34

IKE: Phase 1! Zwei Varianten zum Aufbau eines sicheren IKE-Kanals! Main mode : sechs Nachrichten! Aggressive mode : Nur drei Nachrichten, Preisgabe von mehr Informationen! Mechanismen zur Authentisierung der DH-Schlüsselvereinbarung:! Verschiedene Arten der Authentisierung: u.a. DSS-Signatur, Public-Key-Verschlüsselung! Nonces gegen Replay-Angriffe! Zertifikate für öffentlichen Schlüssel! Wahl der Parameter für die DH-Schlüsselvereinbarung! mehrere fest vorgegebene Gruppen: n und g vorgegeben (Beispiel nächste Folie) 35 Beispiel: DH-Parameter! n=2 1536-2 1472-1 + 2 64 * { [2 1406!] + 741804}! Hexadezimale Darstellung: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF! Generator: g=2. 36

Vereinfachter Ablauf von IKE Initiator A Partner B Cookie-Erzeugung Anfrage-Cookie C A Cookie-Erzeugung Überprüfung CA, falls korrekt: Berechnen des gemeinsamen IKE- Schlüssels C A, Anfrage-Cookie C B DH-Parameter, C B Überprüfung C b, falls korrekt: Berechnen des gemeinsamen IKE-Schlüssels DH-Parameter Wechsels. Authentisierung Verschlüsselt Verschlüsselter Austausch von Sicherheitsattributen SA -Erzeugung SA -Erzeugung 37 Bemerkungen zu IPsec! Viele Modes, Optionen, etc.! Interoperabilitäts- und Konfigurationsalbtraum! Komplexe Wartung der IPsec-Policy und Installation! Sehr viele IPsec-Optionen, schlechte Dokumentation! Systemebene vs. Benutzerebene! Hauptanwendung: VPN-Szenarien! Z.B. Unterstützung von IPsec in Windows XP, Ersatz für PPTP 38

IPsec vs. NATs! Zusammenspiel von IPsec und NATs problematisch:! Authentisierung der äußeren Quelladressen in AH ist wenig nützlich! NATs ändern diese Adressen für nach außen gehende Pakete! Rückweg von globaler Seite in den genatteten Adreßraum?! Einkapselung in UDP 39 IKEv2! Ziele von IKEv2:! Vereinfachung und Verbesserung von IKEv1! Fixing von Fehlern! Performance-Verbesserung! Keine grundlegende Änderung: It was also a goal of IKEv2 to understand IKEv1 and not to make gratuitous changes. (Radia Perlman) 40

IKEv2: was ist neu?! Zwei-Phasen für Handshake nur noch optional:! Ein-Phasen-Mechanismus auch möglich, bei dem nur eine IPsec- SA erzeugt wird! Zwei-Phasen aber weiterhin empfohlen! Festlegung von Cipher-Suites (mit den entsprechenden Parametern) wie in SSL/TLS:! Der initiierende Kommunikationspartner bietet Cipher-Suites an, der antwortende Partner wählt die Kombination von Verfahren aus! Cookie-Mechanismus optional! Cookie braucht nur überprüft zu werden, wenn ein Angriff vorliegt (z.b. wenn Ressourcen knapp werden) 41 IKEv2: was ist neu?! You Tarzan, me Jane! IP-Adresse allein mag nicht ausreichen! Authentisierung kann mit EAP erfolgen! Leichte Erweiterbarkeit, z.b. für EAP-SIM! Während des Austauschs kann auch eine IP-Adresse vergeben werden! Szenario VPN-Login in geschütztes Netz! Überwindung von NATs ist Standard-Bestandteil! Patentfragen leider großenteils ungeklärt 42

Nächste Termine Mo, 20.06.2005 10 12 Uhr: Übung Do, 23.06.2005 08 10 Uhr: Sicherheitsmanagement Übungsblatt 9 bald auf Stud.IP, s.: https://elearning.uni-bremen.de 43