Understanding SmartCards: A Complete Technical view on EMV and APDU

EMV integrates several standards: the physical and transport layers for contact cards are defined by ISO/IEC 7816 (electrical, ATR/PTS negotiation, T=0/T=1 protocols), and for contactless by ISO/IEC 14443 (anti-collision, activation, frame formats, bit rates). On top of those transports, ISO/IEC 7816-4 specifies the interindustry APDU command/response model. EMV Book 3 defines the data model, transaction state machine, and APDU usage in payment applications. Host authorization commonly uses ISO 8583 to convey chip data (DE55) to issuers. The primary actors are the ICC (contact) or PICC (contactless), the terminal and its EMV kernel, the acquirer/processor, and the issuer.

An APDU is an application-layer request/response pair transported over T=0 or T=1 (or 14443). The command APDU consists of a 4-byte header {CLA, INS, P1, P2}, optional Lc and Data, and optional Le. The response APDU consists of optional Data followed by SW1 SW2. Short-length encodings use single-byte Lc/Le; extended-length encodings use three bytes. The four classical APDU cases are: Case 1 (no data, no Le), Case 2 (no data, Le), Case 3 (Lc+Data, no Le), and Case 4 (Lc+Data and Le).

The status words determine control flow. A terminal must treat any status outside success (90 00) and well-formed advisory responses (62xx/63xx) as a failure. A typical warning is 63 Cx indicating verification failed with x tries remaining. Selection failures return 6A 82 (file or DF not found). Parameter misuse often yields 6A 86 (incorrect P1/P2) or 6A 80 (incorrect data). Security preconditions are signaled by 69 82 (security status not satisfied) or 69 85 (conditions of use not satisfied).

EMV adopts BER‑TLV for the application data model. Tags may be one or more bytes, lengths use definite forms, and values are either primitive (opaque octet strings) or constructed (nesting further TLVs). The discipline is exacting: single-occurrence tags must not repeat in a given context; lengths must not exceed container boundaries; constructed/primitive forms are not interchangeable. EMV defines application templates such as 6F (FCI Template), A5 (FCI Proprietary Template), and 70 (EMV Record Template). A correct parser is strict: it rejects overlength values, duplicate singletons, and illegal forms and distinguishes normalizable encodings from canonical ones during certification testing.

Selection binds the terminal and card to a specific payment application. Two approaches are used.

The first is direct AID selection: the terminal issues SELECT by name with P1/P2 indicating name selection and first occurrence, the data field carrying the AID (RID + PIX, 5–16 bytes). The card returns an FCI with 84 (DF Name) and optionally 50 (Application Label), 9F12 (Application Preferred Name), and 9F38 (PDOL). The status 6A 82 indicates the requested AID is not present.

The second approach uses a directory: contact cards may implement PSE (1PAY.SYS.DDF01) and contactless cards implement PPSE (2PAY.SYS.DDF01). Selecting the directory yields directory records enumerating candidate AIDs and priorities. The terminal reads directory records with READ RECORD, extracts 4F (AID) and 87 (Priority), applies merchant/terminal policy, then performs direct AID selection. Absence of the directory mandates direct selection from terminal configuration.

The AID structure consists of a 5-byte RID (Registered Application Provider Identifier) and a scheme-specific PIX. Device configuration holds the terminal’s supported AIDs with parameters such as floor limits, terminal capabilities, CVM supports, and kernel options; selection succeeds only if the terminal implements the correct kernel for the chosen AID (especially for contactless).

After SELECT, the terminal initiates application processing with GET PROCESSING OPTIONS (GPO). If the FCI contained a PDOL (9F38), the terminal constructs a PDOL value in exactly the order and lengths specified by PDOL entries and wraps it in a 83 template as the data field of GPO. If PDOL is absent, the terminal may send an empty PDOL (83 00) or omit it per EMV rules. The card’s response is either 80 LL AIP(2) AFL(…​) or 77 LL [82 AIP] [94 AFL] …​. The AIP (Application Interchange Profile) announces capabilities such as offline data authentication support (SDA/DDA/CDA), cardholder verification options, and online processing capability. The AFL (Application File Locator) is a sequence of 4-byte items describing which records (record range and SFI) the terminal shall read.

For each AFL entry, the terminal performs a sequence of READ RECORD commands. The parameters are precise: P1 is the record number; P2 encodes the SFI in the high 5 bits and the record-access mode in the low 3 bits, compute P2 = (SFI << 3) | 0x04. Responses are wrapped in the 70 EMV Record Template holding TLVs such as 57 (Track 2 Equivalent), 5A (PAN), 5F24 (Expiry), 5F34 (PAN Sequence), 9F10 (Issuer Application Data), 8E (CVM List), 90 (Issuer Public Key Certificate), and ODA artifacts. Failure to read any record required by AFL is terminal error. The terminal aggregates these data for subsequent authentication, CVM selection, and risk analysis.

