Data Objects and Commands

[Tomcat]

Let's start by comparing CPA, M / Chip 4 and VSDC applications in terms of the data objects and commands used in them. Let's dwell on the most important data objects and their formats, as well as on the peculiarities of using commands.

Card Verification Results

Card Verification Results (CVR) is one of the most important data objects that stores the results of the risk management procedures performed by the card. Based on this data, the card makes a decision on how to complete the operation. The CVR data object is a required element of the IAD object transmitted by the card to its issuer during an online transaction.

In VSDC, the CVR size is 4 bytes, including the data length indicator byte (byte '03'h). On M / Chip 4, the CVR size is 6 bytes.

The uniform format of the CVR data object is a prerequisite for the unification of the decision making procedure by the card. This format is defined in the CCD specification (see tables 4.19-4.22). According to EMV 4.2, in a CCD application, the CVR size is 5 bytes.

In VSDC and M / Chip 4 applications, as part of the card risk management procedure using the CVR object, a decision is made on how to proceed with the transaction. In the CPA application, the ADR (Application Decisional Results) data object is used for this, and the CVR object is used only to inform the issuer about the results of checks performed by the card application (for this purpose, the CVR object is also used in the M / Chip 4 and VSDC applications).

The structure of the data field of the ADR object is shown in table. 8.1-8.6.

Tab. 8.1. First byte of the data field of the ADR object

B8	Ь7	B6	B5	B4	ьз	B2	NS	Meaning
1			Last online transaction not completed
	1			The flag "The next transaction is being processed online" is set
		1			Issuer Script Processing Failed
		1			Issuer authentication failed
		1			Issuer Authentication Data was not received by the card during the last online operation.
		1			PIN Try Limit exceeded
		1		PIN Offline verification has not been performed
		1	PIN offline verification failed

Tab. 8.2. The second byte of the data field of the ADR object

B8	Ь7	B6	B5	B4	ьз	B2 b	Meaning
1				Unable to service transaction online
	1		The terminal mistakenly believes that the PIN Offline check has been completed, although the check was either not performed, or it was performed and failed
		1			Card script received
		1			Offline app authentication failed in previous transaction
		1			Found a match in the check Additional Check Table 1
		1		No match found in the check Additional Check Table 1
	3	Found a match in the check Additional Check Table 2
1	No match found in the check Additional Check Table 2

Tab. 8.3. The third byte of the data field of the ADR object

B8	Ь7	B6	B5	B4	ЬЗ	B2	NS	Meaning
1			The lower limit of the Accumulator 1 counter has been exceeded
	1			The lower limit of the Accumulator 2 counter has been exceeded
		1			The lower limit of the counter Counter 1 has been exceeded
		1			The lower limit of the counter Counter 2 has been exceeded
		1			The lower limit of the counter Counter 3 has been exceeded
		1			The lower limit of the Additional Accumulator counter has been exceeded
		1		The lower limit of the Additional Counter is exceeded
		1	Number of Days Offline counter limit exceeded (number of days since last online transaction)

Tab. 8.4. The fourth byte of the data field of the ADR object

B8 b7 b6 b5 b4 b3 b2 b

Meaning

• 1 The upper limit of the Accumulator 1 counter has been exceeded
• 1 The upper limit of the Accumulator 2 counter has been exceeded
• 1 The upper limit of the counter Counter 1 has been exceeded
• 1 The upper limit of the counter Counter 2 has been exceeded
• 1 The upper limit of the counter Counter 3 has been exceeded
• 1 The upper limit of the Additional Accumulator counter has been exceeded
• 1 The upper limit of the Additional Counter has been exceeded
• 1 Maximum Transaction Amount (MTA) limit exceeded

Tab. 8.5. The fifth byte of the data field of the ADR object

B8	Ь7	B6	B5	B4	ЬЗ	B2	NS	Meaning
1			Cyclic Accumulator 1 counter limit exceeded
	1			Cyclic Accumulator 2 counter limit exceeded
		1			Additional Cyclic Accumulator counter limit exceeded
		1			Check Failed: npoH3onma error preventing the execution of risk management procedures (for example, data is missing or data is not in the correct format)
		X			Bit reserved
		X			Bit reserved
		X		Bit reserved
		X	Bit reserved

Tab. 8.6. Sixth byte of the ADR object data field

B8	Ь7	B6	B5	B4	ЬЗ	B2	NS	Meaning
X	X	X	X	X	X	X	X	Values are reserved for use by the issuer

Issuer Application Data

The Issuer Application Data (IAD) object is an important data object used to transfer information from the card to the issuer. This information is used by the issuer to decide on how to complete the transaction. In accordance with the requirements of the EMV 4.2 standard, the length of the data field of the IAD object does not exceed 32 bytes. In the IAD object, the issuer usually receives the CVR object, offline application counters, information about the key used to generate the cryptogram and the version of the cryptogram, as well as additional information (Issuer Discretionary Data) determined by the issuer when personalizing the card and used by it to authorize the transaction. Additional information may include some of the current application parameters and the results of terminal checks obtained during the operation.

