Understanding APDU Commands: EMV Transaction Flow (Part -2)

Introduction:

Smart cards are widely used in various applications, from payment systems to identification and access control. To facilitate communication between smart cards and card readers or terminals, a standardized protocol called APDU (Application Protocol Data Unit) is employed. In this blog post, we will delve into the world of APDU commands, exploring their structure, purpose, and how they enable seamless interaction between smart cards and devices.

What is an APDU Command?

An APDU command serves as a communication unit between a smart card and a card reader or terminal. It consists of a command header and, optionally, command data. The command header includes essential information such as the command class, instruction, parameters, and command data length. APDU commands are sent from the reader/terminal to the smart card, initiating various actions and operations.

APDU Command Request Format:

The request format of an APDU command follows a specific structure:

• CLA (Class Byte): Specifies the command class and defines the card type or organization.
• INS (Instruction Byte): Identifies the specific command to be performed by the card.
• P1 and P2 (Parameter Bytes): Parameters related to the command, providing additional information or addressing data within the card.
• LC (Length of Command Data): Indicates the length of the Command Data field (if present).
• Data (if applicable): Contains the command-specific data to be sent to the card.

APDU Command Response Format:

Upon receiving an APDU command, the smart card processes the request and sends back a response. The response format consists of two parts:

• Response Data: Contains the data sent by the card in response to the command.
• Status Word (SW1 and SW2): Indicates the status of the command execution, providing information about success, errors, or warnings encountered during the process.

The Status Word (SW1 and SW2) plays a crucial role in interpreting the outcome of an APDU command. It provides insights into the execution status, error codes, and additional details about the command’s success or failure. Careful analysis of the Status Word helps diagnose issues and ensures proper handling of responses.

APDU Command Examples:

Let’s consider a practical example to illustrate the APDU command flow.

Response: SW1: 90 , SW2: 00 (Command successfully executed (OK).)

The persons interested in the SW1/SW2 list can familiarize themselves with it, here, for example.

These commands follow a specific sequence to initialize the transaction, exchange data, and finalize the process.below is the step-by-step flow of APDU commands in a contact-based smart card transaction.

A complete list of all EMV commands (including standard ISO7816–4 commands):

1. SELECT PSA (Payment System Environment):

For the very first step we need to know for which type card we are going to perform the transaction for that we need to go send SELECT PSA command PSA is a directory on the card commonly named “1PAY.SYS.DDF01” in the case a contact chip and “2PAY.SYS.DDF01” is always present on a contactless chip.

In case of contact chip “2PAY.SYS.DDF01” will not be present on the card so we need to check if it is present or not hence we will be able to know if the transaction is being done by contact or contactless.

Let’s understand SELECT CANDIDATE command with an example command i.e. “ 00 A4 04 00 0F 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00” and we are going receive a byte array which can be converted to human readable using TLV(Tag Length Value) format i.e. “6F 20 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0E 88 01 02 5F 2D 04 6E 6F 65 6E 9F 11 01 01” in this first bytes is the TAG next 1 byte is Length in hexadecimal(Let’s say n in decimal) and then next n bytes is value of that TAG and this continues…

Let’s break down the command and understand its components:

• “00” indicates the class of the command, which in this case is a standard command.
• “A4” represents the INS (Instruction) field, specifying the operation to be performed, which is application selection.
• “04 00” is the P1-P2 field, which determines the exact context or purpose of the command. In this example, it indicates that the command is used for application selection by AID.
• “0F” represents the length of the data field and in hexadecimal format, indicating that the AID being sent for selection consists of 15 bytes in decimal format.
• “31 50 41 59 2E 53 59 53 2E 44 44 46 30 31” byte array encoding of string “1PAY.SYS.DDF01”

Let’s break down the response and understand its meaning:

2. READ PSE:

Now, we know which directory in card we need to read to get the AID(Application Identifier). In above SELECT PSE command we know by tag “88” of length 1 byte in tag “A5” of length 14 bytes hennce the directory index “2” in this case

So, we are going to send READ PSE command on index 2. Then command we are going to send to the card from the terminal will be “00 B2 01 02 00”

Let’s break down the command and understand its components:

• “00” indicates the class of the command, which in this case is a standard command.
• “B2” represents the INS (Instruction) field, specifying the operation to be performed, which is application selection.
• “01” is the P1 field, which represents the record number at directory
• “02” is the P2 field, which represents the index of the directory
• “00” is the LC.

