Chapter 9: Key Management

1
Chapter 9 Key Management

• All algorithms we have introduced are based on
  one assumption keys have been distributed. But
  how to do that?
• Key generation, distribution, storage, revocation
• Bind key to identity (owner)

2
Overview

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

3
Notation

• X ? Y Z W kX,Y
• X sends Y the message produced by concatenating Z
  and W enciphered by key kX,Y, which is shared by
  users 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 nonces (non-repeating random numbers)

4
Session, Interchange Keys

• Session key associate with a communication only
  is used for a short period of time
• Interchange key associate with a principal
  usually is used to establish session keys is
  used for a longer period of time

5
Session, Interchange Keys

• Alice wants to send a message m to Bob
• Alice generates a random cryptographic key kA,B
  and uses it to encipher m
• To be used for this message only
• Called a session key
• She enciphers kA,B with Bobs public key kpub_B
• kpub_B enciphers all session keys that Alice uses
  to communicate with Bob
• Called an interchange key
• Alice sends m kA,B kA,B kpub_B

6
Benefits

• Limit the amount of traffic that is enciphered
  with a single key
• Use interchange keys to encrypt session keys
• Use session keys to encrypt data
• decrease the amount of traffic an attacker can
  obtain
• Prevents some attacks
• Example Alice will send Bob a message that is
  either BUY or SELL. Eve computes possible
  ciphertexts BUY kpub-B and SELL
  kpub-B. Eve intercepts enciphered message,
  compares, and gets plaintext at once
• Called forward search

7

• Threats to key distribution/establishment
  procedures
• Who is the other party of the communication
• She says that she is Alice, but is she?
• Is the key generated for the communication b/w me
  and Alice?
• Who are the two parties for the key
• Does the other party actually know the key?
• Is the key fresh?
• Two ways to guarantee this

8
Key Exchange Algorithms

• Goal Alice, Bob get shared key
• Key cannot be sent in clear
• Attacker can listen and get the key
• Key can be sent enciphered, or derived from
  exchanged data plus data not known to an
  eavesdropper (pre-distributed)
• Alice, Bob may trust a third party
• All cryptosystems, protocols publicly known
• The only secret data are the keys, and some
  pre-distributed information to Alice and Bob (for
  key derivation)
• Anything transmitted on the network is assumed to
  be known to attacker

9
Classical Key Exchange

• Bootstrap problem how do Alice, Bob begin?
• Alice cant send the key to Bob in the clear!
• Assume a trusted third party, Cathy
• Alice and Cathy share secret key kA,C
• Bob and Cathy share secret key kB,C
• Use this to exchange shared key kA,B

10
Simple Protocol
request for session key to Bob kA,C
Alice
Cathy
kA,B kA,C kA,B kB,C
Alice
Cathy
Alice, kA,B kB,C
Alice
Bob
11
Problems

• Now let us look at Bob
• Does Bob knows the other party? Not really
• Does Bob knows the key is for him Yes
• Does the other party actually know the key? Not
  sure
• Is the key fresh? Not sure
• Some attacks may exist
• Session key reuse Eve talked to Bob and got a
  session key. She replays this message and
  pretends to be Alice to talk to Bob

12

• Methods to fix the problems
• About two communication parties
• The names of two parties should be clearly
  identified in the encrypted messages
• The other party needs to show that he/she
  actually knows the key
• Challenge-response
• Freshness of the key
• Use time stamp
• Or use freshly generated random numbers

13
Otway-Rees Protocol

• Does not use timestamps
• Does not need clocks to be synchronized
• Uses integer n to associate all messages with
  particular exchange

14
The Protocol
n Alice Bob r1 n Alice Bob
kA
Alice
Bob
n Alice Bob r1 n Alice Bob
kA r2 n Alice Bob kB
Cathy
Bob
n r1 ks kA r2 ks kB
Cathy
Bob
n r1 ks kA
Alice
Bob
15
Argument Alice talking to Bob

• Why a number n
• To link all messages of this exchange together
• How does Alice make sure
• This is b/w her and Bob
• The random number r1 is linked to this connection
  b/w Alice and Bob. Only Cathy can open the 2nd
  message and see it.
• The key is fresh
• Because of the random number r1
• The other party actually knows the key
• Not guaranteed in the protocol, but will see in
  the following data communication

16
Argument Alice talking to Bob

• How does Bob make sure
• This is b/w him and Alice
• The random number r2 is linked to this connection
  b/w Alice and Bob. Only Cathy can open the 2nd
  message and see it.
• The key is fresh
• Because of the random number r2
• The other party actually knows the key
• Not guaranteed in the protocol, but will show in
  the following data communication

17
Replay Attack

• Possible attack
• Eve acquires old ks and the message in the third
  step
• The message is n r1 ks kA r2
  ks kB
• Eve resends the message to Alice
• Alice has no ongoing key exchange with Bob n
  matches nothing, so is rejected
• Alice has ongoing key exchange with Bob r1 does
  not match, so is again rejected

18
Public Key Key Exchange

• Here interchange keys are known to everyone
• eA, eB Alice and Bobs public keys known to all
• dA, dB Alice and Bobs private keys known only
  to the owner
• A simple protocol to establish the session key
• ks is the desired session key

ks eB
Alice
Bob
19
Problem and Solution

• Vulnerable to forgery or replay
• Because eB is known to everyone, Bob has no
  assurance that Alice sent the message
• Simple fix uses Alices private key to double
  encrypt the message
• Ks is the desired session key

ks dA eB
Alice
Bob
20
Notes

• Assumes Bob has Alices public key, and vice
  versa
