this bit is encapsulated to much bigger packet which
is then sent over the communication medium. This
observation shows that the standard cryptographic ap-
proach of rapid bit exchange is not efficient in prac-
tice. Here we don’t consider the time needed for the
message to pass through the communication stack.
It is desirable for the proposed protocol that
all computations are performed in a preprocessing
stage, i.e., when the time is measured the processing
delay to be negligible e.g. it only amounts at the
comparison of two numbers. The protocol should be
easily composable with other protocols and because
the goal is to measure the proximity to mobile devices
the proposed protocol should allow secure periodical
execution.
Threat Model. The protocol should be secure against
both cheating verifier and mafia attacks. The reason
why we don’t consider terrorists attacks is twofold,
first as noted by using trusted hardware this attack is
prevented (as this is the case for DRM). Secondly,
the only way a cryptographic proximity protocol to
be secure against terrorists attacks is to force the
prover to give away to the terrorists his private se-
crets (private-asymmetric or shared-symmetric key).
In some cases this will prevent such an attack from
a potential cheater. But depending on the application
terrorists attacks are still a possible threat (e.g. DRM
or sensor networks cases - if the device has been com-
promised by an attacker).
Since we would like the prover to belong to a
large class of devices some of them with very limited
resources, e.g. RFID, it is reasonable to assume that
he either has no source of randomness or it is limited
and thus insecure (predictable). Note that all existing
protocols are subject to mafia attacks if the prover
has insecure random number generator.
The Protocol. The purpose of the protocol is to prove
to the verifier that the prover is within a given dis-
tance, without using any source of randomness. We
assume that the proverP and the verifierV share some
common secrets. Namely, a distance-authentication
key and denoted by K and a seed by R, both with a
fixed length
˜
k. These two secrets may be derived from
the authentication protocol executed in advance by
both parties, if the parties have already established a
secure authenticated channel, or distributed via other
means. Thus we separate the phase when the distance
is measured from the phase when the authentication
takes place. A pseudo-random function is used for
the calculation of the verifier’s challenge and prover’s
response. Since we don’t consider the terrorist attacks
the attacker has no access to the shared key. We will
denote by h(s;m) the pseudo-random function which
has as inputs a secret key s and a public string m and
outputs a string with a fixed length
˜
k, computationally
indistinguishable from a uniformly random string. In
practice, h can be HMAC or AES.
Recall that a goal when designing the protocol was
to allow the periodical execution of it once a secure
channel is established between the parties. In other
words, the protocol can be executed several times at
unspecified time intervals in order to ensure that the
communicating parties are still in the same proximity.
We assume that in case distance-bounding protocol
fails then the secure authenticated channel is termi-
nated.
Thus in the preprocessing stage both parties com-
pute two sequences say {a
i
} and {b
i
} (for i = j +
1,..., j + k), where j is a counter known for both par-
ties (initialized to zero when the protocol is executed
for the first time). For example, by using dedicated h
and the seed R, i.e. a
i
= h(R;i|V) and b
i
= h(R;i|P).
Note that the sequences {a
i
} and {b
i
} may also be
public and not pseudo-random. For example, a re-
currence relation like the Fibonacci sequence (a
i
is
i + 5-th Fibonacci number and b
i
= a
i
+ 1) can be
used. We stress here that the sequences {a
i
} and {b
i
}
should satisfy the following condition: the probabil-
ities Prob(a
i
= b
j
),Prob(b
i
= b
j
) and Prob(a
i
= a
j
)
are negligible. In case the sequences are public the
seed R is either made public (thus anybody can com-
pute a
i
= h(R;i|V) and b
i
= h(R;i|P)) or the seed is
not used in the computation (in the recurrence rela-
tion case). By using these sequences we avoid the
need of random source for the prover. Our protocol is
described below.
1. Let’s assume that the prover P and verifierV share
a common secret (distance-authentication key K)
and another common secret (seed R) both with a
fixed length
˜
k.
2. Let k be a security parameter and j be a counter
known for both parties (initialized to zero when
the protocol is executed for the first time). In
the preprocessing stage both parties first compute
fixed parts of the two sequences {a
i
} and {b
i
} (for
i = j + 1,..., j + k).
3. The second step in the preprocessing stage for
both parties is to compute the tags ma
i
= h(K;a
i
)
and mb
i
= (K;b
i
) (for i = j + 1,..., j+ k).
4. The interactive stage starts with the verifier choos-
ing at random i ∈
R
[ j + 1, j + k]. Then V starts his
timer and sends the tuple i,ma
i
to P.
5. The prover P compares the received value ma
i
with his pre-computed one and if they are the
same returns the tuple i,mb
i
to V.
SECRYPT 2008 - International Conference on Security and Cryptography
220