CPS110: Secure communication

1. CPS110: Secure communication Landon Cox March 27, 2008

2. Physical reality Alice Bob 4 basic tools of the attacker: eavesdrop, delete modify, insert, Corollary attacks: replay, identity spoofing, man-in-the-middle

3. Desired properties • Confidentiality • Only receiver can understand message • Authentication • Received message is from whom I expect • Freshness • Replay effectiveness should be limited • No denial-of-service • Attacker can’t deny me service indefinitely • Primary tool for providing these: encryption

4. Basic encryption • Encrypt(clear text, e-key) = cipher text • Decrypt(cipher text, d-key) = clear text {msg}E Encrypt E Decrypt D

5. Basic encryption • Encrypt/decrypt are inverses • Decrypt(encrypt(clear,e-key),d-key)=clear • Must have d-key to recover clear text • Given arbitrary ‹clear, cipher› pairs • Shouldn’t be able to recover d-key • Describe a bad encryption function • E.g. “add a number to each char”

6. Symmetric key encryption • Keys • E-key = d-key • (hence symmetric) • Sender and receiver know the key • Nobody else knows it • Sometimes called the “secret key” • Symmetric key algorithms are fast E S D

7. Symmetric key encryption • Like having a box with a lock • Only you and I have the key to the box • Let’s say that • I put a thumb drive in the box • Send the box to you via an untrusted carrier • When you open the box, what do you know? • I put the message there (authentication) • No one else read it (confidentiality)

8. Example • Say I’m sending grades to the registrar • I send {“B”}s-key • Can someone modify the message? • Yes, but they won’t know what the effect is

9. Example • Say I’m sending grades to the registrar • I send {“B”}s-key • How to detect a modification? • Add a checksum to the message • Random changes will invalidate the checksum • Add known text to message • Random changes will be wrong format • {“B,CS(B)”}s-key or {“grade is B”}s-key

10. Example • Say I’m sending grades to the registrar • I send {“B”}s-key • This gives us authentication/confidentiality • What is missing? • No denial-of-service • How do I mount a denial-of-service attack? • Adversary removes all of my messages • (no way to really stop this)

11. Example • Say I’m sending grades to the registrar • I send {“B”}s-key • How to share s-key in the first place? • I can’t send you the key without a private line! • Solution: use a trusted key server • I don’t believe that you are who you say you are • I will trust a key server to tell me who you are

12. Symmetric key distribution • All hosts start sharing a key with key server • Key server then • Sends out secret keys to communicate • Vouches that only the right people have those keys SA SB SA SB AB AB AB server {K-AB}K-SB {K-AB}K-SA Alice Bob

13. Public key encryption • Keys • E-key ≠ d-key • Typically, encrypt() = decrypt () = crypt () E Crypt Encrypt Decrypt D

14. Public key encryption Crypt Crypt E D D E Crypt Crypt

15. Public key encryption • Crypt(clear, e-key) = cipher1 • Crypt(cipher1, d-key) = clear • Crypt(clear, d-key) = cipher2 • Crypt(cipher2, e-key) = clear • Cipher1 ≠ cipher2

16. Public key encryption • One key is public (e.g. e-key) • One key is private (e.g. d-key) • The private key should be secret • Known only to the key-pair owner • The public key is known by all • Published in some well-known place • Both keys must be hard to guess • Even if you know other key, crypt(), many encrypted pairs

17. Use 1: authentication • Can authenticate sender • Send message {“from lpcox” {message}lpcox-private} • Anyone can read it • Only lpcox could have sent it • Anyone can verify by using lpcox-public • Why “from lpcox”? • Need to know which public key to use • Called a digital signature

18. Use 2: confidentiality • Send message to lpcox {message}lpcox-public • Anyone can send such a message • Only lpcox can read it • Why? • Everyone has access to lpcox-public • Only lpcox can decrypt with lpcox-private

19. Use 3: auth. and confident. • Send message • {“from lpcox” {message}lpcox-private}chase-public • Only chase can read it • Only lpcox can send it • Does the order of lpcox-private/chase-public matter? • “from lpcox” { {message}chase-public }lpcox-private • Yes. Everyone could know lpcox sent the message. • Though no one except chase could know the message.

20. Use 3: auth. and confident. • Send message • {“from lpcox” {message}lpcox-private}chase-public • Only chase can read it • Only lpcox can send it • Another problem? • “from lpcox” { {message}chase-public }lpcox-private • Attacker could pretend to have sent message • Decrypt using lpcox-public • Re-encrypt using villain-private

21. Public key encryption • Used a lot in practice • SSL (secure socket layer, used in https) • Ssh (secure shell) • Pgp (pretty-good-privacy secure email) • Not without its problems though

22. Problems with public key crypto • Public key algorithms are slow • How do we get around this? • Use pub keys to establish symmetric keys • aka Short-lived “session keys” • Encryption with session key is fast • SSL and ssh use session keys

23. Problems with public key crypto • What if I have to change my public key? • Must notify everyone with old key • With symmetric key server • Only have to notify server that K-AS changed • Why is this? • All pair-wise communication starts at server

