IT-Sicherheit:

Sicherheitsprotokolle

Zurück zur Theorie:

Wie funktionierenSicherheitsprotokolle?

3

Das Needham-Schroeder-Protokoll

! Roger Needham, Michael Schroeder (1978)! Schlüsselaustausch-Protokoll:

Kommunikationspartner A und B vereinbaren mit Hilfe desProtokolls einen gemeinsamen Schlüssel KAB, ohne einPublic-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: KAS

und KBS

4

Die Schritte des Needham-Schroeder-Protokolls (1)

1. A ! S : A, B, NA

! A fragt S nach einem gemeinsamen geheimen Schlüssel KAB fürdie Kommunikation mit B.

2. S ! A : {NA, B, KAB, {KAB,A}KBS }KAS

! S antwortet mit dem geheimen Schlüssel KAB, der mittels KAS

verschlüsselt ist

! das Nonce NA verhindert einen Replay-Angriff

! Nachricht enthält ferner ein „Zertifikat“ für B mit demgemeinsamen geheimen Schlüssel KAB

5

Die Schritte des Needham-Schroeder-Protokolls (2)

3. A ! B :, {KAB,A}KBS

! A sendet das von S ausgestellte „Zertifikat“ an B, d.h. B kennt nunden gemeinsamen Schlüssel KAB

4. B ! A : {NB}KAB

5. A ! B : {NB-1} KAB

! Die Schritte 4. und 5. stellen eine Art Challenge-Response dar: Büberprüft, dass A wirklich mit B kommunizieren will.

6

Sicherheitsproblem desNeedham-Schroeder Protokolls

! Subtiles Sicherheitsproblem:B nimmt an, dass der Schlüssel KAB aktuell von S stammt(vgl. Nachricht 3):

3. S ! A : {NA, B, KAB, {KAB,A}KBS }KAS

! Wiedereinspielungen mit geknacktem KAB sind möglich.! Bei Kompromittierung von KAS kann sich der Angreifer sogar auf

Vorrat Schlüssel KAX für verschiedene KommunikationsteilnehmerX besorgen (nicht nur für B).Selbst wenn A erkennt, dass KAS gebrochen ist, werden dadurchdie Schlüssel KAX nicht automatisch ungültig.

! Lösung: Nachrichten mit Zeitstempel versehen.

7

Design-Prinzipien fürSicherheitsprotokolle (1)

! M. Abadi, R. Needham: Prudent Engineering Practice forCryptographic Protocols, IEEE Transactions on SoftwareEngineering, 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

8

Design-Prinzipien fürSicherheitsprotokolle (2)

! Regel 2: Verschlüsselungszweck klären:! Gewährleisten der Vertraulichkeit,! Nachweis der Authentizität des Absenders! Verknüpfung unterschiedlicher Nachrichten-BestandteileBemerkung: unterschiedliche Schlüssel für unterschiedliche Zwecke

verwenden, z.B. Signieren, Verschlüsseln

! Regel 3: Vorsicht bei DoppelverschlüsselungRedundanz verursacht unnötige Kosten, ggf. sogar Lücken

9

Design-Prinzipien fürSicherheitsprotokolle (3)

! Regel 4: Digitale Signaturen:Erst Signieren (nach dem Hashen), dann Verschlüsseln

! Regel 5: frischer SchlüsselFrischenachweis über Zeitstempel oder Nonces(vgl. Problem bei Needham-Schroeder Protokoll)

10

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

11

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 KCS für den Ticket-Granting Server S von AS an

! KCS 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 Sund dem Dienst -Server B durch

12

Kerberos-Architektur

Benutzer

AliceC

Client AS

Schlüssel-

datenbank

Ticket-Granting-Server

S

DB Drucken NFS...

Key Distribution Center – KDC

1.

2.

3.

4.

5.6.

Server Server Server

13

Kerberos: Protokollschritte

! Schritte 1. und 2.: Aushandlung des gemeinsamen Schlüssel KCS fürden Client C und den Ticket-Granting-Server S

! Hier nur das abgewandelte Needham-Schroeder-Protokoll:

3. C ! S : C, B

4. S ! C : {TS, L, KCB, B, {TS, L, KCB,C}KBS }KCS

