Cryptography Reference
In-Depth Information
Note that what entity authentication primarily requires is a notion of
liveness
,
which is an indication that an entity is currently active. A freshness mechanism
does not provide this by default, since just because a message is 'new' does not
imply that the sender is 'alive'. For example, an attacker could intercept a 'fresh'
message and then delay relaying it to the intended receiver until some point in
the future. When the receiver eventually receives the message they may well be
able to identify that it is fresh (not a replay) but they will not necessarily have
any assurance that the sender is still 'alive'. However, all freshness mechanisms
can be used to provide liveness if they are managed appropriately, particularly by
controlling the window of time within which a notion of 'freshness' is deemed
acceptable.
There are three common types of freshness mechanism, which we now review.
8.2.1
Clock-based mechanisms
A
clock-based
freshness mechanism is a process that relies on the generation of
some data that identifies the time that the data was created. This is sometimes
referred to as a
timestamp
. This requires the existence of a clock upon which
both the creator of the data and anyone checking the data can rely. For example,
suppose that Alice and Bob both have such a clock and that Alice includes the time
on the clock when she sends a message to Bob. When Bob receives the message, he
checks the time on his clock and if it 'matches' Alice's timestamp then he accepts
the message as fresh. The granularity of time involved might vary considerably
between applications. For some applications the datemight suffice, however, more
commonly an accurate time (perhaps to the nearest second) is more likely to be
required.
Clock-based freshness mechanisms seem a natural solution, however, they
come with four potential implementation problems:
Existence of clocks
. Alice and Bob must have clocks. For many devices, such as
personal computers and mobile phones, this is quite reasonable. It may not be
so reasonable for other devices, such as certain types of smart token.
Synchronisation
. Alice's and Bob's clocks need to be reading the same time, or
sufficiently close to the same time. The clocks on two devices are unlikely to
be perfectly synchronised since clocks typically suffer from
clock drift
. Even if
they drift by a fraction of one second each day, this drift steadily accumulates.
How much drift is acceptable before Bob rejects the time associated with a
message? One solution might be to only use a highly reliable clock, for example
one based on a widely accepted time source such as universal time. Another
solution might be to regularly run a resynchronisation protocol. The most
obvious solution is to define a window of time within which a timestamp
will be accepted. Deciding on the size of this
window of acceptability
is appli-
cation dependent and represents a tradeoff parameter between usability and
security.
