06 security handshake - rwth aachen · 5 security in communication networks ws‘00/01 6. security...

23
1 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 1 / 45 Contents 6.1 Introduction 6.2 Log-in Only 6.3 Mutual Authentication 6.4 Integrity/Encryption of Data 6.5 Mediated Authentication (with KDC) 6.6 Bellovin-Merrit 6.7 Network Log-in and Password Guessing 6.8 Nonce-Types Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 2 / 45 Alice Bob Initialization Phase (Handshake) Communication (Secure) In Chapter 5 examples of security handshakes were discussed. Even minor deviations from secure protocols may produce security holes. 6.1 Introduction During the handshake phase communication parameters are negotiated and initial information are exchanged. Some of these information are secret (e.g. the password), some are not (e.g. the user names).

Upload: others

Post on 21-Apr-2020

6 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

1

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

1 / 45Contents

6.1 Introduction6.2 Log-in Only6.3 Mutual Authentication6.4 Integrity/Encryption of Data6.5 Mediated Authentication (with KDC)6.6 Bellovin-Merrit6.7 Network Log-in and Password Guessing6.8 Nonce-Types

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

2 / 45

Alic

e

Bob

InitializationPhase

(Handshake)

Communication(Secure)

In Chapter 5 examples of security handshakes were discussed.Even minor deviations from secure protocols may produce security holes.

6.1 Introduction

During the handshake phase communication parameters are negotiated andinitial information are exchanged. Some of these information are secret (e.g. thepassword), some are not (e.g. the user names).

Page 2: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

2

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

3 / 456.1 Introduction

To cope with different types of threats individual protocols have differentstrengths and weaknesses.

– Some threats are more likely in some situations.– Availability of resources may differ:

· Computational power· Specialized hardware

– Humans and computers may behave differently.– Protocols themselves may be flawed.

The aim of this chapter:– To describe some typical protocols and evaluate their respective performance,

i.e.· Number of messages needed,· processing power required,· compactness of messages.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

4 / 456.2 Login Only

Many protocols were designed for environments where eavesdropping was nota concern. Authentication in such protocols consist of:

1. Alice sends her name and password to Bob.2. Bob verifies the name and password, and then communication commences,

without any further attention to security.

A very common enhancement to such a protocol is to replace the transmissionof the cleartext password with a cryptographic challenge/response.

Alic

e

Bob

1. Name, Password 2. Check Name and Password!Authentication

Communication

Page 3: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

3

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

5 / 456.2 Login Only / Shared Secret

This would be a big improvement over cleartext passwords. An eavesdroppercannot impersonate Alice based on overhearing the exchange, since next timethere will be a different challenge. However, there are some weaknesses to thisprotocol:

– Authentication is not mutual.– If this is the entire protocol, then Trudy can hijack the conversation after the

initial exchange.– An eavesdropper could mount an off-line password-guessing attack.– Someone who has access to Bob’s database can impersonate Alice.

Alic

e

Bob

I’m Alice

a challenge R

KAB{R}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

6 / 456.2 Login Only / Shared Secret

This protocol has only minor security differences from the previous one:– This protocol requires reversible cryptography, for example a secret key

cryptographic algorithm.– If R is a recognizable quantity, Trudy can mount a password-guessing attack

without eavesdropping by merely sending the message „I am Alice“ andobtaining KAB{R}.

Alic

e

Bob

I’m Alice

R

KAB{R}

A minor variation

Page 4: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

4

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

7 / 456.2 Login Only / Shared Secret

This modification requires Bob and Alice to have synchronized clocks. Theproperties of this modification include:

– It can be added very easily to a protocol designed for sending cleartextpasswords, since is does not add any additional messages.

– The protocol is now more efficient. The server does not have to keep anytransient status information about Alice.

– Someone eavesdropping can use Alice’s KAB{timestamp} to impersonate Alice(albeit only within a small time interval).

– Another potential security pitfall occurs if there are multiple servers for whichAlice uses the same secret KAB: an eavesdropper who acts quickly can useAlice’s encrypted timestamp field, and impersonate Alice on a different server.

Alic

e

BobI’m Alice, KAB{timestamp}Another variation of

the original protocol:

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

8 / 456.2 Login Only / Shared Secret

Requirenents and disadvantages of the discussed protocols:

– They require a secret key cryptography algorithm, and therefore shared secretkeys.

– Trudy can impersonate Alice if she can read Bob’s database.

