Cryptographic Authentication

Security Handshake Pitfalls
Password authentication is subject to

eavesdropping
Ahmet Burak Can

Alternative: Cryptographic challenge-response
Hacettepe University
◦ Symmetric key
[email protected]
◦ Public key

1 2

Symmetric Key Challenge-

Challenge-Response Symmetric Key Challenge-
Challenge-Response
An example protocol: An alternative protocol:

I’m Alice I’m Alice

a challenge R KAB{R}
Bob
Alice

Bob
Alice
F(KAB,R) R

Authentication not mutual (login only)
Requires reversible cryptography

Subject to connection hijacking (login only)

Subject to dictionary attack, without eavesdropping, if R

Subject to off-line password guessing (if K is derived is recognizable
from password)
Can be used for mutual authentication if R is

Bob’s database has keys in the clear recognizable and has limited lifetime
3 4
 Symmetric Key Challenge-
Challenge-Response Public Key Challenge-
Challenge-Response
A one-message protocol: By signature:

I’m Alice, KAB{timestamp} I’m Alice

Alice

Bob
R

Bob
Alice
[R]A

Easy integration into password-sending systems

More efficient: Single message, stateless

Care needed against replays: timeout needed

Care needed if key is common across servers

Clock has to be protected as well

Alternatively, with a hash function, send,
I’m Alice, timestamp, H(KAB,timestamp)

5 6

Public Key Challenge-

Challenge-Response Mutual Authentication
By decryption: An example protocol:
I’m Alice
I’m Alice
{R}A
Bob
Alice

R1
R
F(KAB,R1)

Bob
Alice R2

Problem: Bob (or Trudy) can get Alice to sign/decrypt any
text he chooses. F(KAB,R2)

Solutions:
◦ Never use the same key for different purposes (e.g., for login and
signature)
◦ Use formatted challenges

7 8
 Mutual Authentication with Few Messages Reflection Attack:
Original session:
Number of messages for mutual authentication can be
I’m Alice, R2
reduced:
R1, F(KAB,R2)

Trudy

Bob
I’m Alice, R2
F(KAB,R1)
R1, F(KAB,R2)

Bob
Alice

F(KAB,R1)
Decoy session:

However, this protocol is vulnerable to I’m Alice, R1

Trudy

Bob
◦ Reflection attack R3, F(KAB,R1)
◦ Dictionary attack :Trudy can do dictionary attack against KAB
acting as Alice, without eavesdropping.

9 10

Results from Reflection Attack A Modified Mutual Authentication Scheme

Solutions:
Solution against both problems:
◦ Different keys for Alice and Bob
◦ Formatted challenges, different for Alice and Bob I’m Alice

Principle:
R1
◦ Initiator should be the first to prove its identity

Bob
Alice
F(KAB,R1), R2

F(KAB,R2)

Dictionary attack is still possible if Trudy can

impersonate Bob.

11 12
Mutual Authentication with Public Keys Session Key Establishment

I’m Alice, {R2}B
A session key is needed for integrity protection and
encryption in a communication session. It must be
R2, {R1}A

Bob
◦ different for each session
Alice

R1 ◦ unguessable by an eavesdropper
◦ not KAB{x} for some x predictable/extractable by an attacker

Session keys can be established by using

Problem: How can the public/private keys be ◦ Symmetric encryption
remembered by ordinary users? ◦ Public key encryption
◦ Possibly, they can be retrieved from a server with password
based authentication & encryption.

13 14

Session Key Establishment with Symmetric Session Key Establishment with Public Key
Encryption Cryptosystem
I’m Alice
An alternative is to use Diffie-Helman key exchange
R algorithm.
Bob
Alice

Another alternative with PKC, send additional random

KAB {R}
nonces {R}A , {R}B and use them to derive a session
key.

Do not use KAB{R} or KAB{R+1}
◦ Take (KAB+1){R} as the session key. {R1}B

I’m Alice

Bob
Alice

{R2}A
R+1
Bob
Alice

KAB {R+1}
K = R1 ⊕ R2 K = R1 ⊕ R2

15 16
Key Establishment and Authentication Key Establishment and Authentication
with Key Distribution Center (KDC) with KDC
A simple protocol:
Another simple protocol:

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

Bob
where ticketB= KB{Alice, KAB}

Alice
KA{Bob, KAB}

Bob
Alice

Alice, ticketB

Problem:
Problems:
◦ Potential delayed key delivery to Bob. (besides others) ◦ No freshness guarantee for KAB
◦ Alice & Bob need to authenticate

17 18

Nonces Needham--Schroeder Protocol

Needham

Nonce: Something created for one particular occasion

Nonce types: N1, Alice, Bob

◦ Random numbers KA{N1, Bob, KAB, ticketB} KDC

◦ Timestamps where ticketB= KB{KAB, Alice}
◦ Sequence numbers
ticketB, KAB{N2}

Bob

Random nonces needed for unpredictability Alice

Obtaining random nonces from timestamps: KAB{N2-1, N3}
encryption with a secret key.
KAB{N3-1}

19 20
 Needham--Schroeder Protocol
Needham Replaying Tickets

Ticket is double-encrypted. (unnecessary)
Messages should be integrity protected. Otherwise, cut-

and-paste reflection attacks possible:

N1: for authenticating KDC & freshness of KAB.

N2, N3: for key confirmation, mutual authentication replay ticketB, KAB{N2}

Why are the challenges N2, N3 encrypted? KAB{N2-1, N3}

Bob
Trudy

Problem: Bob doesn’t have freshness guarantee for KAB KAB{N3-1}
(i.e., can’t detect replays).

ticketB, KAB{N3}

Bob
Trudy
KAB{N3-1, N4}

21 22

Expanded Needham-
Needham-Schroeder Protocol Protocol Performance Comparison
hello
Computational Complexity:
(to minimize CPU time, power consumption)
KB{NB} ◦ Number of private-key operations
◦ “ “ public-key “
N1, Alice, Bob, KB{NB} ◦ “ “ bytes encrypted with secret key
KA{N1, Bob, KAB, ticketB} ◦ “ “ bytes hashed
KDC
where ticketB= KB{KAB, Alice, NB}
Alice

Bob

Communication Complexity:
ticketB, KAB{N2} ◦ Number of message rounds
◦ Bandwidth consumption
KAB{N2-1, N3}

KAB{N3-1}

23 24