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