1. 1 03Crypto - Hugo Krawczyk

2. 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. 3 03Crypto - Hugo Krawczyk 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. 4 03Crypto - Hugo Krawczyk Network Layers Application s TCP/UDP/… IP/IPSEC Network Device Drivers TCP/UDP/… API’s TCP/UDP/… IP/IPSEC API’s TCP/UDP/… Application s IP Secure Tunnel Network Device Drivers

5. 5 03Crypto - Hugo Krawczyk Virtual Private Networks (VPN) Source: www.vpn-technology.com

6. 6 03Crypto - Hugo Krawczyk 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. 7 03Crypto - Hugo Krawczyk IPSec Encapsulation Mechanisms IP HDRPayload Plain IP packet IP HDR Encrypted Payload ESP HDR MAC Encapsulated Security Payload (ESP) ESP-Tunnel Mode MAC Encrypted Payload Encryp’d IP HDR Gateway IP HDR ESP HDR IP HDRPayload ESP HDR MAC ESP MAC-only

8. 8 03Crypto - Hugo Krawczyk ESP Format [RFC 2403] IP Header SPI Replay Prevention Sequence Number Initial Vector Payload Padding Pad Length Protocol MAC Value MAC Encrypted (padded) Payload

9. 9 03Crypto - Hugo Krawczyk 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: MAC K (M)=MD5(K | M)  encrypt-then-authenticate (the “ right order ” ) [Bellovin ’ 96, K ’ 01, CK ’ 01] length (from IP Hdr)

10. 10 03Crypto - Hugo Krawczyk 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

11. 11 03Crypto - Hugo Krawczyk IKE: Internet Key Exchange When A wants to talk to B under protection of IPSec, and they do not have an established SA:  A invokes IKE to signal B its request for an SA  IKE is run between A and B: result is a shared SA (services to be applied and fresh shared keys)  Negotiated parameters stored locally at A and B (SAD)  SPI (sec. parameters index): pointer to SA included in the IPSec header of each packet Architectural separation: IKE writes to SAD, IPSec reads from SAD (full picture more involved: e.g.SPD)

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

13. 13 03Crypto - Hugo Krawczyk 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

14. 14 03Crypto - Hugo Krawczyk 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)

15. 15 03Crypto - Hugo Krawczyk 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

16. 16 03Crypto - Hugo Krawczyk 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]

17. 17 03Crypto - Hugo Krawczyk 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

18. 18 03Crypto - Hugo Krawczyk SIGMA: Basic Requirements Diffie-Hellman (PFS) Signature-based authentication Optional identity protection

19. 19 03Crypto - Hugo Krawczyk 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)

20. 20 03Crypto - Hugo Krawczyk 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

21. 21 03Crypto - Hugo Krawczyk Diffie-Hellman Exchange [DH’76] A B both parties compute the secret key K=g xy assumes authenticated channels (DDH assumption) open to m-i-t-m in a realistic unauthenticated setting B, g y A, g x

22. 22 03Crypto - Hugo Krawczyk Basic Authenticated DH (BADH) 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=g xy with B ” (K  B) B: “ Shared K=g xy with A ” (K  A) Looks fine, but … B, g y, SIG B (g x,g y ) SIG A (g y,g x ) A, g x AB (there must be a reason we call it BADH)

23. 23 03Crypto - Hugo Krawczyk Identity-Misbinding Attack * [DVW’92] (a.k.a. Unknown Key-Share attack)  Any damage? Wrong identity binding! A: “ Shared K=g xy with B ” (K  B) B: “ Shared K=g xy with E ” (K  E) E doesn ’ t know K=g xy but B considers anything sent by A as coming from E B, g y, SIG B (g x,g y ) A, g x E, g x B, g y, SIG B (g x,g y ) SIG A (g y,g x ) SIG E (g y,g x ) AB E

24. 24 03Crypto - Hugo Krawczyk A: “Shared K=g xy with B” (K  B) B: “Shared K=g xy 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 ”

25. 25 03Crypto - Hugo Krawczyk A Possible Solution (ISO-9796) A, g x B, g y, SIG B (g x,g y,A) SIG A (g y,g x,B) B Thwarts the identity-misbinding attack by including the identity of the peer under the signature A

