CPS110:
Secure communication
Landon Cox
Physical reality
Alice
Bob
4 basic tools of the attacker: eavesdrop, modify, insert, delete
Corollary attacks: replay, identity spoofing, man-in-the-middle
Desired properties
1. Confidentiality
 Only receiver can understand message
2. Authentication
 Received message is from whom I expect
3. Freshness
 Replay effectiveness should be limited
4. No denial-of-service
 Attacker can’t deny me service indefinitely

Primary tool for providing these: encryption
Basic encryption
 Encrypt(clear text, e-key) = cipher text
E
Encrypt
 Decrypt(cipher text, d-key) = clear text
D
Decrypt
{msg}E
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”
Symmetric key encryption
 Keys
 E-key = d-key
 (hence symmetric)
S
E
 Sender and receiver know the key
 Nobody else knows it
 Sometimes called the “secret key”
 Symmetric key algorithms are fast
D
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?
1.I put the message there (authentication)
2.No one else read it (confidentiality)
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
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
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)
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
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
AB
server
AB
SA
SB
Alice
Bob
AB
Public key encryption
 Keys
 E-key ≠ d-key
 Typically, encrypt() = decrypt () = crypt ()
E
Crypt
D
Encrypt
Decrypt
Public key encryption
Crypt
E
D
Crypt
D
Crypt
Crypt
E
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
Public key encryption
 One key is public (e.g. e-key)
 One key is private (e.g. d-key)
1. The private key should be secret
 Known only to the key-pair owner
2. The public key is known by all
 Published in some well-known place
3. Both keys must be hard to guess
 Even if you know other key, crypt(), many encrypted pairs
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
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
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.
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
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
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
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
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
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
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
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.
Authenticating public keys
 PGP
 Verify “fingerprint“ of public key
 Use telephone or trusted web server
 (something “out-of-band”)
 SSL
 Telephone isn’t scalable
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
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
Step 1: authenticating e-trade
 E-trade has a public key
{“e-trade’s public key is Etrade-public”}verisign-private
 Decrypt using verisign’s public key
 I see that verisign vouches for Etrade-public
 Once talking to e-trade
 Establish session key
{“use session key K-sec”}Etrade-public
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
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
{“user lpcox, password pass”}K-sec
 E-trade knows message came from session key sender
 E-trade decrypts to check password
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
$100
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