Comparison of EMV-compatible applications

The purpose of this section is to compare the functionality, security, and implementation features of the most popular EMV-compatible applications on the market. These applications primarily include applications of the leading payment systems VISA and MasterCard, known under the brands VSDC and M/Chip, respectively.
The previous version of the EMV standard (version 4.1, approved in may 2004) introduced the Common Core Definition (CCD) specification and introduced the concept of a CCD application.
The CCD specification specifies the set and format of data used in the card and Issuer dialog, as well as the set and format of commands sent by the terminal to the card for transmitting Issuer data to it. In addition, the CCD specification defines certain features of transaction processing (for example, excluding terminal velocity checking checks), and also unifies the way chip data is exchanged between the Bank host and the payment network (according to the CCD, the DE 55 field of the authorization request/response is required for transmitting chip data).
An important example of a CCD-compatible application is the CPA (Common Payment Application), approved by EMVCo as a standard in December 2005. This is the only EMV application recognized by the MasterCard, VISA, JCB and American Express payment systems as an alternative payment application to their own applications (M/Chip, VSDC, etc.). the Latter means that each Bank of the above-mentioned payment systems has the ability to use both its own unique application of this system and the universal CPA application.
EMVCo has developed procedures for certifying cards for compliance with the CCD and CPA standards — the so-called Card Type Approval procedures. These procedures allow you to check whether the physical parameters of the card meet EMV requirements, as well as the functionality of the card,
this includes the correct execution of functions by the application that ensure the security of operations on the card.
To evaluate the security of the chip and its operating system, a separate special EMVCo Security Evaluation Process is used, applied to cards that support the CCD application and the CPA application.
Certification of cards and applications in accordance with the Card Type Approval and EMVCo Security Evaluation Process is performed by laboratories accredited by EMVCo for these tasks.
The owner of the intellectual property rights to the M/Chip app is MasterCard WorldWide. The m/Chip specification is confidential information.
The owner of the intellectual property rights to the VIS app is VISA International. The VIS specification is confidential information.
The owner of the intellectual property rights to the CPA specification is EMVCo, whose founders at the end of 2009 were MasterCard Worldwide, VISA International, JCB and American Express. The CPA specification is public information, and anyone can download this specification from the EMVCo website www.emvco.com. Any company can use the CPA specification for developing its own card product for free.
If the developer company wants to confirm that the application it has developed meets the CPA specification, it must be certified by EMVCo. The EMVCo website has a list of laboratories accredited by EMVCo to perform such certification.
The VISA and MasterCard payment systems require card providers with the CPA application to certify the card for compliance with the CPA standard if the supplier intends to sell these cards to banks for use in these payment systems.
This section will compare M/Chip 4, VSDC, and CPA applications in terms of:
the data objects and commands they use;
functionalities;
transaction security provided by the application;
the complexity of the implementation.
The following specifications were used for comparative analysis of applications:
for the VSDC application: Visa Integrated Circuit Card (ICC) Specification,
V. 1.4.0, 31 October, 2001, Integrated Circuit Card Specification (VIS) Corrections, November 2003, and Technical guide to applets for Global Platform cards (Technical Guide to Vis’s Applet For Global Platform Cards, March 2007);
for the application M/Chip 4 M/Chip 4 Version 1.1 Card Application Specifications for Debit and Credit, October 2006;
for the CPA application: Common Payment Application Specification, Version 1.0, December 2005, and CPA Specification V. 1 Plus Bulletins, March 2008.
Data objects and commands
Let’s start comparing CPA, M/Chip 4, and VSDC applications in terms of the data objects and commands they use. Let’s focus on the most important data objects and their formats, as well as on the specifics of using commands.
Card Verification Results
Card Verification Results (CVR) is one of the most important data objects that stores the results of risk management procedures performed by the card. Based on this data, the card decides how to complete the operation. The CVR data object is a mandatory element of the IAD object that the card passes to its Issuer during an online transaction.
In VSDC, the CVR size is 4 bytes, including the byte indicator for the length of the data block (byte ‘ 03’h). In the M/Chip 4, the size of the CVR is equal to 6 bytes.
The uniform format of the CVR data object is a necessary condition for unifying the decision-making procedure for the card. This format is defined in the CCD specification. In accordance with EMV 4.2, the size of the CVR in the CCD application is 5 bytes.
In VSDC and M/Chip 4 applications, as part of the card risk management procedure, a CVR object is used to decide how to continue the transaction. The CPA application uses the ADR data object (Application Decisive Results) for this purpose, while the CVR object is only used to inform the Issuer of the results of checks performed by the card application (for this purpose, the CVR object is also used in m/Chip 4 and VSDC applications).
The structure of the ADR object data field is shown in the table.

First byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
1 the Last online transaction was not completed
1 the “Next transaction is processed online” flag is Set»
1 the issue Script Processing Procedure failed
1 Issuer Authentication failed
1 Issuer Authentication Data was not received by the card during the last online operation
1, the maximum PIN Try Limit
1 PIN Offline Verification was not performed
1 PIN Offline Verification failed

Second byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
1 it is not Possible to service the transaction online
1 the Terminal mistakenly believes that the PIN Offline check was performed, although the check was either not performed, or was performed and failed
1 the Script was received by the card
1 Offline app authentication failed in a previous transaction
1 match Found in the Additional Check Table 1 check
1 no match found in the Additional Check Table 1 check
1 match Found in Additional Check Table 2
1 no match found in the Additional Check Table 2 check

Third byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
1 exceeded the lower limit of the Accumulator 1 counter
1 exceeded the lower limit of the Accumulator counter 2
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 has been Exceeded
1 Exceeded the number of Days Offline counter limit (the number of days since the last online operation)

Fourth byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
1 exceeded the upper limit of the Accumulator 1 counter
1 exceeded the upper limit of the Accumulator counter 2
1 Exceeded the upper limit of the Counter Counter 1
1 Exceeded the upper limit of the Counter Counter 2
1 Exceeded the upper limit of the Counter Counter 3
1 the upper limit of the Additional Accumulator counter has been Exceeded
1 the upper limit of the Additional Counter has been Exceeded
1 Exceeded the MTA limit (Maximum Transaction Amount)

Fifth byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
1 exceeded the limit of the counter Cyclic Accumulator 1
1 exceeded the limit of the counter Cyclic Accumulator 2
1 additional Cyclic Accumulator counter limit Exceeded
1 Check Failed: an error occurred that interferes with risk management procedures (for example, missing data or data in an incorrect format)
x Bit reserved
x Bit reserved
x Bit reserved
x Bit reserved

Sixth byte of the ADR object data field

b8 b7 b6 b5 b4 b3 b2 b1 Value
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 for transmitting information from the card to the Issuer. This information is used by the Issuer to make a decision 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 keys used to generate the cryptogram, and verbs these cryptograms, as well as additional information (Issuer Discretionary Data), determined by the Issuer during card personalization and used by it for transaction authorization. Additional information may include some 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

Tag ‘9F10’ Length ’20’h ‘0F’h
(1byte) CCI
(1byte) DKI
(A 1-byte) CVR
5(bytes) Counters (8 bytes) ‘0F’h
(1byte) IDD
Figure 8.1. Format of the IAD data object of the CCD application

CCI — Common Core Identifier) is a data element whose first half — byte defines the IAD format, and the second half-byte defines the cryptogram version. Currently, the CCI element can take a single value of “A5″h;
DKI — Derived Key Identifier) – a data element that defines the ID of the Issuer’s key used for generating 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, it needs to make a decision on the completion of the operation. The list of data whose values make up the IDD content is determined by the card Issuer. The 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), and others.
The IAD object in the CPA application has exactly the same format.
In the VIS specification the data object Issuer Application Data has the form:

Tag ‘9F10’ Length VISA Discretionary Data Length= ‘ 06’h (1 byte) VISA
Discretionary Data (6 bytes) Length IDD IDD

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 application is 18 bytes long and is shown in the table:

Data element Length, bytes
Key Derivation Index 1
Cryptogram Version Number 1
Card Veriﬁcation Results 6
DAC/ICC Dynamic Number 2
Plaintext/Encrypted Counters 8

The data field for the IAD object of the M/Chip 4 application does not contain any Issuer Discretionary Data.

Application Control
M/Chip 4 and CPA applications support an Application Control data object that activates or blocks certain application functions, and defines how to implement a number of application functions. For example, this data object is used to define:
algorithm for displaying session card keys;
a set of keys used to encrypt the PIN block when performing the PIN Offline verification procedure;
whether to activate the Additional Check Table check (only for M/Chip 4) or select a profile (only for CPA);
conditions for changing card counters and indicators;
need to include offline counters in the IAD;
whether offline counters need to be encrypted when they are sent to the Issuer, etc.
The application Control object is not supported in VSDC.

