Explain AAC generation process

[Papa Carder]

Overview of AAC Generation Process​

The Application Authentication Cryptogram (AAC) is an 8-byte cryptographic value generated by an EMV chip card to indicate that a transaction has been declined, either offline or after an online authorization attempt. It serves as a Message Authentication Code (MAC) that confirms the decline decision and the integrity of the transaction data, preventing tampering or replays. The AAC is one type of Application Cryptogram (AC), produced when the card's risk management determines the transaction cannot proceed (e.g., due to exceeded limits, failed verification, or issuer decline via ARC). Unlike the Transaction Certificate (TC) for approvals or Authorization Request Cryptogram (ARQC) for online requests, the AAC (indicated by tag 9F27 = 0x00) signals rejection and is used for logging or settlement purposes. The generation follows EMV specifications (e.g., EMV Book 2: Security and Key Management, and Book 3: Application Specification), typically using Triple DES (3DES) in CBC mode with ISO 9797-1 MAC Algorithm 3, though AES variants exist in newer systems.

AAC generation occurs in response to the terminal's GENERATE AC command during Card Action Analysis, where the card evaluates risk parameters (e.g., Issuer Action Codes, Terminal Verification Results). It can happen in the first GENERATE AC (offline decline) or second (after failed online authorization or ARPC verification).

Step-by-Step AAC Generation Process​

The process mirrors TC or ARQC generation but results in a decline cryptogram. It uses the session key SK_AC and transaction data from the Card Risk Management Data Object List (CDOL1 for offline/first AC, CDOL2 for online/second AC).

1. Derive the Session Key (SK_AC):
   • SK_AC is a 16-byte key unique to the transaction, derived from the ICC Application Cryptogram Master Key (MK_AC) and the Application Transaction Counter (ATC) using the Common Session Key (CSK) method (as in prior explanations). This ensures the cryptogram is fresh and tied to the specific transaction.
2. Prepare the Input Data:
   • Gather transaction data as defined in CDOL1 (offline) or CDOL2 (online, potentially including ARPC and ARC for failed verifications). Key elements include: Authorized Amount (9F02), Transaction Currency Code (5F2A), Terminal Verification Results (95), Unpredictable Number (9F37), and for online declines, the ARPC (9F26) and ARC (9F10).
   • Concatenate these in the CDOL-specified order (typically 21-55 bytes).
   • Pad to a multiple of 8 bytes per ISO 9797-1 Method 2 (append 0x80, then 0x00 as needed).
3. Compute the MAC (AAC):
   • Apply a CBC MAC over the padded data using SK_AC, via Retail MAC (ISO 9797-1 Algorithm 3).
     • Split SK_AC into two 8-byte DES keys (left and right).
     • Set IV to 0x0000000000000000.
     • Encrypt blocks: XOR each with the prior ciphertext (or IV for first), then use 3DES (encrypt with left, decrypt with right, encrypt with left for the final block).
   • The AAC is the leftmost 8 bytes of the MAC. The card sets the Cryptogram Information Data (CID, tag 9F27) to 0x00 to indicate AAC (decline).
4. Send the AAC:
   • The card returns the AAC in the GENERATE AC response, along with CID and other data (e.g., Issuer Application Data). The terminal declines the transaction and may log it for reporting.

Key Security Aspects​

• Decline Triggers: Exceeded offline limits, failed CVM (e.g., PIN), risk flags in TVR, or invalid ARPC/ARC.
• Cryptographic Algorithm: 3DES primary, with IV=0 and padding; ensures uniqueness via ATC.
• Contactless Notes: Identical process in NFC (ISO 14443), but with faster kernels.

For full details, consult EMVCo specifications.