Cryptography Reference
In-Depth Information
• The second run is initiated by the attacker, who asks if Bob is alive. Bob thinks
that this request is from Alice, but it is from the attacker. Note that this run of
Protocol 3 begins
after
the first run of the protocol has begun, but completes
before
the first run ends. This is why we describe the two runs as 'nested'.
Thus, if this reflection attack is feasible, then Protocol 3 does not meet the third
security goal. It is tempting to respond to this by pointing out that if this reflection
attack is
not
feasible then Protocol 3 is secure. However, by this stage in our
cryptographic studies it should be clear that this is not the attitude of a wise
cryptographic designer. If there are circumstances under which a cryptographic
protocol might fail then we should really consider the protocol as insecure.
A better response would be to repair Protocol 3. There are two 'obvious'
options:
Include an action to check for this attack
. This would involve Bob keeping a
note of all Protocol 3 sessions that he currently has open. He should then check
whether any request messages that he receives match any of his own open
requests. This is a cumbersome solution that makes Protocol 3 less efficient.
Further, the additional actions that Bob needs to perform during the protocol
are not 'obvious' and, although they could be clearly specified in the protocol
description, some implementations might fail to include them.
Include an identifier
. A far better solution would be to include some sort of
identifier in the reply that prevents the reflection attack fromworking. There is
no point in doing so in the request since it is unprotected and an attacker could
change it without detection. There are many different identifiers that could be
used, but one of the simplest is to include the name of the intended recipient
in the reply, in other words add an identifier
Bob
into the reply text. If we do
this then we convert Protocol 3 into Protocol 1.
REMARKS
Protocol 3 has raised an important issue. Even when considering such a simple set
of protocol goals, we have come up against a subtle attack. It is generally regarded
as good practice in the design of cryptographic protocols to include the identifiers
of recipients in protocol messages to prevent reflection attacks of this type.
There are several other general classes of attack that can be launched against
cryptographic protocols. These include
interleaving attacks
, which exploit several
parallel protocol sessions and switch messages from one protocol run into
another. Hopefully our earlier remark in Section 9.2.2 about the dangers of
inexperienceddesigners inventing their own cryptographic protocols is nowbetter
justified.
9.3.5
Protocol 4
Figure 9.6 shows the protocol flow andmessages of our fourth candidate protocol.