Theses weaknesses can be avoided if the protocol is based onpublic key technology.

Page 5: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

5

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

9 / 456.2 Login Only / One-Way Public Key

The above protocol is based on a public key and similar to the first protocol.Bob verifies Alice’s signature [R]Alice using her public key, and accepts thelogin if the result matches R.The advantage of this protocol:

– Reading Bob’s database at is no longer a potential security-threat, but itmust beprotected from unauthorized modification.

– If you can impersonate Bob’s network address you can trick Alice into signingsomething (wait for Alice to try log in and then give her your quantity).

Alic

e

Bob

I’m Alice

R

[R]Alice

[R]Alice means that Alicesigns R, i.e. transforms Rusing her private key.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

10 / 456.2 Login Only / One-Way Public Key

Properties of this protocol:– Requires a reversible public key algorithm.– If you can impersonate Bob’s network address you can trick Alice into

decrypting something (wait for Alice to try log in and sned the encryptedmessage).

Solution:– A message should have a structure so that it cannot be mistaken for another

type. à See Public-Key Cryptography Standard (PKCS).

Alic

e

Bob

I’m Alice

R

{R}Alice

{R}Alice means thatBob encrypts R withAlices public key.

Page 6: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

6

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

11 / 456.2 Login Only / Lamport’s Hash

Lamport’s Hash:– Interesting one-time password scheme.– It allows Bob to authenticate Alice in a way that neither eavesdropping on an

authentication exchange nor reading Bob’s database enables someone toimpersonate Alice.

– No need for public key cryptography.

Requirements:– Alice remembers a password, Alice is a human.– Bob (the server) has a database; for each user it stores:

· username,· n, decremented each time the user authenticates herself,· hashn(Password), i.e. hash(hash(...(hash(Password))...)))

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

12 / 456.2 Login Only / Lamport’s Hash

Initialization of a password:– Alice chooses a password.– The workstation of Alice chooses the number n and computes

x1=hash(Password), x2=hash(x1), ..., xn=hash(xn-1)=hashn(Password) and sendsit to Bob together with n.

Alic

e

Alic

e‘s

Wor

ksta

tion

Bob

Alice, Passwordxn=hashn(Password), n

xn=hashn(Password), n

Database

Page 7: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

7

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

13 / 456.2 Login Only / Lamport’s Hash

Authentication of a user:– Alice enters her username and password.– Her workstation sends the name to Bob which returns n.– The workstation computes hashn-1(Password) and sends the result to Bob.

– Bob takes the received value and hashes it once, and compares it with itsdatabase. In case of a match Bob considers the response valid, replaces thestored quantity with the received quantity, and replaces n by n-1.

Alic

e

Alic

e‘s

Wor

ksta

tion

Bob

Alice, Password Alice

n

x=hashn-1(Password)

knows <n,hashn(Password)>

compares hash(x) tohashn(Password);if equal, replaces<n, hashn(Password)> with <n-1,x>

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

14 / 456.2 Login Only / Lamport’s Hash

Setting up a new password:– If n = 1 Alice needs to set her password again.– In many situations it suffices to choose a new password, compute hashn(new

Password), and transmit hashn(new Password) and n to Bob.– An enhancement is to add a salt value to the password (like in the UNIX-

Password environment), with the same advantages.

– Another advantage of salt is that Alice will not need to change her password if n= 1.

Properties:ä It is similar to Public-Key schemes in that Bob’s database at is not security

sensitive.æ User can only log-in a finite number of times before having to re-install the

password at the server.æ No mutual authentication.æ The small n attack.

Page 8: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

8

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

15 / 456.2 Login Only / Lamport’s Hash - The small n attack

The small n attack is the worst weakness of Lamport’s Hash.

– An intruder Trudy, who is able to impersonate Bob’s network address, waits forAlice’s log-in.

– When Alice attempts to log into Bob, Trudy returns a small value for n, say 50.

– When Alice responds with hash50(Password) Trudy has enough information toimpersonate Alice for some time, assuming that the actual value of n at Bob isgreater than 50.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

16 / 456.2 Login Only / Lamport’s Hash - The small n attack

Two Solutions:

– Human and Paper environment:· When <n, hashn(Password)> is installed at the server all values of hashi(Password)

for i<n are computed, encoded into a typeable string, printed on paper, and given toAlice.

· When she logs in, she uses the string at the top of the page, crosses that value, anduses the next value the next time.

