03Crypto - Hugo Krawczyk

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

03Crypto - Hugo Krawczyk

IPSec: IP Security

[RFC2401-12]
(Internet Protocol)

Transport security at the IP

Any

layer

Goal: secure traffic between any two IP systems

device with an IP address: hosts, gateways, mobile devices, IP-enabled microwaves, and authentication

Security services for IP packets

encryption

SA (Security Association) creation & management Application independent: security for the Internet infrastructure
03Crypto - Hugo Krawczyk 3

Network Layers
Applications
APIs TCP/UDP/ IP/IPSEC Network Device Drivers IP Secure Tunnel

Applications
APIs TCP/UDP/ IP/IPSEC Network Device Drivers

03Crypto - Hugo Krawczyk

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
6

03Crypto - Hugo Krawczyk

IPSec Encapsulation Mechanisms

IP HDR Payload Plain IP packet Encapsulated Security Payload (ESP) ESP MAC-only ESP-Tunnel Mode
7

IP HDR

ESP HDR

Encrypted Payload

MAC

IP HDR

ESP HDR

Payload

MAC

Gateway ESP Encrypd IP HDR HDR IP HDR

03Crypto - Hugo Krawczyk

Encrypted Payload

MAC

IPSecs Crypto Algorithms

Negotiable Default (for interoperability and common use)

Encryption:

3DES (moving to AES)

Integrity:

HMAC (SHA1, MD5)

length (from IP Hdr)

Some crypto highlights:

HMAC

developed for use in IPSec

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

encrypt-then-authenticate

[Bellovin96, K01, CK01]

(the right order)

9

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 (1998): ISAKMP for mgmt, IKE for KE (2003): IKE specifies it all

Manages SAs: create, refresh, maintain, delete

IKEv1 IKEv2

03Crypto - Hugo Krawczyk

10

The IKE-IPSec API

IKE Signaling KEY EXCHANGE

Session Mgmt
SPI Application Kernel (OS) ADDR ALG KEY

. . .
IPSec

. . .

. . .

. . .

. . .

SA Database (SAD) 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 Perfect

key exchange: public and symmetric keys

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. certs) vs. IP/physical addresses
13

03Crypto - Hugo Krawczyk

IKEv1 [RFC2409]

Several authenticated DH protocols supported. Differ in mode of authentication:

Long-term Public-key Digital Re-key

pre-shared (symmetric) key encryption

Signature (with optional DH)

With and without identity protection Modes designed to share as many elements as possible (e.g., authd info, nonces, key derivation)
14

03Crypto - Hugo Krawczyk

IKEv1

Many cryptographic elements taken from SKEME [K95] and OAKLEY [Orman98]
Uniform Key But

set of authentication modes based on public-key encryption

derivation SKEME did not provide signature-based authn

Authentication

Signature mode specifically developed for IKE (the SIGMA protocol)

Replacement

for Photuris signature-based DH which used an (insecure) variant of the STS protocol
15

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 signature mode: kept SIGMA design setting [HK99]

Single

Added password-based authentication

Asymmetric

Streamlined key derivation spec Added optional Denial-of-Service defense [Karn]

16

03Crypto - Hugo Krawczyk

SIGMA: IKEs 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 A

to a broad audience of crypto designers and security engineers formal analysis presented last year [Canetti-K02]

The name SIGMA is relatively recent (used in SIGMA stands for SIGn-and-MAc the main IKEv2 revision to differentiate from other proposals) authentication elements in the protocol

Design goes back to 1995

17

03Crypto - Hugo Krawczyk

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 ids protected against passive attacks but only one against active attacks
identity should get active defense?

Whose

Initiator:

roaming user (e.g. hide location)

avoid probing attacks (who are you?)

Responder:

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

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

03Crypto - Hugo Krawczyk

20

Diffie-Hellman Exchange [DH76]

A
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, gy, SIGB(gx,gy)

SIGA(gy,gx)
Each party signs its own DH value to prevent m-i-t-m attack (and

the peers DH value as a freshness guarantee against replay )

A: Shared K=gxy with B (KB) B: Shared K=gxy with A (KA)

