1 / 35

CPS110: Secure communication

CPS110: Secure communication. Landon Cox. Physical reality. Alice. Bob. 4 basic tools of the attacker: eavesdrop,. delete. modify,. insert,. Corollary attacks: replay, identity spoofing, man-in-the-middle. Desired properties. Confidentiality Only receiver can understand message

toby
Télécharger la présentation

CPS110: Secure communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPS110: Secure communication Landon Cox

  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

More Related