Specification of the EMV standard in the CPA application

Additional requirements for the CPA application
Further refinements of the EMV standard adopted in application CPA 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 PSE CPA card DEF file, all Directory Entry objects (Tag ‘61’) represent only ADF files. At the same time, the CPA card must support selecting the application by the shortened name of the card application directory (selecting the application by at least 5 higher bytes of DF Name, and the card’s support for the Next Occurrence indicator in the SELECT command);
the third bit of the first byte of the AIP object is 0, i.e. the second GENERATE AC command is used to authenticate the Issuer;
the Cryptogram Information Data (CID) element contained in the card’s response to the GENERATE AC command indicates that there is no support for the notification message (advice) — the card cannot transmit the notification to the Issuer. The M/Chip app also does not support advice notifications, and the VSDC app allows sending notifications in the following cases: 1)the PTL limit was exceeded and the transaction was rejected, 2)the transaction was rejected offline, and 3)Issuer authentication failed or failed;
The CPA card contains a DDOL object consisting of a single data object.;
all the applications under consideration do not support the AAR (Application Authorization Referral) cryptogram.

A comparison of the functionality of the application
The functionality of an application is mainly determined by the functionality of the following procedures that it performs:
selecting the operation processing method during application initialization;
ensuring the integrity of sensitive application data;
offline and online authentication of the card app;
verification of the card holder;
application risk management procedures, including:
used offline app counters (cumulative, transactional counters, maximum transaction size, ways to reset counters);
methods supported by currency conversion during processing of a transaction;
transaction logs;
authentication of the Issuer;
generating a cryptogram of the transaction;
Script Processing procedures.
Let’s focus on each of the above procedures separately.

Selecting the transaction processing method
The transaction processing method is selected when the card processes the GET PROCESSING OPTIONS command. Of course, in terms of choosing the way to process a transaction, the CPA application is the most advanced, far ahead of the very limited capabilities of VSDC applications, and even more so of M/Chip 4.
To begin with, in VSDC and M/Chip applications, the transaction processing method is defined only by two objects — AIP (Application Interchange Profile, ‘82’) and AFL (Application File Locator, ‘94’), which are returned to the terminal in response to the GET PROCESSING OPTIONS command.
As described above, the AIP object “instructs” the terminal about the capabilities of the card application:

informs the terminal of offline authentication methods supported by the application;
informs the terminal about the application’s support for cardholder verification (the presence of a CVM List object on the card).
notifies the terminal about the Issuer’s authentication method: using the EXTERNAL AUTHENTICATE command or the second GENERATE AC command;
notifies the terminal of the need for the terminal to perform terminal risk management procedures (floor limit, velocity checking, stop-list, etc.);
sometimes (in the case of M/Chip 4, PayPass) informs the terminal about the type of contactless mode supported by the card.

Typically, these AIP and AFL objects are defined in VSDC and M/Chip 4 applications when the application is personalized, and are independent of the transaction and terminal characteristics. In accordance with EMV 4.2 specifications, the terminal characteristics and transactions required by the application to select the transaction processing method can be reported to the application in the data of the GET PROCESSING OPTIONS command. The set of data expected by the card application is defined in the PDOL object (Tag ‘9F38’), which contains the tags and lengths of data objects expected by the application. This object is set in the application’s FCI Template ADF file during personalization of the card application.
In the M/Chip 4 application, the PDOL object is always empty (missing in FCI Template)! This means that the M/Chip 4 application does not support selecting the transaction processing method. This drawback, as we saw in Chapter 7, was particularly sensitive for contactless applications, when the terminal’s ability to immediately inform the card of the data it needs to make a decision at the beginning of the operation significantly reduces the operation execution time.
The VSDC application may contain a non-empty list of PDOLS. The most commonly used PDOL list includes the Terminal Country Code object (Tag ‘9F1A’). This object is used for checking so-called geographical restrictions. For example, if the transaction turns out to be an in-country transaction, the card can terminate processing of the selected application and the terminal can proceed to executing another card application that is intended for processing in-country operations.
If the card supports VLP transaction processing mode, VLP Terminal Support objects are added to the VSDC application’s PDOL

