Protocol

Shuai Wang
Protocol
• Human protocols ¾ the rules followed in human
interactions
• Example: Asking a question in class
• Networking protocols ¾ rules followed in
networked communication systems
• Examples: HTTP, FTP, etc.
• Security protocol ¾ the (communication) rules
followed in a security application
• Examples: SSH, SSL, IPSec, Kerberos, etc.
Protocols
• Protocol flaws can be very subtle
• Several well-known security protocols have
significant flaws
• Including WEP, GSM, and IPSec
• Implementation errors can also occur
• Heartbleed
• Not easy to get protocols right…
Ideal Security Protocol
• Must satisfy security requirements
• Requirements need to be precise
• Efficient
• Minimize computational requirement
• Minimize bandwidth usage, delays…
• Robust
• Works when attacker tries to break it
• Works if environment changes (slightly)
• Easy to implement, easy to use, flexible…
• Difficult to satisfy all of these!
Authentication Protocols

Part 3 ¾ Protocols
5
Authentication
• Alice must prove her identity to Bob
• Alice and Bob can be humans or computers
• May also require Bob to prove he’s Bob (mutual
authentication)
• Probably need to establish a session key
• May have other requirements, such as
• Public keys, symmetric keys, hash functions, …
• Anonymity, plausible deniability, perfect forward
secrecy, etc.

Part 3 ¾ Protocols
6
Authentication
• Authentication on a stand-alone computer is
relatively simple
• For example, hash a password with a salt
• Authentication over a network is challenging
• Attacker can passively observe messages
• Attacker can replay messages
• Active attacks possible (insert, delete, change)

Part 3 ¾ Protocols
7
Simple Authentication
“I’m Alice”

Prove it

My password is “frank”

Alice Bob

• Simple and may be OK for standalone system

• But highly insecure for networked system
• Subject to a replay attack (next 2 slides)
• Also, Bob must know Alice’s password

Part 3 ¾ Protocols
8
Authentication Attack
“I’m Alice”

Prove it

My password is “frank”

Alice Bob

Trudy

Part 3 ¾ Protocols
9
Authentication Attack

“I’m Alice”

Prove it

My password is “frank”
Trudy Bob

• This is an example of a replay attack

• How can we prevent a replay?
Part 3 ¾ Protocols
10
Simple Authentication

I’m Alice, my password is “frank”

Alice Bob

• More efficient, but…

• … same problem as previous version
Part 3 ¾ Protocols
11
Better Authentication
“I’m Alice”

Prove it

h(Alice’s password)

Alice Bob

• This approach hides Alice’s password

• From both Bob and Trudy
• But still subject to replay attack

Part 3 ¾ Protocols
12
Challenge-Response
• To prevent replay, use challenge-response
• Goal is to ensure “freshness”
• Suppose Bob wants to authenticate Alice
• Challenge sent from Bob to Alice
• Challenge is chosen so that…
• Replay is not possible
• Only Alice can provide the correct response
• Bob can verify the response
Nonce
• To ensure freshness, can employ a nonce
• Nonce == number used once
• What to use for nonces?
• That is, what is the challenge?
• What should Alice do with the nonce?
• That is, how to compute the response?
• How can Bob verify the response?

Part 3 ¾ Protocols
14
Challenge-Response
“I’m Alice”

Nonce

h(Alice’s password, Nonce)

Alice Bob

q Nonce is the challenge

q The hash is the response
q Nonce prevents replay (ensures freshness)
q Password is something Alice knows
q Note: Bob must know Alice’s pwd to verify
qCan we do better?
Symmetric Key Notation
• Encrypt plaintext P with key K
C = E(P,K)
• Decrypt ciphertext C with key K
P = D(C,K)
• Here, we are concerned with attacks on protocols,
not attacks on cryptography
• So, we assume crypto algorithms are secure

Part 3 ¾ Protocols
16
Authentication: Symmetric Key
• Alice and Bob share symmetric key K
• Key K known only to Alice and Bob
• Authenticate by proving knowledge of shared
symmetric key
• How to accomplish this?
• Cannot reveal key, must not allow replay (or other)
attack, must be verifiable, …

Part 3 ¾ Protocols
17
Authenticate Alice Using Symmetric
Key
“I’m Alice”

E(R,K)
Alice, K Bob, K

q Secure method for Bob to authenticate Alice

q But, Alice does not authenticate Bob

q So, can we achieve mutual authentication?

Part 3 ¾ Protocols
18
Mutual Authentication?

“I’m Alice”, R

E(R,K)

E(R,K)
Alice, K Bob, K

• What’s wrong with this picture?

Part 3 ¾ Protocols
19
Mutual Authentication
• Since we have a secure one-way authentication
protocol…
• The obvious thing to do is to use the protocol twice
• Once for Bob to authenticate Alice
• Once for Alice to authenticate Bob
• This has got to work…

Part 3 ¾ Protocols
20
Mutual Authentication
“I’m Alice”, RA

RB, E(RA, K)

E(RB, K)
Alice, K Bob, K

• This provides mutual authentication…

• …or does it? Subject to reflection attack
• Next slide

Part 3 ¾ Protocols
21
Mutual Authentication Attack
1. “I’m Alice”, RA