Looks fine, but (there must be a reason we call it BADH)

03Crypto - Hugo Krawczyk 22

Identity-Misbinding Attack*[DVW92]
(a.k.a. Unknown Key-Share attack)

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

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

SIGA(gy,gx)
Any
A: Shared K=gxy with B (KB)

SIGE(gy,gx)
B: Shared K=gxy with E (KE)

damage? Wrong identity binding!

E doesnt know K=gxy but B considers anything sent by A as coming from E

03Crypto - Hugo Krawczyk 23

A: Shared K=gxy with B (KB)

B: Shared K=gxy with E (KE)

B = Bank A,E = customers

A B: {deposit $1000 in my account}K B deposits the money in K s account, i.e. Es!

B=Central Command A=F-16 E= small unmanned plane

B E: {destroy yourself}K A destroys itself E passes command to A

Identity Misbinding Attack: the differential cryptanalysis of key-exchange protocols

03Crypto - Hugo Krawczyk 24

A Possible Solution (ISO-9796)

A
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 B, gy, SIGB(gx,gy,E)

E, gx 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??
26

03Crypto - Hugo Krawczyk

The ISO Protocol is

Secure [CK01] Unsuited for identity protection

B needs to know As 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 peers identity) Letting each party sign its own identity rather than the peers solves the privacy issues but makes the protocol insecure (the identity-misbinding attack again)
27

03Crypto - Hugo Krawczyk

Another Solution: STS [DVW92]

Idea: each peer proves knowledge of K=gxy

(prevents the Id-M attack since in BADH E doesnt know gxy)

As a Proof of Knowledge the STS protocol uses encryption under K=gxy

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

03Crypto - Hugo Krawczyk

28

STS Pros and Cons

Pro: STS can protect identities
Peers Can

id not needed for your own authentication

extend encryption to cover identities (or certs)

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

03Crypto - Hugo Krawczyk

29

STS Pros and Cons

Con: encryption is not the right function to
prove knowledge of a key
E.g.:
.

if Eve can register As public-key under her name she can mount the I-M attack (w/o even knowing gxy!)

A E

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

03Crypto - Hugo Krawczyk

30

Identity-Misbinding on STS

Assumes Eve registers As 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 certs 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
31

03Crypto - Hugo Krawczyk

STS with MAC

A E

(instead of encryption) gx

[DVW]

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

03Crypto - Hugo Krawczyk

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

03Crypto - Hugo Krawczyk

SIGMA: Basic Version

A
gx 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 peers id for own authentication Great for id protection 03Crypto - Hugo Krawczyk

34

SIGMA-I:active protection of Initiators id

gx

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

03Crypto - Hugo Krawczyk

Initiators (A) id protected

35

SIGMA-R:active protection of Responders id

gx
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):

gx

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

A, SIGA (MACKm (A, gy,gx))

this is IKEs aggressive mode (no id protectn)

Note: MAC(SIG(id,)) is not secure!! (STS-MAC)
03Crypto - Hugo Krawczyk 37

IKE Main Mode

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

SIGMA Summary

SIGMA suitable for most applications requiring a Diffie-Hellman key exchange:

Simple

and efficient (minimizes msgs and computn)

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
39

03Crypto - Hugo Krawczyk

But is SIGMA Secure?!

Secure! (rigorous analysis): Canetti-K Crypto02

Formal

proof: each element is essential secure channels

e.g., SIG(MAC(id,)) vs. (SIG(id,), MAC(SIG(id,)))

Guarantees 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] ID Protn: Encryption secure against active attackers (CCA) X Certificates,
40

03Crypto - Hugo Krawczyk

If we only had more time

Many aspects of IKEs crypto not covered

Pre-shared
Key

key authentication
protocol IKEv2 (asym. model [HK99])

Password-based

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
41

03Crypto - Hugo Krawczyk

Final Remark

The KE area has matured to the point in which there is no reason to use unproven protocols
Addressing Proofs It

practicality does not require (or justify) giving up on rigorous analysis not an absolute guarantee (relative to the security model), but the best available assurance 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