The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.

Security Handshake Pitfalls. Client Server (K R c, S c) (K s, S s) Concerns: 1. Some public key systems can only do signatures, not reversible ...

Discover the best professional documents and content resources in AnyFlip Document Base.
Search
Published by , 2017-06-16 20:00:03

Security Handshake Pitfalls - John Franco

Security Handshake Pitfalls. Client Server (K R c, S c) (K s, S s) Concerns: 1. Some public key systems can only do signatures, not reversible ...

Security Hand

dshake Pitfalls

Security Hand

Client Hell
(K)

dshake Pitfalls

Server
lo (K)

Security Hand

Client Challe
(K)

dshake Pitfalls

enge R Server
(K)

Security Hand

Client f(K, 
(K)

dshake Pitfalls

Server
 R) (K)

Security Hand

Client f(K, 
(K)

Problems:
   1. Authentication is not mutual ­ on
       Anyone can send the challenge R

   

dshake Pitfalls

Server
 R) (K)

nly Server authenticates Client
R.

Security Hand

Client f(K, 
(K)

Problems:

   1. Authentication is not mutual ­ on
       Anyone can send the challenge R

   2. Connection can be hijacked – if 
       cryptographic protection and atta
   

dshake Pitfalls

Server
 R) (K)

nly Server authenticates Client
R.
 the rest of the transaction is without
acker makes packets with Client addr

Security Hand

Client f(K, 
(K)

Problems:
   1. Authentication is not mutual ­ on
       Anyone can send the challenge R

   2. Connection can be hijacked – if 
       cryptographic protection and atta
   3. Off­line password guessing attac
       because both R and f(K,R) are ob

   

dshake Pitfalls

Server
 R) (K)

nly Server authenticates Client
R.
 the rest of the transaction is without
acker makes packets with Client addr
ck ­ if K is derived from password
bservable.

Security Hand

Client f(K, 
(K)

Problems:

   1. Authentication is not mutual ­ on
       Anyone can send the challenge R

   2. Connection can be hijacked – if 
       cryptographic protection and atta
   3. Off­line password guessing attac
       because both R and f(K,R) are ob

   4. Someone reading the Server data
       later or to another server that the

dshake Pitfalls

Server
 R) (K)

nly Server authenticates Client
R.
 the rest of the transaction is without
acker makes packets with Client addr
ck ­ if K is derived from password
bservable.
abase may be able to impersonate Client
e client uses

Security Hand

Client Hello
(K)

dshake Pitfalls

Server
o (K)

Security Hand

Client K{R
(K)

dshake Pitfalls

Server
R} (K)

Security Hand

Client R
(K)

dshake Pitfalls

Server
(K)

Security Hand

Client R
(K)

Concerns:
   1. Requires reversible cryptograph

dshake Pitfalls

Server
(K)

hy ­ no hash

Security Hand

Client R
(K)

Concerns:

   1. Requires reversible cryptograph
   2. No need to eavesdrop if R is rec
       and gets back K{R}, if K derive
       of Ks for a dictionary attack.

dshake Pitfalls

Server
(K)

hy ­ no hash
cognizable ­ Attacker says hello 
ed from password can generate lots 

Security Hand

Client R
(K)

Concerns:

   1. Requires reversible cryptograph
   2. No need to eavesdrop if R is rec
       and gets back K{R}, if K derive
       of Ks for a dictionary attack.

   3. If R is recognizable by Client, t
       but only if life of R is short, oth
       attacker

dshake Pitfalls

Server
(K)

hy ­ no hash
cognizable ­ Attacker says hello 
ed from password can generate lots 
then protocol authenticates Server
herwise K{R} can be replayed by 

Security Hand

Client Hello, K
(K)

dshake Pitfalls

K{time} Server
(K)

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for existing prot.

Security Hand

Client Hello, K
(K)

Advantage:

   1. One direction, more efficient ­ i
   2. The server does not need to kee

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i
   2. The server does not need to kee

Problems:
   1. Attacker can use K{time} to im

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

mpersonate Client ­ within acc clock skew 

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i
   2. The server does not need to kee

Problems:
   1. Attacker can use K{time} to im
       But can be foiled if Server reme

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

mpersonate Client ­ within acc clock skew
embers all timestamps sent. 

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i
   2. The server does not need to kee

Problems:
   1. Attacker can use K{time} to im
       But can be foiled if Server reme
   2. If multiple Servers, same K, K{
       

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

mpersonate Client ­ within acc clock skew
embers all timestamps sent.
{time} on one can work on others

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i
   2. The server does not need to kee

Problems:
   1. Attacker can use K{time} to im
       But can be foiled if Server reme
   2. If multiple Servers, same K, K{
       Can be foiled by sending K{tim

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

mpersonate Client ­ within acc clock skew
embers all timestamps sent.
{time} on one can work on others
me | server} 

Security Hand

Client Hello, K
(K)

Advantage:
   1. One direction, more efficient ­ i
   2. The server does not need to kee

Problems:
   1. Attacker can use K{time} to im
       But can be foiled if Server reme
   2. If multiple Servers, same K, K{
       Can be foiled by sending K{tim
   3. Vulnerable to attacker setting ti

dshake Pitfalls

K{time} Server
(K)

is drop­in replacement for cleartext prot.
ep volatile state (such as R)

mpersonate Client ­ within acc clock skew
embers all timestamps sent.
{time} on one can work on others
me | server} 
ime back on Server!!

Security Hand

Client Hello, K
(K)

Problems:
   4. Setting time requires a security 
       (that is, not depending on time) 

        of machines are too far apart – 

dshake Pitfalls

K{time} Server
(K)

 handshake ­ better make it chllng/resp
 or else there is a problem if clocks 

 the negotiation will fail.

Security Hand

Client Hello, time, h
(K)

dshake Pitfalls

hash{K,time} Server
(K)

Security Hand

Client Hello, time, h
(K)

Advantage:

   1. Otherwise, if time not sent, for S
       different acceptable times befor

dshake Pitfalls

hash{K,time} Server
(K)

Server to check hash, must try lots of 
re one matches the hash


Click to View FlipBook Version