slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Hugo Krawczyk Technion & IBM Research PowerPoint Presentation
Download Presentation
Hugo Krawczyk Technion & IBM Research

Hugo Krawczyk Technion & IBM Research

250 Vues Download Presentation
Télécharger la présentation

Hugo Krawczyk Technion & IBM Research

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. The Cryptography of the IPSec and IKE Protocols Hugo Krawczyk Technion & IBM Research

  2. Outline of the Talk • Short introduction to IPSec (very high level) • Some crypto aspects of IPSec • Introduction to IKE functionality (IKE = “Internet Key Exchange”) • The cryptography of IKE • Rationale and development of SIGMA • the cryptographic core of the main authenticated Diffie-Hellman exchange of IKE (v1 and v2)

  3. IPSec: IP Security [RFC2401-12] • Transport security at the IP (Internet Protocol) layer • Goal: secure traffic between any two IP systems • Any device with an IP address: hosts, gateways, mobile devices, IP-enabled microwaves, … • Security services for IP packets • encryption and authentication • SA (“Security Association”) creation & management • Application independent: security for the “Internet infrastructure”

  4. Applications Applications API’s API’s TCP/UDP/… TCP/UDP/… TCP/UDP/… TCP/UDP/… IP/IPSEC IP Secure Tunnel IP/IPSEC Network Device Drivers Network Device Drivers Network Layers

  5. Virtual Private Networks (VPN) Source:

  6. IPSec Processing Basics • Two IP devices A and B want to communicate securely under the protection of IPSec • First a Security Association (SA) between A and B is established • SA: a set of parameters, algs, & shared keys agreed between A and B, and locally stored by each party • Then, A and B secure the IP traffic by applying ENC and MAC on each IP packet they exchange • Omitted: many details, system issues, implementation, complexities, controversies, etc

  7. IP HDR Payload Encapsulated Security Payload (ESP) Encrypted Payload IP HDR ESP HDR MAC ESP-Tunnel Mode Encryp’d IP HDR Encrypted Payload ESP HDR IP HDR ESP HDR Payload ESP MAC-only MAC MAC Gateway IP HDR IPSec Encapsulation Mechanisms Plain IP packet

  8. length (from IP Hdr) IPSec’s Crypto Algorithms • Negotiable • Default (for interoperability and common use) • Encryption: 3DES (moving to AES) • Integrity: HMAC (SHA1, MD5) • Some crypto highlights: • HMAC developed for use in IPSec • the prepend key story: MACK(M)=MD5(K | M) • encrypt-then-authenticate (the “right order”) [Bellovin’96, K’01, CK’01]

  9. IKE: Internet Key Exchange • Creates SAs for use by IPSec • Negotiates security parameters for the SA • type of key exchange, credentials, crypto algorithms, crypto strength, traffic to protect, etc • Key Exchange: share keys between parties • Manages SAs: create, refresh, maintain, delete • IKEv1 (1998): ISAKMP for mgmt, IKE for KE • IKEv2 (2003): IKE specifies it all

  10. SPI ADDR ALG KEY … WRITE . . . . . . . . . . . . . . . READ SA Database (SAD) The IKE-IPSec API IKE Signaling KEY EXCHANGE Session Mgmt Application Kernel (OS) IPSec Packet handling CRYPTO PROCESSING (ENC,MAC) Inbound-Outbound in/out

  11. The Cryptography of IKE • We omit discussion of broad mgmt functions –focus on the cryptography of IKE key exchange • Driving cryptographic requirements • Authenticated key exchange: public and symmetric keys • Perfect forward secrecy (PFS): exposure of long term keys does not compromise security of past sessions • Diffie-Hellman (optional for fast re-key functionality) • Identity protection: hiding parties identities from passive and/or active attackers • Logical identities (e.g. cert’s) vs. IP/physical addresses

  12. IKEv1 [RFC2409] • Several authenticated DH protocols supported. Differ in mode of authentication: • Long-term pre-shared (symmetric) key • Public-key encryption • Digital Signature • Re-key (with optional DH) • With and without identity protection • Modes designed to share as many elements as possible (e.g., auth’d info, nonces, key derivation)

  13. IKEv1 • Many cryptographic elements taken from SKEME [K’95] and OAKLEY [Orman’98] • Uniform set of authentication modes • Key derivation • Authentication based on public-key encryption • But SKEME did not provide signature-based auth’n • Signature mode specifically developed for IKE (the SIGMA protocol) • Replacement for Photuris’ signature-based DH which used an (insecure) variant of the STS protocol

  14. IKEv2 (RFC to appear) • Simplification of SA management spec • Simplification of Key Exchange • Got rid of many of the authentication options: e.g., the PK Encryption and “aggressive” modes • Single signature mode: kept SIGMA design • Added password-based authentication • Asymmetric setting [HK’99] • Streamlined key derivation spec • Added optional Denial-of-Service defense [Karn]

  15. SIGMA: IKE’s Signature Mode(v1&v2) • The focus for the rest of this talk • A paper containing the detailed rationale for SIGMA design contributed to the proceedings • Intended to a broad audience of crypto designers and security engineers • A formal analysis presented last year [Canetti-K’02] • SIGMA stands for “SIGn-and-MAc” the main authentication elements in the protocol • The name SIGMA is relatively recent (used in . IKEv2 revision to differentiate from other proposals) • Design goes back to 1995

  16. SIGMA: Basic Requirements • Diffie-Hellman (PFS) • Signature-based authentication • Optional identity protection

  17. Identity Protection • Passive vs. active attacker • Best possible: both id’s protected against passive attacks but only one against active attacks • Whose identity should get active defense? • Initiator: roaming user (e.g. hide location) • Responder: avoid probing attacks (who are you?) • Presents some design challenges: conflict between anonymity and authentication • SIGMA principle: id protection as an added value (KE must be secure also w/o the id protection part)

  18. How did we get to SIGMA? • By learning from the good and bad aspects of previous protocols • Here is the story… • We start with “core security” issues and then add identity protection

  19. A, gx B, gy Diffie-Hellman Exchange [DH’76] AB • both parties compute the secret key K=gxy • assumes authenticated channels (DDH assumption) • open to m-i-t-m in a realistic unauthenticated setting

  20. A, gx B, gy, SIGB(gx,gy) SIGA(gy,gx) Basic Authenticated DH (BADH) A B Each party signs its own DH value to prevent m-i-t-m attack (and the peer’s DH value as a freshness guarantee against replay ) A: “Shared K=gxy with B” (KB) B: “Shared K=gxy with A” (KA) Looks fine, but… (there must be a reason we call it BADH)

  21. Identity-Misbinding Attack*[DVW’92] (a.k.a. Unknown Key-Share attack) A, gx E, gx A B E • Any damage? Wrong identity binding! A: “Shared K=gxy with B” (KB) B: “Shared K=gxy with E” (KE) E doesn’t know K=gxy but B considers anything sent by A as coming from E B, gy, SIGB(gx,gy) B, gy, SIGB(gx,gy) SIGA(gy,gx) SIGE(gy,gx)

  22. A: “Shared K=gxy with B” (KB) B: “Shared K=gxy with E” (KE) • B = Bank A,E = customers • A B: {“deposit $1000 in my account”}K • B deposits the money in “K”’s account, i.e. E’s! • B=Central Command A=F-16 E= small unmanned plane • B E: {“destroy yourself”}K • E passes command to A A destroys itself • Identity Misbinding Attack: the “differential cryptanalysis of key-exchange protocols”

  23. A Possible Solution (ISO-9796) A, gx A B B, gy, SIGB(gx,gy,A) SIGA(gy,gx,B) Thwarts the identity-misbinding attack by including the identity of the peer under the signature

  24. B, gy, SIGB(gx,gy,E) B, gy, SIGB(gx,gy,E) The ISO defense A, gx E, gx A B A: aha! B is talking to E not to me! Note that E cannot produce SIGB(gx,gy,A) • The ISO protocol thus avoids the misbinding attack; but is it secure?? E

  25. The ISO Protocol is… Secure [CK’01]  Unsuited for identity protection • B needs to know A’s identity before he can authenticate to A; same for A  Protection against active attackers is not possible • Another privacy concern: leaving a signed proof of communication (signing the peer’s identity) • Letting each party sign its own identity rather than the peer’s solves the privacy issues but makes the protocol insecure (the identity-misbinding attack again)

  26. A, gx A A B B B, gy, {SIGB(gx,gy)}K B, gy, {SIGB(gx,gy)}K {SIGA(gy,gx )}K {SIGA(gy,gx )}K Another Solution: STS [DVW’92] • Idea: each peer proves knowledge of K=gxy (prevents the Id-M attack since in BADH E doesn’t know gxy) • As a “Proof of Knowledge” the STS protocol uses encryption under K=gxy

  27. STS Pro’s and Con’s  Pro: STS can protect identities • Peer’s id not needed for your own authentication • Can extend encryption to cover identities (or cert’s) gx A A B B gy, {B, SIGB(gx,gy)}K {A, SIGA(gy,gx )}K

  28. STS Pro’s and Con’s  Con: encryption is not the right function to . prove knowledge of a key • E.g.: if Eve can register A’s public-key under her name she can mount the I-M attack (w/o even knowing gxy!) gx A A E B B gy, B, {SIGB(gx,gy)}K A, {SIGA(gy,gx )}K E/

  29. Identity-Misbinding on STS • Assumes Eve registers A’s PK as her own PK • Many certification settings check for identity of registrant but not for “possession” (PoP) of private key (in particular, in common IPSec settings) • The attack is trivial if cert’s not encrypted and trivial too if encrypted with a stream cipher • First issue is debatable but enough to show that “proof of knowledge of gxy” via encryption is not enough. Moreover…

  30. STS with MAC (instead of encryption) [DVW] gx A A B B E • MACK better suited to provide Proof of Knowledge of K • Yet: same attack as w/ encryption is possible! • Can be mounted even if priv-key PoP is required!!! [BM99] Even if id put under sig (“on-line registration attack”) gy, B, SIGB(gx,gy), MACK(SIGB) A, SIGA(gy,gx ), MACK(SIGA) E/

  31. What is going on? • The point is that “proof of knowledge” of K=gxy is not the issue • What is required is: binding the key K with the peer identities • Which brings us to the SIGMA design • SIGnand MAc-your-own-identity!! • And what about Photuris? • Yet another STS variant: Sign K=gxy as “proof of knowledge”; also insecure (see the SIGMA paper)

  32. SIGMA: Basic Version gx A B gy, B, SIGB (gx,gy) , MACKm(B) A, SIGA(gy,gx) , MACKm(A) *Km and session key derived from gxy via a prg/prf SIG and MAC: complementary roles (mitm and binding, resp) Does not require knowing the peer’s id for own . authentication  Great for id protection

  33. SIGMA-I:active protection of Initiator’s id gx A B gy, {B, SIGB (gx,gy), MACKm(B) }Ke {A, SIGA(gy,gx), MACKm (A) }Ke *Ke and Km derived from gxy via pseudorandom function Responder (B) identifies first  Initiator’s (A) idprotected

  34. SIGMA-R:active protection of Responder’s id A B gx gy { A, SIGA (gy,gx), MACKm (A) }Ke { B, SIGB (gx,gy), MACKm’(B) }Ke’ Note: Km, Km’ and Ke, Ke’ (againstreflectionattack)

  35. gy, B, SIGB (MACKm (B, gx,gy)) IKEv1 Variant: MAC under SIG Equivalent security (just save MAC space): A gx B A, SIGA (MACKm (A, gy,gx))  this is IKE’s “aggressive mode” (no id protect’n) Note: MAC(SIG(id,…)) is not secure!! (STS-MAC)

  36. IKE Main Mode A B gx gy { A, SIGA (MACKm (A, gy,gx)) }Ke { B, SIGB (MACKm’ (B, gx,gy)) }Ke’ IKE v2: a slight variant – only MAC(id) under SIG

  37. SIGMA Summary • SIGMA suitable for most applications requiring a Diffie-Hellman key exchange: • Simple and efficient (minimizes msgs and comput’n) • No over-design (nor under-design) • With or without ID Protection • Provides best possible protection (I or R protected against active attacks depending on application) • The “intelligent passport” application • Standardized: core key-exchange protocol for both IKEv1 and IKEv2 • Recently proposed for smart-card authentication to ESIGN

  38. But is SIGMA Secure?! • Secure! (rigorous analysis): Canetti-K Crypto’02 • Formal proof: each element is essential • e.g., SIG(MAC(id,…)) vs. (SIG(id,…), MAC(SIG(id,…))) • Guarantees secure channels • Secure composition with arbitrary applications (UC) • From theory to practice • Specification, implementation, DETAILS (see “full fledge” appendix in paper -- web version) • DoS defenses: selective (IKEv2), integral (JFK-R) • ID Prot’n: Encryption secure against active attackers (CCA) • Certificates, … Care with variants!! RCCA [Thu] X

  39. If we only had more time… • Many aspects of IKE’s crypto not covered • Pre-shared key authentication • Password-based protocol IKEv2 (asym. model [HK99]) • Key derivation from DH: over non-DDH groups, and the use of “Public PRFs” as Universal Hashing • Analysis: work in progress • Many aspects of SIGMA design and properties not covered (see proceedings – url for full version) • Biggest missing piece in this presentation: formalizing KE and analysis

  40. Final Remark • The KE area has matured to the point in which there is no reason to use unproven protocols • Addressing practicality does not require (or justify) giving up on rigorous analysis • Proofs not an absolute guarantee (relative to the security model), but the best available assurance • It is easy to design simple and secure key-exchange protocols, but it is easier to get them wrong…

  41. And one truly last word… ThAnKs 