According to the CCD, the IAD object is exactly 32 bytes in size. The format of the IAD object is shown in Fig. 8.1.

Tad '9F10'

Length '20’h

'OF'h (1 byte)

CCI (1 byte)

DKI (1 byte)

CVR 5 (byte)

Counters (8 bytes)

'OF'h (1 byte)

INDEED

Rice. 8.1. IAD CCD Application Data Object Format

In fig. 8.1 the following abbreviations are used:

• - CCI (Common Core Identifier) is a data element, the first nibble of which identifies the IAD format, and the second nibble identifies the cryptogram version. Currently, the CCI element can have a single value "A5" b;
• - DKI (Derived Key Identifier) - data element defining the identifier of the issuer key used to generate the card key, which is used to calculate the session key for calculating the cryptogram;
• - IDD (Issuer Discretionary Data) - a set of data values that, in the opinion of the issuer, is necessary for him to make a decision on the completion of the operation. The list of data whose values make up the content of the IDD is determined by the card issuer. IDD can include Terminal Verification Results (TVR), ICC Dynamic Number (IDN), Data Authentication Code (DAC), Issuer Script Results (results of the Issuer Script Processing procedure), CVM Results (results of the cardholder verification procedure), etc.
• - Exactly the same format (see Fig. 8.1) has the IAD object in the CPA application.

In the VIS specification, the Issuer Application Data is:

Tad '9F10'

Length

VISA Discretionary Data Length=‘06’h (1 байт)

VISA Discretionary Data (6 bytes)

IDD Length

INDEED

VISA Discretionary Data includes CVN (Cryptogram Version Number, 1 byte), DKI (Derivation Key Indicator, 1 byte) and CVR (4 bytes) objects.

The data field of the IAD object in the M / Chip Select 4 appendix is 18 bytes long and is presented in the table:

Data item	Length, bytes
Key Derivation Index	1
Cryptogram Version Number	1
Card Verification Results	6
DAC/ICC Dynamic Number	2
Plaintext/Encrypted Counters	8

Issuer Discretionary Data is missing in the M / Chip 4 application IAD object data field.

Application Control

M / Chip 4 and CPA applications support the Application Control data object, which enables or disables certain features of the application, and also determines how a number of features of the application are implemented. For example, this data object defines:

• - algorithm for outputting session keys of the card;
• - a set of keys used to encrypt the PIN-block when performing the PIN Offline verification procedure;
• - the need to activate the Additional Check Table (only for M / Chip 4) or select a profile (only for CPA);
• - conditions for changing the counters and indicators of the card;
• - the need to include offline meters in the IAD;
• - the need to encrypt offline meters during their transfer to the issuer, etc.

The Application Control object is not supported in VSDC.

Card Status Update

The Card Status Update is an evolution of the M / Chip 4 ARPC Response Code and has a data field size of 4 bytes. The structure of the object is shown in table. 4.24-4.27. It is not used in M / Chip 4 and VSDC applications.

The role of the object in the CPA application is great. It determines the result of authorization of the transaction by the issuer, and also solves a number of tasks of the Script Processing procedure: changing the offline parameters of card risk management, blocking the card / application, etc.

Decision making by the card

The card makes a decision on how to complete the operation in the M / Chip 4 and VSDC applications based on the CVR data, and in the CPA application based on the ADR object data. At the same time, as described in paragraph 4.11, the decision criteria are formalized in M / Chip 4 and VSDC in different ways. M / Chip 4 uses Card Issuer Action Code (CIAC) objects, VSDC uses an ADA object (4 bytes in size). The CIAC model is selected in the cards with the CPA application. The structure of CIAC-Default, CIAC-Decline, CIAC-Online objects completely repeats the structure of the ADR object (see Table 8.1-8.6).

ARQC cryptogram

Table 8.7 shows the difference between the data used to compute the ARQC cryptogram in VSDC and CCD applications. The difference is that the CPA application uses the IAD element containing the CVR instead of the CVR element.

Tab. 8.7. Data used to form a cryptogram

SCREW 1.4 и M / Chip 4	CCD
Amount, Authorized	Amount, Authorized
Amount, Other	Amount, Other
Terminal Country Code	Terminal Country Code
Terminal Verification Results	Terminal Verification Results
Transaction Date	Transaction Date
Transaction Type	Transaction Type
Unpredictable Number	Unpredictable Number
Application Interchange Profile	Application Interchange Profile
Application Transaction Counter	Application Transaction Counter
Card Verification Results	Issuer Application Data including CVR

The rest of the algorithm for calculating the cryptogram in the CCD remains the same. The changes affected only the algorithm for generating a card key with a PAN value of more than 16 digits. In CCD, it was replaced by a different algorithm (cryptogram version 5). In accordance with this algorithm, the session key for outputting the cryptogram is output using the 3DES algorithm using the card key, in which the Application Transaction Counter number is used as an argument.

