Diffie hellman

103Crypto - 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)


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”


Network Layers

Applications

TCP/UDP/…

IP/IPSEC

Network Device Drivers

TCP/UDP/…

API’s

TCP/UDP/…

IP/IPSEC

API’s

TCP/UDP/…

Applications

IP Secure Tunnel

Network Device Drivers


Virtual Private Networks (VPN)

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


IPSec Encapsulation Mechanisms

IP HDR Payload Plain IP packet

IP HDR Encrypted Payload

ESPHDR MAC

Encapsulated Security Payload (ESP)

ESP-Tunnel ModeMAC

Encrypted Payload

Encryp’d IP HDR

Gateway IP HDR

ESPHDR

IP HDR PayloadESPHDR MAC ESP MAC-only


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]

length (from IP Hdr)


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


The IKE-IPSec APIIKE

Signaling

KEY EXCHANGE

Session Mgmt

IPSec

Packet handling

CRYPTO PROCESSING (ENC,MAC)

Inbound-Outbound

Application

in/out

Kernel (OS)

READ

WRITE SPI ADDR ALG KEY …

. . . . . . . . . . . . . . .

SA Database (SAD)


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


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)


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


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]


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


SIGMA: Basic Requirements

Diffie-Hellman (PFS)

Signature-based authentication

Optional identity protection


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)


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


Diffie-Hellman Exchange [DH’76]

A B

• both parties compute the secret key K=gxy

• assumes authenticated channels (DDH assumption)

• open to m-i-t-m in a realistic unauthenticated setting

B, gy

A, gx


Basic Authenticated DH (BADH)

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” (KB) B: “Shared K=gxy with A” (KA)

Looks fine, but…

B, gy, SIGB(gx,gy)

SIGA(gy,gx)

A, gxA B

(there must be a reason we call it BADH)


Identity-Misbinding Attack*[DVW’92] (a.k.a. Unknown Key-

Share attack)

Any damage? Wrong identity binding!

A: “Shared K=gxy with B” (KB) B: “Shared K=gxy with E” (KE)

E doesn’t know K=gxy but B considers anything sent by A as coming from E

B, gy, SIGB(gx,gy)

A, gx

E, gx

B, gy, SIGB(gx,gy)

SIGA(gy,gx)

SIGE(gy,gx)

A BE


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. 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”


A Possible Solution (ISO-9796)

A, gx

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

SIGA(gy,gx,B)

B

Thwarts the identity-misbinding attack by including the identity of the peer under the signature

A


The ISO defense

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

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

A, gx

E, gxA BE

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


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)


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

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

{SIGA(gy,gx )}K

A, gxA B

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

{SIGA(gy,gx )}K

A B


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)

gxA B

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

A B

{A, SIGA(gy,gx )}K


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

gxA B

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

A B

A, {SIGA(gy,gx )}K

E

E/


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…


STS with MAC (instead of encryption) [DVW]

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

gxA B

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

A B

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

E

E/


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)


SIGMA: Basic Version

A, SIGA(gy,gx)

BA

gy, B, SIGB (gx,gy)

gx

*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

, MACKm(B)

, MACKm(A)


SIGMA-I:active protection of Initiator’s id

gx

gy, {B, SIGB (gx,gy), MACKm(B) }Ke

{A, SIGA(gy,gx), MACKm (A) }Ke

BA

*Ke and Km derived from gxy via pseudorandom function

Responder (B) identifies first

Initiator’s (A) id protected


SIGMA-R:active protection of Responder’s id

BA

{ B, SIGB (gx,gy), MACKm’(B) }Ke’

gx

gy

{ A, SIGA (gy,gx), MACKm (A) }Ke

Note: Km, Km’ and Ke, Ke’ (against reflection attack)


IKEv1 Variant: MAC under SIG

Equivalent security (just save MAC space):

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

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

gxA B

this is IKE’s “aggressive mode” (no id protect’n)

Note: MAC(SIG(id,…)) is not secure!! (STS-MAC)


IKE Main Mode

BA 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


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


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, …

RCCA [Thu]

X

Care with variants!!


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


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…


And one truly last word…

ThAnKs

Diffie hellman

Education

crypto hugo krawczyk

crypto hugo krawczyk

crypto highlights

crypto strength

internet key exchange

ip traffic

ip devices

key story