cmsc 414 computer and network security lecture 14
Post on 09-Jan-2016
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
CMSC 414Computer 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
AKDC: N, “Bob”
KDCA: EncKA{N, “Bob”, KAB, ticket},
where ticket = EncKB{KAB, “Alice”, exp-time}
AB: ticket, EncKAB{timestamp}
BA: 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-the-
middle 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(AB) = SignSKA(“B”, PKB, info)– “info” can contain expiration time, restrictions, etc.
Can view this as a directed edge in a graph:
If you know A’s public key (and trust its certification), you can learn B’s public key
PKA PKB
Transitivity/“certificate chains”
Can learn keys via multiple hops:
Semantics are slightly different here: you may trust A to certify B, but do you trust A to certify that B can certify others?
PKA PKB PKC
Cert(AB) Cert(BC)
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 PKC
PKD PKE
Public keys I already know
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
top related