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
