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)
1
Overview
• Key exchange
– Session vs. interchange keys
– Classical, public key methods
• Cryptographic key infrastructure
– Certificates
• Key revocation
• Digital signatures
2
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
3
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
4
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”
5
• 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
6
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
7
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
8
Simple Protocol
Alice
Alice
Alice
{request for session key to Bob } kA,C
{ kA,B } kA,C || { kA,B } kB,C
Alice, { kA,B } kB,C
Cathy
Cathy
Bob
9
• 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
10
Otway-Rees Protocol
• Does not use timestamps
– Does not need clocks to be synchronized
• Uses integer n to associate all messages
with particular exchange
11
The Protocol
Alice
n || Alice || Bob || { r1 || n || Alice || Bob } kA
n || Alice || Bob || { r1 || n || Alice || Bob } kA ||
Cathy
{ r2 || n || Alice || Bob } kB
Cathy
Alice
n || { r1 || ks } kA || { r2 || ks } kB
n || { r1 || ks } kA
Bob
Bob
Bob
Bob
12
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
13
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
Alice
{ ks } eB
Bob
14
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
Alice
{ { ks } dA } eB
Bob
15
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
16
Man-in-the-Middle Attack
I need Bob’s public key Eve intercepts request
Alice
Cathy
I need Bob’s public key
Cathy
Eve
Bob’s pub key eB
Cathy
Eve
Bob’s pub key eE
Eve
Alice
Alice
{ k s } eE
Eve intercepts message
Eve
{ ks } eB
Bob
Bob
17
Cryptographic Key
Infrastructure
• Goal: bind identity to 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
18
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
19
Use
• Bob gets Alice’s certificate
– 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
20
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
21
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
22
X.509 Validation and CrossCertifying
• 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>>
23
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!)
24
Validating Certificates
• Alice needs to validate
Bob’s certificate
– Alice does not know Fred,
Giselle, or Ellen
Arrows show signatures
Self signatures not shown
Jack
• Alice gets Giselle’s cert
– Knows Henry slightly, but
his signature is at “casual”
level of trust
• Alice gets Ellen’s cert
Henry
Irene
– Knows Jack, so uses his
cert to validate Ellen’s, then
hers to validate Bob’s
Ellen
Giselle
Fred
Bob
25
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
26
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
27
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
28
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!
29
Digital Signatures
• 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
30
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
31