EMV’s trust bootstraps from scheme Certification Authority (CA) public keys provisioned to terminals. The Issuer Public Key Certificate (on card) is verified against the CA key; the ICC Public Key Certificate is verified against the Issuer key. This chain authenticates the card’s public key for dynamic operations.

Static Data Authentication (SDA) verifies a signature over static application data. It proves issuer origination and data integrity but does not prevent cloning because the signature is static.

Dynamic Data Authentication (DDA) uses the ICC private key to sign a terminal-provided challenge and card-resident data via INTERNAL AUTHENTICATE. The terminal verifies this signature with the ICC public key, obtaining per-transaction freshness.

Combined DDA/Application Cryptogram (CDA) couples DDA with generation of the first application cryptogram. The response carries a dynamic signature that covers critical application data and binds to the AC, preventing man-in-the-middle modifications between dynamic authentication and cryptogram generation. CDA is preferred in modern profiles due to its superior integrity guarantees at minimal incremental latency on capable hardware.

The CVM List (8E) encodes ordered methods and conditions. The terminal selects the first method mutually supported and applicable given amount, terminal type, and results of offline authentication. Offline PIN (plaintext or enciphered) is used only on the contact interface; the VERIFY command conveys a PIN block that the card checks against the reference, updating the PIN try counter (9F17). Online PIN is verified by the issuer host rather than by the ICC. Signature requires merchant comparison and does not involve the ICC. For contactless, consumer-device verification methods (CDCVM) satisfied on a mobile device can fulfill the CVM requirement. The results contribute bits in TVR (Terminal Verification Results) and map into the card’s CVR (often present inside the Issuer Application Data).

The terminal computes TVR based on outcomes of ODA, CVM, exception file checks, velocity, and amount limits. It enforces the acquirer-defined floor limit and online selection rules (including random selection). The card enforces issuer policy with Issuer Action Codes (IAC-Default, IAC-Denial, IAC-Online) and issuer risk limits (e.g., cumulative offline amount 9F50, offline spending limit 9F1B, and counters). The goal is a coherent Terminal Action Analysis and Card Action Analysis that converge to one of three paths: offline approve, go online, or offline decline.

The first GENERATE AC requests the card to compute an application cryptogram over CDOL1-provided data. The terminal constructs the CDOL1 payload exactly in the tag order and lengths specified by 8C. Typical inputs include amount, other amount, terminal country code, transaction currency code, transaction date, transaction type, unpredictable number, TVR, TSI, terminal capabilities, additional terminal capabilities, and terminal type. The command header 80 AE carries request semantics via the CID request bits; in practice, the terminal requests ARQC for online or TC for offline approval.

The response is returned as a TLV set (often in 77). It contains the Application Cryptogram (9F26), the Cryptogram Information Data (9F27), the ATC (9F36), and the Issuer Application Data (9F10). The cryptogram is a MAC-like value computed under a session key derived from issuer master keys and the ATC; historically, 3DES retail MAC algorithms were used, while contemporary designs can employ AES CMAC where supported. The CID value encodes whether the returned cryptogram is ARQC (request online), TC (offline approval), or AAC (decline). The card may override the terminal’s request based on IAC evaluation and internal limits.

When ARQC is returned, the terminal packages EMV data in ISO 8583 field DE55 (EMV data field) and submits an authorization request via the acquirer to the issuer. The issuer validates the ARQC using card-specific keys, evaluates account and fraud risk, and returns an authorization decision. It may include Issuer Authentication Data (91, commonly the ARPC) and Issuer Scripts (71/72). Issuer authentication is executed either explicitly via EXTERNAL AUTHENTICATE or implicitly by including 91 in CDOL2 for the second GENERATE AC. A correct card will validate ARPC and refuse completion if issuer authentication fails or scripts are tampered with. Issuer scripts execute as secure commands authenticated by issuer script keys and allow post-issuance management (e.g., setting counters, blocking applications, updating parameters).

The second GENERATE AC consumes CDOL2 data (including the authorization response code and, if applicable, issuer authentication artifacts) and returns the final cryptogram: TC if approved or AAC if declined. The ATC is updated accordingly. The terminal performs any required script processing and reports script results upstream. For some legacy host protocols, a post-completion “EMV Final Advice” leg is sent to synchronize the terminal and host state with the final cryptogram and issuer authentication outcome.

The online authentication anchor is the ARQC, a MAC-like value computed under a session key derived from issuer master keys. A common derivation uses the ATC combined with card identifiers to derive the unique session key from the issuer’s per-card master key (for example, a 3DES key diversification with left/right halves based on ATC). The MAC over CDOL1 inputs and selected card/terminal parameters yields the ARQC. The issuer recomputes the expected ARQC from DE55 to authenticate the request.

The issuer response contains the Authorization Response Code (ARC) and optionally the ARPC. A widespread ARPC construction is to transform the ARQC under the session key with ARC embedded (for example, XOR of a two-byte ARC into a defined block position prior to MACing) to produce a value the card can verify with its session key. A verified ARPC assures the ICC that the issuer approved the transaction and that the response is fresh and authentic. If ARPC verification fails, the ICC must not produce TC in the second GENERATE AC.

