Lect 7 Security Handshake and Pitfalls
-
Upload
api-26355935 -
Category
Documents
-
view
200 -
download
3
Transcript of Lect 7 Security Handshake and Pitfalls
![Page 1: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/1.jpg)
V.E.S.I.T_M.C.A NishiTiku 1
Lecture 7 Security handshake pitfalls.
Network Security
![Page 2: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/2.jpg)
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
![Page 3: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/3.jpg)
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
![Page 4: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/4.jpg)
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
![Page 5: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/5.jpg)
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
![Page 6: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/6.jpg)
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.
![Page 7: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/7.jpg)
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
![Page 8: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/8.jpg)
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.
![Page 9: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/9.jpg)
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.
![Page 10: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/10.jpg)
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!
![Page 11: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/11.jpg)
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
![Page 12: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/12.jpg)
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) ===============================}
![Page 13: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/13.jpg)
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.
![Page 14: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/14.jpg)
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) > ================================}
![Page 15: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/15.jpg)
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)
![Page 16: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/16.jpg)
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) >
=================================}
![Page 17: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/17.jpg)
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)
![Page 18: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/18.jpg)
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.
![Page 19: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/19.jpg)
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).
![Page 20: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/20.jpg)
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) ===============================}
![Page 21: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/21.jpg)
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++) =================================}
![Page 22: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/22.jpg)
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 > ===============================}
![Page 23: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/23.jpg)
V.E.S.I.T_M.C.A NishiTiku 23
Establishing a Shared Key:The Diffie -Hellman Key Exchange
The Diffie-Hellman key exchange.
![Page 24: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/24.jpg)
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 ?
![Page 25: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/25.jpg)
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}
![Page 26: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/26.jpg)
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
![Page 27: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/27.jpg)
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}
![Page 28: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/28.jpg)
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
![Page 29: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/29.jpg)
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}
![Page 30: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/30.jpg)
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).
![Page 31: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/31.jpg)
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}
![Page 32: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/32.jpg)
V.E.S.I.T_M.C.A NishiTiku 32
Mutual authentication using public-key cryptography
Authentication Using Public-Key Cryptography
![Page 33: Lect 7 Security Handshake and Pitfalls](https://reader033.fdocuments.in/reader033/viewer/2022061116/5464bde0b4af9f7d208b466b/html5/thumbnails/33.jpg)
V.E.S.I.T_M.C.A NishiTiku 33
Case study