– Workstation environment:· Alice’s workstation displays n to the human(!) Alice.· If Alice remembers approximately what n should be she can at least do a rough

probability check on n.

Page 9: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

9

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

17 / 456.3 Mutual Authentication

Mutual authentication means that both communication partners are able toidentify each other.An example for a simple protocol for mutual authentication is based on sharedsecrets.

Alic

e

Bob

I’m Alice

KAB{R1}

R1

R2

KAB{R2}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

18 / 456.3 Mutual Authentication

– The previous protocol is inefficient (it needs 5 messages).– Improvement: reduce the number of messages to three by putting more than one

item of information into each message.

Alic

e

Bob

I‘m Alice, R2

KAB{R1}

R1,KAB{R2}

This version of the protocol has a security pitfall known as reflection attack.

Protocol 6.3

Page 10: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

10

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

19 / 456.3 Mutual Authentication / Refleciton Attack

Reflection attack:– Trudy starts Protocol 6.3 , but when she receives the challenge from Bob, she

cannot proceed further, because she cannot encrypt R1.

– Trudy has made Bob encrypt R2.– At this point Trudy opens a second session to Bob and uses R1 as the challenge.

– Trudy cannot continue this session because she cannot encrypt R3, but sheknows KAB{R1}, so she can complete the first session.

Tru

dy

Bob

I’m Alice, R2

R1,KAB{R2}T

rudy

Bob

I’m Alice, R1

R3,KAB{R1}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

20 / 456.3 Mutual Authentication / Refleciton Attack

Two counter-measures against the Reflection attack:

– Both are based on the principle “don’t have Alice and Bob do exactly the samething”.

� Different-keys: the key used to authenticate Alice should be different from thekey used to authenticate Bob. For example: Bob’s key might be -KAB or KAB+1or KAB+F0F0F0F0F0F0F0F016

� Different-challenges: the initiator’s challenge must be different from the one ofthe responder. For example, use Bob|R as challenge.

Page 11: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

11

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

21 / 456.3 Mutual Authentication / Password Guessing

Another security weakness of Protocol 6.3 is that Trudy can mount an off-linepassword-guessing attack without needing to eavesdrop.

– Trudy has to send a message to Bob claiming to be Alice.– Bob will obligingly return the encrypted value.– Then Trudy has the pair <R, KAB{R}> which she can use to check password

guesses.– This weakness can fixed by adding another message to Protocol 6.1.

Alic

e

Bob

I’m Alice

KAB{R1}, R2

R1

KAB{R2}

With this protocol Trudy is unable to obtain quantities for an off-lineguessing attack.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

22 / 456.3 Mutual Authentication / Public Keys

Mutual authentication can also be done with public key technology, assumingthat Bob and Alice know each other’s public key.

Problems:– How does Alice know Bob’s public key?– How could Alice’s workstation obtain Alice’s private key when a password is

all Alice knows?

Alic

e

Bob

I’m Alice, {R2}B

R1

R2,{R1}A

Page 12: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

12

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

23 / 456.3 Mutual Authentication / Timestamps

Mutual authentication can be reduced to two messages by using timestampsinstead of random numbers for challenges.

– It is easy to add to existing protocols, since it does not add any additionalmessages.

– Bob must send another timestamp as Alice does.– Kerberos V4 uses this scheme.

Tru

dy

Bob

I’m Alice, KAB{timestamp}

KAB{timestamp+1}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

24 / 456.4 Integrity/Encryption for Data

After the initial authentication Alice and Bob have to:– add integrity checks to the data or– encrypt the data.– establish a shared, secret, per-conversation key, called session key, to be used

for integrity protection and encryption.

The authentication exchange should be enhanced so that both Alice and Bob willshare a session key.

It is important that an eavesdropper is not able to figure out the session key is.After establishing a session key, the workstation can forget the user’s password.

Page 13: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

13

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

25 / 456.4 Integrity/Encryption for Data / Shared Secret

– Alice and Bob share a secret key KAB.– The Authentication is like in the previous

protocol.

– In case of mutual authentication there aretwo of each Rs, R1 and R2.

Alic

e

Bob

I’m Alice

KAB{R1}

R1

R2

KAB{R2}

– There ís sufficient information in this protocol for Alice and Bob to establish ashared session key at this point.

– For example, they can use (KAB+1){R}.

