Transcript Example:the Diffie-Hellman Key Exchange

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

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 Krawczyk
3
Network Layers
Applications
Applications
API’s
API’s
TCP/UDP/…
TCP/UDP/…
IP/IPSEC
Network
Device Drivers
03Crypto - Hugo Krawczyk
IP Secure Tunnel
IP/IPSEC
Network
Device Drivers
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
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 HDR IP HDR
03Crypto - Hugo Krawczyk
Encrypted
Payload
7
IPSec’s 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
[Bellovin’96, K’01, CK’01]
03Crypto - Hugo Krawczyk
(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 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
 Key
set of authentication modes
derivation
 Authentication
 But

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
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
relatively recentthe
(used
in
SIGMA
stands
foris“SIGn-and-MAc”
main
IKEv2 revision toelements
differentiate
fromprotocol
other proposals)
authentication
in the

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
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
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
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
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 deposits the money in “K” ’s account, i.e. E’s!

B=Central Command A=F-16 E= small unmanned plane

B

E passes command to A

B: {“deposit $1000 in my account”}K
E: {“destroy yourself”}K
A destroys itself
Identity Misbinding Attack: the “differential
cryptanalysis of key-exchange protocols”
03Crypto - Hugo Krawczyk
24
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
03Crypto - Hugo Krawczyk
25
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)

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
 Can
id not needed for your own authentication
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)
gx
A E
[DVW]
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
 Great for id protection
03Crypto - Hugo Krawczyk
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
03Crypto - Hugo Krawczyk
 Initiator’s (A) id protected
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

No over-design (nor under-design)
 With


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
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

secure channels
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 Prot’n: Encryption secure against active attackers (CCA)
X
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