Card Status Update
The Card Status Update object appeared as a development of the ARPC Response Code element used in the M/Chip 4 specification, and has a data field size of 4 bytes. The structure of the object shown In the applications M/Chip 4 and VSDC not in use.

The object’s role in the CPA application is large. It determines the result of transaction authorization by the Issuer, and also solves a number of tasks of the Script Processing procedure: changing offline parameters of card risk management, blocking the card/application, and so on.

Making a decision on the card
The card makes a decision about how to complete the operation in the m/Chip 4 and VSDC applications based on CVR data, and in the CPA application based on the ADR object data. At the same time, the decision criteria are formed in M/Chip 4 and VSDC in various ways. M/Chip 4 uses Card Issuer Action Code (CIAC) objects, while VSDC uses an ADA object (4 bytes in size). In cards with the CPA app, the CIAC model is selected. The structure of CIAC-Default, CIAC-Decline, and CIAC-Online objects completely repeats the structure of the ADR object

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

1.4 VIS and M/Chip 4 CCD
Amount, Authorized Amount, Authorized
Amount, Other Amount, Other
Terminal Country Code Terminal Country Code
Terminal Veriﬁcation Results Terminal Veriﬁcation Results
Transaction Date Transaction Date
Transaction Type Transaction Type
Unpredictable Number Unpredictable Number
Application Interchange Proﬁle Application Interchange Proﬁle
Application Transaction Counter Application Transaction Counter
Card Verification Results Issuer Application Data, including CVR

Otherwise, the algorithm for calculating the cryptogram in the CCD remains the same. The changes only affect the algorithm for generating the 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 cryptogram output is output using the 3DES algorithm using the card key, which uses the Application Transaction Counter transaction number as an argument.

A cryptogram ARPC
In the CPA application, the ARPC cryptogram is calculated using the ISO 9797-1 MAC calculation algorithm 3 applied to the sequence Z = ARQC| / CSU. The 4 leftmost bytes of the result are used as the cryptogram.
The following cryptogram generation algorithm is used in the VIS and M/Chip specifications:
ARC (Authorization Response Code) is padded on the right with six null bytes: X: = (ARC||‘00’||‘00’||‘00’||‘00’||‘00’||‘00’);
Y:=ARQCÅX;
ARPC:=DES3(SKAC) [Y], i.e. the Triple DES algorithm is applied to Y on the session key of the SKAC 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)

Usually, in practice, the data field of the Issuer Authentication Data has the form ARPC| / CSU and the size of 8 bytes (the CDOL2 list contains the required Tag ‘91 ‘ pair and the length of 8 bytes).
In the M/Chip 4 and VSDC applications, the data field of the Issuer Authentication Data object has the form ARPC| / ARC, i.e. the size of this data element is exactly ten bytes
The Issuer can pass the 10-byte Issuer Authentication Data element to the card, as is customary in VSDC and M / Chip 4.in this case, the terminal itself will trim the rightmost bytes, sending only the 8 leftmost bytes to the card in the GENERATE AC command.
The VSDC application uses the EXTERNAL AUTHENTICATE command to transmit the Issuer Authentication Data from the card terminal, and the m/Chip 4 and CPA applications use the GENERATE AC command.

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

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

Terminal Velocity Checking Procedure
The CPA application does not support the procedure for checking offline limits by the terminal (Terminal Velocity Checking). In accordance with the CCD, the card must not pass the lower Sequential Offline Limit (Tag ‘9F14’) and Upper Sequential Offline Limit (Tag ‘9F23’) objects to the terminal.
In M/Chip 4 and VSDC applications, Terminal Velocity Checking can be supported.

Script Processing Procedure
In accordance with the CCD, the Issuer can transmit only one block of commands to the card: the Issuer Script Template (block size less than 128 bytes). At the same time, the CPA application supports critical (Tag ‘71’) and non-critical (Tag ‘72’) procedures for issuing Script Processing.
The M/Chip 4 application also uses critical and non-critical Issuer Script Processing procedures. The VSDC application only supports the non-critical issue Script Processing procedure.

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