24. Problems with public key crypto • What if I have to change my public key? • Must notify everyone with old key • With symmetric key server • Only have to notify server that K-AS changed • Partial solution • Keys expire after a certain amount of time • E.g. really old Netscape binaries

25. Problems with public key crypto • How to trust authenticity of public keys? • Say A wants to talk to B using public key crypto • A’s real public key is A-public • B’s real public key is B-public • Villain has two public keys: V-public1 and V-public2 • What if villain • Convinces A that B’s public key is V-public1 and • Convinces B that A’s public key is V-public2

26. Problems with public key crypto • How to trust authenticity of public keys? • {“from Alice” {message}Alice-private}Bob-public • {“from Bob” {message}Bob-private}Alice-public

27. Problems with public key crypto • How to trust authenticity of public keys? • {“from Alice” {message}Alice-private}V-public1 • {“from Alice” {message2}V-private2}Bob-public • V can recover “message.” • Why? • Why does Bob believe that Alice said “message2?” • Called the “man-in-the-middle” attack.

28. Authenticating public keys • PGP • Verify “fingerprint“ of public key • Use telephone or trusted web server • (something “out-of-band”) • SSL • Telephone isn’t scalable

29. Authenticating SSL public keys • I want to send my CCN to e-trade • No one but e-trade should see my message • E-trade wants to know it’s really me • Step 1: authenticate e-trade to you • Step 2: authenticate you to e-trade

30. Step 1: authenticating e-trade • E-trade has a public key • How do you learn this public key? • Web solution: someone else vouches for key • Often called a certification authority • E.g. verisign • E-trade sends you their public key • Public key is digitally signed by verisign • {“e-trade’s public key is Etrade-public”}verisign-private

31. Step 1: authenticating e-trade • E-trade has a public key • Decrypt using verisign’s public key • I see that verisign vouches for Etrade-public • Once talking to e-trade • Establish session key • {“e-trade’s public key is Etrade-public”}verisign-private • {“use session key K-sec”}Etrade-public

32. Step 1: authenticating e-trade • Once talking to e-trade, establish session key • Any problems with this? • How do you know verisign’s public key? • Hard-coded into Firefox/IE binary • How to trust Firefox binary? • Arrives in sealed CD package or pre-installed • Could download from the Internet • Why trust this? • At some point you have to trust something

33. Step 2: authenticate you to e-trade • E-trade must know it is talking to you • Use a password • Can be sent using session key from step 1 • Only e-trade can see password • E-trade knows message came from session key sender • E-trade decrypts to check password • {“user lpcox, password pass”}K-sec

34. Replay attack • {“charge $100 to credit card”}AET-secret • {“charge $100 to credit card”}AET-secret • {“charge $100 to credit card”}AET-secret Attacker doesn’t even have to know any secret keys! Alice’s balance = $200 Alice’s balance = $100

35. Replay attack • How to defend against? • Use a unique identifier for each request • ID ensures message is fresh • Called a “nonce“ • Client • Picks a new nonce for each request • Server • Remembers which nonces have been used • Refuses to do anything with re-used nonces • Client and server maintain state about previous requests

36. Replay attack • Can we design a stateless nonce-choosing protocol? • (assume only probabilistic freshness)

37. Stateless nonce K = shared key btw client/server Client Server 1: clientID, {“I want to request, nonce1”}K Server generatesnonce2 Client uses nonce2 2: {“Go ahead, nonce1, nonce2”}K Server marks nonce2 used 3: {“Request, nonce2”}K 4: {“Response, nonce2”}K Idea: client and server each pick part of nonce

38. Stateless nonce K = shared key btw client/server Client Server 1: clientID, {“I want to request, nonce1”}K Server generatesnonce2 Client uses nonce2 2: {“Go ahead, nonce1, nonce2”}K Server marks nonce2 used 3: {“Request, nonce2”}K 4: {“Response, nonce2”}K What if attacker replayed message 1? Can’t decrypt message 2 and get nonce2.

39. Stateless nonce K = shared key btw client/server Client Server 1: clientID, {“I want to request, nonce1”}K Server generatesnonce2 Client uses nonce2 2: {“Go ahead, nonce1, nonce2”}K Server marks nonce2 used 3: {“Request, nonce2”}K 4: {“Response, nonce2”}K What if attacker replayed message 2? Client will reject: old nonce1 won’t match new nonce1.

40. Stateless nonce K = shared key btw client/server Client Server 1: clientID, {“I want to request, nonce1”}K Server generatesnonce2 Client uses nonce2 2: {“Go ahead, nonce1, nonce2”}K Server marks nonce2 used 3: {“Request, nonce2”}K 4: {“Response, nonce2”}K What if attacker replayed message 3? Server will reject since old nonce2 unexpected

41. Stateless nonce K = shared key btw client/server Client Server 1: clientID, {“I want to request, nonce1”}K Server generatesnonce2 Client uses nonce2 2: {“Go ahead, nonce1, nonce2”}K Server marks nonce2 used 3: {“Request, nonce2”}K 4: {“Response, nonce2”}K What if attacker replayed message 4? Old nonce2 won’t match what client expects

43. Next time: general security • Access control • Buffer overflows • Hidden channels • Trojan horses • Viruses and other malware