Indicator (Tag ‘9F7A’), Amount Authorized (Tag ‘9F02’), and Transaction Currency Code (Tag ‘5F2A’). Using these objects, the card determines how the current operation will be performed — in standard VSDC mode or in VLP mode (i.e., it must be in offline mode with authorization of the operation against the VLP Available Fund application parameter).
In the PDOL of the VISA contactless application qVSDC, a mandatory object is the Terminal Transaction Qualifiers object (Tag ‘ 9F66’), which defines the terminal’s capabilities for processing a contactless operation, as well as the terminal’s offer for further processing of the transaction after the terminal performs pre-processing.
In the case of using CPA, the transaction processing method is determined by the application profile, which specifies the data set used during the operation:
set (AIP, AFL);
CIAC objects used by the CPA application to decide how to continue processing a transaction;
the object Issuer Options Profile Control;
three offline counters;
two cumulative offline counters;
two cumulative cyclic offline counters;
the maximum size of a transaction;
the parameters of the VLP-processing.

The dependence of offline counters on the app profile is limited. Regardless of the profile, the rules for changing the counter during operation processing and two sets of counter limits are defined. The counter depends on the profile by selecting one of two sets of limits, as well as determining whether it is necessary:
activation of the counter for this profile (used or not used).
resetting the counter value after an online operation;
enabling the counter in the IAD data object.

Note that in addition to the counters defined by the app profile, the app can use three counters that are independent of the card profile. These counters include Additional Counter, Additional Accumulator, and Additional Cyclic Accumulator.

In other words, the profile selection completely determines the card behavior, i.e. the composition and content of the card application’s risk management procedures that will be performed by the CPA application when processing the operation.

An important element of the Profile Control data is the issue Options object. This object defines the need for the transaction to be executed:
logging a transaction;
activate additional checks based on the GENERATE AC command data.
resetting the counter for the number of days since the last online operation;
encryption of offline counter data when transmitting it to the Issuer in IAD,
as well as the ability to bypass CIAC-Default checks for CAT3 devices (terminal type=26), the data size in the first and second GET commands

PROCESSING OPTIONS, values, and Common Core Identifier Derivation Key Index.
The Common Core Identifier object (equal to ‘A5’h for any CCD application) defines the format of the Issuer Application Data and the cryptogram version.

The Structure Of The Issuer Options Profile Control
Important elements of the issue Options object are additional checks (up to two checks) that are defined for the card payment application regardless of the selected profile. In this case, the CPA application profile only determines whether each of the checks should be performed. Additional checks are performed based on the data received by the card in the first GENERATE AC command.
Additional check x (x = 0, 1, or 2) is defined by the Additional Check Table x object as the number of the first byte (Position) and the number of bytes of data extracted from the GENERATE AC (Length) command to perform the check);
Comparison Blocks
Comparison Value (n – 1)
Position Length Number of Blocks(n) Bit Mask

Structure of the Additional Check Table x object the number (n-1) of comparison value blocks and the actual values of comparison blocks defined by the application Issuer;
the Bit Mask used to get comparison data from the extracted data of the GENERATE AC command.
If the extracted data is equal to one of the pre-defined values of The comparison Value by the Issuer, the check is considered completed with a positive result (a match was found). The results of the checks determine the corresponding ADR bits and thus influence the decision of the card application based on the results of the risk management procedure. Diagram of the algorithm for performing additional verification
The CPA also defines three dedicated profiles:
Default Proﬁle (Proﬁle ID= ‘01’);
Authentication Token Proﬁle (Proﬁle ID= ‘7E’);
VLP Proﬁle (Proﬁle ID= ‘7D’).
The first profile (Default Profile) is used when the application does not use the option to select a profile (this is set by a specific bit of the Application Control object of the CPA application).
The second profile is used for implementing the one-time password generation function in accordance with the Chip Authentication Program (CAP/DPA) algorithm.
Finally, the third profile (VLP Profile) is used to implement the VLP mode (Visa Low Value Payments) for processing transactions for small amounts. The peculiarity of this profile is that no offline card counter changes its value when it is used. In addition, in this case, the transaction size is not checked against the MTA (Maximum Transaction Amount).
The application profile is selected for a specific transaction based on the data from the GET PROCESSING OPTIONS command

