Security Handshake Pitfalls - John Franco

Security Hand

Client f(K,
(K)

Reflection Attack can't succeed wit

  

Reason: Initiator always is first to pr
   

dshake Pitfalls

,Rc) Server
(K)

th this protocol:
rove its identity!!

Security Hand

Client Hello, encry
(Kc, Sc)

Public key mutual authentication:

  

dshake Pitfalls

ypt{Rc}Ks Server
(Ks, Ss)

Security Hand

Client Rc, encryp
(Kc, Sc)

Public key mutual authentication:

  

dshake Pitfalls

pt{Rs}Kc Server
(Ks, Ss)

Security Hand

Client Rs
(Kc, Sc)

Public key mutual authentication:

  

dshake Pitfalls

Server
(Ks, Ss)

Security Hand

Client Rs
(Kc, Sc)

Public key mutual authentication:

  

   Variant: Rs and Rc are signed by the

dshake Pitfalls

Server
(Ks, Ss)

eir respective parties

Security Hand

Client Rs
(Kc, Sc)

Public key mutual authentication:

  

   Variant: Rs and Rc are signed by the

   How does the client's workstation r
   all the client knows is a password? 
   from passwords, e.g. RSA

   Use a directory service ­  client wo
      1. Client's private key which is en
      2. Certificate for Server's public k

dshake Pitfalls

Server
(Ks, Ss)

eir respective parties
retrieve the client's private key when
 – usually keys cannot be recovered

orkstation retrieves the following:  
ncrypted with Client's password
key, signed with Client's private key

Security Hand

