03Crypto - Hugo Krawczyk 1

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)

03Crypto - Hugo Krawczyk 2

 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”
03Crypto - Hugo Krawczyk 3
 Network Layers
Applications Applications

API’s API’s

TCP/UDP/… TCP/UDP/…

IP/IPSEC IP Secure Tunnel IP/IPSEC

Network Network
Device Drivers Device Drivers

03Crypto - Hugo Krawczyk 4

 Virtual Private Networks (VPN)

03Crypto - Hugo Krawczyk 5

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

03Crypto - Hugo Krawczyk 6

 IPSec Encapsulation Mechanisms
Plain IP
IP HDR Payload
packet

Encapsulated
ESP Encrypted
IP HDR HDR MAC Security
Payload
Payload (ESP)

ESP
IP HDR HDR
Payload MAC ESP MAC-only

Gateway ESP Encryp’d Encrypted ESP-Tunnel

MAC Mode
IP HDR HDR IP HDR Payload
03Crypto - Hugo Krawczyk 7
 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 length (from IP Hdr)

 the prepend key story: MACK(M)=MD5(K | M)

 encrypt-then-authenticate (the “right order”)
[Bellovin’96, K’01, CK’01]
03Crypto - Hugo Krawczyk 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

03Crypto - Hugo Krawczyk 10

 The IKE-IPSec API
IKE
Signaling
KEY EXCHANGE
Session Mgmt

SPI ADDR ALG KEY …

Application . . . . .
. . . . .
Kernel (OS) . . . . .
SA Database (SAD)
IPSec
in/out Packet handling
CRYPTO PROCESSING (ENC,MAC)
Inbound-Outbound
03Crypto - Hugo Krawczyk 12
 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

03Crypto - Hugo Krawczyk 13

 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)

03Crypto - Hugo Krawczyk 14

 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
03Crypto - Hugo Krawczyk 15
 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]
03Crypto - Hugo Krawczyk 16
 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]
 The name
SIGMA SIGMA
stands foris“SIGn-and-MAc”
relatively recentthe main
(used in
. IKEv2 revision toelements
authentication differentiate fromprotocol
in the other proposals)
 Design goes back to 1995

03Crypto - Hugo Krawczyk 17

 SIGMA: Basic Requirements

 Diffie-Hellman (PFS)
 Signature-based authentication
 Optional identity protection

03Crypto - Hugo Krawczyk 18

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

03Crypto - Hugo Krawczyk 20

 Diffie-Hellman Exchange [DH’76]

A B
A, gx

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

03Crypto - Hugo Krawczyk 21

 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)

03Crypto - Hugo Krawczyk 22
 Identity-Misbinding Attack*[DVW’92]
(a.k.a. Unknown Key-Share attack)

A A, gx E E, gx B

B, gy, SIGB(gx,gy) B, gy, SIGB(gx,gy)

SIGA(gy,gx) SIGE(gy,gx)

 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
03Crypto - Hugo Krawczyk 23
 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”

03Crypto - Hugo Krawczyk 24

 A Possible Solution (ISO-9796)
A B
A, gx

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

03Crypto - Hugo Krawczyk 25

 The ISO defense

A A, gx E E, gx B

B, gy, SIGB(gx,gy,E) 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)
 The ISO protocol thus avoids the misbinding
attack; but is it secure??

03Crypto - Hugo Krawczyk 26

 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)

03Crypto - Hugo Krawczyk 27

 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
A A, gx B

B, gy, {SIGB(gx,gy)}K

{SIGA(gy,gx )}K
03Crypto - Hugo Krawczyk 28
 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)

A gx B

gy, {B, SIGB(gx,gy)}K

{A, SIGA(gy,gx )}K

03Crypto - Hugo Krawczyk 29

 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!)

A E gx B

gy, B, {SIGB(gx,gy)}K

E
A,
/ {SIGA(gy,gx )}K

03Crypto - Hugo Krawczyk 30

 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…

03Crypto - Hugo Krawczyk 31

STS with MAC (instead of encryption) [DVW]

A E gx B

gy, B, SIGB(gx,gy), MACK(SIGB)

E
A,
/ SIGA(gy,gx ), MACK(SIGA)

 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”)
03Crypto - Hugo Krawczyk 32
 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
 SIGn 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)

03Crypto - Hugo Krawczyk 33

 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
03Crypto - Hugo Krawczyk
 Great for id protection 34
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
 Initiator’s (A) id protected
03Crypto - Hugo Krawczyk 35
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)

03Crypto - Hugo Krawczyk 36
 IKEv1 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)
03Crypto - Hugo Krawczyk 37
 IKE Main Mode

A gx B

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

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

03Crypto - Hugo Krawczyk 39

 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) RCCA [Thu]
 X
ID Prot’n: Encryption secure against active attackers (CCA)
 Certificates, …
03Crypto - Hugo Krawczyk 40
 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

03Crypto - Hugo Krawczyk 41

 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…

03Crypto - Hugo Krawczyk 42

 And one truly last word…

ThAnKs

03Crypto - Hugo Krawczyk 43