In Response of above request we are going this byte array: “70 23 61 21 4F 07 A0 00 00 00 03 10 10 50 04 056 49 53 41 9F 12 0C 56 49 53 41 20 43 6C 61 73 73 59 53 87 01 02”

Let’s break down the response and understand its components:

2. SELECT AID:

The transaction begins with the SELECT command, which is used to select the application on the smart card.. For instance, a SELECT command “00 A4 04 00 07 A0 00 00 00 03 10 10” with the AID (Application Identifier) “A0 00 00 00 03 10 10” is sent from the terminal to the card. The response “6F 37 84 07 A0 00 00 00 03 10 10 A5 2C 50 04 56 49 53 41 87 01 02 9F 38 06 9F 1A 02 5F 2A 02 5F 2S 04 6E 6F 65 6E 9F 11 01 01 9F 12 0C 56 49 53 41 20 43 6C 61 73 73 69 63 90 00” “90 00”confirms a successful application selection. If application is not available we will recieve “6A82 (File not found)”

Let’s break down the command and understand its components:

• “00” indicates the class of the command, which in this case is a standard command.
• “A4” represents the INS (Instruction) field, specifying the operation to be performed, which is application selection.
• “04 00” is the P1-P2 field, which determines the exact context or purpose of the command. In this example, it indicates that the command is used for application selection by AID.
• “07” represents the length of the data field, indicating that the AID being sent for selection consists of seven bytes.
• “A0 00 00 00 03 10 10” represents the actual AID data. Each byte corresponds to a hexadecimal value, so the AID being selected is “A0 00 00 00 04 10 10”.

Let’s break down the response and understand its components:

6F 37 84 07 A0 00 00 00 03 10 10 A5 2C 50 04 56 49 53 41 87 01 02 9F 38 06 9F 1A 02 5F 2A 02 5F 2S 04 6E 6F 65 6E 9F 11 01 01 9F 12 0C 56 49 53 41 20 43 6C 61 73 73 69 63 90 00

3. GET PROCESSING OPTIONS(GPO) :

The GPO command is used to request the processing options for the transaction. It enables the terminal to understand the capabilities and parameters of the card. The command is sent from the terminal to the card, and the card responds with the processing options data. This data guides subsequent steps in the transaction, the command “80 A8 00 00 02 83 00” is sent, and the response “77 4e 82 02 00 00 9F 36 02 00 01 57 13 40 23 60 09 00 12 50 08 D1 80 52 21 15 15 29 93 00 00 0F 9F 10 07 06 0A 0A 03 A0 00 00 9F 26 08 4E 29 20 46 BF 43 38 51 5F 34 01 01 9F 6C 02 30 00 5F 20 0F 56 49 53 41 20 43 41 52 44 48 4F 4C 44 45 52 90 00” contains the processing options data.

Let’s break down the response and understand its meaning:

• “77” indicates that the response data is in extended length format, meaning the data length exceeds 255 bytes.
• “4e” represents the total length of the response data, excluding the status bytes (SW1-SW2).
• “82 02” indicates that the data field consists of two bytes.

In summary, the GPO response provides important information about the card’s capabilities (AIP), the files or records involved in the transaction (AFL), and their respective ranges. This data helps the terminal understand the card’s capabilities and determines how to proceed with the transaction, such as initiating authentication or retrieving specific transaction data.

4. VERIFY :

The VERIFY command is optional and is used to verify a PIN or other authentication information. It provides an additional layer of security. In this step, the terminal sends a VERIFY command with the relevant data, such as a PIN value, to the card for verification. The response confirms the success or failure of the verification process.

The command “00 20 00 80 08 08 12 34 56 78 ff ff ff” is sent to verify the PIN “12345678”. The response “90 00” indicates that the verification was successful.

Let’s break down the command and understand its components:

• “00” indicates the class of the command, which in this case is a standard command.
• “20” represents the INS (Instruction) field, specifying the operation to be performed, which is PIN verification.
• “00 00” is the P1-P2 field, which determines the exact context or purpose of the command. In this example, it indicates that the command is used for a standard PIN verification.
• “08” represents the length of the data field, indicating that the PIN being sent for verification consists of eight characters.
• “08 12 34 56 78 ff ff ff” represents the actual PIN data. Each byte corresponds to a character, so the PIN being sent for verification is “12345678”.

The terminal sends this VERIFY command to the card, indicating the PIN data to be verified. The card then performs the necessary checks to validate the PIN. The card’s response will indicate whether the verification was successful “90 00” or unsuccessful.

