03 Crypto Hugo Krawczyk Outline of the Talk

03 Crypto - Hugo Krawczyk

Outline of the Talk n Short introduction to IPSec (very high level) n Some crypto aspects of IPSec n Introduction to IKE functionality (IKE = “Internet Key Exchange”) n The cryptography of IKE n Rationale and development of SIGMA ¨ the cryptographic core of the main authenticated Diffie-Hellman exchange of IKE (v 1 and v 2) 03 Crypto - Hugo Krawczyk

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

Network Layers Applications API’s TCP/UDP/… IP/IPSEC Network Device Drivers 03 Crypto - Hugo Krawczyk IP Secure Tunnel IP/IPSEC Network Device Drivers

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

IPSec Processing Basics n n 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 n n 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 03 Crypto - Hugo Krawczyk

IPSec Encapsulation Mechanisms Payload Plain IP packet IP HDR ESP HDR Encrypted Payload MAC Encapsulated Security Payload (ESP) IP HDR ESP HDR Payload MAC ESP MAC-only MAC ESP-Tunnel Mode IP HDR Gateway ESP Encryp’d IP HDR 03 Crypto - Hugo Krawczyk Encrypted Payload

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

IKE: Internet Key Exchange n Creates SAs for use by IPSec ¨ Negotiates n type of key exchange, credentials, crypto algorithms, crypto strength, traffic to protect, etc ¨ Key n security parameters for the SA Exchange: share keys between parties Manages SAs: create, refresh, maintain, delete ¨ IKEv 1 (1998): ISAKMP for mgmt, IKE for KE ¨ IKEv 2 (2003): IKE specifies it all 03 Crypto - Hugo Krawczyk

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

The Cryptography of IKE n n 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 n Diffie-Hellman (optional for fast re-key functionality) ¨ Identity protection: hiding parties identities from passive and/or active attackers n Logical identities (e. g. cert’s) vs. IP/physical addresses 03 Crypto - Hugo Krawczyk

IKEv 1 [RFC 2409] n n n 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) 03 Crypto - Hugo Krawczyk

IKEv 1 n Many cryptographic elements taken from SKEME [K’ 95] and OAKLEY [Orman’ 98] ¨ Uniform ¨ Key set of authentication modes derivation ¨ Authentication ¨ But n based on public-key encryption 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 03 Crypto - Hugo Krawczyk

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

SIGMA: IKE’s Signature Mode n n (v 1&v 2) 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 n. formal analysis presented last year [Canetti-K’ 02] The name SIGMA relatively recentthe (used in SIGMA stands foris“SIGn-and-MAc” main IKEv 2 revision toelements differentiate fromprotocol other proposals) authentication in the o Design goes back to 1995 03 Crypto - Hugo Krawczyk

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

Identity Protection n 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: n 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) 03 Crypto - Hugo Krawczyk

How did we get to SIGMA? n n 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 03 Crypto - Hugo Krawczyk

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

Basic Authenticated DH (BADH( A A, gx B B, gy, SIGB(gx, gy) SIGA(gy, gx) 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) 03 Crypto - Hugo Krawczyk

Identity-Misbinding Attack*[DVW’ 92] (a. k. a. Unknown Key-Share attack) A A, gx E B, gy, SIGB(gx, gy) SIGA(gy, gx) ¨ Any E, gx B B, gy, SIGB(gx, gy) SIGE(gy, gx) 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 03 Crypto - Hugo Krawczyk

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

A Possible Solution (ISO-9796( A A, gx 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 03 Crypto - Hugo Krawczyk

The ISO defense A A, gx B, gy, SIGB(gx, gy, E) E E, gx B B, gy, SIGB(gx, gy, E) A: aha! B is talking to E not to me! Note that E cannot produce SIGB(gx, gy, A) n The ISO protocol thus avoids the misbinding attack; but is it secure? ? 03 Crypto - 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) 03 Crypto - Hugo Krawczyk

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

STS Pro’s and Con’s Pro: STS can protect identities ¨ Peer’s ¨ Can id not needed for your own authentication extend encryption to cover identities (or cert’s) A gx gy, {B, SIGB(gx, gy)}K {A, SIGA(gy, gx )}K 03 Crypto - Hugo Krawczyk B

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!) AE gx gy, B, {SIGB(gx, gy)}K E A, / {SIGA(gy, gx )}K 03 Crypto - Hugo Krawczyk B .

Identity-Misbinding on STS n Assumes Eve registers A’s PK as her own PK ¨ Many certification settings check for identity of registrant but not for “possession” (Po. P) of private key (in particular, in common IPSec settings) n n 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… 03 Crypto - Hugo Krawczyk

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

What is going on? n n 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 n Which brings us to the SIGMA design ¨ SIGn n and 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) 03 Crypto - Hugo Krawczyk

SIGMA: Basic Version A gx 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 03 Crypto - Hugo Krawczyk

SIGMA-I: active protection of Initiator’s id A gx 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 03 Crypto - Hugo Krawczyk Initiator’s (A) id protected

SIGMA-R: active protection of Responder’s id A gx B gy { A, SIGA (gy, gx), MACKm (A) }Ke { B, SIGB (gx, gy), MACKm’(B) }Ke’ Note: Km, Km’ and Ke, Ke’ (against reflection attack) 03 Crypto - Hugo Krawczyk

IKEv 1 Variant: MAC under SIG Equivalent security (just save MAC space): A gx B gy, B, SIGB (MACKm (B, gx, gy)) 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) 03 Crypto - Hugo Krawczyk

IKE Main Mode A gx B gy { A, SIGA (MACKm (A, gy, gx)) }Ke { B, SIGB (MACKm’ (B, gx, gy)) }Ke’ IKE v 2: a slight variant – only MAC(id) under SIG 03 Crypto - Hugo Krawczyk

SIGMA Summary n SIGMA suitable for most applications requiring a Diffie-Hellman key exchange: ¨ Simple n No over-design (nor under-design) ¨ With n n and efficient (minimizes msgs and comput’n) 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 IKEv 1 and IKEv 2 n Recently proposed for smart-card authentication to ESIGN 03 Crypto - Hugo Krawczyk

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

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

Final Remark n 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… 03 Crypto - Hugo Krawczyk

And one truly last word… Th. An. Ks 03 Crypto - Hugo Krawczyk