7 From Relay Attacks to Distance-Bounding Protocols
129
Last but not least, the theoretical DB protocols presented in Sect. 7.3 follow a
design whereby the fast phase is generally formed of a repetition of a number of
timed rounds, where each challenge/response is one bit. These designs (endorsed
by formal models/proofs, etc.) were traditionally anchored in practice, and Sect. 7.2
alluded to this: i.e., a challenge given as a bitstring can lead to bit-by-bit early reads
and therefore possible early responses by dishonest provers. But, as of recently,
there seem to be mechanisms for these early-send attacks to be effectively counteracted by other ingenious, practical mechanisms in designs even in cases where
the timed challenges/responses are bitstrings (see Sect. 7.5 or [531]). However, it
is important to recall that the security of the DB design in [531] has not yet been
formally analyzed, and the protocol only claims to protect against relay attacks, not
other DB threats.
7.6.2 Application-Aware DB
In the formal models presented in Sect. 7.4 and even in the practical considerations
given in Sect. 7.2, we saw that the DB threat-model has thus far been generally
focused on this primitive in isolation; that is, it assumes an honest verifier, a
dishonest prover and a malicious man-in-the-middle. However, as DB is adopted in
different applications (e.g., PKES as per the above), these security considerations
will need adjustments. To begin with, the verifier may be dishonest, or some
threats—such as terrorist fraud—may become irrelevant, or specific anonymity
concerns may be considered. In this space of fine-tuned threat models for DB,
two lines have recently emerged [107, 326]. Namely, [107] advances a formal DB
threat-model where a fine-grained level of corruption of the prover (i.e., white-box,
black-box) is taken into account, such that each application can “pick and choose”.
In turn, this also leads to clear-cut, DB-security properties and even the exclusion of
resistance to terrorist fraud, in some cases. Complementary to this, [326] recently
advances a formal DB model with three parties, where the new party is a named
piece of hardware and this also leads to a fine taxonomy of DB-security properties,
with an application-ready nature.
DB efficiency is paramount, but it varies from application to application. A
DB solution that can be acceptable on a smartphone, may be unacceptable on
a simple, passive card. A series of research lines [111, 325] discussed the
efficiency of DB protocols with “traditional” structure, i.e., following the designs
presented in Sect. 7.3, from a theoretical-analysis viewpoint. At the same time, the
practical solution for proximity-checking in PKES offered by 3DB (see Sect. 7.5)
is extremely efficient in practice. However, this question of efficiency stands,
especially if new DB solutions are to be given on top of different applications, such
as EMV.
In DB adoption, there are also strong backwards-compatibility constraints. For
instance, in EMV, the public-key infrastructure or the restrictions of keeping as
129
Last but not least, the theoretical DB protocols presented in Sect. 7.3 follow a
design whereby the fast phase is generally formed of a repetition of a number of
timed rounds, where each challenge/response is one bit. These designs (endorsed
by formal models/proofs, etc.) were traditionally anchored in practice, and Sect. 7.2
alluded to this: i.e., a challenge given as a bitstring can lead to bit-by-bit early reads
and therefore possible early responses by dishonest provers. But, as of recently,
there seem to be mechanisms for these early-send attacks to be effectively counteracted by other ingenious, practical mechanisms in designs even in cases where
the timed challenges/responses are bitstrings (see Sect. 7.5 or [531]). However, it
is important to recall that the security of the DB design in [531] has not yet been
formally analyzed, and the protocol only claims to protect against relay attacks, not
other DB threats.
7.6.2 Application-Aware DB
In the formal models presented in Sect. 7.4 and even in the practical considerations
given in Sect. 7.2, we saw that the DB threat-model has thus far been generally
focused on this primitive in isolation; that is, it assumes an honest verifier, a
dishonest prover and a malicious man-in-the-middle. However, as DB is adopted in
different applications (e.g., PKES as per the above), these security considerations
will need adjustments. To begin with, the verifier may be dishonest, or some
threats—such as terrorist fraud—may become irrelevant, or specific anonymity
concerns may be considered. In this space of fine-tuned threat models for DB,
two lines have recently emerged [107, 326]. Namely, [107] advances a formal DB
threat-model where a fine-grained level of corruption of the prover (i.e., white-box,
black-box) is taken into account, such that each application can “pick and choose”.
In turn, this also leads to clear-cut, DB-security properties and even the exclusion of
resistance to terrorist fraud, in some cases. Complementary to this, [326] recently
advances a formal DB model with three parties, where the new party is a named
piece of hardware and this also leads to a fine taxonomy of DB-security properties,
with an application-ready nature.
DB efficiency is paramount, but it varies from application to application. A
DB solution that can be acceptable on a smartphone, may be unacceptable on
a simple, passive card. A series of research lines [111, 325] discussed the
efficiency of DB protocols with “traditional” structure, i.e., following the designs
presented in Sect. 7.3, from a theoretical-analysis viewpoint. At the same time, the
practical solution for proximity-checking in PKES offered by 3DB (see Sect. 7.5)
is extremely efficient in practice. However, this question of efficiency stands,
especially if new DB solutions are to be given on top of different applications, such
as EMV.
In DB adoption, there are also strong backwards-compatibility constraints. For
instance, in EMV, the public-key infrastructure or the restrictions of keeping as