Chapter 9: Key Management

1
Chapter 9 Key Management

• Key exchange
• Session vs. interchange keys
• Classical, public key methods
• Cryptographic key infrastructure
• Certificates
• Key storage
• Key revocation
• Digital signatures

2
Key Establishment Protocols

• Common implementation of secure sessions
  establish a secret key known only to two parties
• Challenge how to establish a secret key using
  only public information
• Even if the two parties share a long-term secret,
  a fresh key should be created for each session a
  session key ? why ?
• Long-term secrets are valuable want to use them
  as sparingly as possible to limit exposure and
  the damage if the key is compromised

3
Other Benefit of Using Session Key

• Prevents some attacks e.g. replay attack,
• forward search attack
• Alice will send Bob message that is either BUY
  or SELL.
• Attacker Eve computes possible ciphertexts
• BUY EB and SELL EB.
• Eve intercepts enciphered message, compares, and
  gets plaintext
• More replay attack example in the protocol
  design

4
Session Key and Interchange Key

• Alice wants to send a message m to Bob, Assume
• public key encryption
• Alice generates a random cryptographic key ks and
  uses it to encipher m
• To be used for this message only, is called a
  session key
• Alice enciphers ks with Bobs public key EB
• EB enciphers all session keys Alice uses to
  communicate with Bob, is called an interchange
  key
• Alice sends m ks ks EB

5
Key Establishment Techniques

• Classical Cryptographic Key Exchange
• Every party shares a pairwise secret key with
  trusted key distribution center (KDC)
• KDC creates a new random session key and then
  distributes it. e.g. Kerberos
• Public-key Cryptography Key Exchange
• Diffie-Hellman authenticated with signatures
• e.g. IKE (Internet Key Exchange)
• One party creates a random key, sends it
  encrypted under the other partys public key
• e.g. TLS (Transport Layer Security)

6
Assumption

• Key cannot be sent in clear
• Attacker can listen in
• Key can be sent enciphered, or derived from
  exchanged data plus data not known to an
  eavesdropper
• Alice, Bob may trust a third party a Trust
  Server
• All cryptosystems, protocols publicly known
• Only secret data is the keys, ancillary
  information known only to Alice and Bob needed to
  derive keys
• Anything transmitted is assumed known to attacker

7
Notation

• X ? Y Z W kX,Y
• X sends Y the message produced by concatenating
  Z and W enciphered by key kX,Y (shared by X and
  Y)
• A ? T Z kA W kA,T
• A sends T a message consisting of the
  concatenation of Z enciphered using kA (As key),
  and W enciphered using kA,T (the key shared by A
  and T)
• r1, r2 are nonces (nonrepeating random numbers)

8
Classical Cryptographic Key Exchange

• Bootstrap problem
• Alice cant send key to Bob in the clear!
• Assume a trusted third party, Cathy
• Alice and Cathy share secret key kA
• Bob and Cathy share secret key kB
• Use this to establish a shared session key
  between Alice and Bob ks

9
A Simple Protocol
request for session key to Bob kA
Alice
Cathy
1)
ks kA ks kB
Alice
2)
Cathy
ks kB
Alice
Bob
3)

• What will happen next?
• Is there any potential problem?

10
Problem with the Simple Protocol

• Bob does NOT know to whom he is talking!
• Replay attack
• Solution? ? Protocols must provide authentication

ks kB
Eve
Bob
3)
deposit 1000 to Eves account ks
Eve
Bob
4)
11
Protocol 2 Needham-Schroeder
Alice Bob r1 kA
Alice
Cathy
1)
Alice Bob r1 ks Alice ks kB
kA
Alice
Cathy
2)
Alice ks kB
Alice
Bob
3)
r2 ks
Alice
Bob
4)
r2 1 ks
Alice
Bob
5)
Is there any potential problem?
12
Problem with Needham-Schroeder Protocol

• Suppose Eve can obtain/break a session key
  (Secure sever generates Ks pseudorandomly) How
  does that affect protocol?
• ? Eve can impersonate Alice, shown below
• ? Solution assure Ks is fresh for each session

Alice ks kB
Eve
Bob
r2 ks
Eve
Bob
r2 1 ks
Eve
Bob
13
Denning-Sacco Modification
Alice Bob r1 kA
Alice
Cathy
1)
Alice Bob r1 ks Alice T ks
kB kA
Alice
Cathy
2)
Alice T ks kB
Alice
Bob
3)
r2 ks
Alice
Bob
4)
r2 1 ks
Alice
Bob
5)
14
Problem with Denning-Sacco Protocol

• Weakness if clocks on both parties not
  synchronized, may either reject valid messages or
  accept replays
• Parties with either slow / fast clocks vulnerable
  to replay
• Solution ?
• ? Does not use timestamps (Otway-Rees Protocol)

15
Otway-Rees Protocol

• Does not use timestamps
• Not vulnerable to the problems that
  Denning-Sacco modification has
• Basic idea Uses an integer n to associate all
  messages with a particular exchange
• (a serial number)

16
Otway-Rees Protocol
n Alice Bob r1 n Alice Bob
kA
Alice
Bob
1)
n Alice Bob r1 n Alice Bob
kA r2 n Alice Bob kB
Cathy
Bob
2)
n r1 ks kA r2 ks kB
Cathy
Bob
3)
n r1 ks kA
Alice
Bob
4)
17
How Otway-Rees Protocol Handles Replay Attack

• If Eve acquires an old ks and message in msg 3)
• n r1 ks kA r2 ks kB
• Eve forwards appropriate part to Alice
• Alice rejects, since no ongoing key exchange
  with Bob with series number n
• The only way Eve succeed is she acquires Ks for
  an ongoing session.

18
In Practice Kerberos System

• Kerberos is an authentication system based on
  Needham-Schroeder with Denning-Sacco modification
• e.g. Alice wants to use a server S (say printing
  a file)
• Alice authenticates herself to the Kerberos
  system
• Alice obtain a ticket to use Server S
• Separate authentication user ? the ticket issuer
• and the vouching of identity ? Server S

19
Idea

• Step 1 User u authenticates to Kerberos server
• Obtains ticket Tu,TGS for ticket granting service
  (TGS)
• Step 2 User u wants to use service s
• User sends authenticator Au and ticket Tu,TGS to
  TGS asking for ticket for service
• TGS sends ticket Tu,s to user
• User sends Au and Tu,s to server as request to
  use s

20
Ticket

• Credential saying issuer has identified ticket
  requester
• e.g. A ticket issued to user u for service s
• Tu,s s u us address valid time
  ku,s ks
• ku,s is session key for user and service
• Valid time is interval for which ticket valid
• us address may be IP address
• ks is key that s shared with the authentication
  server

21
Authenticator

• Credential containing identity of sender of
  ticket
• to confirm sender is entity to which ticket was
  issued
• e.g. authenticator user u generates for service
  s
• Au,s u generation time kt ku,s
• kt is alternate session key
• Generation time is when authenticator generated
• Note more fields, not relevant here

22
Kerberos Protocol
user TGS
user
Cathy
1)
ku,TGS ku Tu,TGS
Cathy
user
2)
service Au,TGS Tu,TGS
user
TGS
3)
user ku,s ku,TGS Tu,s
user
TGS
4)
Au,s Tu,s
user
service
5)
t 1 ku,s
user
service
6)
23
Problems of Kerberos

• Relies on synchronized clocks
• If not synchronized and old tickets,
  authenticators not cached, replay is possible
• Tickets have some fixed fields
• Dictionary attacks possible
• Kerberos 4 session keys are weak (had much less
  than 56 bits of randomness)