Lect 7 Security Handshake and Pitfalls

V.E.S.I.T_M.C.A NishiTiku 1

Lecture 7 Security handshake pitfalls.

Network Security

V.E.S.I.T_M.C.A NishiTiku 2

So far………

Part 1: Cryptography Introduction Secret key crypto Modes of operation Hashes and message digests Public key crypto Number Theory AES and Elliptic curves And much more

V.E.S.I.T_M.C.A NishiTiku 3

So far………and more

Part 2: Authentication Overview Cryptographic protocols Authentication of people Security handshake pitfalls

V.E.S.I.T_M.C.A NishiTiku 4

…….and more

Part 3:Standards Public Key Infrastructure (PKI) Kerberos: V4 ,V5 Network security E_com security System security

V.E.S.I.T_M.C.A NishiTiku 5

Need for protocols

In most practical scenarios, the desired security goals are more complex than just “the message should be confidential” or “the data should be accompanied by an integrity check”. Often we want several security properties all at once.

Cryptographic protocols are the methods by which the toolkit of cryptographic services are implemented together as a package in order to achieve more precise and sophisticated security goals.  

These procedures are normally defined by a sequence of steps that have to be followed in a specific order, most of which consist of a message that has to be passed from one of the entities to another

V.E.S.I.T_M.C.A NishiTiku 6

Security Handshake Protocols

The following is a series of security handshake protocols.

They are presented and evaluated according to security and performance. The performance parameters are:

Number of messages, Processing power required, and Compactness of messages.

V.E.S.I.T_M.C.A NishiTiku 7

Login Protocols  Shared Secret Protocol 1:  

