Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
Contents
1 / 45
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 i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.1 Introduction
2 / 45
Bob
Alice
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).
Initialization
Phase
(Handshake)
Communication
(Secure)
In Chapter 5 examples of security handshakes were discussed.
Even minor deviations from secure protocols may produce security holes.
1
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.1 Introduction
3 / 45
To cope with different types of threats individual protocols have different
strengths 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.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only
4 / 45
Many protocols were designed for environments where eavesdropping was not
a 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.
Communication
Bob
Alice
1. Name, Password
Authentication
2. Check
Name and Password!
A very common enhancement to such a protocol is to replace the transmission
of the cleartext password with a cryptographic challenge/response.
2
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Shared Secret
5 / 45
a challenge R
Bob
Alice
I’m Alice
KAB {R}
This would be a big improvement over cleartext passwords. An eavesdropper
cannot impersonate Alice based on overhearing the exchange, since next time
there will be a different challenge. However, there are some weaknesses to this
protocol:
– 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.
A minor variation
6 / 45
Alice
I’m Alice
KAB {R}
Bob
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Shared Secret
R
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“ and
obtaining KAB{R}.
3
I’m Alice, KAB{timestamp}
7 / 45
Bob
Another variation of
the original protocol:
Alice
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Shared Secret
This modification requires Bob and Alice to have synchronized clocks. The
properties of this modification include:
Security i n Communication
Networks WS‘00/01
– It can be added very easily to a protocol designed for sending cleartext
passwords, since is does not add any additional messages.
– The protocol is now more efficient. The server does not have to keep any
transient 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 which
Alice uses the same secret K AB: an eavesdropper who acts quickly can use
Alice’s encrypted timestamp field, and impersonate Alice on a different server.
6. Security Handshake Pitfalls
6.2 Login Only / Shared Secret
8 / 45
Requirenents and disadvantages of the discussed protocols:
– They require a secret key cryptography algorithm, and therefore shared secret
keys.
– Trudy can impersonate Alice if she can read Bob’s database.
Theses weaknesses can be avoided if the protocol is based on
public key technology.
4
9 / 45
I’m Alice
R
Bob
[R] Alice means that Alice
signs R, i.e. transforms R
using her private key.
Alice
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / One-Way Public Key
[R]Alice
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 the
login if the result matches R.
The advantage of this protocol:
– Reading Bob’s database at is no longer a potential security-threat, but itmust be
protected from unauthorized modification.
– If you can impersonate Bob’s network address you can trick Alice into signing
something (wait for Alice to try log in and then give her your quantity).
10 / 45
I’m Alice
{R}Alice
Bob
{R}Alice means that
Bob encrypts R with
Alices public key.
Alice
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / One-Way Public Key
R
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 encrypted
message).
Solution:
– A message should have a structure so that it cannot be mistaken for another
type. à See Public-Key Cryptography Standard (PKCS).
5
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash
11 / 45
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 to
impersonate 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))...)))
xn=hashn(Password), n
12 / 45
Database
Bob
Alice
Alice, Password
Alice‘s Workstation
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash
xn=hashn(Password), n
Initialization of a password:
– Alice chooses a password.
– The workstation of Alice chooses the number n and computes
x 1=hash(Password), x 2=hash(x 1), ..., x n=hash(x n-1)=hash n(Password) and sends
it to Bob together with n.
6
13 / 45
Alice
knows <n,hashn (Password)>
n
x=hashn-1(Password)
Bob
Alice
Alice, Password
Alice‘s Workstation
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash
compares hash(x) to
hash n(Password);
if equal, replaces
<n, hashn (Password)> with <n-1,x>
Authentication of a user:
– Alice enters her username and password.
– Her workstation sends the name to Bob which returns n.
– The workstation computes hash n-1(Password) and sends the result to Bob.
– Bob takes the received value and hashes it once, and compares it with its
database. In case of a match Bob considers the response valid, replaces the
stored quantity with the received quantity, and replaces n by n-1.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash
14 / 45
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 hash n(new Password) and n to Bob.
– An enhancement is to add a salt value to the password (like in the UNIXPassword 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.
7
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash - The small n attack
15 / 45
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 for
Alice’s log-in.
– When Alice attempts to log into Bob, Trudy returns a small value for n, say 50.
Security i n Communication
Networks WS‘00/01
– When Alice responds with hash50(Password) Trudy has enough information to
impersonate Alice for some time, assuming that the actual value of n at Bob is
greater than 50.
6. Security Handshake Pitfalls
6.2 Login Only / Lamport’s Hash - The small n attack
16 / 45
Two Solutions:
– Human and Paper environment:
· When <n, hash n(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 to
Alice.
· When she logs in, she uses the string at the top of the page, crosses that value, and
uses 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.
8
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.3 Mutual Authentication
17 / 45
KAB {R1}
R2
Bob
Alice
I’m Alice
R1
KAB {R2}
6. Security Handshake Pitfalls
6.3 Mutual Authentication
18 / 45
I‘m Alice, R 2
R1,KAB{R2}
KAB {R1}
Bob
– 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.
Alice
Security i n Communication
Networks WS‘00/01
Mutual authentication means that both communication partners are able to
identify each other.
An example for a simple protocol for mutual authentication is based on shared
secrets.
Protocol 6.3
This version of the protocol has a security pitfall known as reflection attack.
9
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.3 Mutual Authentication / Refleciton Attack
19 / 45
Reflection attack:
I’m Alice, R 2
R1,KAB{R2}
Bob
Trudy
– Trudy starts Protocol 6.3, but when she receives the challenge from Bob, she
cannot proceed further, because she cannot encrypt R1.
I’m Alice, R 1
R3,KAB{R1}
Bob
Trudy
– Trudy has made Bob encrypt R2 .
– At this point Trudy opens a second session to Bob and uses R1 as the challenge.
Security i n Communication
Networks WS‘00/01
– Trudy cannot continue this session because she cannot encrypt R3, but she
knows K AB{R1 }, so she can complete the first session.
6. Security Handshake Pitfalls
6.3 Mutual Authentication / Refleciton Attack
20 / 45
Two counter-measures against the Reflection attack:
– Both are based on the principle “don’t have Alice and Bob do exactly the same
thing”.
• Different-keys: the key used to authenticate Alice should be different from the
key used to authenticate Bob. For example: Bob’s key might be -K AB or K AB+1
or K AB+F0F0F0F0F0F0F0F016
‚ Different-challenges: the initiator’s challenge must be different from the one of
the responder. For example, use Bob|R as challenge.
10
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.3 Mutual Authentication / Password Guessing
21 / 45
Another security weakness of Protocol 6.3 is that Trudy can mount an off-line
password-guessing attack without needing to eavesdrop.
I’m Alice
R1
KAB {R1}, R2
Bob
Alice
– 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.
KAB {R2}
With this protocol Trudy is unable to obtain quantities for an off-line
guessing attack.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.3 Mutual Authentication / Public Keys
22 / 45
R2,{R1}A
R1
Bob
Alice
I’m Alice, {R2}B
Mutual authentication can also be done with public key technology, assuming
that 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?
11
I’m Alice, KAB{timestamp}
KAB {timestamp+1}
23 / 45
Bob
Trudy
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.3 Mutual Authentication / Timestamps
Mutual authentication can be reduced to two messages by using timestamps
instead of random numbers for challenges.
Security i n Communication
Networks WS‘00/01
– It is easy to add to existing protocols, since it does not add any additional
messages.
– Bob must send another timestamp as Alice does.
– Kerberos V4 uses this scheme.
6. Security Handshake Pitfalls
6.4 Integrity/Encryption for Data
24 / 45
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 will
share 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.
12
– In case of mutual authentication there are
two of each Rs, R1 and R2.
25 / 45
I’m Alice
R1
KAB {R1}
R2
KAB {R2}
Bob
– Alice and Bob share a secret key K AB.
– The Authentication is like in the previous
protocol.
Alice
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.4 Integrity/Encryption for Data / Shared Secret
– There ís sufficient information in this protocol for Alice and Bob to establish a
shared session key at this point.
– For example, they can use (K AB+1){R}.
Security i n Communication
Networks WS‘00/01
– In general: Take the shared secret KAB and modify it in some way, then encrypt
the challenge R using the modified KAB as the key, and use the result as the
session key.
6. Security Handshake Pitfalls
6.4 Integrity/Encryption for Data / Two-Way Public Key
26 / 45
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 can
later 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. Bob
sends {R 2}A to Alice. The session key will R 1⊕R2 . An intruder is not able to
learn R1 and R 2 only by overtaking Bob or Alice.
„ Alice and Bob can do a Diffie-Hellman key establishment exchange, where
every partner signs the quantity he is sending.
13
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.4 Integrity/Encryption for Data / One-Way Public Key
27 / 45
In some cases only one of the parties in the conversation has a public/private
key 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 the
conversation.
Security i n Communication
Networks WS‘00/01
‚ Bob and Alice could do a Diffie-Hellman exchange, where Alice signs her
quantity.
6. Security Handshake Pitfalls
6.4 Integrity/Encryption for Data / Lamport‘s Hash
28 / 45
With Lamport’s Hash neither side has a public key, and they do not have a
shared secret key. Nevertheless, there are several possibilities to establish a
shared session key:
• They can first do the authentication handshake, and then a Diffie-Hellman
exchange to establish a session key.
• An intruder could hijack the conversation after the initial authentication and
before the Diffie-Hellman exchange.
‚ They can do first a Diffie-Hellman exchange, and then do the authentication
handshake as part of a conversation protected with the Diffie-Hellman key.
‚ An intruder could do a bucket-brigade, establishing a separate Diffie-Hellman
key with both Alice and Bob.
14
invents
key KAB
29 / 45
KB{use KAB for Alice}
Bob
Alice wants Bob
KA{use KAB for Bob}
KDC
Alice
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.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 their
communication 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 would
not know how to decrypt it.
invents
key KAB
30 / 45
Bob
Alice
Alice wants Bob
KA{use KAB for Bob}
ticket to Bob = KB {use KAB for Alice}
KDC
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.5 Mediated Authentication
“I’am Alice“, ticket = KB {use KAB for Alice}
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.
15
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.5 Mediated Authentication / Needham-Schroeder
31 / 45
The Needham-Schroeder protocol is a classic KDC-arbitrated authentication
protocol.
– Kerberos and many other protocols are based on the Needham -Schroeder
protocol.
– Nonce refers to a number that is used only once. A nonce could be a sequence
number 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 K AB to Alice, which it has
generated for Alice and Bob to share.
ticket, KAB{N2}
32 / 45
invents
key KAB
Bob
N1, Alice wants Bob
KA{N1, “Bob”, KAB , ticket to Bob}
where ticket to Bob = KB{KAB , “Alice”}
KDC
6. Security Handshake Pitfalls
6.5 Mediated Authentication / Needham-Schroeder
Alice
Security i n Communication
Networks WS‘00/01
· 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.
KAB {N2-1, N3}
KAB {N3-1}
– Message 3: Alice sends a challenge (N2) to Bob, encrypted with K AB, along with
the ticket. Alice knows that only someone who knows Bob’s key can decrypt
the ticket and obtain the shared key K AB.
– Message 4: Bob can prove that he knows K AB if he can find N2. Also in
message 4 Bob sends a challenge (N3) to Alice, encrypted with K AB.
– Message 5: Alice proves she knows K AB.
16
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.5 Mediated Authentication / Expanded Needham-Schroeder
33 / 45
KA {N1, “Bob”, KA B, ticket to Bob}
where ticket to Bob = KB {KAB, “Alice”, NB }
invents
key KAB,
extracts NB
Bob
Alice
N1, Alice wants Bob, KB{NB}
KDC
I want to talk you
KB{NB}
ticket, KAB{N2}
KAB {N2-1, N3}
KAB {N3-1}
– 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 if
Alice changes her key.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.5 Mediated Authentication / Otway-Rees
34 / 45
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.
invents
key KAB,
extracts NB
KA{NA, NC, “Alice”, “Bob”},
KB{NB, NC, “Alice”, “Bob”}
NC, KA{NA, KAB}, KB{NB, KAB}
Bob
KDC
Alice
NC, “Alice”, “Bob”, KA{NA, NC, “Alice”, “Bob”}
KA{NA, KAB}
KAB {anything recognizable}
17
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.5 Mediated Authentication / Otway-Rees
35 / 45
– Message 2: Bob forwards Alice’s encrypted message, along with an encrypted
message which includes his own nonce NB .
· The KDC makes sure that the common nonce NC is the same in both encrypted
messages. If not, the KDC will reject the message.
– Message 3: The KDC gives Bob a message to forward to Alice. This message
proves 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 key
K AB.
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 K B is the same as the
one in the message encrypted with K A.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.6 Bellovin-Merrit
36 / 45
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:
Bob
Alice
a challenge R
KAB {R}
I’m Alice, KAB{timestamp}
Bob
The intruder learns KAB{timestamp}
information.
Alice
An intruder learns <R, K AB{R}> pairs.
I’m Alice
ðBellovin-Merrit designed two protocols to prevent off-line password guessing.
18
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.6 Bellovin-Merrit / First Scheme
37 / 45
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.
KAB {gRA mod p}
K{R 1|0}
R1, K{R2|1}
Bob
Alice
KAB {gRB mod p}
Security i n Communication
Networks WS‘00/01
R2
6. Security Handshake Pitfalls
6.6 Bellovin-Merrit / First Scheme
38 / 45
Why can an eavesdropper obtain no information in this case?
– No way to do a password-guessing attack based on KAB {g R mod p} .
· An intruder has to guess a password, convert it into a key, and then use that key to
decrypt 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 they
are 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.
19
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.6 Bellovin-Merrit / Second Scheme
39 / 45
KAB {gRA mod p}
K{R}
K{Alice’s password{Alice’s private key}}
Bob
Alice
KAB {gRB mod p}, R
knows
KAB=hash(passwordA ),
passwordA(private keyA )
[R] A
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 key
and 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.
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.7 Network Login and Password Guessing
40 / 45
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 some
location B. Alice’s workstation A needs to retrieve this information from B and
then decrypt it using Alice’s password.
• A sends “Give me Alice’s encrypted secret” to B, who returns it to A. This is
typically done if Alice’s private key, which is encrypted with Alice’s password,
is stored in the directory service.
passwordA{high-quality secret A}
Database
B
A
“Give me Alice’s encrypted secret”
passwordA {high-quality secretA}
20
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.7 Network Login and Password Guessing
41 / 45
“Alice’s encrypted secret”,
hash(passwordA)
Database
B
A
‚ Before B is willing to transmit Alice’s encrypted high-quality secret it asks A to
prove 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.
passwordA {high-quality secretA}
passwordA{high-quality secret A}
ƒ As in ‚, but encrypt the exchange between B and A by using a key established
“on the fly”.
Security i n Communication
Networks WS‘00/01
„ 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. Security Handshake Pitfalls
6.8 Nonce-Types
42 / 45
A nonce is a quantity which any given user of a protocol uses only once. Many
protocols deploy nonces, and there are different types with different sorts of
properties.
– 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.
21
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.8 Nonce-Types
43 / 45
KAB {R}
Bob
Alice
I’m Alice
R
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.
6. Security Handshake Pitfalls
6.8 Nonce-Types
44 / 45
R
Bob
I’m Alice
Alice
Security i n Communication
Networks WS‘00/01
– If the intruder knows that Bob is using sequence numbers he can claim to be
Alice, get an undecipherable pile of bits from Bob, and returns R+1.
à The attack will be successful!
KAB {R}
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 the
next sequence number to attack successfully.
– If the intruder can impersonate Bob’s networks address, he can wait for Alice’s
attempts to authenticate herself.
– Then the intruder sends the next sequence number to Alice, who returns this
number encrypted. The intruder can now use this number for an attack.
– This is similar to the bucket brigade attack.
22
Security i n Communication
Networks WS‘00/01
6. Security Handshake Pitfalls
6.8 Nonce-Types
45 / 45
KAB {R}
Bob
Alice
I’m Alice
(KAB +1){R}
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.
23