CMSC 414
Computer and Network Security
Lecture 14
Jonathan Katz
Session key establishment
 There are very few applications for which
authentication alone is sufficient!
– Can you think of any?
– What do you do once you are authenticated?
 Generally, need to establish a session key to
authenticate (and encrypt) subsequent
communication
– Also efficiency advantages to using symmetric-key
techniques even if public-key authentication is used
– Advantages even if a symmetric key is already shared…
Session keys
 Maintain independence of sessions
– E.g., prevent replay of messages from other sessions
 If key compromised, only one session affected
– Forward secrecy – even if long-term key compromised,
session keys unaffected
 Reduces effectiveness of cryptanalysis
Adding key exchange
 Not sufficient to simply “add on” key
establishment before/after authentication
– Splicing attack…
 Need “authenticated key exchange”
Public-key based…
 Include Epk(session-key) in protocol?
– No authentication of the ciphertext
 Encrypt session key and sign the result?
– No forward secrecy…
– Potentially vulnerable to replay attacks
 Client sends Epks(R1); server sends Epkc(R2);
session key is R1+R2
– Reasonable…though no forward secrecy
– Why isn’t it a problem that the ciphertexts are not
authenticated?
– Implicit vs. explicit authentication
Authenticated Diffie-Hellman
 Add signatures/MACs and nonces to Diffie-
Hellman protocol
– Subtle details involved…need to ensure freshness and
asymmetry
– Achieves forward secrecy
Using session keys
 Generally, want to provide both secrecy and
integrity for subsequent conversation
–
–
–
–
Use authenticated encryption (e.g., encrypt-then-MAC)
Use sequence numbers to prevent replay attacks
Use a directionality bit
Periodically refresh the session key
Mediated authentication
(KDCs)
KDCs
 Key Distribution Centers
 Advantages of symmetric-key crypto, without
O(n2) keys
– But requires a trusted intermediary
– Single point of failure/attack
 Kerberos is a famous example
Basic idea
 Every user i shares a key Ki with the KDC
 When Alice wants to talk to Bob, the KDC
authenticates the request from Alice, chooses
random K, and sends EncKa(K), EncKb(K) to Alice
– Alice forwards EncKb(K) to Bob
 Alice and Bob use K to communicate
 Note that the KDC can read all communication!
Multiple intermediaries
 Allows users in different domains to communicate
securely
 Use multiple KDCs…
– Can have all pairs of KDCs share a key
– More likely, there will be a hierarchy of KDCs
Mediated authentication
 Simple protocol:
– Alice requests to talk to Bob
– KDC generates KAB and sends it to Alice and Bob,
encrypted with their respective keys
 No authentication of KDC here, but impostor can’t
determine KAB
 Other drawbacks:
– KDC has to initiate session with Bob
– Alice may try to communicate with Bob before Bob
hears from the KDC
Improvement…
 Have KDC send to Alice the encryption of KAB
under Bob’s key
– Reduces communication load on KDC
– Resilient to message delays in network
 Bob and Alice follow with mutual authentication
and key exchange (using KAB)
Kerberos
 Simpler; assumes loosely coordinated clocks
 AKDC: N, “Bob”
 KDCA: EncKA{N, “Bob”, KAB, ticket},
where ticket = EncKB{KAB, “Alice”, exp-time}
 AB: ticket, EncKAB{timestamp}
 BA: EncKAB{timestamp+1}
Desiderata and summary
 This is not an exhaustive list!
 These are concerns to be aware of; in some cases
you may decide that certain threats are not a
concern
 Better to formally define a security model and
prove security (but here we will be informal)
Desiderata and summary
 Adversary initiating session as client (i.e., client
impersonation)
– No impersonation (obviously!)
– No off-line dictionary attacks
– Should not learn information that will subsequently
allow impersonation of server to client
– Be aware of server decrypting/signing unauthenticated
challenges
– Splicing messages into the session
 Similar for server impersonation (though this is a
harder attack to carry out)
Desiderata and summary
 Eavesdropping
– Should not learn information that would allow for later
impersonation (possibly to another replica of Bob)
– Messages should be encrypted
– No off-line dictionary attacks
 Server compromise
– Should not learn client’s long-term secret/password
– Forward secrecy
– Impersonation of client to server (possibly a replica)
Certificate authorities and PKI
PKI overview
 In our discussion of public-key crypto, we have
assumed users know each others’ public keys
 But how can public keys be reliably distributed?
– Download from web page insecure against man-in-themiddle attack
– Can be obtained from CD-ROM or in person, but this is
impractical in general
 One solution: bootstrap new public keys from
public keys you already know!
– Certificates vouch for binding of public keys to names
Certificates
 One party can vouch for the public key of another
 Cert(AB) = SignSKA(“B”, PKB, info)
– “info” can contain expiration time, restrictions, etc.
 Can view this as a directed edge in a graph:
PKA
PKB
 If you know A’s public key (and trust its
certification), you can learn B’s public key
Transitivity/“certificate chains”
 Can learn keys via multiple hops:
PKA
Cert(AB)
PKB
PKC
Cert(BC)
 Semantics are slightly different here: you may
trust A to certify B, but do you trust A to certify
that B can certify others?
Transitivity
 Can also infer trust from multiple (disjoint?) paths
to the same public key for the same identity
– Edges may also have weights indicating level of trust
– A difficult problem in general
PKA
PKB
PKD
PKE
Public keys I already know
PKC
Usage of certificates
 “Trust anchors” = set of public keys already
known (and trusted to certify others)
 How to obtain certificates?
 Some possibilities:
– B “collects” certificate(s) for itself, sends these all
when starting a connection
– A finds certificates/certificate chains beginning at its
own trust anchors and terminating at B
– A tells B its trust anchors, B (finds and) sends
certificates or certificate chains beginning at those trust
anchors and terminating at itself
Certificates in the real world
 PGP keyserver (http://pgp.mit.edu)
 CAs embedded in browsers
– (Firefox:) Options→Advanced