1 / 41

Hugo Krawczyk Technion & IBM Research

The Cryptography of the IPSec and IKE Protocols. Hugo Krawczyk Technion & IBM Research. Outline of the Talk. Short introduction to IPSec (very high level) Some crypto aspects of IPSec Introduction to IKE functionality (IKE = “ Internet Key Exchange ” )

fallon
Télécharger la présentation

Hugo Krawczyk Technion & IBM Research

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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: www.vpn-technology.com

  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 

More Related