5. GENERATE APPLICATION CRYPTOGRAM (AC):

The Generate AC command is typically used when the GPO response does not include the required Application Cryptogram or when additional transaction data needs to be processed by the card to generate the cryptogram. It is used to perform cryptographic calculations on the card side based on the transaction data and key information.

The need to send a Generate AC command depends on the specific requirements of the payment system, card issuer, or the transaction itself. If the GPO response contains all the necessary cryptogram data and the transaction is deemed complete, there may not be a need for an additional Generate AC command.

This command is used to generate an application cryptogram, which serves as a proof of the card’s legitimacy and authorization during the transaction. The command is sent from the terminal to the card, and the card responds with the application cryptogram data. for example, the command “80 AE 40 00 1D 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 09 78 09 07 30 21 F9 94 CB 92 00 00 00” is sent, and the response “9F 26 04 A3 B7 6C E7 90 00” contains the application cryptogram data.

Let’s break down the command and understand its components:

• “80” indicates the class of the command, which in this case is a proprietary command.
• “AE” represents the INS (Instruction) field, specifying the operation to be performed, which is to generate an Application Cryptogram.
• “04 00” is the P1-P2 field, which determines the exact context or purpose of the command. In this example, it indicates the specific options or parameters for generating the AC.
• “1D” represents the length of the data field, indicating that the data being sent for generating the AC consists of twenty nine bytes.
• “00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 09 78 09 07 30 21 23 73 EB A5 66 0A 21 FF 00 00 00” represents the data sent for generating the AC. The specific meaning and format of this data depend on the payment system, the card, and the transaction context.

Let’s break down the response and understand its components:

• “9F 26” is the tag indicating the Application Cryptogram (AC) data element.
• “04” represents the length of the AC data, indicating that the AC consists of four bytes.
• “A3 B7 6C E7” represents the actual Application Cryptogram value.
• “90 00” at the end of the response indicates the SW1-SW2 status bytes, indicating successful processing of the command.

The Application Cryptogram (AC) is a cryptographic value generated by the card to provide proof of the authenticity and integrity of the transaction data. It is typically used during the transaction authorization process to verify that the card is genuine and that the transaction data has not been tampered with.

The specific format and meaning of the AC data may vary depending on the payment system, card application, and transaction context. The AC value is calculated by the card using cryptographic algorithms and is based on the transaction data and other parameters.

In this example, the AC value is “A3 B7 6C E7”. The significance of this value depends on the card and the payment system specifications.

The “90 00” response status bytes indicate that the GENERATE AC command was processed successfully, with no errors or exceptions.

There are two type Cryptogram Transaction Certificate(TC) and Authorization Request Cryptogram (ARQC)

Transaction Certificate(TC): A cryptogram generated by the card at the end of all offline and online approved transactions. The cryptogram is the result of card, terminal, and transaction data encrypted by a DES key. The TC provides information about the actual steps and processes executed by the card, terminal, and merchant during a given transaction and can be used during dispute processing.

Authorization Request Cryptogram (ARQC): A cryptogram used for a process called Online Card Authentication. This cryptogram is generated by the card for transactions requiring online authorization. It is the result of card, terminal, and transaction data encrypted by a DES key. It is sent to the issuer in the authorization or full financial request. The issuer validates the ARQC to ensure that the card is authentic and card data was not copied from a skimmed card.

In above we are going to get the cryptogram in resposne

6. EXTERNAL AUTHENTICATE :

The EXTERNAL AUTHENTICATE command is an optional step that involves additional authentication procedures, if required. It enhances the security of the transaction by performing external authentication steps. The terminal sends the command to the card, and the card responds accordingly. for example, the command “00 82 00 00 08 4E 29 20 46 02 03 38 51 00” is sent for external authentication. The response “90 00” indicates that the authentication was successful.

Let’s break down the command and understand its components:

• “00” indicates the class of the command, which in this case is a proprietary command.
• “82” represents the INS (Instruction) field, specifying the operation to be performed, which is external authentication.
• “00 00” is the P1-P2 field, which determines the exact context or purpose of the command. In this example, it indicates the specific options or parameters for the authentication process.
• “08” represents the length of the data field, indicating that the authentication data being sent consists of eight bytes.
• “4E 29 20 46 02 03 38 51” represents the authentication data, which is a sequence of eight bytes used for the authentication process. The specific format and content of this data depend on the security protocol and key exchange mechanism being used.

7. READ RECORD:

