Systemsicherheit 12: IPSec Das TCP/IP-Schichtenmodell Anwendungsschicht (FTP, HTTP, SMTP,...) Transportschicht (TCP, UDP) Internetschicht (IP) Netzwerkschicht (z.b. Ethernet, TokenRing,...) IPSec Beobachtung: IP ist das einzige Protokoll, das im Internet durchgängig verwendet wird.
Hybride Verschlüsselung für IP? IP-Nutzlast wird symmetrisch verschlüsselt Verwendeter Schlüssel wird asymmetrisch verschlüsselt (RSA) in neuem Header transportiert Sender Empfänger Hybride Verschlüsselung für IP? (2) Nein! Public-Key-Kryptogramme sind zu lang: RSA-Kryptogramm ohne Zusatzinfo: 512-1024 Bit, d.h. 64-128 Byte. Mit notwendiger Zusatzinfo (Zertifikatskette) leicht 1000 Byte. Maximal Transfer Unit (MTU) liegt wegen Ethernet-Strecken oft nur bei 1500 Byte.
SKIP (1) SKIP wird heute noch von SUN unter dem Produktnamen SunScreen SKIP angeboten. Unter Solaris und Windows verfügbar. Entwicklungen wurden weitgehend eingestellt. (Die jüngsten technischen Papiere datieren von 1998.) SKIP kann mit den Datenformaten ESP und AH zusammenarbeiten. Dabei bleiben aber die Nachteile (s.u.) erhalten, Vorteile sind gegenüber IKE nicht zu erkennen. SKIP (2) SKIP: Simple Key management for Internet Protocols basiert auf der Diffie-Hellman-Schlüsselvereinbarung A kennt a g a g b B kennt b K = (g b ) a = g ab K = (g a ) b = g ab
SKIP (3) g a und g b werden in gemeinsamer Datenbank gespeichert Shared secret von A und B: g ab mod p A Privater Schlüssel: a (g b ) a = (g a ) b = g ab B Privater Schlüssel: b g a g b g a g b A: g a B: g b Datenbank aller öffentlichen Schlüssel SKIP (4): Ableitung der Schlüssel g ab mod p K ab Die 40 bis 128 Least Significant Bits bilden den Startwert K ab =Kij0 einer Schlüsselfolge Nach Ablauf einer festgelegten Lebensdauer wird Kij(n+1) mit Hilfe einer Hashfunktion aus Kijn gebildet
SKIP (5) : Header SKIP (6): Ableitung der Schlüssel Der mit Hilfe von Kijn entschlüsselte Wert Kp aus dem SK wird verwendet, um Verschlüsselungs- und Authentisierungsschlüssel abzuleiten Crypt Alg Kp MAC Alg 02h hash hash 00h 03h hash hash 01h E Kp E Kp A Kp A Kp
SKIP (7) Probleme: SKIP setzt funktionierende PKI voraus, insbesondere eine Datenbank aller öffentlichen Schlüssel SK ist zu groß IPSec Nahezu alle zwischen zwei Hosts ausgetauschten Daten werden verschlüsselt. IP ist verbindungslos, d.h. alle Sicherheitsparameter müssen im IP-Paket stehen Idee: Nur Referenz auf Datenbankeintrag, der den Schlüssel enthält, steht im IP-Paket. Schlüsselmanagement: Separate Applikation mit Datenbankeintrag IPSec: IETF RFCs 1828, 1829, 2085, 2104, 2401-2412, 2451, 2857 B2B-Projekte (ANX, ENX), viele große und kleine Hersteller (Cisco)
Warum Sicherheit auf IP-Ebene? Internet-Protokoll (IP) ist das meistbenutzte Netzprotokoll IP ist für alle Dienste und alle Netzwerke duchgängig: Netzwerke: IP über Ethernet, PPP/ISDN, X.25, ATM, Frame Relay,... Dienste: IP unter TCP, UDP Absicherung ist Applikations-unabhängig Einsatzgebiete LAN2LAN (Tunnel) Host2LAN (Tunnel) Host2Host (Transport) LAN Host Host GW I N T E R N E T GW GW LAN LAN Host
Tunnel- und Transportmodus Transportmodus Es werden Pakete höherer Protokolle (TCP/UDP,...) als Payloads gesichert Effizient, da keine Kapselung von IP-Paketen Möglich, solange kein Gateway als Anfangs- oder Endpunkt der Kommunikationsbeziehung auftritt Tunnelmodus Es werden IP-Pakete als Payloads gesichert Kapselung von IP-Paketen bedeutet Overhead Wird benötigt sobald ein Gateway als Anfangs- und/oder Endpunkt der Kommunikationsbeziehung auftritt IPSec: Datenformate Transportmodus ESP Originaler Daten Originaler ESP- Header Daten Padding ESP- Auth. Tunnelmodus ESP Originaler Daten Neuer ESP- Header Originaler Daten Padding ESP- Auth.
IPSec: Datenformate Aufbau des Encapsulation Security Payload (RFC 2406) Security Parameters Index (SPI) Sequence Number Field Payload Data (variable) authentisch vertraulich Padding (0-255 Bytes) Pad Length Authentication Data (variable) Next Header Formate: AH, Tunnel- und Transportmodus Transportmodus AH Originaler Daten Originaler AH- Header Daten Tunnelmodus AH Authentifiziert (bis auf sich verändernde Felder des s) Originaler Daten Neuer AH- Header Originaler Daten Authentifiziert (bis auf sich verändernde Felder des neuen s)
Formate: AH, Tunnel- und Transportmodus Authentication Header: Behandlung der zu authentisierenden Felder des s IPSec-Formate: AH (Authentication Header) Ziele des AH (RFC 2402) kryptographische Prüfsumme über den Payload und (fixe) Teilen des s Next Header Payload Length RESERVED Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) Daten
IPv6: Datenformate IPSec integraler Bestandteil des Standards IPv6- Header Erweiterungs -Header ESP- Header Daten Padding ESP- Auth. IPSec Bestandteile IKE TCP/IP SAD AH/ESP SPD TCP/IP
Schlüsselvereinbarung mit ISAKMP/IKE Security Association Database (SAD) Verwaltet ausgehandelte kryptographische Parameter Schlüssel Hash- und Verschlüsselungsalgorithmen Modus (ESP oder AH) Lebensdauer der SA Einträge sortiert nach IP-Adressen der anderen Hosts SPI zur Unterscheidung von SAs auf dem gleichen Host (wird vom empfangenden Host gewählt)
Empfangene IPSec-Pakete IKE IP SAD 1. Anhand der Absendeadresse und der SPI des empfangenen IPSec- Pakets werden aus der SAD die kryptographischen Parameter gelesen. AH/ESP TCP/IP SPD 2. Das IP-Paket wird entschlüsselt/verifiziert und an den TCP/IP-Stack übergeben. Security Policy Database (SPD) Legt fest, wie mit zu sendenden IP-Paketen zu verfahren ist unverschlüsselt senden, verwerfen oder mit SPI x verschlüsselt senden. Unterschiedliche Policies für gleiche Zieladresse möglich Auswahl anhand höherer Protokolle, z.b. UDP Port 500 (IKE) unverschlüsselt senden
Zu sendende IPSec-Pakete IKE TCP/IP 1. Anhand der Zieladresse des IP- Pakets (und ggf. anderer Parameter) wird in der SPD ermittelt, wie weiter zu verfahren ist, und welche SPI zu verwenden ist. SAD AH/ESP SPD 2. Anhand der von der SPD gelieferten SPI werden aus der SAD die kryptographischen Parameter gelesen. IP 3. Das verschlüsselte IP-Paket wird an den IP-Stack übergeben. Schlüsselvereinbarung mit ISAKMP/IKE IKE TCP/IP 1. Mit IKE wird ein sicherer, bidirektionaler ISAKMP-Tunnel aufgebaut ( Eintrag bidirektionale SA in SAD). 2. Innerhalb dieses Tunnels wird mit IKE je eine SA für jede Richtung ausgehandelt ( Eintrag zweier unidirektionaler SAs in SAD) SAD AH/ESP SPD IP
IKE (Internet Key Exchange Protocol) Standardisiert bei der IETF (RFC 2409) Setzt sich zusammen aus folgenden Protokollen: ISAKMP (Internet Security Association and Key Management Protocol, RFC 2408) OAKLEY (Key Determination Protocol, RFC 2412) DoI (The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407) IKE (The Internet Key Exchange, RFC 2409) insgesamt ca. 490.000 Byte Spezifikation Geschichte von IKE (1) Basiert auf: Diffie-Hellman-Schlüsselvereinbarung A kennt a g a g b B kennt b K = (g b ) a = g ab K = (g a ) b = g ab
Geschichte von IKE (2) Station-to-Station-Protokoll (Diffie, van Oorschot und Wiener) Löst das Man-in-the-Middle-Problem von DH Geschichte von IKE (3) Photuris (RFC 2522, Karn und Simpson) Einsatz von (stateless) Cookies zum Schutz gegen Denial-of- Service-Angriffe
Geschichte von IKE (4) SKEME (Krawzyk 1996) Authentisierung ohne digitale Signaturen Bei mehrmaligem DH-Austausch höhere Performance, da SHARE nur einmal benötigt wird Geschichte von IKE (5) SKEME (Krawzyk 1996) Phasen können auch verschachtelt werden
Geschichte von IKE (6) OAKLEY (RFC 2412, Orman): Kombination aus Photuris, SKEME, STS Datenfeld CKY-I CKY-R MSGTYPE GRP g^x (or g^y) EHAO EHAS IDP ID(I), ID(R) Ni, Nr Beschreibung Cookie des Initiators Cookie des Responders Typ der nachfolgenden Nachricht: ISA_KE&AUTH_REQ oder ISA_KE&AUTH_REP bei Schlüsselaustausch, ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP beim Aushandeln einer neuen Diffie-Hellman-Gruppe. Name/Bezeichnung der verwendeten Diffie-Hellman-Gruppe DH-Nachricht als ganze Zahl beliebiger Länge ( multiprecision integer ) Liste mit angebotenen Verschlüsselungs-, Hash- und Authentisierungs algorithmen ( Encryption Hash Authentication Offering ) Auswahl jeweils eines Verschlüsselungs-, Hash- und Authentisierungs algorithmus ( Encryption Hash Authentication Selection ) Flag das angibt, ob die Daten hinter der Verschlüsselungsgrenze verschlüsselt sind (IDP, 1) oder nicht (NIDP, 0) Identität von Initiator bzw. Responder Zufallszahl ( nonce ) von Initiator bzw. Responder Geschichte von IKE (7) OAKLEY (RFC 2412, Orman)
Geschichte von IKE (8) OAKLEY: Feste Felder, Authentisierung aus STS oder SKEME, Einsatz von Cookies (Photuris) für 2 verschiedene Zwecke Geschichte von IKE (9) OAKLEY: 3 Primzahlgruppen und 2 EC-Gruppen sind standardisiert
ISAKMP Ehrgeiziges Ziel: ISAKMP soll FÜR ALLE Schlüsselvereinbarungen im Internet genutzt werden Stellt Protokollrahmen mit bestimmten Nachrichtenformaten bereit UDP Port 500 Ansatz: 2-Phasen-Modell Phase 1: Aufbau eines sicheren Kanals zwischen 2 Instanzen Parteien authentifizieren sich gegenseitig ISAKMP-SA (Security Associations) wird etabliert Phase 2: Aufbau von SAs für Clienten Benutzung der Phase1-SA als sicheren Kanal Etablierung von IPSec SAs ISAKMP (2) ISAKMP Phase 1: Keine SA zur Verschlüsselung Originaler UDP 500 ISAKM P Daten ISAKMP Phase 2: ISAKMP-SA zur Verschlüsselung Originaler UDP 500 ISAKM P Daten IPSec: IPSec-SA zur Verschlüsselung Neuer ESP- Header Originaler Daten Padding ESP- Auth.
ISAKMP (3) ISAKMP (4)
ISAKMP (5) ISAKMP-Felder Next Payload Type Value NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14-127 Private USE 128-255 Internet Key Exchange (IKE) ISAKMP und OAKLEY bieten zu viele Optionen: Interoperabilität kann nicht gewährleistet werden ISAKMP-Dokument ist unlesbar ISAKMP muss mit einem Domain of Interpretation: IP -Dokument an IPSec angepasst werden OAKLEY erlaubt zu viele verschiedene Modi, und Kombinationen dieser Modi IKE (RFC 2409, 41 Seiten): Auswahl verschiedener Optionen, und Beschränkung auf diese ISAKMP (RFC 2408, 86 Seiten) DOI-IP (RFC 2407, 32 Seiten) OAKLEY (RFC 2412, 55 Seiten) In Summe: 214 Seiten Spezifikation
IKE Phase 1 Main Mode IKE Phase 1 Main Mode (2)
IKE Phase 1 Main Mode (3) IKE Phase 2 Quick Mode
IKE Phase 2 Quick Mode Aussagen zur Interoperabilität http://ipsec-wit.antd.nist.gov/ Web-basiertes Test-Tool des amerikanischen NIST http://www.icsalabs.com/html/communities Interoperabilitätstests bei der ICSA (International Computer Security Association) aktueller Kompatibilitätsstand: 1.0D Interoperabilität mit Zertifikaten: 1.1 (nur wenige Zertifizierungen) http://www.vpnc.org/ Virtual Private Network Consortium
Weiterentwicklungen Network Address Translation (NAT) RFC 1918: Address Allocation for Private Internets The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0-10.255.255.255 (10/8 prefix) 172.16.0.0-172.31.255.255 (172.16/12 prefix) 192.168.0.0-192.168.255.255 (192.168/16 prefix) Das Paar (Private IP-Adresse, Portnummer) wird durch NATP- Gateway durch (Offizielle IP-Adresse, freie Portnummer) ersetzt Weiterentwicklungen (2) Network Address Translation (NAT) Problem: NAT(P) ist mit IPSec nicht mehr möglich Lösung: Ergänzung zu IKE um zu erkennen, ob zwischen zwei Hosts NAT(P) stattfindet Falls ja, UDP-Enkapsulierung von IP-Paketen
Weiterentwicklungen (3) IKEv2 Probleme mit IKE Anfällig gegen DoS-Attacken (Cookies unwirksam) Zu langsam (3,5 bis 4,5 RTT) Zu komplex (über 4 RFCs verteilt) IKEv2 soll diese Probleme lösen Nur noch ein RFC IPSec-Verschlüsselung bereits nach 2 RTT möglich Besserer Schutz gegen DoS Integration von NAT Traversal Dead Peer Detection Weiterentwicklungen (3) IPSEC KEYing information resource record (ipseckey) http://www.ietf.org/html.charters/ipseckey-charter.html Nutzung von Secure DNS zum Schlüsselaustausch
Sourcecode KAME Project http://www.kame.net/ Freie IPv6 und IPv4-IPSec-Implementierung für BSD Unix Linux FreeS/WAN http://www.freeswan.org/ Freie IPSec-Implementierung für Linux, mit einigen Problemen SSH Communications Security http://www.ssh.com/ Führende Firma für kommerzielle IPSec-Entwicklungstools