Scribd
Upload
80 views

Key Management Protocols and Compositionality: John Mitchell Stanford

The document summarizes key management protocols and cryptographic techniques: 1) It discusses key distribution methods like out-of-band communication, public key infrastructure (PKI), and protocols to generate session keys. It also notes properties of good key management like avoiding key reuse. 2) It provides an overview of the Internet standardization process and how protocols progress from draft to standard. 3) It describes several key exchange protocols like Kerberos, Diffie-Hellman, and IKE that allow parties to securely establish a shared secret key.

Uploaded by

SandraPerera
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
80 views

Key Management Protocols and Compositionality: John Mitchell Stanford

The document summarizes key management protocols and cryptographic techniques: 1) It discusses key distribution methods like out-of-band communication, public key infrastructure (PKI), and protocols to generate session keys. It also notes properties of good key management like avoiding key reuse. 2) It provides an overview of the Internet standardization process and how protocols progress from draft to standard. 3) It describes several key exchange protocols like Kerberos, Diffie-Hellman, and IKE that allow parties to securely establish a shared secret key.

Uploaded by

SandraPerera
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 30

TECS Week 2005

Key Management Protocols


and Compositionality

John Mitchell
Stanford
Key Management Options
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


Internet Standardization Process

 All standards published as RFC (Request for


Comment)
• Available: http://www.ietf.org
• Not all RFCs are Internet Standards !
 Typical path to standardization
• Internet Drafts
• RFC
• Proposed Standard
• Draft Standard (requires 2 working implementation)
• Internet Standard (declared by IAB)
 David Clark, MIT, 1992: "We reject: kings,
presidents, and voting. We believe in: rough
consensus and running code.”
Key Distribution: Kerberos Idea
Shared symmetric key Kc

KeyCenter

Shared
Client symmetric
key Ks

Server
Key Center generates session key Kcs and
distributes using shared long-term keys
Kerberos Protocol
Kc KDC

Ktgs

{C}Kt S {C, Kt}Ktgs


Ticket 1
Client TGS
{Ks}Kt Ticket
{C, 2
Ks}Kv

Kv
Service
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 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 xS is x = gn
• Example: integers modulo prime p
Protocol
ga mod p

A gb mod p
B

Alice, Bob share gab mod p not known to anyone else


Diffie-Hellman Key Exchange

ga mod p

A gb mod p B

Authentication?
Secrecy?
Replay attack
Forward secrecy?
Denial of service?
Identity protection?
IKE subprotocol from IPSEC

m1
A, (ga mod p)

B, (gb mod p), signB(m1,m2)


A B
m2
signA(m1,m2)

Result: A and B share secret gab mod p


Signatures provide authentication, as long as signature
verification keys are known
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
Protocol Derivation Framework
Protocols are constructed from:
• components
by applying a series of:
• composition, refinement and transformation
operations.
Incrementally achieve design goals
• Properties accumulate as a derivation proceeds
Examples in papers:
• STS, ISO-9798-3, JFKi, JFKr, IKE, …

Acknowledgement: Dusko Pavlovic [Kestrel]


STS family

STS0
cookie
STS0H
JFK (Just Fast Keying)
and RFK (our name)
were proposed
distribute
certificates
open

STSa STSaH
responder
JFK0 successors to IKE
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
– research will produce compositional methods

You might also like