Abstract
In Mastercard's contactless payment protocol called RRP (Relay Resistant Protocol), the reader is measuring the round-trip times of the message-exchanges between itself and the card, to see if they do not take too long. If they do take longer than expected, a relay attack would be suspected and the transaction should be dropped. A recent paper of Financial Crypto 2019 (FC19) raises some questions w.r.t. this type of relay-protection in contactless payments. Namely, the authors point out that the reader has no incentive to protect against relaying, as it stands to gain from illicit payments. The paper defines the notion of such a rogue reader colluding with a MiM attacker, specifically in the context of contactless payments; the paper dubs this as collusive relaying. Two new protocols, PayBCR and PayCCR, which are closely based on Mastercard's RRP and aim to achieve resistance against collusive relaying, are presented therein. Yet, in the FC19 paper, there is no formal treatment of the collusive-relaying notion or of the security of the protocols. In this paper, we first lift the FC19 notions out of the specifics of RRP-based payments - to the generic case of distance bounding. Thus, we set to answer the wider question of what it would mean to catch if RTT-measuring parties (readers, cards, or others) cheat and collude with proximity-based attackers (i.e., relayers or other types). To this end, we give a new distance-bounding primitive (validated distance-bounding) and two new security notions: strong relaying and strong distance-fraud. We also provide a formal model that, for the first time in distance-bounding, caters for dishonest RTT-measurers. In this model, we prove that the new contactless payments in the FC19 paper, PayBCR and PayCCR attain secuity w.r.t. strong relaying. Finally, we define one other primitive (validated and audited distance-bounding), which, in fact, emulates more closely the PayCCR protocol in the Financial Crypto 2019 paper; this is because, contrary to the line introducing them, we note that PayBCR and PayCCR in fact differ in construction and security guarantees especially in those that go past relaying and into authentication.