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 Cryptographic key infrastructure Key revocation
Session vs. interchange keys
Classical, public key methods
Cryptographic key infrastructure
Certificates
Key revocation
Digital signatures

3. Notation X  Y : { Z || W } kX,Y A  T : { Z } kA || { W } kA,T
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 (A’s 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 Bob’s 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 can’t 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: Some attacks may exist
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
{ 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 Bob’s public keys known to all
dA, dB: Alice and Bob’s 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 Alice’s private key to double encrypt the message
Ks: is the desired session key
{ { ks } dA } eB
Alice
Bob

20. Notes Assumes Bob has Alice’s 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 Bob’s public key
Eve intercepts request
Alice
Cathy
I need Bob’s public key
Eve
Cathy
Bob’s pub key eB
Eve
Cathy
Bob’s pub key eE
Alice
Eve
{ ks } eE
Eve intercepts message
Alice
Bob
{ ks } eB
Eve
Bob

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 Alice’s certificate Now Bob has Alice’s public key
If he knows Cathy’s public key, he can decipher the certificate
When was the certificate issued?
Is the principal Alice?
Now Bob has Alice’s public key
It does not have to come from Alice
Problem: Bob needs Cathy’s 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 Alice’s 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 issuer’s private key
Validate
Obtain issuer’s public key
Decipher enciphered hash
Re-compute hash value from certificate and compare
Problem: getting issuer’s 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
Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s certificate?
Let Cathy and Don cross-certify each other
Each issues certificate for the other

27. X.509 Validation and Cross-Certifying
Certificates:
Cathy<<Alice>>
Dan<<Bob>
Cathy<<Dan>>
Dan<<Cathy>>
Alice validates Bob’s certificate
Alice obtains Cathy<<Dan>>
Alice uses (known) public key of Cathy to validate Cathy<<Dan>>
Alice uses Dan’s public key to validate Dan<<Bob>>

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 Bob’s certificate
Alice does not know Fred, Giselle, or Ellen
Alice gets Giselle’s cert
Knows Henry slightly, but his signature is at “casual” level of trust
Alice gets Ellen’s cert
Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s
Arrows show signatures
Self signatures not shown
Jack
Henry
Ellen
Irene
Giselle
Fred
Bob

30. Key Revocation Certificates invalidated before expiration Problems
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 one’s 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
Alice’s 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
She’s 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