– In general: Take the shared secret KAB and modify it in some way, then encryptthe challenge R using the modified KAB as the key, and use the result as thesession key.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

26 / 456.4 Integrity/Encryption for Data / Two-Way Public Key

There are several methods to establish session keys with public keys:� Alice chooses a random number R, encrypst it with Bob’s public key, and sends

{R}B to Bob attached to one of the messages in the authentication exchange.� An intruder could hijack the conversation by picking his own R, encrypting it

with Bob’s public key, and sending it to Bob.� Alice can additionally sign the result. In this case, she sends [{R}B]A to Bob.

Bob first has to verify Alice’s signature before decrypting R.

� Trudy could record the entire conversation between Alice and Bob. If she canlater take over Bob she will be able to decrypt the conversation.

� This is like �, but Alice picks R1 and Bob R2. Alice sends {R1}B to Bob. Bobsends {R2}A to Alice. The session key will R1⊕R2. An intruder is not able tolearn R1 and R2 only by overtaking Bob or Alice.

� Alice and Bob can do a Diffie-Hellman key establishment exchange, whereevery partner signs the quantity he is sending.

Page 14: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

14

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

27 / 456.4 Integrity/Encryption for Data / One-Way Public Key

In some cases only one of the parties in the conversation has a public/privatekey pair, e.g. Alice, who needs to prove her identity to a server Bob:

� Bob could choose a random number R, encrypt it with Alice’s public key, send{R}A to Alice, and R could be the session key.

� If Trudy records the conversation and later takes over Alice she can decrypt theconversation.

� Bob and Alice could do a Diffie-Hellman exchange, where Alice signs herquantity.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

28 / 456.4 Integrity/Encryption for Data / Lamport‘s Hash

With Lamport’s Hash neither side has a public key, and they do not have ashared secret key. Nevertheless, there are several possibilities to establish ashared session key:

� They can first do the authentication handshake, and then a Diffie-Hellmanexchange to establish a session key.

� An intruder could hijack the conversation after the initial authentication andbefore the Diffie-Hellman exchange.

� They can do first a Diffie-Hellman exchange, and then do the authenticationhandshake as part of a conversation protected with the Diffie-Hellman key.

� An intruder could do a bucket-brigade, establishing a separate Diffie-Hellmankey with both Alice and Bob.

Page 15: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

15

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

29 / 456.5 Mediated Authentication

– The Key Distribution Center (KDC) has a database holding keys for all users.– Any user registered with the KDC can securely communicate with it.

– The user and the KDC can authenticate each other and encrypt theircommunication because they each know the key (see figure).

Problems with this protocol:– The KDC does not know whether it was really Alice who wanted to talk to Bob.– If Alice immediately sent a message to Bob based on the new shared key, it

would be possible that Alice’s message arrives first, in which case Bob wouldnot know how to decrypt it.

Alic

e

Bob

Alice wants BobKA{use KAB for Bob} KB{use KAB for Alice}K

DC invents

key KAB

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

30 / 456.5 Mediated Authentication

KDC operation in practice (improvement of the previous protocol):– The KDC gives Alice the information it would have sent to Bob (Kerberos calls

this encrypted information a ‘ticket’).– The ticket holds information that will allow Alice to access Bob.

Alic

e

Bob

Alice wants Bob

KA{use KAB for Bob}ticket to Bob = KB{use KAB for Alice}

“I’am Alice“, ticket = KB{use KAB for Alice}

KD

C inventskey KAB

Page 16: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

16

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

31 / 456.5 Mediated Authentication / Needham-Schroeder

The Needham-Schroeder protocol is a classic KDC-arbitrated authenticationprotocol.

– Kerberos and many other protocols are based on the Needham -Schroederprotocol.

– Nonce refers to a number that is used only once. A nonce could be a sequencenumber or a large random number.

Discussion of the protocol:– Message 1: Alice informs the KDC that she wants talk to Bob. The nonce N1 is

used to prove that Alice is really talking to the KDC.– Message 2: The KDC securely transmitts the key KAB to Alice, which it has

generated for Alice and Bob to share.· The String “Bob” makes it impossible for an intruder to tamper with Alice’s request.· Along with the encrypted key KAB and Bob’s name, the KDC also sends Alice a

ticket to Bob.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

32 / 456.5 Mediated Authentication / Needham-Schroeder

– Message 3: Alice sends a challenge (N2) to Bob, encrypted with KAB, along withthe ticket. Alice knows that only someone who knows Bob’s key can decryptthe ticket and obtain the shared key KAB.

