diffie hellman
TRANSCRIPT
103Crypto - Hugo Krawczyk
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)
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”
403Crypto - Hugo Krawczyk
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
503Crypto - Hugo Krawczyk
Virtual Private Networks (VPN)
Source: www.vpn-technology.com
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
703Crypto - Hugo Krawczyk
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
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)
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
1203Crypto - Hugo Krawczyk
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)
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
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)
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
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]
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
1803Crypto - Hugo Krawczyk
SIGMA: Basic Requirements
Diffie-Hellman (PFS)
Signature-based authentication
Optional identity protection
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)
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
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
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, gxA B
(there must be a reason we call it BADH)
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
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”
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
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)
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)
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, gxA B
B, gy, {SIGB(gx,gy)}K
{SIGA(gy,gx )}K
A B
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)
gxA B
gy, {B, SIGB(gx,gy)}K
A B
{A, SIGA(gy,gx )}K
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!)
gxA B
gy, B, {SIGB(gx,gy)}K
A B
A, {SIGA(gy,gx )}K
E
E/
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…
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”)
gxA B
gy, B, SIGB(gx,gy), MACK(SIGB)
A B
A, SIGA(gy,gx ), MACK(SIGA)
E
E/
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)
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)
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
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)
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)
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
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
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!!
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
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…
4303Crypto - Hugo Krawczyk
And one truly last word…
ThAnKs