Diagram of the additional application verification algorithm CPA
The card (Profile Selection Identifier byte)and the Profile Selection File. The Profile Selection File consists of Profile Selection Entry entries, each of which is a brick in the application profile selection procedure.
Type of entry Profile Selection Table Entry
Each entry in the Profile Selection Table defines:
the number of the first byte (Position) and the number of bytes of data extracted from the GET PROCESSING OPTIONS command;
the number (n-1) of comparison value blocks and the actual values of comparison blocks defined by the application Issuer;
a Bit Mask used to get comparison data from previously extracted data in the GET PROCESSING OPTIONS command;
the type of comparison Type Check;
actions of the CPA application in case of a positive comparison result for the current Profile Selection Table Entry (Positive Action).
actions of the CPA application in case of a negative comparison result for the current Profile Selection Table Entry (Negative Action).

Entry Length Position Comparison Block Length Number of blocks <n)
Bit Mask Comparison Value 1 Comparison Value 2
Comparison Value (n – 1) Check Type Positive Action Negative Action

The Structure Of The Profile Selection Table Entry

The Check Type element defines the type of comparison of the data of the Comparison Value 1,…, Comparison Value n entry Profile Selection Table Entry with the selected data of the GET PROCESSING OPTIONS command.
If the comparison type is “equality”, the number of Comparison Value blocks can be any natural number. If the comparison type is “greater” or “less”, then a single Comparison Value 1 block is used.If the comparison type is “equal”, the check is considered successful if the data selected from the GET PROCESSING OPTIONS command is equal to any of the Comparison Value 1,…, Comparison Value n blocks.
The Positive Action and Negative Action elements of the Profile Selection Table Entry record determine the next actions of the CPA application to select its profile. These elements are 1 byte each. If bit 8 of the Positive Action or Negative Action element is 0, bits 7-1 define The profile ID that the application selects. If bit 8 of the Positive Action or Negative Action element is equal to 1, bits 7-1 determine the number of Profile Selection Table Entry entries that must be skipped before accessing the next entry in the Profile Selection Table.

Algorithm for selecting a card profile
Some implementations of the CPA application may support the optional option to select the application profile not only based on the GET PROCESSING OPTIONS command, i.e. transaction and terminal data, but also based on the card data. To do this, the CPA application uses the Profile Selection Diversifier (PSD) object, whose data field is one byte in size and is associated with certain application parameters defined by the Issuer (for example, the CPA application AID).
The PSD is used in the following way. It is added to the data of the GET PROCESSING OPTIONS command on the left (Fig. 8.8). Then everything is the same as if the object PSD was part of the team data GET PROCESSING OPTIONS: as the result of accession PSD data block undergoes the same processing using the Bit mask,