– Message 4: Bob can prove that he knows KAB if he can find N2. Also inmessage 4 Bob sends a challenge (N3) to Alice, encrypted with KAB.

– Message 5: Alice proves she knows KAB.

Alic

e

Bob

N1, Alice wants Bob

KA{N1, “Bob”, KAB, ticket to Bob}where ticket to Bob = KB{KAB, “Alice”} K

DC invents

key KAB

ticket, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

Page 17: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

17

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

33 / 456.5 Mediated Authentication / Expanded Needham-Schroeder

– The expanded Needham-Schroeder fixes a security hole of the original protocol.– If an intruder finds out Alice’s key he can claim to be Alice and obtain from the KDC

a shared key with, and a ticket to, Bob.

– The problem with the original protocol is that the ticket to Bob reamains valid even ifAlice changes her key.

Alic

e

Bob

N1, Alice wants Bob, KB{NB}

KA{N1, “Bob”, KA B, ticket to Bob}where ticket to Bob = KB{KAB, “Alice”, NB} K

DC invents

key KAB,extracts NB

ticket, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

I want to talk youKB{NB}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

34 / 456.5 Mediated Authentication / Otway-Rees

The Otway-Rees protocol is an improvement:– It solves the ticket invalidation problem.– It does mutual authentication in 5 messages.

Discussion of the protocol:– Message 1: Alice generated two nonces.

· NC ist sent in the clear to Bob.· NA is encrypted by Alice and Bob cannot interpret it.

Alic

e

BobK

DC invents

key KAB,extracts NB

NC, “Alice”, “Bob”, KA{NA, NC, “Alice”, “Bob”}

KA{NA, NC, “Alice”, “Bob”},KB{NB, NC, “Alice”, “Bob”}

NC, KA{NA, KAB}, KB{NB, KAB}

KA{NA, KAB}

KAB{anything recognizable}

Page 18: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

18

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

35 / 456.5 Mediated Authentication / Otway-Rees

– Message 2: Bob forwards Alice’s encrypted message, along with an encryptedmessage which includes his own nonce NB.

· The KDC makes sure that the common nonce NC is the same in both encryptedmessages. If not, the KDC will reject the message.

– Message 3: The KDC gives Bob a message to forward to Alice. This messageproves that the KDC and Bob are who they claim to be.

– Message 4: Bob forwards this message to Alice.

– Message 5: Communication starts when both parties have got the session keyKAB.

Problems:– The only authentication of Bob in the protocol is done by the KDC, which

verifyies that the nonce NC in the message encrypted with KB is the same as theone in the message encrypted with KA.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

36 / 456.6 Bellovin-Merrit

Most of the protocols discussed have the following properties:– User’s key could be derived from a password.– Thus, there is the danger that an intruder captures some quantity for an off-line

password-guessing attack.

Examples:

Alic

e

BobI’m Alice, KAB{timestamp}

An intruder learns <R, KAB{R}> pairs.

The intruder learns KAB{timestamp} information.

ðBellovin-Merrit designed two protocols to prevent off-line password guessing.

Alic

e

Bob

I’m Alice

a challenge R

KAB{R}

Page 19: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

19

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

37 / 456.6 Bellovin-Merrit / First Scheme

Bellovin-Merrit’s first scheme:– The basic idea is that Alice and Bob do a Diffie-Hellman exchange, but encrypt

the values they exchange.– The Diffie-Hellman key is K = gRA·RB mod p .– Subsequently, they do a standard mutual authentication exchange proving each

other that they know K.A

lice

Bob

KAB{gRA mod p}

KAB{gRB mod p}

K{R1|0}

R1, K{R2|1}

R2

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

38 / 456.6 Bellovin-Merrit / First Scheme

Why can an eavesdropper obtain no information in this case?– No way to do a password-guessing attack based on KAB{gR mod p}.

· An intruder has to guess a password, convert it into a key, and then use that key todecrypt the messages. The intruder could not verify that he really got gRA mod p,since it would be indistinguishable from a random number.

– On messages 3-5 there is also no way to do a password-guessing attack as theyare based on a key that has nothing to do with the user’s password.

Why is it necessary to encrypt the Diffie-Hellman exchange?– An intruder could gain information for a password-guessing attack by

impersonating either Alice or Bob.

