06 security handshake - rwth aachen · 5 security in communication networks ws‘00/01 6. security...
TRANSCRIPT
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).
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
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
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.
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.
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
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.
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.
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
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.
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
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.
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.
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.
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
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}
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}
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}
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.
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}
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.
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}
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}