Cryptography Reference
In-Depth Information
What happens in this attack is that two DHKEs are being performed simultane-
ously, one between Alice and Oscar and another one between Bob and Oscar. As
a result, Oscar has established a joined key with Alice, which we termed
k
AO
, and
another one with Bob, which we named
k
BO
.
However, neither Alice nor Bob is
aware of the fact that they share a key with Oscar and not with each other!
Both assume that they have computed a joint key
k
AB
.
From here on, Oscar has much control over encrypted traffic between Alice and
Bob. As an example, here is how he can read encrypted messages in a way that goes
unnoticed by Alice and Bob:
Message Manipulation After a Man-in-the-Middle Attack
Alice
Oscar
Bob
message
x
y
= AES
k
AO
(
x
)
y
−−−−−−−→
intercept
decrypt
x
= AES
−
1
k
AO
(
x
)
re-encrypt
y
'
=
AES
k
BO
(
x
)
y
'
−−−−−−−→
decrypt
x
= AES
−
1
k
BO
(
y
')
For illustrative purposes, we assumed that AES is used for the encryption. Of course,
any other symmetric cipher can be used as well. Please note that Oscar can not only
read the plaintext
x
but can also alter it prior to re-encrypting it with
k
BO
. This can
have serious consequences, e.g., if the message
x
describes a financial transaction.
13.3.2 Certificates
The underlying problem of the man-in-the-middle attack is that public keys are not
authenticated. We recall from Sect. 10.1.3 that message authentication ensures that
the sender of a message is authentic. However, in the scenario at hand Bob receives
a public key which is supposedly Alice's, but he has no way of knowing whether
that is in fact the case. To make this point clear, let's examine how a key of a user
Alice would look in practice:
k
A
=(
k
pub
,
A
,
ID
A
)
,
where
ID
A
is identifying information, e.g., Alice's IP address or her name together
with date of birth. The actual public key
k
pub
,
A
, however, is a mere binary string,
e.g., 2048 bit. If Oscar performs a MIM attack, he would change the key to:
k
A
=(
k
pub
,
O
,
ID
A
)
.
