03Crypto - 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)
2
03Crypto - Hugo Krawczyk
IPSec: IP Security
[RFC2401-12]
(Internet Protocol)
Transport security at the IP
Any
layer
Goal: secure traffic between any two IP systems
device with an IP address: hosts, gateways, mobile devices, IP-enabled microwaves, and authentication
Security services for IP packets
encryption
SA (Security Association) creation & management Application independent: security for the Internet infrastructure
03Crypto - Hugo Krawczyk 3
Network Layers
Applications
APIs TCP/UDP/ IP/IPSEC Network Device Drivers IP Secure Tunnel
Applications
APIs TCP/UDP/ IP/IPSEC Network Device Drivers
03Crypto - Hugo Krawczyk
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
6
03Crypto - Hugo Krawczyk
IPSec Encapsulation Mechanisms
IP HDR Payload Plain IP packet Encapsulated Security Payload (ESP) ESP MAC-only ESP-Tunnel Mode
7
IP HDR
ESP HDR
Encrypted Payload
MAC
IP HDR
ESP HDR
Payload
MAC
Gateway ESP Encrypd IP HDR HDR IP HDR
03Crypto - Hugo Krawczyk
Encrypted Payload
MAC
IPSecs Crypto Algorithms
Negotiable Default (for interoperability and common use)
Encryption:
3DES (moving to AES)
Integrity:
HMAC (SHA1, MD5)
length (from IP Hdr)
Some crypto highlights:
HMAC
developed for use in IPSec
the prepend key story: MACK(M)=MD5(K | M)
encrypt-then-authenticate
[Bellovin96, K01, CK01]
(the right order)
9
03Crypto - 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 (1998): ISAKMP for mgmt, IKE for KE (2003): IKE specifies it all
Manages SAs: create, refresh, maintain, delete
IKEv1 IKEv2
03Crypto - Hugo Krawczyk
10
The IKE-IPSec API
IKE Signaling KEY EXCHANGE
Session Mgmt
SPI Application Kernel (OS) ADDR ALG KEY
. . .
IPSec
. . .
. . .
. . .
. . .
SA Database (SAD) 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 Perfect
key exchange: public and symmetric keys
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
13
03Crypto - Hugo Krawczyk
IKEv1 [RFC2409]
Several authenticated DH protocols supported. Differ in mode of authentication:
Long-term Public-key Digital Re-key
pre-shared (symmetric) key encryption
Signature (with optional DH)
With and without identity protection Modes designed to share as many elements as possible (e.g., authd info, nonces, key derivation)
14
03Crypto - Hugo Krawczyk
IKEv1
Many cryptographic elements taken from SKEME [K95] and OAKLEY [Orman98]
Uniform Key But
set of authentication modes based on public-key encryption
derivation SKEME did not provide signature-based authn
Authentication
Signature mode specifically developed for IKE (the SIGMA protocol)
Replacement
for Photuris signature-based DH which used an (insecure) variant of the STS protocol
15
03Crypto - 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 signature mode: kept SIGMA design setting [HK99]
Single
Added password-based authentication
Asymmetric
Streamlined key derivation spec Added optional Denial-of-Service defense [Karn]
16
03Crypto - Hugo Krawczyk
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 A
to a broad audience of crypto designers and security engineers formal analysis presented last year [Canetti-K02]
The name SIGMA is relatively recent (used in SIGMA stands for SIGn-and-MAc the main IKEv2 revision to differentiate from other proposals) authentication elements in the protocol
Design goes back to 1995
17
03Crypto - Hugo Krawczyk
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 ids protected against passive attacks but only one against active attacks
identity should get active defense?
Whose
Initiator:
roaming user (e.g. hide location)
avoid probing attacks (who are you?)
Responder:
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)
19
03Crypto - 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
03Crypto - Hugo Krawczyk
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 Krawczyk 21
Basic Authenticated DH (BADH)
A
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 Krawczyk 22
Identity-Misbinding Attack*[DVW92]
(a.k.a. Unknown Key-Share attack)
A, gx B, gy, SIGB(gx,gy)
E, gx B, gy, SIGB(gx,gy)
SIGA(gy,gx)
Any
A: Shared K=gxy with B (KB)
SIGE(gy,gx)
B: Shared K=gxy with E (KE)
damage? Wrong identity binding!
E doesnt know K=gxy but B considers anything sent by A as coming from E
03Crypto - Hugo Krawczyk 23
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. Es!
B=Central Command A=F-16 E= small unmanned plane
B E: {destroy yourself}K A destroys itself E passes command to A
Identity Misbinding Attack: the differential cryptanalysis of key-exchange protocols
03Crypto - Hugo Krawczyk 24
A Possible Solution (ISO-9796)
A
A, gx
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, 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??
26
03Crypto - Hugo Krawczyk
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)
27
03Crypto - Hugo Krawczyk
Another Solution: STS [DVW92]
Idea: each peer proves knowledge of K=gxy
(prevents the Id-M attack since in BADH E doesnt know gxy)
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 Krawczyk
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 Krawczyk
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 Krawczyk
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
31
03Crypto - Hugo Krawczyk
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)
32
03Crypto - 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)
33
03Crypto - Hugo Krawczyk
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 own authentication Great for id protection 03Crypto - Hugo Krawczyk
34
SIGMA-I:active protection of Initiators id
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 Krawczyk
Initiators (A) id protected
35
SIGMA-R:active protection of Responders id
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 Krawczyk 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 Krawczyk 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 Krawczyk 38
SIGMA Summary
SIGMA suitable for most applications requiring a Diffie-Hellman key exchange:
Simple
and efficient (minimizes msgs and computn)
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
39
03Crypto - Hugo Krawczyk
But is SIGMA Secure?!
Secure! (rigorous analysis): Canetti-K Crypto02
Formal
proof: each element is essential secure channels
e.g., SIG(MAC(id,)) vs. (SIG(id,), MAC(SIG(id,)))
Guarantees 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) RCCA [Thu] ID Protn: Encryption secure against active attackers (CCA) X Certificates,
40
03Crypto - Hugo Krawczyk
If we only had more time
Many aspects of IKEs crypto not covered
Pre-shared
Key
key authentication
protocol IKEv2 (asym. model [HK99])
Password-based
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
41
03Crypto - Hugo Krawczyk
Final Remark
The KE area has matured to the point in which there is no reason to use unproven protocols
Addressing Proofs It
practicality does not require (or justify) giving up on rigorous analysis not an absolute guarantee (relative to the security model), but the best available assurance 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
