Diffie hellman

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)

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

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

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” (KB) B: “Shared K=gxy
with A” (KA)
Looks fine, but…
B, gy
, SIGB(gx
,gy
)
SIGA(gy
,gx
)
A, gx
A 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” (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
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” (KB) B:
“Shared K=gxy
with E” (KE)
 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, gx
A 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)
gx
A 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
!)
gx
A 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”)
gx
A 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

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Diffie hellman

Editor's Notes