4

In the EMV book 2: security and key management on page 151, it is stated that

"The counter results in uniqueness to the cryptograms (ARQC) and provides tracking values for the host verification services, allowing replayed transactions and cloned cards to be identified."

If issuer relies on the acquirer for ARQC (terminal sends nonce for session UN) then what is the purpose of ATC and what means by "allowing replayed transaction"? Who replays the ARQC?

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
user1887464
  • 533
  • 2
  • 6
  • 11
  • UN (unpredictable number ) is nonce sent by terminal to EMV chip for the purpose of ARQC generation which is sent to issuer for authorization. Issuer checks if ATC contained in the ARQC is greater than stored ATC in issuer database for the given card number. – user1887464 Apr 02 '16 at 07:35
  • What about replaying a refund transaction (using the same terminal Unpredictable Number)? How would the issuer detect that? Cloning cards is detectable by checking ATC as well. – vlp Apr 02 '16 at 18:21
  • UN is provided by the terminal to the card to make it possible to ensure that two transactions for the same amount do not produce the same AQRC or TC (for offline authorised transactions). Remember, that the EMV spec does not mandate the content of TDOL, CDOL1 or CDOL2. The EMV specs just establishes the framework that allow a payment system to implement the transaction processing according to its financial security requirements. But the same EMV technology could be used for other different purposes. This is why the separate VISA, MC, AMEX, JCB and DC certification processes exist(ed) – Serge May 12 '16 at 01:31
  • @vlp Refund transaction is completely separate transaction that is processed exactly the same way as a regular normal purchase, but has different transaction type, thus it has its own ATC value. You probably meant reversal. Reversal is not a transaction but an instruction of voiding the original transaction caused by the technical means like failure of vending machine to dispose the goods, a card withdrawn from the reader before the PoS made final GenerateAC, e.t.c. It is assumed, that a cardholder has no access to the PoS connectivity facilities (see my answer). – Serge May 12 '16 at 01:38
  • @vlp However, Refund tx is not mandated to be authenticated by the chip card at all and it may be send to the network with just `PAN` and sum included as this is a merchant decision to return the funds to the client. If a merchant wants to protect himself from inappropriate employee's behavior then it could request from Acquirer to accept only chip-authenticated refunds or set up the PoS device to only allow chip-authenticated refunds. This is a matter of locally established procedures. – Serge May 12 '16 at 01:43
  • @Serge Actually EMV specifications do recommend a minimum set of data elements for AC generation (see Book 2, section 8.1.1, Table 26) which means that those elements should be (and are) present in CDOL. Two transactions for the same amount have a different cryptogram primarily because of different ATC (and thus different keys under a sane payment scheme). – vlp May 12 '16 at 09:10
  • @vlp yes you are damn correct: it does recommend, but it does not mandate. – Serge May 12 '16 at 09:13
  • @Sarge I would describe UN as a nonce providing confidence to the terminal that the card is genuine (in combination with DDA/CDA) -- the terminal can then accept offline transaction (I wouldn't allow any terminal to accept offline transaction from a SDA-only validated card). Similarily the ATC is a nonce providing confidence to the issuer that the transaction was not replayed. – vlp May 12 '16 at 09:16
  • @vlp look at the EMV spec as at a framework that allows to create many funny things and payment transaction processing with all security measures implemented in a right way is just one of possible appliances. – Serge May 12 '16 at 09:19
  • @Sarge I used refund transaction as an example of the easiest/safest misuse -- i.e. replaying the same refund to an anonymous card many times. I did not mean reversal (you are right that card presence is usually not required for that). I totally agree that EMV specs provide a framework. Good luck! – vlp May 12 '16 at 09:23

4 Answers4

12

Using an unpredictable number (UN) that is generated by the terminal gives the terminal control over the freshness of the cryptogram that the card has to generate. Thus, for the same transaction data (authorized amount, transaction date/time, etc. or whatever is in CDOL1), the card has to generate a new (and different) signature ("cryptogram"). Thus, the UN is a challenge that the terminal sends to the card. The card, in turn, has to sign that challenge (togehter with the transaction data) to prove that it received that specific challenge.

The problem is that using the UN, the terminal (and the card issuer host that later verifies the transaction) can only be sure that the card signed that specific challenge + transaction data packed once in its lifetime. It cannot be sure that this signature has been created during a specific interaction between card and terminal. The same transaction could just as well have been overserved by an eavesdropping attacker at an earlier interaction between a terminal and the card or an active attacker could have queried the card for that specific input data (UN + transaction data) at an eariler time.

For instance, an attacker with access to the genuine card could pre-generate transaction signatures for all possible values of UN and a specific set of transaction data (the exact same set that the attacker later expects when paying at a genuine terminal). The attacker then has a set of pre-played data:

UN   Transaction data  Cryptogram
  0  XXXXXXXXXXXXXXXX  AAAAAAAAAA
  1  XXXXXXXXXXXXXXXX  BBBBBBBBBB
  3  XXXXXXXXXXXXXXXX  CCCCCCCCCC
  4  XXXXXXXXXXXXXXXX  DDDDDDDDDD
...        ...            ...

Equipped with some card emulator hardware that can send the given cryptograms upon receiving an UN and the expected transaction data, the attacker can go to an genuine terminal at a merchant and pay using the emulator hardware.

To overcome this possible attack scenario, an additional monotonically increasing transaction counter (ATC) that is managed by the card is used. This also gives the card control over the freshness of the generated cryptograms. Thus, the card makes sure that each signature/cryptogram that it generates differs from all signatures it generated before. This is even the case for two transactions with exactly the same UN and transaction data.

ATC  UN   Transaction data  Cryptogram
  0    Z  XXXXXXXXXXXXXXXX  GGGGGGGGGG
  1    Z  XXXXXXXXXXXXXXXX  HHHHHHHHHH
  3    Z  XXXXXXXXXXXXXXXX  IIIIIIIIII
...  ...   ...            ...

In order to prevent re-use of old transactions, the card issuing host can reject transactions with an ATC value lower than the highest ATC value that it observed in a transaction.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • 3
    Usually some window for ATC value overlap is allowed especially if the card supports offline authorisation: the legitimate offline transaction could reach the issuer *after* some legitimate online authorised transaction had place. In either case this is a task for risk management module to decide if a transaction has to be rejected/declined. – Serge May 11 '16 at 22:40
  • please read "*after* some legitimate" as "*after* subsequent legitimate" in my comment above – Serge May 11 '16 at 22:48
  • @Michael Roland is ATC value 0 valid? According to EMV spec ATC indicates "count of the number of transaction" so is 0 a valid ATC? – mystery Jul 15 '21 at 04:53
2

One more scenario of a transaction replay in addition to @Michael Roland's answer.

In the most cases the Point-of-Sale is not controlled/visually monitored 24/7 by the Acquirer. The malicious merchant or some middle-man (say, telco personnel) may record the traffic and make an attempt to replay (re-send over the wire) the transaction that used non-digital CVM, i.e. signature, the ID visual check, whatever.

There is a lot of different POS-to-AcquirerHostSystem exchange protocols exist. Some of them have optional Message Authentication, some of them have mandatory MAC checks, some of the protocols does not provide message protection at all.

In either case, this last mile is out of issuer awareness nor control. The ATC fixes this problem: no two valid transactions with the same ATC could be send to the issuer as the card ensures the ATC value uniqueness.

Serge
  • 6,088
  • 17
  • 27
0

During arqc calculation Atc value used as input to algorithm. Atc is used as a seed value and cause to generate different cryptogram evertime. So when counter is increasing and different cryptograms generated old arqc values can not be used for new transaction. This prevent replay(use old values) attacks.

Ahmet Arslan
  • 5,380
  • 2
  • 33
  • 35
  • But if terminal already take care of fresh ness different cryptogram by sending nonce to be included in ARQC generation what is the purpose of ATC. – user1887464 Apr 02 '16 at 11:57
0

ATC is also used to get the derivative key from MDK. It is using this derivative key the ARPC is generated.

Adarsh Nanu
  • 2,133
  • 1
  • 13
  • 18