(T Zeitstempel, L Gültigkeitsdauer)

5. C ! B :, {TS, L, KCB,C}KBS , {C,TC}KCB

6. B ! C : {TS+1}KCB

! {TS, L, KCB,C}KBS ist das Ticket für den Zugriff auf den Server

! {C,TC}KCB der Authentikator

Sicherheitsprotokolle auf denunteren Schichten:IPsec

(unter Nutzung von Material von Prof. Gollmann, TU-Hamburg Harburg, das wiederum auf Material von Kenny Paterson, Royal Holloway, basiert)

15

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...

16

Sicherer Kanal (Secure Channel)

! Oft nicht ganz klar:Was genau wird authentisiert?! Maschine, OS?

! Anwendung?

! Benutzer?

! Nicht-Ziele:

NichtabstreitbarkeitSchutz lokaler Daten

17

Schritte zu einem sicheren Kanal

! Ein sicherer Kanal wird üblicherweise in folgendenSchritten erzeugt:! Authentisierter Schlüsselaustausch

! Eine oder beide Parteien werden authentisiert

! Ein frisches gemeinsames Geheimnis wird erzeugt

! Ableitung von Schlüsselinformationen aus dem gemeinsamenGeheimnis! MAC

! Verschlüsselung

! Schutz des Datenverkehrs mit MACs und durch Verschlüsselung

! Nützlich: Wiederverwendung von Schlüsseln;schnelles Aushandeln neuer Schlüssel (rekeying)

18

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

19

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 einessicheren 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

20

Transportmodus

Header Payload

IP datagram

Network

Header Payload

IP datagram

21

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-Paketeingkapselt! 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.

22

Tunnelmodus (2)

Header PayloadHeader Payload

Header Payload

Inner IP datagram

OuterHeader

Network

Header Payload

Inner IP datagram

Inner IP datagramInner IP datagram

Security

Gateway

Security

Gateway

OuterHeader

23

AbgesagtIPsec-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! Laufnummern

! Abwehr von Replay-Angriffen! AH-Laufnummer wird mitauthentisiert

! Einsatz von MACs und geheimen Schlüsseln

24

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

25

Security Association (SA)

! Woher wissen die Kommunikationspartner, welche Parameter für ESPbzw. 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 ...

26

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

27

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)

28

Schlüsselmanagement von IPsec

! Extensive Verwendung von symmetrischen Schlüsseln inIPsec! 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.

29

Sicherheitsziele von IKE (1)

! IKE (Oakley) beruht aufDiffie-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

30

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 IKEKommunikationskanals (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üsselungund zur Bildung von MACs, Hash-Algorithmen

31

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

32

Cookie-Mechanismus (2)

! Drei grundlegende Anforderungen an Cookies:! Cookie muss von den Kommunikationspartnern abhängen (wie z.B. Quell-

und Zieladresse und Quell- und Zielports enthalten)! gegen Fälschen von Adressen und Ports

! Nur der ausgebende Kommunikationsteilnehmer kann den Cookieerzeugen (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

33

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

34

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) nichtrekonstruieren

! Lösung: authentisierter Diffie-Hellman! Statt verschlüsselt übertragenen Sitzungsschlüsseln

35

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)

36

Beispiel: DH-Parameter

! n=21536 - 21472 - 1 + 264 * { [21406 !] + 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.

37

Vereinfachter Ablauf von IKEInitiator A Partner B

Cookie-Erzeugung

Cookie-ErzeugungAnfrage-Cookie CA

CA , Anfrage-Cookie CBÜberprüfung CA ,

falls korrekt:

DH-Parameter, CB

Überprüfung Cb ,falls korrekt: Berechnen des gemeinsamen IKE-Schlüssels

DH-ParameterBerechnen desgemeinsamen IKE-Schlüssels

Verschlüsselter Austausch von Sicherheitsattributen

Wechsels. Authentisierung

SA -Erzeugung SA -Erzeugung

Verschlüsselt

38

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

39

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

40

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)

41

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)

42

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 vergebenwerden! Szenario VPN-Login in geschütztes Netz

! Überwindung von NATs ist Standard-Bestandteil

! Patentfragen leider großenteils ungeklärt

43

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