9F26 Application Cryptogram

The Application Cryptogram is the 8-byte value at the heart of EMV security. The card computes it over transaction data and its own data, using a key that only the card and its issuer can derive. Depending on the CID, it is an ARQC (online request), a TC (offline approval) or an AAC (decline).

How it is computed

The card derives a session key from its unique card key and the Application Transaction Counter (9F36), so every transaction uses a different key. It then computes a MAC over the data the terminal sent in the GENERATE AC command, as listed in CDOL1 or CDOL2, plus card data such as the AIP and ATC. Typical inputs are the amount, currency, country, date, transaction type, the unpredictable number from the terminal and the TVR. The exact data, session key method and algorithm depend on the scheme and the cryptogram version, which the issuer reads from the Issuer Application Data (9F10).

How it is verified

The issuer, or its processor's hardware security module, rebuilds the same input from the authorisation message, derives the same session key and recomputes the MAC. A match proves the card is genuine and the data was not changed. For an ARQC, the issuer can return an ARPC so the card can authenticate the issuer in turn.

Example

9F26 08 8E 31 A4 F1 D5 B6 C2 90. On its own, the value tells you nothing: it is only meaningful together with the data it covers and the issuer's keys. Use test keys and our 3DES and AES calculator to reproduce cryptograms when debugging.

Common mistakes

• Changing any field covered by the cryptogram between the card and the issuer, for example reformatting the amount or the date. Verification then fails.
• Sending a different unpredictable number online from the one given to the card.
• Using the wrong session key derivation or padding method for the card's cryptogram version.
• Treating a TC or AAC as something the issuer must verify in real time. They are usually checked later, in clearing or disputes.