Security handshake pitfalls - Computer Science

Security handshake pitfalls
How come nobody gets it right?
CS349 Cryptography
Department of Computer Science
Wellesley College
Getting it right
o
We mortals should never
need to design our own
cryptographic algorithms.
o
However, it may be the
case that we will need to
design security features
into protocols.
o
We had better
understand (at least some
of) what can go wrong.
Handshake pitfalls
18-2
1
Protocol 1. Login only
Many protocols were designed in an environment where
eavesdropping was not a concern.
I’m Alice, the password is fiddlesticks
Bob
Alice
o
Handshake pitfalls
18-3
Protocol 2a. Shared secret
a challenge R
Bob
Alice
I’m Alice
f(Kalice-Bob, R)
o
This is a big improvement over passwords in the clear. An
eavesdropper cannot impersonate Alice based on
overhearing the exchange.
o
However, the protocol is not without weakness.
Handshake pitfalls
18-4
2
Protocol 2b. Shared secret, second try*
KAlice-Bob{R}
Bob
Alice
I’m Alice
R
*An attempt at mutual authentication.
Handshake pitfalls
18-5
I’m Alice, KAlice-Bob{timestamp)
Bob
Alice
Protocol 2c.
Shared secret, attempt to abbreviate*
*Requires that Bob and Alice have reasonably synchronized clocks.
Handshake pitfalls
18-6
3
I’m Alice, timestamp, hash(KAlice-Bob,timestamp}
Bob
Alice
Protocol 2d.
Shared secret, a detail
Handshake pitfalls
18-7
Protocol 3a. One-way public key
o
Our protocols based on shared secrets all have one major
disadvantage. Our bad guy can impersonate Alice if she
can read Bob’s database.
o
Protocols based on public key technology can avoid this.
a challenge R
Bob
Alice
I’m Alice
[R]Alice
Handshake pitfalls
18-8
4
Protocol 3b. One-way public key*
[R]Alice
Bob
Alice
I’m Alice
R
*A minor variant, possible with reversible public key schemes that avoids
tricking Alice into signing away the farm.
Handshake pitfalls
18-9
How can we avoid getting into trouble?
o
The general rule is that
you should not use the
same key for two
different purposes unless
the designs for all uses of
the key are coordinated.
o
Part of the purpose of the
Public-key Cryptography
Standard is to impose
enough structure to
prevent this sort of
problem.
Handshake pitfalls
18-10
5
Protocol 4a. Mutual authentication
base on a shared secret*
I’m Alice
f(Kalice-Bob, R1)
R2
Bob
Alice
R1
f(Kalice-Bob, R2)
*We could just do an authentication exchange in each direction.
Handshake pitfalls
18-11
Protocol 4b. Optimized mutual
authentication based on shared secret
R1, f(Kalice-Bob, R2)
Bob
Alice
I’m Alice, R2
f(Kalice-Bob, R1)
Handshake pitfalls
18-12
6
Reflection attack
Bob
Trudy
I’m Alice, R2
R1, f(Kalice-Bob, R2)
“I can’t explain myself, I’m afraid sir,” said Alice, “because,
I’m not myself, you see.”
Alice in Wonderland
Handshake pitfalls
18-13
Trudy opens a second session to Bob*
R3, f(Kalice-Bob, R1)
Bob
Trudy
I’m Alice, R1
*Which she still cannot complete. However, . . .
Handshake pitfalls
18-14
7
Foiling reflection attacks
o
The general principle is
simple: Don’t have Alice
and Bob do exactly the
same thing.
o
For example, we could
have the key used to
authenticate Alice be
different from the key
used to authenticate Bob.
o
Alternatively, we could
insist that the challenge
from Alice look different
from the challenge from
Bob.
Handshake pitfalls
18-15
Protocol 4a does not suffer
from reflection attack
Moral of the story
The initiator should be the first to prove its identity.
. . . if you only spoke when you were spoken to, and the
other person always waited for you to begin, you see
nobody would ever say anything . . .
Alice (in Through the Looking Glass)
Handshake pitfalls
18-16
8
Password guessing
o
Optimized Protocol 4b suffers from an another security
weakness. Trudy can mount an off-line password-guessing
attack without needing to eavesdrop.
R1, f(Kalice-Bob, R2)
Bob
Alice
I’m Alice, R2
f(Kalice-Bob, R1)
Handshake pitfalls
18-17
Protocol 4c. Less optimized mutual
authentication base on shared secret
I’m Alice
f(Kalice-Bob, R1), R2
Bob
Alice
R1
f(Kalice-Bob, R2)
Handshake pitfalls
18-18
9
Protocol 5. Mutual authentication
using Timestamps
o
f(Kalice-Bob, timestamp+1)
Bob
Alice
I’m Alice, f(Kalice-Bob, timestamp)
The issues involving one-way authentication done with
timestamps apply here as well (time must not go
backwards, they must remember values used within the
clock skew, and so forth . . .)
Handshake pitfalls
18-19
Protocol 6. Mutual authentication
with public keys
R2, {R1}Alice
Bob
Alice
I’m Alice, {R2}Bob
R1
Handshake pitfalls 18-20
10
Key management
o
Techniques for the
distribution of public keys
fall into following
schemes:
o
Public announcement;
o
Publicly available
directory;
o
Public-key authority; or
o
Public-key certificates.
Handshake pitfalls
18-21
Public announcement of public keys
Handshake pitfalls 18-22
11
Publicly available directory
Handshake pitfalls 18-23
Public-key authority
Handshake pitfalls 18-24
12
Public-key certificates
Handshake pitfalls 18-25
13