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?
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.