2. 203Crypto - 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)
3. 303Crypto - Hugo Krawczyk
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”
6. 603Crypto - Hugo Krawczyk
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
7. 703Crypto - Hugo Krawczyk
IPSec Encapsulation Mechanisms
IP HDR Payload
Plain IP
packet
IP HDR
Encrypted
Payload
ESP
HDR MAC
Encapsulated
Security
Payload (ESP)
ESP-Tunnel
ModeMAC
Encrypted
Payload
Encryp’d
IP HDR
Gateway
IP HDR
ESP
HDR
IP HDR Payload
ESP
HDR MAC ESP MAC-only
8. 903Crypto - Hugo Krawczyk
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)
9. 1003Crypto - 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
Manages SAs: create, refresh, maintain, delete
IKEv1 (1998): ISAKMP for mgmt, IKE for KE
IKEv2 (2003): IKE specifies it all
10. 1203Crypto - Hugo Krawczyk
The IKE-IPSec API
IKE
Signaling
KEY EXCHANGE
Session Mgmt
IPSec
Packet handling
CRYPTO PROCESSING (ENC,MAC)
Inbound-Outbound
Application
in/out
Kernel (OS)
READ
W
RITE
SPI ADDR ALG KEY …
. . . . .
. . . . .
. . . . .
SA Database (SAD(
11. 1303Crypto - Hugo Krawczyk
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
12. 1403Crypto - Hugo Krawczyk
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)
13. 1503Crypto - Hugo Krawczyk
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
14. 1603Crypto - 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
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]
15. 1703Crypto - Hugo Krawczyk
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
17. 1903Crypto - Hugo Krawczyk
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)
18. 2003Crypto - 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
19. 2103Crypto - Hugo Krawczyk
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
20. 2203Crypto - Hugo Krawczyk
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, gx
A B
(there must be a reason we call it BADH)
21. 2303Crypto - Hugo Krawczyk
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
22. 2403Crypto - Hugo Krawczyk
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”
23. 2503Crypto - Hugo Krawczyk
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
24. 2603Crypto - Hugo Krawczyk
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)
25. 2703Crypto - Hugo Krawczyk
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)
26. 2803Crypto - Hugo Krawczyk
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, gx
A B
B, gy
, {SIGB(gx
,gy
)}K
{SIGA(gy
,gx
)}K
A B
27. 2903Crypto - Hugo Krawczyk
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)
gx
A B
gy
, {B, SIGB(gx
,gy
)}K
A B
{A, SIGA(gy
,gx
)}K
28. 3003Crypto - Hugo Krawczyk
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
!)
gx
A B
gy
, B, {SIGB(gx
,gy
)}K
A B
A, {SIGA(gy
,gx
)}K
E
E
/
29. 3103Crypto - Hugo Krawczyk
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…
30. 3203Crypto - Hugo Krawczyk
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”)
gx
A B
gy
, B, SIGB(gx
,gy
), MACK(SIGB)
A B
A, SIGA(gy
,gx
), MACK(SIGA)
E
E
/
31. 3303Crypto - 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)
32. 3403Crypto - Hugo Krawczyk
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)
33. 3503Crypto - Hugo Krawczyk
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
34. 3603Crypto - Hugo Krawczyk
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)
35. 3703Crypto - Hugo Krawczyk
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)
36. 3803Crypto - Hugo Krawczyk
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
37. 3903Crypto - Hugo Krawczyk
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
38. 4003Crypto - Hugo Krawczyk
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!!
39. 4103Crypto - Hugo Krawczyk
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
40. 4203Crypto - Hugo Krawczyk
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…