Key Management
Shared Key Exchange Problem
•
•
How do Alice and Bob exchange a shared secret?
Offline
–
•
•
•
Doesn’t scale
Using public key cryptography (possible)
Using specially crafted messages (Diffie Hellman)
Using a trusted third party (KDC)
–
–
–
Secrets should never be sent in clear
We should prevent replay attacks
We should prevent reuse of old keys
Diffie Hellman Key Exchange
•
Exchange a secret with someone you never
met while shouting in a room full of
people
•
Alice and Bob agree on g and large
n
g a mod n
Alice chooses random a, sends b
•
Bob chooses random b, sends
•
Alice takes Bob’s message and calculates
•
•
g mod n
g ab mod n
Bob does the same;
ab now they both know
g mod n
shared secret
KDC Based Key Distribution
• Building up to Needham Schroeder/Kerberos
• User sends req. to KDC (key distrib. center)
• KDC generates a shared key: Kc,s
1. C, S
C
3. EKKDC,S{C, Kc,s}
KDC
ticket
2. EKKDC,C{S, Kc,s}
• Keys KKDC,C and KKDC,S are preconfigured
• No keys ever traverse net in the clear
• Why are identities in tickets?
S
KDC Based Key Distribution
• KDC does not have to talk both to C and S
ticketS = EKKDC,S{C, Kc,s}
1. C, S
KDC
C
2. EKKDC,C{S, Kc,s}, ticketS
S
3. ticketS
• Messages 2 or 3 can be replayed by M
– Force C and S to use same secret for a long time
– Cause S to have an old ticket, break comm. w C
Needham-Shroeder Key Exchange
• Use nonces to prevent replay attacks
ticketS = EKKDC,S{C, Kc,s}
1. N1, C, S
KDC
2. EKKDC,C{N1, S, Kc,s, ticketS}
C
3. EKC,S{N2}, ticketS
4. EKC,S{N2-1, N3}
5. EKC,S{N3-1}
S
Whys …
•
•
•
•
Why N1?
Why N2?
Why N3?
Why encrypt ticketS
Problem
• What happens if attacker gets session key?
– Can reuse old session key to answer challengeresponse, generate new requests, etc
– Need timestamps to ensure freshness = tickets
expire after some time
Solution
• Introduce Ticket Granting Server (TGS)
– Daily ticket plus session keys
• Authentication server (AS) authenticates users
• TGS+AS = KDC
– This is modified Needham-Schroeder
– Basis for Kerberos
Kerberos
Third-party authentication service
– Distributes session keys for authentication,
confidentiality, and integrity
AS
TGS
3. TGSReq
2. ASRep
1. ASReq
4. TGSRep
C
5. SReq
S
Kerberos
•
•
•
•
•
•
•
KC, AS = f(passuser)
ASReq = username, TGS, timestamp1
TTGS = EKAS,TGS(C, KTGS,C, timestamp2, lifetime2)
ASRep = EKC,AS(KTGS,C, TGS, timestamp2, lifetime2), TTGS
TGSReq = TTGS, S, EKTGS,C(C, timestamp3)
TS = EKS,TGS(C, KC,S, timestamp4, lifetime4)
TGSRep = TS, EKC,TGS(KC,S, S, timestamp4, lifetime4)
SReq = EKC,S(C, timestamp5), TS
Public Key Exchange Problem
•
How do we verify an identity:
–
–
–
Alice sends to Bob her public key Pub(A)
Bob sends to Alice his public key Pub(B)
How do we ensure that those keys really belong to
Alice and Bob? Need a trusted third party
Man-in-the-Middle Attack
On Key Exchange
•
•
•
•
•
Alice sends to Bob her public key Pub(A)
Mallory captures this and sends to Bob Pub(M)
Bob sends to Alice his public key Pub(B)
Mallory captures this and sends to Alice Pub(M)
Now Alice and Bob correspond through Mallory
who can read/change all their messages
Public Key Exchange
• Public key is public but …
– How does either side know who and what the key is
for?
• Does this solve key distribution problem?
– No – while confidentiality is not required, integrity is
• Still need trusted third party
– Digital certificates – certificate authority (CA) signs
identity+public key tuple with its private key
– Problem is finding a CA that both client and server
trust
Digital Certificates
•
•
•
•
•
Everyone has Trent’s public key
Trent signs both Alice’s and Bob’s public keys – he
generates public-key certificate
When they receive keys, verify the signature
Mallory cannot impersonate Alice or Bob because
her key is signed as Mallory’s
Certificate usually contains more than the public
key
– Name, network address, organization
•
Trent is known as Certificate Authority (CA)
Certificate-Based Key Exchange
• Authentication steps
– Alice provides nonce, or a timestamp is used
instead, along with her certificate.
– Bob selects session key and sends it to Alice with
nonce, encrypted with Alice’s public key, and signed
with Bob’s private key. He sends his certificate too
– Alice validates certificate – it is really Bob’s key
inside
– Alice checks signature and nonce – Bob really
generated the message and it is fresh
PGP
• Pretty Good Privacy
– “Web of Trust”
– Public key, identity association is signed by
many entities
– Receiver hopefully can locate several signatures
that he can trust
– Like an endorsement scheme
SSH
• User keys installed on server out of band
– User logs in with a password
– Copies her public key onto server
• Weak assurance of server keys
– User machine remembers server keys on first
contact
– Checks if this is still the same host on
subsequent contact
– But no check on first contact
Recovery From Stolen Private Keys
• Revocation lists (CRL’s)
– Long lists
– Hard to propagate
• Lifetime / Expiration
– Short life allows assurance of validity at time of
issue
• Real time validation
– Receiver of a certificate asks the CA who signed it
if corresponding private key was compromised
– Can cache replies