{================================== Alice                                                                Bob

I'm Alice                                                             > <                                                       a Challenge R f(K, R)                                                                  > ==================================}

f(K, R) : K is a shared secret between Alice and Bob. f can be either encryption or hash function.

Pitfalls: An eavesdropper could mount an off-line password-guessing

attack knowing both R and f(K,R). No mutual authentication

V.E.S.I.T_M.C.A NishiTiku 8

Protocol 2:

   {===============================Alice                                                        Bob

I'm Alice                                                     > <                                                            K{R} R                                                                 > ===============================}

K{R}  is  encryption  and not  a hash function. Pitfalls: If R is a recognizable quantity (e.g., a 32-bit random

number  padded with 32 zero bits to fill out an encryption block), then Trudy, without eavesdropping, mount a dictionary attack by sending "I'm Alice" and obtaining K{R}.

On the other hand, Alice can authenticate Bob by recogizing R ( the 32 zeros). To foil the replaying of K{R} (Trudy impersonate Bob to Alice), use a timestamp instead of zeros to fill the encryption block.

V.E.S.I.T_M.C.A NishiTiku 9

  Protocol 3 & 4Alice                                                                 Bob Protocol 3:

I'm Alice, K{timestamp}                                       >----------------------------------------------------------------- Protocol 4:  I'm Alice, timestamp, hash {K, timestamp}        >

====================================

Requires that both Alice and Bob have reasobaly synchronized clocks.

Beside saving two messages, Bob does not need to keep any volatile state (e.g., R).

Pitfalls: If Alice using the same K on multiple servers, Trudy can send

the same message to another server as Alice! Even if Alice is using K for only one server, if Trudy can reset

Bob's clock back, he can also impersonate Alice to the server.  

V.E.S.I.T_M.C.A NishiTiku 10

    One-way Public Key Note that in the above four  protocols, Trudy can impersonate

Alice if she can read Bob's database This can be avoided by using public key technology.

    Protocol 5:  

{================================ Alice                                                         Bob  

I'm Alice                                                       > <                                                                   R sign R:  [R]Alice                                          > ================================}

Pitfalls: Trudy can trick Alice into signing something she does not

know!

V.E.S.I.T_M.C.A NishiTiku 11

Protocol  6

  {================================ Alice                                                        Bob  

I'm Alice                                                     > X <                                                  {R}Alice sign X:  R = [X]Alice                                  > =================================}

Pitfalls: Trudy can trick Alice into decrypting a message sent to Alice by

someone else that he likes to read. The solution for the above two problems is to ensure that R has

a known type/structure. Use diff keys for diff purposes unless coordinated

V.E.S.I.T_M.C.A NishiTiku 12

Mutual Authentication

Shared Secret

Protocol 7:

  {=============================== Alice                                                        Bob

I'm Alice                                                     > <                                                               Rb f(K, Rb)                                                       > Ra                                                                > <                                                      f(K, Ra) ===============================}

V.E.S.I.T_M.C.A NishiTiku 13

Authentication Based on a Shared Secret Key

Two-way authentication using a challenge-response protocol.

V.E.S.I.T_M.C.A NishiTiku 14

Protocol 8 

Reduce number of messages in Protocol by putting more than one item of information into each message:

  {================================ Alice                                                        Bob

I'm Alice, Ra                                                > <                                                  Rb, f(K, Ra) f(K, Rb)                                                         > ================================}

V.E.S.I.T_M.C.A NishiTiku 15

Authentication Based on a Shared Secret Key (2)

A shortened two-way authentication protocol (pitfall-------reflection attack)

V.E.S.I.T_M.C.A NishiTiku 16

Pitfall 1:  Reflection Attack Trudy can impersonate Alice to Bob by opening a second connection to

Bob (or to another sever that share the same secret with Alice):  Session1: {=================================

Trudy                                                        Bob I'm Alice, Ra                                                >

<                                                  Rb, f(K, Ra) suspend session 1......

Session 2: {================================= Trudy                                                             Bob

I'm Alice, Rb                                                > <                                                  Rb', f(K, Rb) abort session 2....... =================================}

continue  session 1......  f(K, Rb)                                                         >

=================================}

V.E.S.I.T_M.C.A NishiTiku 17

The reflection attack

Use diff . challenges for two diff. runs Use diff . challenges for the initiator and the responder e;g use odd & even nos.No identical things to b allowed by the two parties

Authentication Based on a Shared Secret Key (3)

V.E.S.I.T_M.C.A NishiTiku 18

Possible fix: Add your name to the encrypted quantity:

  {================================

Alice                                                        Bob I'm Alice, Ra                                                >

<                                          Rb, f(K, Bob|Ra) f(K, Alice|Rb)                                                > ================================}  

Why Protocol 7 does not suffer from the reflection attack? It follows a good security principle: 

The initiator should be the first to prove its identity.

V.E.S.I.T_M.C.A NishiTiku 19

Pitfall 2:  Passwod guessing Trudy mount an off-line password guessing attack:    

{========================================

Trudy                                                                 Bob I'm Alice, Ra                                                          >

<                                                            Rb, f(K, Ra) ......... suspend session and use: Ra, and f(K,Ra) to guess K. =======================================} Protocol 7 does not suffer from such attack (though Trudy can impersonate Bob to mount such attack, but it is much more difficult to impersonate Bob than to impersonate Alice).

V.E.S.I.T_M.C.A NishiTiku 20

Protocol 9 Protocol 7 is very good, since it does not

suffer from Reflection and Password attacks. We can improve it by reducing the number of messages to four instead of five as follows:  

{=============================== Alice                                                        Bob

I'm Alice                                                     > <                                                               Rb f(K, Rb), Ra                                                > <                                                      f(K, Ra) ===============================}

V.E.S.I.T_M.C.A NishiTiku 21

Protocol 10 

We can use time stamps to reduce the number of messages to two:

{================================= Alice                                                           Bob

I'm Alice, f(K, timestamp)                            > <                                         f(K, timestamp++) =================================}

V.E.S.I.T_M.C.A NishiTiku 22

Two-way Public Key Protocol 11: {================================

Alice                                                          Bob   I'm Alice , Ra                                               >

<                                                 Rb, signed Ra signed Rb                                                        > =================================}  

Protocol 12:   {===============================

Alice                                                        Bob  

I'm Alice,  {Ra}Bob                                      > X <                                            Ra, {Rb}Alice

Rb                                                               > ===============================}

V.E.S.I.T_M.C.A NishiTiku 23

Establishing a Shared Key:The Diffie -Hellman Key Exchange

The Diffie-Hellman key exchange.

V.E.S.I.T_M.C.A NishiTiku 24

Establishing a Shared Key:The Diffie-Hellman Key Exchange

The bucket brigade or man-in-the-middle attack

Pitfall ?

V.E.S.I.T_M.C.A NishiTiku 25

Key Establishment and Authentication with KDCA simple protocol:

Problem: Potential delayed key delivery to Bob. (besides others)

Alic

e

Bo

bKDC

Alice, Bob

KA{Bob, KAB}KB{Alice, KAB}

V.E.S.I.T_M.C.A NishiTiku 26

Another simple protocol:

Problems:No freshness guarantee for KABAlice & Bob need to authenticate

Alic

e

Bo

bKDC

Alice, Bob

KA{Bob, KAB}, ticketB

where ticketB= KB{Alice, KAB}

Alice, ticketB

V.E.S.I.T_M.C.A NishiTiku 27

Needham-Schroeder ProtocolA

lice

Bo

b

KDC

N1, Alice, Bob

KA{N1, Bob, KAB, ticketB} where ticketB= KB{KAB, Alice}

ticketB, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

V.E.S.I.T_M.C.A NishiTiku 28

Needham-Schroeder Protocol

N1: for authenticating KDC & freshness of KAB.

Ticket is double-encrypted. (unnecessary)

N2, N3: for key confirmation, mutual authentication

V.E.S.I.T_M.C.A NishiTiku 29

Messages should be integrity protected. Otherwise, cut-and-paste reflection attacks possible:

Tru

dy

Bo

b

replay ticketB, KAB{N2}

KAB{N2-1, N3}

Tru

dy

Bo

b

ticketB, KAB{N3}

KAB{N3-1, N4}

KAB{N3-1}

V.E.S.I.T_M.C.A NishiTiku 30

Needham-Schroeder Protocol

Why are the challenges N2, N3 encrypted?

Against reflection attacks; e.g., with CBC encryption. (any other solutions?)

Problem: Bob doesn’t have freshness guarantee for KAB (i.e., can’t detect replays).

V.E.S.I.T_M.C.A NishiTiku 31

Expanded Needham-Schroeder Protocol

Alic

eB

obKDC

N1, Alice, Bob, KB{NB}

KA{N1, Bob, KAB, ticketB} where ticketB= KB{KAB, Alice, NB}

ticketB, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

hello

KB{NB}

V.E.S.I.T_M.C.A NishiTiku 32

Mutual authentication using public-key cryptography

Authentication Using Public-Key Cryptography

V.E.S.I.T_M.C.A NishiTiku 33

Case study