2. RB, E(RA, K)

5. E(RB, K)
Trudy Bob, K

3. “I’m Alice”, RB

4. RC, E(RB, K)

Trudy Bob, K

Part 3 ¾ Protocols
22
Mutual Authentication
• Our one-way authentication protocol is not
secure for mutual authentication
• Protocols are subtle!
• In this case, “obvious” solution is not secure
• Also, if assumptions or environment change,
protocol may not be secure
• This is a common source of security failure
• For example, Internet protocols

Part 3 ¾ Protocols
23
Symmetric Key Mutual
Authentication
“I’m Alice”, RA

RB, E(“Bob”,RA,K)

E(“Alice”,RB,K)

Alice, K Bob, K

• Do these “insignificant” changes help?

• Yes!
Part 3 ¾ Protocols
24
Public Key Notation
• Encrypt M with Alice’s public key: {M}Alice
• Sign M with Alice’s private key: [M]Alice
• Then
• [{M}Alice ]Alice = M
• {[M]Alice }Alice = M
• Anybody can use Alice’s public key
• Only Alice can use her private key

Part 3 ¾ Protocols
25
Public Key Authentication

“I’m Alice”

{R}Alice

Alice Bob

• Is this secure?
• But usually use two key pairs (why?)

Part 3 ¾ Protocols
26
Public Key Authentication

“I’m Alice”

[R]Alice

Alice Bob

• Is this secure?
• But usually use two key pairs (why?)

Part 3 ¾ Protocols
27
Public Keys
• Generally, a bad idea to use the same key pair for
encryption and signing
• Instead, should have…
• …one key pair for encryption/decryption and
signing/verifying signatures…
• …and a different key pair for authentication

Part 3 ¾ Protocols
28
Session Key
• Usually, a session key is required
• A symmetric key for current session
• Used for confidentiality and/or integrity
• Ideal case
• When authentication completed, Alice and Bob share a
session key
• Trudy cannot break the authentication…
• …and Trudy cannot determine the session key

Part 3 ¾ Protocols
29
Authentication & Session Key
“I’m Alice”, R

{R, K}Alice

{R, K}Bob
Alice Bob

• Is this secure?
• Alice is authenticated and session key is secure
• Alice’s “nonce”, R, useless to authenticate Bob
• No mutual authentication
Public Key Authentication and
Session Key
“I’m Alice”, R

[R, K]Bob

[R, K]Alice
Alice Bob

• Is this secure?
• Mutual authentication (good), but…
• … session key is not protected (very bad)

Part 3 ¾ Protocols
31
Public Key Authentication and
Session Key
“I’m Alice”, R

[{R, K}Alice]Bob

[{R, K}Bob]Alice
Alice Bob

• Is this secure?
• should be OK
• Anyone can see {R, K}Alice and {R, K}Bob
Perfect Forward Secrecy
• Consider this “issue”…
• Alice encrypts message with shared key K and sends
ciphertext to Bob
• Trudy records ciphertext and later attacks Alice’s (or
Bob’s) computer to recover K
• Then Trudy decrypts recorded messages
• Perfect forward secrecy (PFS): Trudy cannot later
decrypt recorded ciphertext
• Even if Trudy gets key K or other secret(s)
• Is PFS possible?
Perfect Forward Secrecy
• Suppose Alice and Bob share key K
• For perfect forward secrecy, Alice and Bob cannot
use K to encrypt
• Instead they must use a session key KS and forget
it after it’s used
• Can Alice and Bob agree on session key KS in a way
that provides PFS?

Part 3 ¾ Protocols
42
Naïve Session Key Protocol

E(KS, K)

E(messages, KS)

Alice, K Bob, K

• Trudy could record E(KS, K)

• If Trudy later gets K then she can get KS
• Then Trudy can decrypt recorded messages
• No perfect forward secrecy in this case
Part 3 ¾ Protocols
43
 Perfect Forward Secrecy

Bob, b

In case you already forgot…

Diffie–Hellman -- An Example

Bob, b
Perfect Forward Secrecy
• We can use Diffie-Hellman for PFS
• Recall: public g and p

ga mod p

gb mod p

Alice, a Bob, b

Part 3 ¾ Protocols
46
 Perfect Forward Secrecy
E(ga mod p, K)

E(gb mod p, K)

Alice: K, a Bob: K, b

• Session key KS = gab mod p

• Alice forgets a, Bob forgets b
• Neither Alice nor Bob can later recover KS

Part 3 ¾ Protocols
47
Mutual Authentication, Session
Key and PFS
“I’m Alice”, RA

RB, [{RA, gb mod p}Alice]Bob

[{RB, ga mod p}Bob]Alice

Alice Bob

q Session key is K = gab mod p

q Alice forgets a and Bob forgets b
q If Trudy later gets Bob’s and Alice’s secrets, she
cannot recover session key K
Real-World Protocols
• Some real secure protocols
• SSH ¾ relatively simple & useful protocol
• Mutual authentication, session key and PFS
• SSL ¾ practical security on the Web
• IPSec ¾ security at the IP layer
• WEP ¾ “Swiss cheese” of security protocols
• GSM ¾ mobile phone (in)security