CODEWITHSUNDEEP
cryptographydigital-signaturesmartcardemvreplay
user1887464
user1887464

Reputation: 557

What is the purpose of Application Transaction Counter stored in EMV chip for ARQC generation?

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?

Upvotes: 4

Views: 19273

Answers (4)

Serge
Serge

Reputation: 6095

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.

Upvotes: 2

Michael Roland
Michael Roland

Reputation: 40831

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.

Upvotes: 12

Adarsh Nanu
Adarsh Nanu

Reputation: 2211

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

Upvotes: 0

Ahmet Arslan
Ahmet Arslan

Reputation: 6130

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.

Upvotes: 0

Related Questions