% tcpcrypt

# secure communication via crypto

Kerberos

SSL/TLS

tcpcrypt

# threat model

passive/active attackers

"Mossad or not-Mossad," James Mickens,
[This World of Ours](http://research.microsoft.com/en-us/people/mickens/thisworldofours.pdf)

# encryption: confidentiality

symmetric encryption: k - shared key  
ciphertext = E(k, plaintext)  
plaintext = D(k, ciphertext)

asymmetric encryption: pk/sk - public/private key  
ciphertext = E(pk, plaintext)  
plaintext = D(sk, ciphertext)

in general, encryption ⇏ integrity

# MAC: integrity

MAC(k, m): message authentication code

HMAC(k, m) = H((k ⊕ opad) ‖ H((k ⊕ ipad) ‖ m))

MAC-Keccak(k ‖ m)

# forward secrecy 

Diffie-Hellman key exchange protocol

agreed on prime number p and base g (primitive root modulo g)

alice: pick random a; send (g^a^ mod p) to bob  
bob: pick random b; send (g^b^ mod p) to alice  
alice: (g^b^)^a^ mod p  
bob:  (g^a^)^b^ mod p

shared secret between alice and bob: g^ab^ mod p

eavesdropper cannot learn the shared secret

# goal

authenticate user to server

q: how about one server? multiple servers?

# Kerberos

central authority: key distribution center (KDC)

KDC knows all keys: trusted by users, clients, servers

high-level: client requests a ticket from KDC to talk to server

ticket: client ID, IP address, timestamp, c-s session key  
encrypted using server's key

symmetric encryption:
[google for details](http://en.wikipedia.org/wiki/File:Kerberos.svg)

popular in managed environments (e.g., intranet) 

# Kerberos downsides

KDC: single point of failure

clock: replay old messages

Kerberos 4: encryption ⇒ integrity?

privacy

scalability

# SSL/TLS strawman

asymmetric encryption

assume client knows server's public key pk~S~

client: generate session key k, send E(pk~S~, k) to server

server: decrypt k using D(sk~S~)

q: why session key - performance

q: replay attacks - nonce needed

q: what if private key is leaked - past messages?

q: how does client know pk~S~?

# certificates

certificate authority (CA) hierarchy: issue certificate (name~S~, pk~S~)

client (browser): trust CAs  
ensure hostname matches name~S~ (one level of subdomains);  
ensure no mix of http and https data (e.g., css/js/cookie);  
correctly display lock icon or issue warnings;  
properties as proved by Quark; ...

user: must understand UI/warnings

# what can go wrong

crypto:
[why does cryptographic software fail?](http://pdos.csail.mit.edu/papers/cryptobugs:apsys14.pdf)

compromised CAs: expiration dates, blacklist

bugs: web apps, browser

users ignore browser warnings, or confused by warnings

javascript: URLs, UTF-7 XSS, phishing attacks, ...

"reflections on trusting trust" [CACM'84]

q: how about client authentication?

# tcpcrypt

layering: application vs network vs transport

default protection against passive attackers

support for protection against active attackers

deployment concerns

[switch to Anna, Danyang, Qiao]