Pre-play attack

In [BCM⁺14], Bond et al. show what can happen if the Unpredictable Number gen-erated by the terminal is not really unpredictable. The UN is the only data field that provides freshness for a transaction from the side of the terminal as the other data fields, such as the transaction amount or country code, could be determined in advance. In their research they found several ATMs for which the UN was either completely or partially predictable because, for example, it was based on a counter or timestamps. Knowing the UN enables an attacker to harvest valid ARQCs or TCs, depending on whether the transaction is online or offline respectively. For example, a malicious POS could harvest a number of ARQCs from a card that is used to pay in a shop. Later the attacker can use the harvested data in an Automatic Teller Machine (ATM) for which he can predict the UN to successfully withdraw money.

He won’t be able to generate a valid TC as this is based on the issuer’s response to the ARQC, which cannot as easily be predicted. This might not be a problem as the terminal cannot verify the TC itself and it could be the case that the TC is not imme-diately sent to the issuer for verification. If CDA is used, this attack would not work for online transactions as the attacker would need a signature on the TC, which would be checked by the terminal. If the customer uses his card before the attacker tries to withdraw money using the customer’s data, the last used ATC that is known by the issuer will be higher than the ones in the ARQCs that the attacker harvested. If the attacker now tries to use the harvested data, the issuer is able to detect that data is replayed, as the ATC only increases. Also, depending on the number of ARQCs the attacker harvests, a big gap between the last successfully used ATC and the current one is used. This could be an indication to the issuer that there is a problem, but it can also be caused by failed transactions.

In a Specification Bulletin, EMVCo announced that additional requirements for the UN would be introduced [EMV12]. Terminal vendors are required to produce UNs that are actually unpredictable. One suggestion for this is to follow international standards for random number generation.

Chapter 4

Analysing EMV

As seen in the previous chapter, EMV is a complex standard with many options. In this chapter we present our formal analysis of these specifications in Section 4.1 as published in [RP12]. To analyse implementations of EMV we used automated learning techniques on real bank cards, as discussed in Section 4.2 and published in [ARP13].

4.1 Formal analysis

In this section we will discuss the formal analysis we performed on the EMV pro-tocol suite [RP12]. For the analysis we make use of the ProVerif tool discussed in Section 2.2.2. Due to the complexity of the EMV specification, we wrote the model in F# and used the tool FS2PV (see Section 2.2.3) to translate our F# model to the untyped pi-calculus that is used by ProVerif. The model grows substantially in size with this translation: whereas the F# model is 370 lines of code, the resulting ProVerif model is 2527 lines of code. The increase in size is caused by the many if-statements in the F# model – which result in duplication of large fragments of code in the untyped pi-calculus – and the (convenient) use of functions in F#. In fact, initially we tried to formalise the EMV protocol in the untyped pi-calculus, but we gave up as the model became too complex to oversee.

Our model includes a card and a terminal. The issuer is not considered in this model as it is not needed for the security requirements we consider in Section 4.1.4.

The F# code models a card that performs a single transaction. For most security properties we want to consider cards performing multiple transactions. For this we have to edit the generated ProVerif code, by simply adding ! for replication in the right place.

We assume that the channel between the card and terminal is public, i.e. a Man-in-the-Middle can intercept and modify all communication. Since the cards are provided by the bank, we assume that there are no dishonest cards. The terminal is assumed to have secure input and output with the customer. Our model makes some assumptions on DOLs based on what we observed in Dutch bank and credit cards. Since we do not know how the cryptogram is computed on the Dutch bank cards, we follow the recommendations from the EMV specification. Here a MAC is computed using the symmetric key SKSAC, which is shared between the card and the issuer, on a minimum set of recommended data elements. The recommended minimum set of

elements to be included in the AC is specified in [EMV11b, Section 8.1.1]. It consists of the amount, terminal country, terminal verification results, currency, date, transaction type, terminal nonce, AIP and ATC. The AIP and ATC are data provided by the card, the other elements are provided by the terminal in the CDOL1 and CDOL2.