Example:the Diffie-Hellman Key Exchange

1

The Cryptography of the IPSec and IKE Protocols
Hugo Krawczyk Technion IBM Research
2
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
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

4
Network Layers
5
Virtual Private Networks (VPN)
Source www.vpn-technology.com
6
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
IPSec Encapsulation Mechanisms
Plain IP packet
8
ESP Format RFC 2403
IP Header
SPI
Replay Prevention Sequence Number
Initial Vector
MAC
Payload
Encrypted (padded) Payload
Padding
Protocol
Pad Length
MAC Value
9
IPSecs 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)
  Bellovin96, K01, CK01

10
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

11
IKE Internet Key Exchange

• When A wants to talk to B under protection of
  IPSec, and they do not have an established SA
• A invokes IKE to signal B its request for an SA
• IKE is run between A and B result is a shared SA
  (services to be applied and fresh shared keys)
• Negotiated parameters stored locally at A and B
  (SAD)
• SPI (sec. parameters index) pointer to SA
  included in the IPSec header of each packet
• Architectural separation IKE writes to SAD,
  IPSec reads from SAD (full picture more involved
  e.g.SPD)

12
The IKE-IPSec API
IKE Signaling KEY EXCHANGE Session Mgmt
Application
Kernel (OS)
IPSec Packet handling CRYPTO PROCESSING
(ENC,MAC) Inbound-Outbound
in/out
13
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. certs) vs. IP/physical
  addresses

14
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., authd info, nonces, key
  derivation)

15
IKEv1

• Many cryptographic elements taken from SKEME
  K95 and OAKLEY Orman98
• Uniform set of authentication modes
• Key derivation
• Authentication based on public-key encryption
• But SKEME did not provide signature-based authn
• Signature mode specifically developed for IKE
  (the SIGMA protocol)
• Replacement for Photuris signature-based DH
  which used an (insecure) variant of the STS
  protocol

16
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 HK99
• Streamlined key derivation spec
• Added optional Denial-of-Service defense Karn

17
SIGMA IKEs Signature Mode (v1v2)

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

18
SIGMA Basic Requirements

• Diffie-Hellman (PFS)
• Signature-based authentication
• Optional identity protection

19
Identity Protection

• Passive vs. active attacker
  
• Best possible both ids 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)

20
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

21
Diffie-Hellman Exchange DH76

• A
  B

• both parties compute the secret key Kgxy
• assumes authenticated channels (DDH assumption)
• open to m-i-t-m in a realistic unauthenticated
  setting

22
Basic Authenticated DH (BADH)

• 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 Kgxy with B (K?B) B Shared
  Kgxy with A (K?A)
• Looks fine, but

A
B

• (there must be a reason we call it BADH)

23
Identity-Misbinding AttackDVW92 (a.k.a.
Unknown Key-Share attack)
A, gx
E, gx
A
B
E
B, gy, SIGB(gx,gy)
B, gy, SIGB(gx,gy)
SIGA(gy,gx)
SIGE(gy,gx)

• Any damage? Wrong identity binding!
• A Shared Kgxy with B (K?B) B
  Shared Kgxy with E (K?E)
• E doesnt know Kgxy but B considers
  anything sent by A as coming from E

24
A Shared Kgxy with B (K?B) B
Shared Kgxy with E (K?E)

• B Bank A,E customers
• A B deposit 1000 in my accountK
• B deposits the money in K s account, i.e. Es!
• BCentral Command AF-16 E small unmanned
  plane
• B E destroy yourselfK
• E passes command to A A destroys itself
• Identity Misbinding Attack the differential
  cryptanalysis of key-exchange protocols

25
A Possible Solution (ISO-9796)
A, gx
B
A
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
26
The ISO defense
A, gx
E, gx
A
B
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??

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

28
Another Solution STS DVW92

• Idea each peer proves knowledge of Kgxy
  (prevents the Id-M attack since in BADH E doesnt
  know gxy)
• As a Proof of Knowledge the STS protocol uses
  encryption under Kgxy

29
STS Pros and Cons

• ? Pro STS can protect identities
• Peers id not needed for your own authentication
• Can extend encryption to cover identities (or
  certs)

gx
A
B
A
B
gy, B, SIGB(gx,gy)K
A, SIGA(gy,gx )K


30
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!)

gx
A
B
A
B
E
gy, B, SIGB(gx,gy)K
A, SIGA(gy,gx )K


E/
31
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

32
STS with MAC (instead of encryption) DVW
gx
A
B
A
B
E

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

gy, B, SIGB(gx,gy), MACK(SIGB)
A, SIGA(gy,gx ), MACK(SIGA)


E/
33
What is going on?

• The point is that proof of knowledge of Kgxy
  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 Kgxy as proof of
  knowledge also insecure (see the SIGMA paper)

34
SIGMA Basic Version
gx
A
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 peers id for own .
authentication ? Great for id protection
35
SIGMA-Iactive protection of Initiators id
gx
A
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
? Initiators (A) id protected
36
SIGMA-Ractive protection of Responders id
A
B
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)
37
IKEv1 Variant MAC under SIG

• Equivalent security (just save MAC space)

A
gx
B
A, SIGA (MACKm (A, gy,gx))
? this is IKEs aggressive mode (no id
protectn) Note MAC(SIG(id,)) is not
secure!! (STS-MAC)
38
IKE Main Mode
A
B
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
39
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

40
But is SIGMA Secure?!

• Secure! (rigorous analysis) Canetti-K Crypto02
• 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 Protn Encryption secure against active
  attackers (CCA)
• Certificates,

Care with variants!!
RCCA Thu X
41
If we only had more time

• Many aspects of IKEs 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

42
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

43
Final Remark

• A new Proposal Just Fast Keying (JFK) Available
  at http//www.research.att.com/smb/papers/jfk-cc
  s.pdf

44
And one truly last word
ThAnKs
?