Cryptography Reference
In-Depth Information
9.3.1
A simple application
We now describe a simple security scenario. This is probably too simple a scenario
to have any real application, however, even this scenario has sufficient complexity
to provide us with an example that we can analyse.
THE OBJECTIVES
In this scenario we suppose that Alice and Bob have access to a common network.
Periodically, at any time of his choosing, Bob wants to check that Alice is still
'alive' and connected to the network. This is our main security objective, which
we will refer to as a check of liveness (see Section 8.2).
In order to make the example slightly more interesting, we assume that Alice
and Bob are just two entities in a network consisting of many such entities,
all of whom regularly check the liveness of one another, perhaps every few
seconds. We thus set a secondary security objective that whenever Bob receives
any confirmation of liveness from Alice, he should be able to determine precisely
which liveness query she is responding to.
THE PROTOCOL GOALS
We now translate these objectives into concrete protocol goals. Whenever Bob
wants to check that Alice is alive he will need to send a
request
to Alice, which
she will need to respond to with a
reply
. When designing protocol goals to meet
these objectives it can be helpful to consider what could go wrong, hence we will
motivate each protocol goal by a potential failure of the protocol if this goal is
not met.
At the end of any run of a suitable cryptographic protocol, the following three
goals should have been met:
Data origin authentication of Alice's reply
. If this is not provided then Alice
may not be alive since the reply message might have been created by an
attacker.
Freshness of Alice's reply
. If this is not provided then, even if there is data origin
authentication of the reply, this could be a replay of a previous reply. In other
words, an attacker could observe a reply that Alice makes when she
is
alive and
then send a copy of it to Bob at some stage after Alice has expired. This would
be a genuine reply created by Alice. But she would not be alive and hence the
protocol will have failed to meet its objectives.
Assurance that Alice's reply corresponds to Bob's request
. If this is not provided
then it is possible that Bob receives a reply that corresponds to a different
request (either one of his own, or of another entity in the network).
Note that it is the combination of the first two goals that provides the basic
guarantee that Alice is alive. However, we will see that the third goal not only
provides more precision, but in some circumstances is essential.
