Network Security

Lecture 7
Security handshake pitfalls.

V.E.S.I.T_M.C.A NishiTiku 1
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 2
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 3
…….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 4
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 5
Security Handshake Protocols
The following is a series of security handshake
protocols.
 They are presented and evaluated according to

securi ty and per formance . The

performance parameters are:
 Number of messages,

 Processing power required, and

 Compactness of messages.

V.E.S.I.T_M.C.A NishiTiku 6
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 7
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 8
Protocol 3 & 4
Alice 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 9
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 10
 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 11
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 12
Authentication Based on a Shared
Secret Key

 Two-way authentication using a challenge-

response protocol.

V.E.S.I.T_M.C.A NishiTiku 13
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 14
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 15
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 16
Authentication Based on a Shared Secret Key
(3)

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

V.E.S.I.T_M.C.A NishiTiku 17
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 18
 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 19
 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 20
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 21
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 22
Establishing a Shared Key:
The Diffie -Hellman Key Exchange
The Diffie-Hellman key exchange.

V.E.S.I.T_M.C.A NishiTiku 23
 Establishing a Shared Key:The
Diffie-Hellman Key Exchange
Pitfall ?
 The bucket brigade or man-in-the-
middle attack

V.E.S.I.T_M.C.A NishiTiku 24
Key Establishment and Authentication
with KDC
A simple protocol:

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

Bob
Problem: Potential delayed key delivery to Bob.
(besides others)
V.E.S.I.T_M.C.A NishiTiku 25
Another simple protocol:

Alice, Bob

KA{Bob, KAB}, ticketB KDC

Alice

Bob
where ticketB= KB{Alice, KAB}

Alice, ticketB

Problems:
No freshness guarantee for KAB
Alice & Bob need to authenticate

V.E.S.I.T_M.C.A NishiTiku 26
Needham-Schroeder Protocol

N1, Alice, Bob

KA{N1, Bob, KAB, ticketB} KDC

where ticketB= KB{KAB, Alice}

ticketB, KAB{N2}

Bob
Alice

KAB{N2-1, N3}

KAB{N3-1}

V.E.S.I.T_M.C.A NishiTiku 27
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 28
Messages should be integrity protected.
Otherwise, cut-and-paste reflection attacks
possible:

replay ticketB, KAB{N2}

KAB{N2-1, N3}
Trudy

Bob
KAB{N3-1}

ticketB, KAB{N3}
Trudy

Bob
KAB{N3-1, N4}

V.E.S.I.T_M.C.A NishiTiku 29
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 30
Expanded Needham-Schroeder
Protocol
hello

KB{NB}

N1, Alice, Bob, KB{NB}

KA{N1, Bob, KAB, ticketB} KDC

Alice

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

ticketB, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

V.E.S.I.T_M.C.A NishiTiku 31
Authentication Using Public-Key
Cryptography

 Mutual authentication using public-key

cryptography

V.E.S.I.T_M.C.A NishiTiku 32
 Case study

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