Key Management

Shared Key Exchange Problem How do Alice and Bob exchange a shared secret? Offline – Doesnt 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

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 Alice chooses random a, sends Bob chooses random b, sends Alice takes Bobs message and calculates Bob does the same; now they both know shared secret Diffie Hellman Key Exchange

Building up to Needham Schroeder/Kerberos User sends req. to KDC (key distrib. center) KDC generates a shared key: K c,s Keys K KDC,C and K KDC,S are preconfigured No keys ever traverse net in the clear Why are identities in tickets? KDC Based Key Distribution C C KDC S S 3. EK KDC,S {C, K c,s } 2. EK KDC,C {S, K c,s } 1. C, S ticket

KDC does not have to talk both to C and S 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 KDC Based Key Distribution C C KDC S S ticket S = EK KDC,S {C, K c,s } 2. EK KDC,C {S, K c,s }, ticket S 1. C, S 3. ticket S

Use nonces to prevent replay attacks Needham-Shroeder Key Exchange C C KDC S S ticket S = EK KDC,S {C, K c,s } 2. EK KDC,C {N 1, S, K c,s, ticket S } 1. N 1, C, S 3. EK C,S {N 2 }, ticket S 4. EK C,S {N 2 -1, N 3 } 5. EK C,S {N 3 -1}

Why N 1 ? Why N 2 ? Why N 3 ? Why encrypt ticket S Whys …

What happens if attacker gets session key? – Can reuse old session key to answer challenge- response, generate new requests, etc – Need timestamps to ensure freshness = tickets expire after some time Problem

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 Solution

Third-party authentication service – Distributes session keys for authentication, confidentiality, and integrity Kerberos TGS 4. TGSRep 3. TGSReq AS 1. ASReq 2. ASRep CS 5. SReq

ASReq = username, TGS, timestamp 1 T TGS = EK AS,TGS (C, K TGS,C, timestamp 2, lifetime 2 ) ASRep = EK C,AS (K TGS,C, TGS, timestamp 2, lifetime 2 ), T TGS TGSReq = T TGS, S, EK TGS,C (C, timestamp 3 ) T S = EK S,TGS (C, K C,S, timestamp 4, lifetime 4 ) TGSRep = T S, EK C,TGS (K C,S, S, timestamp 4, lifetime 4 ) SReq = EK C,S (C, timestamp 5 ), T S Kerberos K C, AS = f(pass user )

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 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 Public Key Exchange

Digital Certificates Everyone has Trents public key Trent signs both Alices and Bobs 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 Mallorys Certificate usually contains more than the public key – Name, network address, organization Trent is known as Certificate Authority (CA)

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 Alices public key, and signed with Bobs private key. He sends his certificate too – Alice validates certificate – it is really Bobs key inside – Alice checks signature and nonce – Bob really generated the message and it is fresh Certificate-Based Key Exchange

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 PGP

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 SSH

Revocation lists (CRLs) – 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 Recovery From Stolen Private Keys