Why was this second scheme developed?– The first scheme requires Bob to know the user’s password.– The second scheme requires Bob only to store a hash of the user’s password.

Page 20: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

20

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

39 / 45A

lice

Bob

KAB{gRA mod p}

KAB{gRB mod p}, R

K{R}

K{Alice’s password{Alice’s private key}}

[R]A

knowsKAB=hash(passwordA),

passwordA(private keyA)

6.6 Bellovin-Merrit / Second Scheme

Bellovin-Merrit’s second scheme:– In message 1 and 2, Alice and Bob do a Diffie-Hellman exchange encrypted

with a hash of Alice’s password to establish a shared key.– Since Alice’s private key is encrypted with her password, the information in

Bob’s database will not be sufficient for someone to learn Alice’s private keyand impersonate Alice to Bob.

– In message 3, Alice proves that she know K.

– In message 4, Bob transmits the encrypted private key, also encrypted with K.– In message 5, Alice proves that she is really Alice. Bob verifies her signature on

R using her public key.

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

40 / 456.7 Network Login and Password Guessing

How to turn the user’s low-quality secret into a high-quality secret?The high-quality secret is encrypted with Alice’s password and stored at somelocation B. Alice’s workstation A needs to retrieve this information from B andthen decrypt it using Alice’s password.

� A sends “Give me Alice’s encrypted secret” to B, who returns it to A. This istypically done if Alice’s private key, which is encrypted with Alice’s password,is stored in the directory service.

A B

“Give me Alice’s encrypted secret”

passwordA{high-quality secretA}Database

passwordA{high-quality secretA}

Page 21: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

21

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

41 / 45

� Before B is willing to transmit Alice’s encrypted high-quality secret it asks A toprove its knowledge of Alice’s password by sending e.g. a hash of the password.Thus no longer allows an active attacker to obtain quantities.

� As in �, but encrypt the exchange between B and A by using a key established“on the fly”.

� As in �, but encrypt the exchange by making A use a secret or public key for B.� Use the first messages of Bellovin-Merrit to establish a secret session key

between A and B, an then do � or �.

6.7 Network Login and Password GuessingA B

“Alice’s encrypted secret”,hash(passwordA) passwordA{high-quality secretA}

Database

passwordA{high-quality secretA}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

42 / 456.8 Nonce-Types

A nonce is a quantity which any given user of a protocol uses only once. Manyprotocols deploy nonces, and there are different types with different sorts ofproperties.

– It is possible that nonces with wrong properties introduce security weaknesses.– Types of nonces include:

· Random number· Sequence number· Timestamp

Next we will discuss some examples of the importance of nonce types.

Page 22: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

22

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

43 / 456.8 Nonce-Types

In the above protocol the unpredictability of the challenge R is important.– Assume Bob is using sequence numbers.– When Alice attempts to log in, Bob encrypts the next sequence number and

transmits it to Alice.– An intruder observing the communication sees the return value of R from Alice.

– If the intruder knows that Bob is using sequence numbers he can claim to beAlice, get an undecipherable pile of bits from Bob, and returns R+1.

àThe attack will be successful!

Alic

e

Bob

I’m Alice

R

KAB{R}

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

44 / 456.8 Nonce-Types

A variation of the previous protocol?– Bob shall again use sequence numbers and the intruder is observing the

communication. Therefore, he sees the value of R but he needs to encrypt thenext sequence number to attack successfully.

– If the intruder can impersonate Bob’s networks address, he can wait for Alice’sattempts to authenticate herself.

– Then the intruder sends the next sequence number to Alice, who returns thisnumber encrypted. The intruder can now use this number for an attack.

– This is similar to the bucket brigade attack.

Alic

e

Bob

I’m Alice

R

KAB{R}

Page 23: 06 Security Handshake - RWTH Aachen · 5 Security in Communication Networks WS‘00/01 6. Security Handshake Pitfalls 9 / 45 6.2 Login Only / One-Way Public Key The above protocol

23

Secu

rity

in

Com

mun

icat

ion

Net

wor

ks

WS

‘00/

01 6. Security Handshake Pitfalls

45 / 456.8 Nonce-Types

A secure protocol:– In the above protocol it is possible to use a predictable nonce for R without

threatening the security of the protocol.– Even if the intruder can predict R he cannot predict the value sent by Bob or the

appropriate response from Alice.

Alic

e

Bob

I’m Alice

KAB{R}

(KAB+1){R}