03Crypto - Hugo K

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 K

IPSec: IP Security

[RFC2401-12]

Transport security at the IP

Goal: secure traffic between any two IP systems

(Internet Protocol)

layer

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 K

Network Layers
Applications

Applications

APIs

APIs

TCP/UDP/

TCP/UDP/

IP/IPSEC
Network
Device Drivers
03Crypto - Hugo K

IP Secure Tunnel

IP/IPSEC
Network
Device Drivers
4

Virtual Private Networks (VPN)

03Crypto - Hugo K

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 K

IPSec Encapsulation Mechanisms

IP HDR

IP HDR

ESP
HDR

IP HDR

ESP
HDR

Gateway ESP Encrypd

IP HDR HDR IP HDR
03Crypto - Hugo K

Plain IP
packet

Payload

Encrypted
Payload

Payload
Encrypted
Payload

MAC

Encapsulated
Security
Payload (ESP)

MAC

ESP MAC-only

MAC

ESP-Tunnel
Mode
7

IPSecs Crypto Algorithms

Negotiable

Default (for interoperability and common use)

Encryption:
Integrity:

3DES (moving to AES)

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

[Bellovin96, K01, CK01]

03Crypto - Hugo K

(the right order)

9

IKE: Internet Key Exchange

Creates SAs for use by IPSec

Negotiates

type of key exchange, credentials, crypto algorithms,

crypto strength, traffic to protect, etc

Key

security parameters for the SA

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 K

10

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)

03Crypto - Hugo K

Inbound-Outbound

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

03Crypto - Hugo K

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., authd info, nonces, key derivation)

03Crypto - Hugo K

14

IKEv1

Many cryptographic elements taken from

SKEME [K95] and OAKLEY [Orman98]
Uniform
Key

set of authentication modes

derivation

Authentication
But

based on public-key encryption

SKEME did not provide signature-based authn

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 K

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 [HK99]

Streamlined key derivation spec

Added optional Denial-of-Service defense [Karn]

03Crypto - Hugo K

16

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

to a broad audience of crypto designers

and security engineers

formal analysis presented last year [Canetti-K02]

The
name
SIGMA
relatively recentthe
(used
in
SIGMA
stands
forisSIGn-and-MAc
main
IKEv2 revision toelements
differentiate
fromprotocol
other proposals)
authentication
in the

Design goes back to 1995

03Crypto - Hugo K

17

SIGMA: Basic Requirements

Diffie-Hellman (PFS)

Signature-based authentication

Optional identity protection

03Crypto - Hugo K

18

Identity Protection

Passive vs. active attacker

Best

possible: both ids 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 K

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 K

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 K

21

Basic Authenticated DH (BADH)

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 K

22

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

A, gx

B, gy, SIGB(gx,gy)
SIGA(gy,gx)
Any

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

damage? Wrong identity binding!

A: Shared K=gxy with B (KB)

B: Shared K=gxy with E (KE)

E doesnt know K=gxy but B considers anything sent

by A as coming from E
03Crypto - Hugo K

23

A: Shared K=gxy with B (KB)

B:

Shared K=gxy with E (KE)

B = Bank A,E = customers

B deposits the money in K s account, i.e. Es!

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

E passes command to A

Identity Misbinding Attack: the differential

cryptanalysis of key-exchange protocols

B: {deposit $1000 in my account}K

E: {destroy yourself}K

03Crypto - Hugo K

A destroys itself

24

A Possible Solution (ISO-9796)

A

A, g

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 K

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??

03Crypto - Hugo K

26

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)

03Crypto - Hugo K

27

Another Solution: STS [DVW92]

Idea: each peer proves knowledge of K=gxy

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

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 K

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 K

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 K

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

03Crypto - Hugo K

31

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

33

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

own03Crypto - Hugoauthentication
Great for 34id protection
K
.

SIGMA-I:active protection of Initiators id

A

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 K

Initiators (A) id35protected

SIGMA-R:active protection of Responders id

A

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 K

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 K

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 K

38

SIGMA Summary

SIGMA suitable for most applications requiring

a Diffie-Hellman key exchange:
Simple

No over-design (nor under-design)

With

and efficient (minimizes msgs and computn)

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 K

39

But is SIGMA Secure?!

Secure! (rigorous analysis): Canetti-K Crypto02

Care with
proof: each element is essential
!!variants
e.g., SIG(MAC(id,)) vs. (SIG(id,), MAC(SIG(id,)))

Formal

Guarantees
Secure

secure channels

composition with arbitrary applications (UC)

From theory to practice

Specification, implementation, DETAILS

fledge appendix in paper -- web version)

DoS defenses: selective (IKEv2), integral (JFK-R)

(see full

RCCA [Thu]
ID Protn: Encryption secure against active attackers (CCA)

Certificates,

03Crypto - Hugo K

40

If we only had more time

Many aspects of IKEs 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 K

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 K

42

And one truly last word

ThAnKs

03Crypto - Hugo K

43