Client  hell
(K)    R

  K{

Establish a session key (secret key 

    After authentication R and K{R} is
    Can't use K{R} as session key ­ so
    Can't use K{R+1} as session key ­
    session key K{R+1} impersonates

    and sends R+1 as the challenge to 
    So attacker can decrypt previous tr
    

dshake Pitfalls

lo Server
(K)

{R}

 system):
s known by Client and Server
omeone may have seen it
­ Attacker seeing transmission using
s Server's network address to Client
 Client.  Client responds with K{R+1}.
ransmission.

Security Hand

Client  hell
(K)    R

  K{

Establish a session key (secret key 

    After authentication R and K{R} is
    Can't use K{R} as session key ­ so
    Can't use K{R+1} as session key ­
    session key K{R+1} impersonates

    and sends R+1 as the challenge to 
    So attacker can decrypt previous tr
    Session key should not be an encry
    extracted later.

dshake Pitfalls

lo Server
(K)

{R}

 system):
s known by Client and Server
omeone may have seen it
­ Attacker seeing transmission using
s Server's network address to Client
 Client.  Client responds with K{R+1}.
ransmission.
ypted value which can be predicted or

Security Hand

Client g, p, [ga mod p]S
(Kc, Sc)

Establish a session key (public key 

    Authenticate with Diffie­Hellman 
    Use gab mod p as the session key.
    Attempt to get root access on eithe
    needed to generate session key to d
    never recorded and the session key

    sent across, it could have been reco
    root access.  If session keys get sen
    attacker can send an R while imper

dshake Pitfalls

Sc, [gb mod p]Ss Server
(Ks, Ss)

 system):
 exchange, RSA signing.

er machine does not reveal the a and b
decrypt recorded messages ­ they were
y was tossed.  If session key had been
orded and decrypted after getting 
nt across without being signed, 
rsonating Client's network address.

Security Hand

Request B

Client A Ka{KAB} K
(Ka) (

KDC operation,  in principle

  

   

dshake Pitfalls

KDC Kb{KAB} Client B
(Ks) (Kb)

Makes KAB

Security Hand

Client A Na, Req B K
(Ka) (

Needham­Schroeder authentication a

   Client A sends a nonce Na and request to

dshake Pitfalls

KDC Client B
(Ks) (Kb)

and session key (secret key system):

o connect to B to the KDC

Security Hand

Client A Kab
(Ka) K
(

Needham­Schroeder authentication a

   Client A sends a nonce Na and request to
   KDC makes a session key Kab for the con

dshake Pitfalls

b, Na Client B
KDC (Kb)
(Ks)

and session key (secret key system):

o connect to B to the KDC

nnection

Security Hand

Client A Ka{Na, B, Kab, T} Kab
(Ka) T=Kb{Kab, A} K
(

Needham­Schroeder authentication a

   Client A sends a nonce Na and request to
   KDC makes a session key Kab for the con
   KDC encrypts Na, B, a ticket T with key 
   To make T the KDC encrypts the session

dshake Pitfalls

b, Na Client B
KDC (Kb)
(Ks)

and session key (secret key system):

o connect to B to the KDC

nnection

 Ka and sends all to A.
n key and A with with Kb. 

Security Hand

Client A K
(Ka) (

T, Kab{Nb}
Needham­Schroeder authentication a

   Client A sends a nonce Na and request to
   KDC makes a session key Kab for the con
   KDC encrypts Na, B, a ticket T with key 
   To make T the KDC encrypts the session

   Client A encrypts a nonce Nb with the se

dshake Pitfalls

KDC Client B
(Ks) (Kb)

and session key (secret key system):

o connect to B to the KDC

nnection

 Ka and sends all to A.
n key and A with with Kb. 
ession key Kab, sends with ticket to B

Security Hand

Client A K
(Ka) (

Needham­Schroeder authentication a

   Client A sends a nonce Na and request to
   KDC makes a session key Kab for the con
   KDC encrypts Na, B, a ticket T with key 
   To make T the KDC encrypts the session

   Client A encrypts a nonce Nb with the se
   Client B subtracts 1 from nonce, make ne
   sends encrypted message to Client A. 

dshake Pitfalls

KDC Client B
(Ks) (Kb)

Kab{Nb­1,Nc}
and session key (secret key system):

o connect to B to the KDC

nnection

 Ka and sends all to A.

n key and A with with Kb. 
ession key Kab, sends with ticket to B
ew nonce, encrypts with session key

Security Hand

Client A K
(Ka) (

Kab{Nc­1}
Needham­Schroeder authentication a

   Client A sends a nonce Na and request to
   KDC makes a session key Kab for the con
   KDC encrypts Na, B, a ticket T with key 
   To make T the KDC encrypts the session

   Client A encrypts a nonce Nb with the se
   Client B subtracts 1 from nonce, make ne

   sends encrypted message to Client A. 
   Client A subtracts 1 from nonce, encrypt

dshake Pitfalls

KDC Client B
(Ks) (Kb)

and session key (secret key system):

o connect to B to the KDC
nnection
 Ka and sends all to A.
n key and A with with Kb. 
ession key Kab, sends with ticket to B
ew nonce, encrypts with session key

ts with session key, sends to Client B

Security Hand

Client A Na, Req B K
(Ka) (

Needham­Schroeder: What is going o
   Nonce Na protects against: attacker, h
   from Client A requesting it, waits for
   the KDC and immediately plays back
   session key encrypted with Client B's

   impersonate Client B to Client A.

       Ka{Na, B, Kab, T} Att
T=Kb{Kab, A}

dshake Pitfalls

KDC Client B
(Ks) (Kb)

on?

having stolen previous Kb and message 
r Client A to request a session key from
k KDC's reply to Client A,  and gets the
s old Kb, which it knows, so it can 

tacker need not know key of Client A

Security Hand

Client A Ka{Na, B, Kab, T} K
(Ka) T=Kb{Kab, A} (

Needham­Schroeder: What is going o
   With the identity of Client B inserted

   

   Nonce is returned to check authentici

   

   Double encryption of session key (Kb
   not considered necessary

dshake Pitfalls

KDC Client B
(Ks) (Kb)

on?
d, attacker id substitution is detected by A

ity of KDC 

b for ticket, then Ka on the ticket) is 

Security Hand

Client A K
(Ka) (

Needham­SchrTo,e Kdeabr{:N Wb}hat is going o
   Client A knows that only someone w

   and get the session key.  With session

dshake Pitfalls

KDC Client B
(Ks) (Kb)

on?

with Client B's key Kb can decrypt
n key, Client B decrypts Nb.

Security Hand

Client A K
(Ka) (

Needham­Schroeder: Vulnerability

   If attacker finds out Client A's key Ka, th
   to the KDC.  But if Client A changes Ka,
   be able to impersonate.  But the ticket to 
   such a change.  Attacker can save Ka{Na,
   it knows the old Ka key, then decrypt to g
   to Client B to convince it that it is connec

   

dshake Pitfalls

KDC Client B
(Ks) (Kb)

hen attacker can impersonate itself

, then we require attacker not to

 Client B remains valid after a 
, B, Kab, Kb{Kab, A}} until
get Kb{Kab, A} and send that
cting with Client A using Kab.

Security Hand

Client A K
(Ka) (

Needham­Schroeder: Vulnerability

   If attacker finds out Client A's key Ka, th
   to the KDC.  But if Client A changes Ka,
   be able to impersonate.  But the ticket to 
   such a change.  Attacker can save Ka{Na,
   it knows the old Ka key, then decrypt to g
   to Client B to convince it that it is connec

   Fixed by Client A connecting to Client B
   and using that nonce throughout the exch

dshake Pitfalls

KDC Client B
(Ks) (Kb)

hen attacker can impersonate itself

, then we require attacker not to

 Client B remains valid after a 
, B, Kab, Kb{Kab, A}} until
get Kb{Kab, A} and send that
cting with Client A using Kab
B requesting an encrypted nonce
hange.   

Security Hand

Client A K
(Ka) (
Nc, A, B, Ka
Otway­Rees:

  

   

dshake Pitfalls

KDC Client B
(Ks) (Kb)
a{Na, Nc, A, B}

Security Hand

Client A K
(Ka) (

Otway­Rees:

  

   If Nc is not the same in both message

dshake Pitfalls

KDC Ka{Na, Nc, A, B}, Client B
(Ks) Kb{Nb, Nc, A, B} (Kb)

es, KDC will stop the transaction.

Security Hand

Client A K
(Ka) K
(
Otway­Rees:

  

   

dshake Pitfalls

Kab Client B
KDC (Kb)
(Ks)

Security Hand

Client A K
(Ka) K
(

Otway­Rees:

  

   Client B is reassured that it is talking
   using Kb and sent back encrypted.

dshake Pitfalls

Kab Nc, Ka{Na, Kab}, Client B
KDC Kb{Nb, Kab} (Kb)
(Ks)

g to KDC since its nonce was extracted