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
