CS 259 2008
Key Exchange Protocols
J. Mitchell
Next few lectures
Today 1/17
• Some possible projects
• Key exchange protocols and properties
Tuesday 1/19
• Contract-signing protocols
• Choose project partner, topic?
Next Thurs 1/24
• Wireless security: 802.11i
• Homework #1 due
Tuesday 1/29
• Probabilistic model checking
Project presentation #1 1/31
• One page, 1-2 slides on your project topic
Course projects
Choose a subject Choose a tool
Network protocol Murphi
• Wired networking (VoIP?) • Standard finite-state tool
• Wireless PRISM
• Mobility • probabilistic checker
Security system MOCHA
• Tamper-proof chip • Games, temporal logic
• “Trusted computing” Constraint solvers
Privacy, security policy Avispa tool set
• HIPAA Prolog
• GLBA Isabelle
• … • Automated theorem proving
Some project topics
Add timestamps to Kerberos
Group key handshake from 802.11i
IPv6 binding update (already taken?)
802.1af, DKIM, …
TCG protocols register TPM to CA, …
HIPAA, other privacy laws, GLBA, ...
Voting machine, voting procedure
• election board “programs” election, votes cast,
counted, possibly recounted …
Send email or talk with us about choosing a project
Process
Choose your project partner
• You can work alone, or with another person
Chose a subject for your project
• Can be something already familiar
• Project presentation #1 at this point!
Formulate an “abstraction” of system
• Separate relevant and irrelevant details
• Identify security properties of interest
Choose a tool and method
Complete your study. Success!
• Clear explanation of security goals
• Possible bugs or insecure configurations
• Identify proper, improper use
Key Management
Out of band
• Can set up some keys this way (Kerberos)
Public-key infrastructure (PKI)
• Leverage small # of public signing keys
Protocols for session keys
• Generate short-lived session key
• Avoid extended use of important secret
• Don’t use same key for encryption and signing
• Forward secrecy
Cryptography reduces many problems to key management
Public-Key Infrastructure
Known public signature verification key Ka
Certificate
Certificate
Sign(Ka, Ks)
Authority
Ks
Client Sign(Ka, Ks), Sign(Ks, msg) Server
Server certificate can be verified
by any client that has CA key Ka
Certificate authority is “off line”
Key Distribution: Kerberos Idea
Shared symmetric key Kc
KeyCenter
s} } Kc
cs , {Kc Ks
{K Shared
Client symmetric
{Kc key Ks
s}
K s {m
sg }
Kcs
Server
Key Center generates session key Kcs and
distributes using shared long-term keys
Key Exchange
Parties may have initial information
Generate and agree on session key
• Authentication – know ID of other party
• Secrecy – key not known to any others
• Avoid replay attack
• Forward secrecy
• Avoid denial of service
• Identity protection – disclosure to others
• Other properties you can think of???
Diffie-Hellman Key Exchange
Assume finite group G = S,
• Generator g so every xS is x = gn
• Example: integers modulo prime p
Protocol
ga mod p
A B
gb mod p
Alice, Bob share gab mod p not known to anyone else
Diffie-Hellman Key Exchange
ga mod p
A B
gb mod p
Authentication?
Secrecy?
Replay attack
Forward secrecy?
Denial of service?
Identity protection?
IPSec: Network Layer Security
Authentication Header (AH)
• Access control and authenticate data origins
• replay protection
• No confidentiality
Encapsulated Secure Payload (ESP)
• Encryption and/or authentication
Internet Key Management (IKE)
• Determine and distribute secret keys
• Oakley + ISAKMP
• Algorithm independent
Security policy database (SPD)
• discarded, or bypass
IKE: Many modes
Main mode
• Authentication by pre-shared keys
• Auth with digital signatures
• Auth with public-key encryption
• Auth with revised public-key encryption
Quick mode
• Compress number of messages
• Also four authentication options
Aug 2001 Position Statement
In the several years since the standardization of
the IPSEC protocols (ESP, AH, and ISAKMP/IKE),
… several security problems…, most notably IKE.
Formal and semi-formal analyses by Meadows,
Schneier et al, and Simpson, have shown … security
problems in IKE stem directly from its complexity.
It seems … only a matter of time before serious
*implementation* problems become apparent, again
due to the complex nature of the protocol, and the
complex implementation that must surely follow.
The Security Area Directors have asked the
IPSEC working group to come up with a
replacement for IKE.
How to study complex protocol
General Problem in Security
Divide-and-conquer is fundamental
• Decompose system requirements into parts
• Develop independent software modules
• Combine modules to produce required system
Common belief:
• Security properties do not compose
Difficult system development problem
Example protocol
Protocol P1
A B : {message}KB
A B : KA-1
This satisfies basic requirements
• Message is transmitted under encryption
• Revealing secret key KA-1 does not reveal
message
Similar protocol
Protocol P2
B A : {message’}KA
B A : KB-1
Transmits msg securely from B to A
• Message is transmitted under encryption
• Revealing secret key KB-1 does not reveal
message
Composition P1; P2
Sequential composition of two protocols
A B : {message}KB
A B : KA-1
B A : {message’}KA
B B : KB-1
Definitely not secure
• Eavesdropper learns both keys, decrypts messages
STS family
cookie
STS0 STS0H
distribute
certificates
open
responder
STSa STSaH JFK0
m=gx, n=gy
k=gxy
STS STSH JFK1
protect
identities
STSP STSPH JFK
symmetric
hash
RFK
Example
Construct protocol with properties:
• Shared secret
• Authenticated
• Identity Protection
• DoS Protection
Design requirements for IKE, JFK,
IKEv2 (IPSec key exchange protocol)
Component 1
Diffie-Hellman
A B: ga
B A: gb
• Shared secret (with someone)
– A deduces:
Knows(Y, gab) (Y = A) ۷ Knows(Y,b)
• Authenticated
• Identity Protection
• DoS Protection
Component 2
Challenge Response:
A B: m, A
B A: n, sigB {m, n, A}
A B: sigA {m, n, B}
• Shared secret (with someone)
• Authenticated
– A deduces: Received (B, msg1) Λ Sent (B, msg2)
• Identity Protection
• DoS Protection
m := ga
Composition n := gb
ISO 9798-3 protocol:
A B: ga, A
B A: gb, sigB {ga, gb, A}
A B: sigA {ga, gb, B}
• Shared secret: gab
• Authenticated
• Identity Protection
• DoS Protection
Refinement
Encrypt signatures:
A B: ga, A
B A: gb, EK {sigB {ga, gb, A}}
A B: EK {sigA {ga, gb, B}}
• Shared secret: gab
• Authenticated
• Identity Protection
• DoS Protection
Transformation
Use cookie: JFK core protocol
A B: ga, A
B A: gb, hashKB {gb, ga}
A B: ga, gb, hashKB {gb, ga}
EK {sigA {ga, gb, B}}
B A: gb, EK {sigB {ga, gb, A}}
• Shared secret: gab
• Authenticated
• Identity Protection
• DoS Protection
(Here B must store b in step 2, but we’ll fix this later…)
Cookie transformation
Typical protocol
• Client sends request to server
• Server sets up connection, responds
• Client may complete session or not (DOS)
Cookie version
• Client sends request to server
• Server sends hashed data back
– Send message #2 later after client confirms
• Client confirms by returning hashed data
• Need extra step to send postponed message
Cookie in JFK
Protocol susceptible to DOS
A B: ga, A eh1
B A: gb, EK {sigB {ga, gb, A}}
A B: EK {sigA {ga, gb, B}}
eh2
Use cookie: JFK core protocol
A B: ga, A
B A: gb, hashKB {gb, ga}
A B: ga, gb, hashKB {gb, ga}, eh2
B A: gb, eh1
Efficiency: Reuse D-H key
Costly to compute ga, gb, gab
Solution
• Keep medium-term ga, gb (change ~10 min)
• Replace ga by pair ga, nonce
JFKi, JFKr protocols (except cert or grpinfo, …)
A B: Na, ga, A
B A: Nb, gb, hashKB {Nb, Na, gb, ga}
A B: Na, Nb, ga, gb, hashKB {Nb, Na, gb, ga},
EK {sigA {Na, Nb, ga, gb, B}}
B A: gb, EK {sigB {Na, Nb, ga, gb, A}}
Note: B does not need to store any short-term data in step 2
Conclusion
Many protocol properties
• Authentication Secrecy
• Prevent replay Forward secrecy
• Denial of service Identity protection
Systematic understanding is possible
• But be careful; easy to make mistakes
• State of the art:
need to analyze complete protocol