• If not, they must get the public keys of the
  other party from a server
• If a public key is not bound to an identity,
  attacker Eve can launch a man-in-the-middle
  attack (next slide)
• Solution to this (binding identity to keys)
  discussed later as public key infrastructure
  (PKI)
• Man-in-the-middle Eve pretends to be Alice to
  Bob, and pretends to be Bob to Alice

21
Man-in-the-Middle Attack
I need Bobs public key
Eve intercepts request
Alice
Cathy
I need Bobs public key
Cathy
Eve
Bobs pub key eB
Cathy
Eve
Bobs pub key eE
Eve
Alice
ks eE
Eve intercepts message
Bob
Alice
ks eB
Bob
Eve
22
Cryptographic Key Infrastructure

• Goal bind identity to key
• Classical not possible as all keys are shared
• Use protocols to agree on a shared key
• Public key bind identity to public key
• It is crucial since people will use the public
  key to communicate to the principal whose
  identity is bound to the public key
• Erroneous binding means no secrecy between
  principals
• We assume that principal identified by an
  acceptable name

23
Certificates

• A certificate token (message) contains
• Identity of principal (here, Alice)
• Corresponding public key
• Timestamp (when issued, when expire)
• Other information (perhaps identity of signer)
• signed by a trusted authority (here, Cathy)
• CA eA Alice T dC

24
Use

• Bob gets Alices certificate
• If he knows Cathys public key, he can decipher
  the certificate
• When was the certificate issued?
• Is the principal Alice?
• Now Bob has Alices public key
• It does not have to come from Alice
• Problem Bob needs Cathys public key to validate
  certificate
• Problem pushed up a level
• Two approaches
• Certificate hierarchy VeriSign signs certificate
  for EBay, EBay signs Alice, now you get Alices
  public key if you trust VeriSign
• Signature chains friend tells friend

25
Certificate Signature Chains

• Create certificate
• Generate hash value of the certificate content
• Encipher hash with issuers private key
• Validate
• Obtain issuers public key
• Decipher enciphered hash
• Re-compute hash value from certificate and
  compare
• Problem getting issuers public key

26
Issuers

• Certification Authority (CA) entity that issues
  certificates
• It will be easy if the whole world has one CA
• Multiple issuers pose validation problem
• Alices CA is Cathy Bobs CA is Don how can
  Alice validate Bobs certificate?
• Let Cathy and Don cross-certify each other
• Each issues certificate for the other

27
X.509 Validation and Cross-Certifying

• Certificates
• CathyltltAlicegtgt
• DanltltBobgt
• CathyltltDangtgt
• DanltltCathygtgt
• Alice validates Bobs certificate
• Alice obtains CathyltltDangtgt
• Alice uses (known) public key of Cathy to
  validate CathyltltDangtgt
• Alice uses Dans public key to validate DanltltBobgtgt

28
PGP Chains

• Locate a chain of people that trust and issue
  certificate for the next one in the chain
• In PGP, the public key of one principal can be
  signed by multiple signatures of different people
• Notion of trust embedded in each signature
• Range from untrusted to ultimate trust
• Signer defines meaning of trust level (no
  standards!)

29
Validating Certificates

• Alice needs to validate Bobs certificate
• Alice does not know Fred, Giselle, or Ellen
• Alice gets Giselles cert
• Knows Henry slightly, but his signature is at
  casual level of trust
• Alice gets Ellens cert
• Knows Jack, so uses his cert to validate Ellens,
  then hers to validate Bobs

Arrows show signatures Self signatures not shown
Jack
Henry
Ellen
Irene
Giselle
Fred
Bob
30
Key Revocation

• Certificates invalidated before expiration
• Usually due to compromised key
• May be due to change in circumstance (e.g.,
  someone leaving company)
• Problems
• Who can revoke certificates Entities that are
  authorized to do so
• How to let every one know Revocation information
  circulates to everyone
• Network delays, infrastructure problems may delay
  information

31
CRLs

• Certificate revocation list lists certificates
  that are revoked
• X.509 only certificate issuer can revoke
  certificate
• Added to CRL
• PGP signers can revoke signatures owners can
  revoke certificates, or dedicate others to do so

32
Digital Signature

• Construct a message that we can prove its origin
  and integrity of contents to a disinterested
  third party (judge)
• Sender cannot deny having sent message (the
  service is nonrepudiation)
• Limited to technical proofs
• cannot deny ones cryptographic key was used to
  sign
• One could claim the cryptographic key was stolen
  or compromised
• Legal proofs, etc., probably required not dealt
  with here

33
Common Error

• Classical Alice, Bob share key k
• Alice sends m m k to Bob
• This is not a digital signature
• Why? Third party cannot determine whether Alice
  or Bob generated message

34
Public Key Digital Signatures

• Alices keys are dAlice, eAlice
• Alice sends Bob
• m m dAlice
• In case of dispute, judge computes
• m dAlice eAlice
• and if it is m, Alice signed the message
• Shes the only one who knows dAlice!

35
RSA Digital Signatures

• Use private key to encipher message
• Key points
• Never sign random documents, and when signing,
  always sign the hash of the document
• Mathematical properties can be turned against
  signer
• Sign message first, then encipher
• Changing public keys causes forgery

36
Key Points

• Key management critical to effective use of
  cryptosystems
• Different levels of keys (session vs.
  interchange)
• Keys need infrastructure to identify holders,
  allow revoking
• Key escrowing complicates infrastructure
• Digital signatures provide integrity of origin
  and content
• Much easier with public key cryptosystems than
  with classical cryptosystems
• Two types of attacks
• Forward search and man-in-the-middle