The READ RECORD command is used in EMV transactions to retrieve specific data records stored on a chip card. It allows the terminal to request and read individual records from the card’s file system. Each record typically contains specific data related to the cardholder or the transaction.

The command has the following structure:

00 B2 <Record Number> <P1> <P2> <Le>

• 00: Class byte indicating a standard command.
• B2: Instruction byte for the READ RECORD command.
• <Record Number>: Specifies the number of the record to be read.
• <P1> and <P2>: Parameters that define the behavior of the command, such as the mode for data retrieval.
• <Le>: Expected length of the response data.

The card responds with the requested data record or an error message if the record is not available or the command is not supported.

8. APPLICATION TRANSACTION COUNTER(ATC):

The GET DATA command is typically used to retrieve the Application Transaction Counter (ATC) from a chip card. The ATC represents a counter that increments with each transaction performed by the card application.

The command has the following structure:

80 CA 9F 36 <Le>

• 80: Class byte indicating a proprietary command.
• CA: Instruction byte for the GET DATA command.
• 9F 36: Data Object Identifier (tag) for the Application Transaction Counter (ATC).
• <Le>: Expected length of the response data.

9. GET CHALLENGE:

The GET CHALLENGE command is used to obtain an unpredictable number from the ICC for use in a security-related procedure. The challenge shall be valid only for the next issued command The data field of the response message contains an 8-byte unpredictable number generated by the ICC

The structure of the GET CHALLENGE command is as follows:

00 84 00 00 <Length>

• 00: Class byte indicating a standard command.
• 84: Instruction byte for the GET CHALLENGE command.
• 00 00: Parameters or data field for the command.
• <Length>: Expected length of the response data.

10. PIN TRY COUNTER:

The PIN Try Counter command is used to retrieve the current number of remaining PIN entry attempts on a chip card. This command provides information about the number of PIN tries that are still allowed before the card blocks further PIN entry.

The structure of the PIN Try Counter command depends on the specific card and application, as it may vary. However, a common implementation can be described as follows:

00 20 00 00 00

• 00: Class byte indicating a standard command.
• 20: Instruction byte for the PIN Try Counter command.
• 00 00 00: Parameters or data field for the command.

The card responds with the current PIN try counter value, which represents the number of remaining PIN entry attempts. This value indicates how many more PIN tries are allowed before the card takes any security measures, such as blocking further PIN entry or taking other actions to protect against unauthorized access.

The PIN try counter is typically decremented each time an incorrect PIN is entered, and it is used to enforce security measures and prevent brute-force attacks on the card’s PIN. Once the counter reaches zero, the card may take actions such as blocking further PIN entry or requiring a specific card activation process to be performed.

11. LAST ONLINE ATC REGISTER:

The LastOnlineATCRegister command is used to retrieve the value of the Last Online Application Transaction Counter (ATC) Register from a chip card. The Last Online ATC Register stores the value of the ATC from the last transaction that was successfully processed online.

The structure of the LastOnlineATCRegister command depends on the specific card and application, as it may vary. However, a common implementation can be described as follows:

80 CA 9F 13 <Length>

• 80: Class byte indicating a proprietary command.
• CA: Instruction byte for the GET DATA command.
• 9F 13: Data Object Identifier (tag) for the Last Online ATC Register.
• <Length>: Expected length of the response data.

The card responds with the value of the Last Online ATC Register, which represents the ATC value from the last transaction that was successfully processed online. The length of the response data depends on the implementation, but it is typically 2 bytes.

The Last Online ATC Register value is useful for various transaction-related operations, such as maintaining transaction logs, detecting potential transaction replay attacks, and ensuring the integrity and uniqueness of transaction data.

Conclusion:

APDU commands form the backbone of communication between smart cards and card readers/terminals. Understanding their structure, request/response formats, and the significance of the Status Word is crucial for efficient and secure interactions with smart cards. Whether it’s authentication, data retrieval, or transaction processing, APDU commands enable seamless and reliable communication, empowering the diverse applications of smart card technology.

References:

• ISO/IEC 7816–4:2013 — Identification cards — Integrated circuit cards — Part 4: Organization, security, and commands for interchange
• https://github.com/sasc999/javaemvreader
• https://en.wikipedia.org/wiki/ISO/IEC_7816
• https://ambimat.com/developer-resources/list-of-application-identifiers-aid/
• https://emvlab.org/

(Note: This blog post provides a high-level overview of APDU commands and their concepts. For detailed implementation and specific use cases, referring to relevant specifications and documentation is recommended.)