ARPC cryptogram

In the CPA application, the ARPC cryptogram is computed using the ISO 9797-1 MAC computation algorithm 3 applied to the sequence Z = ARQC11CSU. The 4 leftmost bytes of the result obtained are used as a cryptogram.

The VIS and M / Chip specifications use the following cryptogram generation algorithm:

• ARC (Authorization Response Code) is padded on the right with six zero bytes: X: = (ARC 11 '00' 11 '00' 11 '00' 11 '00' 11 '00' 11 '00');
• Y: = ARQC © X;
• ARPC: = DES3 (SK ac ) [Y], that is, the Triple DES algorithm is applied to Y on the session key of the SK AC cryptogram output .

Issuer Authentication Data

In the CPA application, the data field of the Issuer Authentication Data object (Tag '91') has a variable length from 8 to 16 bytes and its format is shown in the table.

Bytes	Content
1-4	Authentication Response Code (ARPC)
5-8	Card Status Update (CSU)
9-16	Proprietary Authentication Data (optional)

Typically, in practice, the Issuer Authentication Data field is ARPC || CSU and size 8 bytes (the CDOL2 list contains the mandatory Tag pair '91' and is 8 bytes long).

In M / Chip 4 and VSDC applications, the Issuer Authentication Data object's data field is ARPC || ARC, i.e. the size of this data element is exactly ten bytes (see 4.12).

The issuer can send an Issuer Authentication Data element of 10 bytes to the card, as is customary in VSDC and M / Chip 4. In this case, the terminal itself will truncate the rightmost bytes, sending only the leftmost 8 bytes to the card in the GENERATE AC command.

To transfer Issuer Authentication Data from the terminal to the card, the VSDC application uses the EXTERNAL AUTHENTICATE command, and the M / Chip 4 and CPA applications use the GENERATE AC command.

Secure Messaging Command Format

The CCD specifications, and thus the CPA application, require all commands using Secure Messaging to be in Format 1 (the command data field is in TLV format). VSDC uses Format 2, M / Chip 4 uses Format 1.

Terminal command response format

In the CCD specifications, and therefore in the CPA application, format 2 support is required in card responses to commands (the command response data field is in TLV format). M / Chip 4 supports Format 2, VSDC uses Format 1 except when responding to the second GENERATE AC command when using the Combined Dynamic Authentication (CDA) authentication method, when using Format 2 of the command response.

Terminal Velocity Checking Procedure

The CPA application does not support the Terminal Velocity Checking procedure. According to the CCD, the card must not transmit the Lower Consecutive Offline Limit (Tag '9F14') and Upper Consecutive Offline Limit (Tag '9F23') objects to the terminal.

Terminal Velocity Checking can be supported in M / Chip 4 and VSDC applications.

Script Processing Procedure

According to the CCD, the issuer can send only one Issuer Script Template command block to the card (block size less than 128 bytes). At the same time, the CPA application supports critical (Tag '71') and non-critical (Tag '72') Issuer Script Processing procedures.

The M / Chip 4 application also uses critical and non-critical Issuer Script Processing. Only the non-critical Issuer Script Processing is supported in the VSDC application.

DE 55 и 3rd Bit Cardping

The requirement to support field 55 by the processing hosts of banks today is mandatory for all banks of the VISA and MasterCard payment systems (banks are required to support the acceptance of CCD cards). Previously, in the VisaNet network, a third card was used to transfer chip data to the issuer in ISO 8583 messages: additional fields 129-192 of the inter-host message message (in the VisaNet network, only fields 130-149 were used). Note that this was done contrary to the requirement of the ISO 8583 standard, which allows the use of only two cards (messages contain up to 128 fields).

Additional requirements for the CPA application

Additional clarifications to the EMV standard adopted in the CPA appendix are listed below:

• if the Payment System Environment (PSE) directory is supported on the CCD card, it is the only DDF file on the card. In other words, in the CPA card PSE DEF file, all Directory Entries (Tag '61') represent only ADF files. In this case, the CPA card necessarily supports the selection of the application by the shortened name of the directory of the card application (selection of the application by at least 5 high-order bytes of the DF Name, and the card's support for the Next Occurrence indicator in the SELECT command (see section 3.10));
• the third bit of the first byte of the AIP object is 0, that is, the second GENERATE AC command is used to authenticate the issuer;
• in the data element Cryptogram Information Data (CID) contained in the card's response to the GENERATE AC command, the fact of the lack of support for the notification message (advice) is indicated - the card cannot send a notification to the issuer. The M / Chip app also does not support advice notifications, and the VSDC app allows a notification to be sent in the following cases: 1) the PTL limit was exceeded and the transaction was rejected, 2) the transaction was rejected offline, and 3) the issuer authentication failed or failed.
• CPA-card contains a DDOL object, consisting of a single UN data object;
• all applications in question do not support the Application Authorization Referral (AAR) cryptogram.