CPS110: Secure communication Landon Cox. Physical reality Bob Alice 4 basic tools of the attacker:...

CPS110: Secure communication

Landon Cox

Physical reality

BobAlice

4 basic tools of the attacker: eavesdrop, modify, insert, deleteCorollary 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

Decrypt(cipher text, d-key) = clear text

EncryptEncrypt

DecryptDecrypt

E

D

{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)

Sender and receiver know the key Nobody else knows it Sometimes called the “secret key”

Symmetric key algorithms are fast

E DS

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


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


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


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

SA SB

server

Alice Bob

AB

ABAB{K-AB} K-SA

{K-AB}K-SB

Public key encryption

Keys E-key ≠ d-key Typically, encrypt() = decrypt () =

crypt ()E D

EncryptEncrypt DecryptDecryptCryptCrypt


E

D

CryptCrypt

CryptCrypt

D

E

CryptCrypt

CryptCrypt


Crypt(clear, e-key) = cipher1 Crypt(cipher1, d-key) = clear Crypt(clear, d-key) = cipher2 Crypt(cipher2, e-key) = clear Cipher1 ≠ cipher2


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


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


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


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


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


How to trust authenticity of public keys?

{“from Alice” {message}Alice-

private}Bob-public

{“from Bob” {message}Bob-private}Alice-

public


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


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


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

E-trade knows message came from session key sender

E-trade decrypts to check password

{“user lpcox, password pass”}K-sec

Replay attack

{“charge $100 to credit card”}AET-secret


Alice’s balance = $100


Alice’s balance = $200

Attacker doesn’t even have to know

any secret keys!

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

CPS110: Secure communication Landon Cox. Physical reality Bob Alice 4 basic tools of the attacker:...

Documents

Transcript of CPS110: Secure communication Landon Cox. Physical reality Bob Alice 4 basic tools of the attacker:...