Scribd
Upload
100 views

Security Handshake Pitfalls

This document discusses various authentication handshake methods and their security weaknesses. It covers logins with shared secrets, public key authentication, mutual authentication protocols, and key establishment. Some common flaws include lack of mutual authentication, offline password guessing, database compromise allowing impersonation, reflection attacks, and replay attacks. Strong authentication requires techniques like nonces, synchronized clocks, separate keys for each party, and confirming both sides have the same key after authentication.

Uploaded by

Swati Sharma
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
100 views

Security Handshake Pitfalls

This document discusses various authentication handshake methods and their security weaknesses. It covers logins with shared secrets, public key authentication, mutual authentication protocols, and key establishment. Some common flaws include lack of mutual authentication, offline password guessing, database compromise allowing impersonation, reflection attacks, and replay attacks. Strong authentication requires techniques like nonces, synchronized clocks, separate keys for each party, and confirming both sides have the same key after authentication.

Uploaded by

Swati Sharma
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

1

Security Handshake Pitfalls


2
Authentication Handshakes
Secure communication almost always includes
an initial authentication handshake:
Authenticate each other
Establish sessions keys
This process may involve many flaws
3
Login with shared secret

Approaches
Using KAlice-Bob as a secret key to encrypt R: KAlice-Bob{R}
Hashing R and KAlice-Bob: h(KAlice-Bob, R)
Different time uses different R
Discussions
Authentication is not mutual: Trudy can convince Alice that she is Bob
Off-line password guessing attack assuming KAlice-Bob is derived from
a password
Trudy can compromise the database at Bob and later impersonate Alice
4
All the previous weakness remains
Minor security difference
Alice has to be able to reverse what Bob has done to
R
If KAlice-Bob is derived from a password, it is
vulnerable to a dictionary attack
Login with shared secret contd
5
Login with shared secret contd
Alice and Bob have reasonably synchronized clocks

more efficient

Impersonate Alice within the acceptable clock skew

If Trudy can set Bobs clock back reuse overheard timestamps

6
Authentication with One-Way Public Key

Advantage
Database at Bob need not be protected from unauthorized
disclosure
Weakness
Trudy can trick Alice into signing/decrypting: Trudy can forge
Alices signature on some quantity
7
Mutual Authentication

Inefficient

8
Mutual Authentication
Reflection Attack

9
Reflection Attack
General Principle
Do not have Alice and Bob do exactly the same
thing
Different Keys: have the key used to authenticate Alice
be different from the key used to authenticate Bob
Different Challenges: the challenge from the initiator
(Alice) looks different from the challenge from the
responder
10
Mutual Authentication
Password Guessing without eavesdropping: send
a message to Bob,
How to fix?
11
Mutual Authentication
Public Keys
Assume Alice and Bob know each others public
keys

12
Mutual Authentication
Timestamps
Require synchronized clocks
Alice and Bob have to encrypt different
timestamps




13
Integrity/Encryption for Data
In order to provide integrity and/or encryption
protection of the data following the authentication
exchange, it is necessary for Alice and Bob to encrypt
and/or add integrity
Require a session key established during mutual
authentication
14
Establishment of Session Keys
Shared Secret based authentication



After the authentication..
Use K
Alice-Bob
{R} as the session key?
Has been used as the third message in the authentication handshake
Use (K
Alice-Bob
+1){R} as the session key
Use K
Alice-Bob
{R+1} as the session key?
Trudy impersonates Bob:
15
Nonce Types
Timestamps
Require reasonably synchronized clocks
Large random numbers
Tend to make the best nonce
Cannot be guessed/predicted
Sequence number
16
Nonce Types
R has to be unpredictable:
suppose Eve impersonates
Alice

Nonce Types
R has to be unpredictable: Eve first
impersonates Bob, then impersonates Alice
17
Nonce Types
18
19
Privacy and Integrity
Replay attack
Use long sequence numbers
Sequence number space rollover
Key rollover: changing keys in the middle of a
conversation
20
Mediated Authentication

Trudy may claim to be Alice and send I am Alice
Will not do Trudy any good
It is possible that Alices messages get to Bob first, so
Bob does not know how to decrypt it
Using a Ticket
Must be followed by a mutual authentication exchange confirm that
Alice and Bob have the same key
21
Needham-Schroeder Protocol
Classic protocol for authentication with KDC
Many others have been modeled after it (e.g. Kerberos)
22
Needham-Schroeder Protocol
Nonce: a number that is used only once
A sequence number or a large random number
Deal with replay attacks
Reflection Attack
Bob -> Alice: K
AB
{N
2
-1, N
3
}
Assume N
i
multiple of encryption blocksize
ECB:
Message splicing: put together own plus revealed
With CBC, no need to decrement N
2
, N
3
A Vulnerability
When Trudy gets a previous key used by Alice, Trudy may reuse a
previous ticket issued to Bob for Alice
Essential Reason
Ticket to Bob stays valid even if Alice changes her key
23
Expanded Needham-Schroeder
The additional two messages assure Bob that the initiator has talked to
KDC since Bob generates N
B
24
Kerberos V4
Based on Needham-Schroeder, but with timestamps
Save exchange of nonce

You might also like