Transcript
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
top related