26. 26 03Crypto - Hugo Krawczyk The ISO defense A: aha! B is talking to E not to me! Note that E cannot produce SIG B (g x,g y,A) The ISO protocol thus avoids the misbinding attack; but is it secure?? B, g y, SIG B (g x,g y,E) A, g x E, g x AB E B, g y, SIG B (g x,g y,E)

27. 27 03Crypto - Hugo Krawczyk 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)

28. 28 03Crypto - Hugo Krawczyk Another Solution: STS [DVW’92] Idea: each peer proves knowledge of K=g xy (prevents the Id-M attack since in BADH E doesn ’ t know g xy ) As a “Proof of Knowledge” the STS protocol uses encryption under K=g xy B, g y, {SIG B (g x,g y )} K {SIG A (g y,g x )} K A, g x AB B, g y, {SIG B (g x,g y )} K {SIG A (g y,g x )} K AB

29. 29 03Crypto - Hugo Krawczyk 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) g x AB g y, {B, SIG B (g x,g y )} K AB {A, SIG A (g y,g x )} K

30. 30 03Crypto - Hugo Krawczyk 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 g xy !) g x AB g y, B, {SIG B (g x,g y )} K AB A, {SIG A (g y,g x )} K E E/E/

31. 31 03Crypto - Hugo Krawczyk 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 g xy ” via encryption is not enough. Moreover …

32. 32 03Crypto - Hugo Krawczyk STS with MAC (instead of encryption) [DVW] MAC K 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 ” ) g x AB g y, B, SIG B (g x,g y ), MAC K (SIG B ) AB A, SIG A (g y,g x ), MAC K (SIG A ) E E/E/

33. 33 03Crypto - Hugo Krawczyk What is going on? The point is that “ proof of knowledge ” of K=g xy is not the issue What is required is: binding the key K with the peer identities Which brings us to the SIGMA design  SIGn and MAc-your-own-identity!! And what about Photuris?  Yet another STS variant: Sign K=g xy as “ proof of knowledge ” ; also insecure (see the SIGMA paper)

34. 34 03Crypto - Hugo Krawczyk SIGMA: Basic Version A, SIG A (g y,g x ) B A g y, B, SIG B (g x,g y ) g x * K m and session key derived from g xy 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, MAC Km (B), MAC Km (A)

35. 35 03Crypto - Hugo Krawczyk SIGMA-I : active protection of Initiator’s id g x g y, {B, SIG B (g x,g y ), MAC Km (B) } Ke {A, SIG A (g y,g x ), MAC Km (A) } Ke B A * K e and K m derived from g xy via pseudorandom function Responder (B) identifies first  Initiator’s (A) id protected

36. 36 03Crypto - Hugo Krawczyk SIGMA-R : active protection of Responder’s id B A { B, SIG B (g x,g y ), MAC Km’ (B) } Ke’ gxgx gygy { A, SIG A (g y,g x ), MAC Km (A) } Ke Note: Km, Km’ and Ke, Ke’ (against reflection attack)

37. 37 03Crypto - Hugo Krawczyk IKEv1 Variant: MAC under SIG Equivalent security (just save MAC space): g y, B, SIG B (MAC Km (B, g x,g y )) A, SIG A (MAC Km (A, g y,g x )) gxgx A B  this is IKE’s “aggressive mode” (no id protect’n) Note: MAC(SIG(id,…)) is not secure!! (STS-MAC)

38. 38 03Crypto - Hugo Krawczyk IKE Main Mode B A gxgx gygy { A, SIG A (MAC Km (A, g y,g x )) } Ke { B, SIG B (MAC Km’ (B, g x,g y )) } Ke’ IKE v2: a slight variant – only MAC(id) under SIG

39. 39 03Crypto - Hugo Krawczyk 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

40. 40 03Crypto - Hugo Krawczyk 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, … RCCA [Thu] X Care with variants!!

41. 41 03Crypto - Hugo Krawczyk 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

42. 42 03Crypto - Hugo Krawczyk 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 …

43. 43 03Crypto - Hugo Krawczyk Final Remark A new Proposal: Just Fast Keying (JFK) Available at: http://www.research.att.com/~smb/papers/jfk -ccs.pdf

44. 44 03Crypto - Hugo Krawczyk And one truly last word… ThAnKs