Using The Profile Selection Diversifier
Then the table is Profile Selection Table application profile CPA to handle the transaction.
It follows from the above that in the CPA application, you can set almost any criteria for selecting an application profile based on the characteristics of a transaction, terminal, and card (Profile Selection Diversifier)!
Finally, note that the CPA application can be used without the option to select an application. To do this, just set the value of bit 4 of byte 2 of the Application Control object data field to 0.
Conclusion. Summarizing the above, it should be noted that CPA provides an almost universal mechanism for selecting the transaction processing method depending on the operation parameters (transaction size, terminal country code, terminal type, terminal capabilities, etc.), as well as the parameters of the card application (Profile Selection Diversifier). Allow it:
depending on the business setting or for security reasons, process the transaction in the most efficient way (for example, in-country transactions can only be performed offline, and transactions from high-risk countries (Malaysia, Thailand, etc.) can only be processed online);
save on the number of card applications, and therefore on the EEPROM memory used. For example, the VISA DPA application is implemented using a separate application with AID=‘A0000000038002′. If you use the CPA app on the card, you don’t need to have an additional DPA (or CAP) app. The functionality of such an application can be implemented using the CPA application profile.

In the VSDC application, the choice of how to process a transaction is reduced to choosing the VLP mode or choosing the application, depending on the results of checking geographical restrictions.
As for the m/Chip 4 application, it does not support the choice of the transaction processing method at all. The following caveat is possible here. If the MasterCard card supports contact and contactless mods, since mods are implemented by two different applications (although with the same AID ID), each mod has its own parameters (AIP, AFL).

Ensuring the integrity of sensitive application data
It should be noted that all the EMV applications we are considering ensure the integrity of sensitive data stored in the application using two mechanisms:
signing sensitive data with the Issuer’s key and verifying this signature (Signed Static Application Data, Tag‘93’) by the terminal during transaction processing using the card application’s static authentication procedure;
checks the card’s public key certificate (ICC Public Key Certificate, Tag ‘9F46’) for cards that support dynamic authentication. In accordance with EMV 4.2 Book2, the data signed when creating a certificate includes sensitive application data (Static Data to be Authenticated) and thus ensures the integrity of this data. Since 2011, this mechanism for ensuring the integrity of static data will become the main one in the regions of MasterCard Europe and VISA CEMEA (Russia belongs to these regions), since from this time banks will be required to issue DDA cards. The static authentication method is no longer used on new Bank cards of the specified regions.

Ensuring the integrity of sensitive application data solves two problems:
guarantees the integrity of sensitive application data while it is being read by the terminal using the READ RECORD command. recall that the CDA method ensures the integrity of data exchanged between the application and the terminal only when executing the GET PROCESSING OPTIONS and GENERATE AC commands;
makes it impossible to personalize a fake card from a blank page.

Conclusion. All the applications under consideration (CPA, M/Chip 4, VSDC) ensure the integrity of the static data they store in the same way and are therefore equivalent from this point of view.
Offline and online authentication of the card app
The applications in question (M/Chip 4, VSDC, CPA) support all three offline authentication methods (SDA, DDA, CDA) and online authentication using ARQC/ARPC cryptograms.
The difference between the ARQC (Authorization Request Cryptogram) generation methods between the M/Chip 4 and VSDC applications on the one hand and the CPA application on the other is as follows. As previously noted, in contrast to the first two applications in CPA, ARQC generation uses the IAD (Issuer Application Data) object instead of the CVR (Card Verification Results) object, which includes offline counters (optional) and the Issuer Discretionary Data in addition to the CVR.
Conclusion. Offline app authentication is performed in all apps in the same way. When performing online authentication in a CPA application, the cryptogram is generated using an IAD object that includes offline application counters in addition to CVR. As we know, the ARQC cryptogram, in addition to being used by the Issuer to authenticate the application, performs the function of ensuring the integrity of the data transmitted by the card to the Issuer. This ensures the integrity of the values of the counters transmitted to the Issuer.
This advantage of the CPA app is certainly not decisive. The fact is that in the m/Chip 4 application, counters can be transmitted to the Issuer in encrypted form (in the CPA application, counters can also be encrypted for transmission to the Issuer, which is determined by the Issuer Options Profile Control object). Encryption of counters makes the task of modifying counter values to the advantage of fraudsters almost impossible. When fraudsters modify encrypted counter values, they don’t know how they will change as a result — whether they will increase or decrease.