Offline data authentication relies on RSA public-key cryptography. Certificate formats in EMV are compact encodings tailored to smart cards, carrying moduli and exponents within constrained lengths and including hashes and padding conforming to EMV’s variants of ISO 9796/PKCS #1 conventions for legacy deployments. CDA’s signature covers dynamic fields and the application cryptogram request/response context, preventing “wedge” attacks that alter terminal-provided inputs between dynamic authentication and AC generation.

Contactless profiles reuse the same APDU vocabulary with kernel-specific behavior. PPSE (2PAY.SYS.DDF01) selection is mandatory; the Terminal Transaction Qualifiers (9F66) dictate support for magstripe-mode fallbacks, EMV-mode processing, and CVM capabilities. Offline PIN is excluded on RF; privacy considerations often omit 5F20 (Cardholder Name). Timers are strict, influencing retry logic and field durations. Outcome parameter sets inform the terminal’s user interface without additional card APDUs. Mobile wallets introduce DPAN tokenization and CDCVM, reducing PAN exposure and shifting cardholder verification to the secure element or device trust zone while preserving EMV cryptographic assurances at tap time.

The acquirer message includes DE55 carrying a BER‑TLV subset of EMV data: typical elements are 9F26 (AC), 9F27 (CID), 9F10 (IAD), 9F37 (UN), 9F36 (ATC), 95 (TVR), 9A (Date), 9C (Type), 9F02 (Amount), 5F2A (Currency), 82 (AIP), and 9F1A (Country Code). The issuer host reproduces the CDOL context from DE55 to validate ARQC and to decide whether to return 91 (Issuer Authentication Data) and scripts. Mapping of PAN, expiry, service code, and track data aligns with DE2/DE14/DE35/DE45 as permitted by scheme rules; PIN data, if online, is carried in DE52 (encrypted under acquirer/issuer PIN keys).

Robust implementations share several invariants. TLV parsing is strict, with canonical acceptance and defensive rejection of malformed values. PDOL/CDOL order is honored literally; missing tags are filled with zeroes only where the specification permits and never omitted silently. READ RECORD P2 is computed as (SFI<<3)|0x04, and the terminal respects the AFL record boundaries. Unpredictable Numbers are high-quality random values to the bit-length required by the profile; low-entropy UNs cause certification failures and enable replay lab attacks. CVM selection is faithful to 8E semantics; offline PIN is never attempted on contactless. EXTERNAL AUTHENTICATE is issued only if the AIP indicates support; otherwise, 91 is provided via CDOL2. Logging avoids sensitive fields: full PAN, track data, IAD, cryptograms, and keys are never persisted, and all traces use lab data during integration and certification.

EMV mitigates cloning by binding approvals to transaction-unique cryptograms. It reduces cardholder impersonation with PIN and CDCVM. It constrains offline risk via issuer-configured counters and limits and forces online reviews on suspicious patterns. Attack classes to consider include relay attacks (extending RF range to misuse genuine cards), terminal compromise (PIN pad malware or key extraction), and protocol downgrades (switching kernels/modes). Defenses include anti-relay distance‑bounding for future contactless enhancements, PCI PTS-compliant cryptographic modules for PIN entry, strict kernel configuration (e.g., disallow MSD-mode when EMV-mode is supported), and telemetry for issuer risk engines. The combination of asymmetric trust bootstrapping and symmetric per-transaction authentication has empirically displaced counterfeit card fraud in EMV‑adopted regions.

This condensed trace demonstrates a nominal online EMV transaction over contact. Values are illustrative.

A parser should reject ambiguous TLV encodings and detect length overruns promptly. The UN must be unpredictable to the card; do not use counters or timestamps without cryptographic randomization. The terminal must not silently elide PDOL elements: if a PDOL entry is unknown, EMV permits sending a zero-filled value of the specified length rather than omitting the field. Missing AFL records are a terminal error, not a recoverable condition. CVM failures set TVR bits and generally preclude offline approval. Issuer Authentication failure must prevent TC at completion. Logs exclude sensitive data: mask PAN, never store Track 2, IAD, cryptograms, or any keys.

EMV’s discipline is the product of a conservative APDU abstraction, strict BER‑TLV data modeling, a layered authentication and authorization pipeline, and issuer‑configurable risk controls. Its effectiveness against cloning arises from transaction‑unique symmetric cryptograms verifiable by issuers, while its resilience against cardholder impersonation follows from robust CVM choices, particularly offline/online PIN and device CVM in mobile wallets. Correctness hinges on exact PDOL/CDOL conformance, strict TLV parsing, precise AFL traversal, high‑entropy unpredictability, and careful handling of issuer authentication and scripts. Implementations that respect these invariants achieve both interoperability and strong security assurances in the presence of realistic adversaries.