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
36
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
37
Perfect Forward Secrecy
Bob, b
In case you already forgot…
Diffie–Hellman -- An Example
Bob, b
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
40
But … Diffie-Hellman is subject to man-in-the-middle
attack, isn’t it?
We don’t worry about that, why? Authentication!
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
Timestamps
• A timestamp T is derived from current time
• Timestamps can be used to prevent replay attack
• A challenge that both sides know in advance
• “Time” is a security-critical parameter (bad)
• Sometimes timestamp is used to as the seed for random numbers
• More importantly, clocks not same and/or network delays, so
must allow for clock skew ¾ creates risk of replay
• During the time-skew window, there is still a room for reply attack
for Attacker to impersonate Alice.
• How much clock skew is enough?
• Too much? Too little?
• Real world: 5 mins….
Part 3 ¾ Protocols
43
Public Key Authentication with
Timestamp T
“I’m Alice”, {[T, K]Alice}Bob
{[T +1, K]Bob}Alice
Alice Bob
Public Key Authentication with
Timestamp T
“I’m Alice”, {[T, K]Alice}Bob
{[T, K]Bob}Alice
Alice Bob
q Secure mutual authentication?
q Session key secure?
q Seems to be OK
Part 3 ¾ Protocols
45
Public Key Authentication with
Timestamp T
“I’m Alice”, [{T, K}Bob]Alice
[{T, K}Alice]Bob
Alice Bob
q Secure authentication and session key?
q Trudy can use Alice’s public key to find
{T, K}Bob and then…
Part 3 ¾ Protocols
46
Public Key Authentication with
Timestamp T
“I’m Trudy”, [{T, K}Bob]Trudy
[{T, K}Trudy]Bob
Trudy Bob
q Trudy obtains Alice-Bob session key K
q Note: Trudy must act within clock skew
Part 3 ¾ Protocols
47
Public Key Authentication with
Timestamp T
“I’m Alice”, [{T, K}Bob]Alice
[{T}Alice]Bob
Alice Bob
q Can we fix the previous flaw?
q No session key is needed in the second round!
Part 3 ¾ Protocols
48
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
• GSM ¾ mobile phone (in)security
Secure Shell (SSH)
Part 3 ¾ Protocols
50
SSH
• Creates a “secure tunnel”
• Insecure command sent thru SSH “tunnel” are then
secure
• SSH is a relatively simple protocol
Part 3 ¾ Protocols
51
SSH
• SSH authentication can be based on:
• Public keys, or
• Digital certificates, or
• Passwords
• Here, we consider certificate mode
• We consider slightly simplified SSH…
Part 3 ¾ Protocols
52
Simplified SSH
Alice, CP, RA
CS, RB
ga mod p
gb mod p, certificateB, SB
Alice E(Alice, certificateA, SA, K) Bob
• CP = “crypto proposed”, and CS = “crypto selected”
• H = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gb mod p,gab mod p)
• SB = [H]Bob
• SA = [H, Alice, certificateA]Alice
• K = gab mod p
Part 3 ¾ Protocols
53
MiM Attack on SSH?
Alice, RA Alice, RA
RB RB
ga mod p gt mod p
gt mod p, certB, SB gb mod p, certB, SB
Alice Trudy E(Alice,certA,SA,K) Bob
E(Alice,certA,SA,K)
• Where does this attack fail?
• Alice computes
Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)
• But Bob signs
Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)
Part 3 ¾ Protocols
54
Secure Socket Layer
Part 3 ¾ Protocols
55
Socket layer
• “Socket layer”
lives between Socket application
User
application and “layer”
transport layers transport
OS
• SSL usually
network
between HTTP
and TCP
link
NIC
physical
Part 3 ¾ Protocols
56
What is SSL?
• SSL is the protocol used for majority of secure
Internet transactions today
• For example, if you want to buy a book at
amazon.com…
• You want to be sure you are dealing with Amazon
(authentication)
• Your credit card information must be protected in
transit (confidentiality and/or integrity)
• No mutual authentication.
• Use password, instead.
Simplified SSL Protocol
Can we talk?, cipher list, RA
certificate, cipher, RB
{S}Bob, E(h(msgs,CLNT,K),K)
h(msgs,SRVR,K)
Alice Data protected with key K Bob
• S is the so-called pre-master secret
• K = h(S,RA,RB)
• “msgs” means all previous messages
• CLNT and SRVR are constants
Implementation considerations
• 6 “keys” derived from K = h(S,RA,RB)
• 2 encryption keys: client and server
• 2 integrity keys: client and server
• 2 IVs: client and server
• Why different keys in each direction?
• Implementation purpose
• Alice authenticates Bob, not vice-versa
• How does client authenticate server?
• Why would server not authenticate client?
