The functionality of an application is mainly determined by the functionality of the following procedures it performs:
8.2.1. Choosing a way to process a transaction
The choice of the transaction processing method is carried out during the card processing of the GET PROCESSING OPTIONS command. Of course, from the point of view of choosing a method of processing a transaction, the CPA application is the most advanced, far ahead of the very limited capabilities of VSDC applications and even more so M / Chip 4.
To begin with, in VSDC and M / Chip applications, the way a transaction is processed is determined by only 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 command. OPTIONS.
As described above, the AIP object "instructs" the terminal about the capabilities of the card application:
- informs the terminal of the offline authentication methods supported by the application;
Typically these AIPs and AFLs are defined in VSDC and M / Chip 4 applications when personalizing the application and are independent of transaction and terminal characteristics. In accordance with the EMV 4.2 specifications, the terminal and transaction characteristics required by the application to select how to process the transaction can be communicated to the application in the data of the GET PROCESSING OPTIONS command. The set of data cards expected by an application is defined in a PDOL object (Tag '9F38') containing the tags and lengths of data objects expected by the application. This object is specified in the FCI Template of the application ADF file during personalization of the card application.
In M / Chip 4 application, PDOL object is always empty (not in FCI Template)! This means that the M / Chip 4 application does not support the choice of how the transaction will be processed. This drawback, as we saw in Chapter 7, turned out to be especially sensitive for contactless applications, when the ability of the terminal to immediately tell the card the data it needs to make a decision at the beginning of the operation can significantly reduce the operation time.
A VSDC application can contain a non-empty PDOL. The most commonly used PDOL list includes the Terminal Country Code object (Tag '9F1A'). This object is used to check so-called Geographical Restrictions. For example, if the transaction turns out to be in-country, the card can complete processing of the selected application and the terminal can proceed to execute another card application designed to process in-country new transactions.
In the case when the card supports VLP transaction processing mode, VLP Terminal Support objects are added to the PDOL of the VSDC application
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 the standard VSDC mode or in the VLP mode (that is, it is mandatory in offline mode with the authorization of the operation against the VLP Available Fund application parameter).
In the PDOL of the qVSDC contactless application of the VISA system, a mandatory object is the Terminal Transaction Qualifiers object (Tag '9F66'), which determines the terminal's capabilities for processing a contactless transaction, as well as the terminal's proposal for further processing of the transaction after the terminal has performed preliminary processing.
In the case of using CPA, the method of transaction processing is determined by the application profile, which specifies the data set used during the operation (Fig. 8.2):
In other words, the choice of the profile completely determines the behavior of the card, that is, the composition and content of the risk management procedures for the card application, which will be performed by the CPA application when processing the transaction.
/
/
Profile control 'x'
An important piece of Profile Control data is the Issuer Options object. This object determines the need for the transaction in progress:
PROCESSING OPTIONS, Common Core Identifier and Derivation Key Index values.
The Common Core Identifier object (equal to 'A5'h for any CCD application) defines the Issuer Application Data format and version of the cryptogram.
In fig. 8.3 shows the structure of the Issuer Options Profile Control object.
Rice. 8.3. Issuer Options Profile Control structure
Important elements of the Issuer Options object are the additional checks (up to two checks) defined for the card payment application, regardless of the selected profile. The CPA application profile in this case only determines the need to perform each of the checks. Additional checks are performed based on the data received by the card in the first GENERATE AC command.
An additional check x (x = 0, 1, or 2) is defined by the Additional Check Table x, shown in Fig. 8.4.
The figure shows that the Additional Check Table x object defines:
• the number of the first byte (Position) and the number of data bytes of the GENERATE AC command (Length) extracted to perform the check;
Comparison Blocks
Rice. 8.4. The structure of the Additional Check Table x object
The CPA application also defines three dedicated profiles:
The second profile is used to implement the function of generating one-time passwords in accordance with the Chip Authentication Program (CAP / DPA) algorithm.
Finally, the third profile (VLP Profile) is used to implement the VLP (Visa Low Value Payments) mode of processing low-value transactions. 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 against the MTA (Maximum Transaction Amount) is not checked.
The choice of an application profile for a specific transaction is based on the data of the GET PROCESSING OPTIONS command, position data
I length
Rice. 8.5. Scheme of additional verification of the CPA application
Card (Profile Selection Identifier byte) and Profile Selection File. The Profile Selection File consists of Profile Selection Entries, each of which is a building block in the process for selecting an application profile.
The Profile Selection Table Entry is shown in Fig. 8.6.
In fig. 8.6 you can see that each entry in the Profile Selection Table defines:
Check Type
Rice. 8.6. Profile Selection Table Entry structure
Positive Negative
Action Action
Comparison Blocks
The Check Type element defines the type of comparison of the Comparison Value 1, ..., Comparison Value n of the Profile Selection Table Entry with the selected data of the GET PROCESSING OPTIONS command.
If the comparison type is "equal", then the number of Comparison Value blocks can be any natural number. If the comparison type is "greater than" or "less", then a single Comparison Value 1 block is used. If the comparison type is "equal", then the check is considered successful if the data selected from the GET PROCESSING OPTIONS command is equal to any of the Comparison Value blocks 1, ..., Comparison Value n.
The above algorithm is shown in Fig. 8.7.
The Positive Action and Negative Action elements of the Profile Selection Table Entry determine the further actions of the CPA application to select its profile. These elements are 1 byte in size each. If bit 8 of the Positive Action or Negative Action element is 0, then bits 7-1 define the Profile ID that the application selects. If bit 8 of the Positive Action or Negative Action element is 1, then bits 7-1 determine the number of Profile Selection Table Entries that must be skipped before accessing the next Profile Selection Table entry.
position
i length
Rice. 8.7. Algorithm for selecting a card profile
Some implementations of the CPA application may support the optional option of selecting an application profile not only by the data of the GET PROCESSING OPTIONS command, i.e. transaction and terminal data, but also based on card data. To do this, the CPA application uses a Profile Selection Diversifier (PSD) object, the data field of which is one byte in size and is associated with some issuer-defined application parameters (for example, with the AID of the CPA application).
Used by PSD as follows. It is added to the left of the data of the GET PROCESSING OPTIONS command (Figure 8.8). Then everything happens in the same way as if the PSD object was part of the data of the GET PROCESSING OPTIONS command: the data block obtained as a result of attaching the PSD is subjected to the same processing using the Bit mask,
Chapter 8. EMV COMPATIBLE APPLICATIONS COMPARISON 595
-DI
position
Rice. 8.8. Using Profile
Selection diversifier
after that, according to the Profile Selection Table, there is a CPA application profile for processing the transaction.
From the above it follows that in the CPA application it is possible to set almost any criterion for selecting an application profile according to the characteristics of a transaction, terminal and card (Profile Selection Diversifier)!
Finally, note that the CPA application can be used without being able to select the application. To do this, it is sufficient to set the value of bit 4 of byte 2 of the data field of the Application Control object to 0.
Output. Summarizing the above, it should be stated that CPA provides an almost universal mechanism for choosing the method of processing a transaction, depending on the parameters of the operation (transaction size, terminal country code, terminal type, terminal capabilities, etc.), as well as the parameters of the card application (Profile Selection Diversifier ). This allows:
As for the M / Chip 4 application, it does not at all support the choice of the method of processing a transaction. The following caveat is possible here. If the MasterCard supports contact and contactless modes, then since the mods are implemented by two different applications (albeit with the same AID), each mod has its own parameters (AIP, AFL).
8.2.2. Ensuring the integrity of sensitive application data
It should be noted that all EMV applications we consider ensure the integrity of sensitive data stored in the application using two mechanisms:
8.2.3. Offline and online card application authentication
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 noted earlier, in contrast to the first two applications in CPA, when forming ARQC, instead of the CVR (Card Verification Results) object, the IAD (Issuer Application Data) object is used, which includes, in addition to CVR, offline counters (optional) and Issuer Discretionary Data.
Output. Offline application authentication is performed the same way across all applications. When performing online authentication in the CPA application, the IAD object is taken into account when generating the cryptogram, which includes, in addition to CVR, offline application counters. 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 transmitted to the issuer of the counters.
This advantage of the CPA application is, of course, not decisive. The fact is that in the M / Chip 4 application, the counters can be transferred to the issuer in encrypted form (in the CPA application, the counters can also be encrypted for transmission to the issuer, which is determined by the Issuer Options Profile Control object). Encrypting the counters makes the task of modifying the counter values in a way that is advantageous for fraudsters almost impossible to solve. By modifying encrypted counter values, fraudsters do not know how they will change as a result - increase or decrease.
8.2.4. Cardholder verification
All considered applications support cardholder verification in the same way: verification methods (CVM Code) and their application codes (Condition Code) are the same in all applications and comply with the EMV v.4.2 standard.
Output. All considered applications support cardholder verification in exactly the same way: verification methods and codes for their use are the same in all applications.
8.2.5. Card risk management procedures
The card's risk management procedures are the main component of its functionality. When using online authorization, the EMV card performs the risk management procedures twice - each time after the card receives the GENERATE AC command.
As a result of the implementation of the risk management procedure in accordance with the EMV specifications, the answers to the following questions are determined:
In the VIS specification, card risk management is performed using ADA (Application Decisional Actions) data objects, internal application parameters (for example, Online Requested by Card Indicator) and CVR. In this case, the “event-driven” principle of making a decision by the card is used. In accordance with this principle, the ADA object (data field size 4 bytes) defines a set of special events that influence the adoption of a decision card by the application, and for each such event determines the application's decision regarding either how the current transaction ends, how the next transaction is processed, or about the need to generate an advice message.
To illustrate, the ADA set contains the following rule: "If the issuer authentication fails, then the next transaction must be processed online." If this rule is activated by the issuer during card personalization (the corresponding bit in the ADA object is equal to 1), then it determines the next event. If card authentication fails during the current operation, the card application must set the Online Requested by Card Indicator of the application's internal indicator to 1.
For CPA and M / Chip 4 applications, card risk management is done using CIAC (Card Issuer Action Codes) and ADR (Application Decisional Results for CPA application) / CVR (for M / Chip 4) data objects. CIAC objects have a different format in CPA and M / Chip 4 applications. However, they are used in the same way technologically.
There are three objects - CIAC-Decline, CIAC-Online, CIAC-Default. Each of the listed objects defines the same list of events that influence the decision-making of the card. If the value of some bit in CIAC is 1, then provided that the ADR / CVR element corresponding to this bit is also 1, depending on which CIAC object the check is performed for, the card:
In terms of functionality, both approaches (table and event) are equivalent.
From the point of view of the criteria used to make the card decision, the considered EMV applications are also equal and allow you to respond to all the most important results of the card risk analysis. This applies to events such as PTE limit exceeded, Issuer Authentication not performed, Issuer Authentication failed, Issuer Script Processing failed, Last online transaction not completed, Set go online next transaction, Offline Authentication failed at previous transaction, PIN Offline verification failed, new card, etc.
Note that all three EMV applications do not support the application authorization referral mode.
With regard to support for advice messages, the M / Chip and CPA applications do not support these messages, and the VSDC application requests the terminal (via Cryptogram Information Data, CID, Tag '9F27') to send an advice message to the card issuer in the following cases:
Key checks performed by the card as part of its risk management procedures relate to the use of so-called offline card counters. Let us consider these counters, their use, the possibility of transmission to the issuer and the procedure for resetting values.
Offline counters for VSDC app. As described in Section 4.10, the VSDC application uses four counters and four corresponding limits, exceeding which counters automatically require an online operation. Counters include:
The values of all the above limits can be obtained by the terminal using the GET DATA command and can be changed by the issuer using the PUT DATA command when executing the Script Processing procedure.
In some VSDC implementations, offline limit values can be transmitted to the issuer in the Issuer Discretionary Data section of the IAD object (in M / Chip 4 and CPA, the counter values are transmitted in the payment system section, i.e. they are mandatory and can be encrypted). In general, support for the transfer of offline meters to the issuer is optional (Implementer-option). However, it is supported in VSDC 2.5 and 2.7 applets.
In addition, the VSDC has an Available Offline Spending Amount data object (Tag '9F52') that indicates the amount available for offline use. This object can be retrieved by the terminal using the GET DATA command and displayed on the terminal screen or printed on a transaction receipt.
Offline counters in M / Chip 4 app. Offline counters in this app are much simpler than in VSDC. There are two counters in total, and each has an upper and lower limit.
• Cumulative Amount is funds spent on successful offline transactions performed in currencies that can be converted to Application Currency using the Currency Conversion Table (Tag 'DI'). The Cumulative Amount counter has two limits - Upper Cumulative Offline Limit and Lower Cumulative Offline Limit. These two limits can be used in different ways by the CIAC mechanism. The most common use case is as follows. If the Lower Cumulative limit is exceeded
Offline Limit, then the card requests the execution of the transaction in real time. If the Upper Cumulative Offline Limit is exceeded and the terminal is offline or is not able to process the transaction online, the card asks to reject the transaction.
• If the transaction currency is not the application currency and is not present in the Currency Conversion Table ('D1'), then a successful offline transaction is appended to the second Consecutive Offline Transaction Number counter . This counter has two limits, the Upper Consecutive Offline Limit and the Lower Consecutive Offline Limit. If the Lower Consecutive Offline Limit is exceeded, then the card requests the execution of the transaction in real time. If the Upper Consecutive Offline Limit is exceeded and the terminal is offline or is unable to process the transaction online, the card asks to reject the transaction.
Both offline counters can be transferred to the issuer in the IAD object. Whether offline meters are transferred to the IAD, as well as whether the meters need to be encrypted are determined by the issuer in the Application Control object.
The values of all offline limits can be received by the terminal using the GET DATA command and can be changed by the issuer using the PUT DATA command when executing the Script Processing procedure.
In addition, the M / Chip 4 app has an Offline Balance data object ('9F50') that indicates the amount currently available for offline use. This object can be retrieved by the terminal using the GET DATA command, if specified in the Application Control object, and displayed on the terminal screen or printed in the transaction receipt.
In addition to checking offline counters, the M / Chip 4 application also checks that the size of the processed transaction does not exceed the Maximum Transaction Amount limit . In addition, in the M / Chip 4 application, it is possible to perform one additional Check Table based on the data obtained by the card in the first GENERATE AC command. The result of the check is recorded in the CVR.
Offline counters of the CPA application. The CPA application supports a set of seven offline counters, depending on the selected profile:
It should be noted that when performing checks with cumulative counters, it is possible to use up to 14 different currency conversion tables (for each counter, the table is defined at the level of the selected application profile). You have to resort to currency conversion whenever the transaction currency does not match the counter currency, which does not depend on the application profile.
In the CPA application, as part of card risk management procedures, in addition to checking offline meters, the following additional checks, depending on the selected profile, can be performed:
Up to two additional checks are applied in the CPA application (two Additional Check Table data objects can be stored on the card). Only one Additional Check Table can be used in the M / Chip 4 app. The VSDC application does not use additional checks at all.
Output. From the point of view of the card risk management procedure, by far the CPA application is the most functional. It uses ten different offline counters, allowing the issuer to monitor the card's offline activity based on a variety of criteria. Of the ten counters, seven depend on the selected application profile. Limits for each of these counters are set at the application profile level. There is a flexible system for converting the transaction currency into the currencies of cumulative meters (its own currency for each meter). In this case, the values of the elements of the conversion table are also determined at the level of the application profile.
In addition to the limits for cumulative meters, the CPA application can support other limits:
The M / Chip 4 application is inferior to CPA in the number of offline counters (only two for the entire application without the option to select a profile) and the number of additional checks (no more than one). In addition, in M / Chip 4, the currency of the cumulative limit and the maximum transaction size is necessarily the same as the currency of the application. At the same time, the M / Chip 4 application retains the ability to reset the offline limit values by the card issuer using the CSU (Card Status Update) object.
VSDC uses 4 offline limits with a fixed mechanism for resetting their values. The application uses only two currencies, between which the conversion ratio is set. VSDC does not support any other limits (such as maximum transaction size) and additional checks. A distinguishing feature of the VSDC application is its support for advice messages.
With all the difference in the capabilities of card risk management procedures for performing the main function - maintaining a balance between the client's offline funds on the card and his funds on the main account - the applications considered are equivalent.
Issuer Authentication
The issuer is authenticated by the card according to the value of the Issuer Authentication Data object received by it. If bit 3 of byte 1 of AIP “Issuer authentication is supported” = 0, the second GENERATE AC command is used to authenticate the issuer by the terminal. The M / Chip 4 and CPA use the GENERATE AC command, and the VSDC use EXTERNAL AUTHENTICATE.
VSDC and M / Chip 4 applications use the first ARPC generation method: ARQC is modulo 2 with (ARD || '00' 11 '00' 11 '00' 11 '00' 11 '00' 11 '00') and the resulting result is encrypted on the session key to generate a cryptogram. Here ARD (Authorization Response Data) is a 2 byte data item that is included as 9 and 10 bytes of the Issuer Authentication Data item.
In VSDC, the ARD element is a regular authorization code. In M / Chip 4, this element is called the ARPC Response Code and, in addition to informing the application about the authorization result, it allows the card issuer to change the PTC (PIN Try Counter) value, set the Go online on next transaction flag, and also instruct the card to reset the application's offline limits.
The CPA application uses Method 2 of ARPC generation. In this case, to obtain ARPC to the value Y = ARQC || Z || 00000000 Algorithm 3 of ISO / IEC 9797-1 MAC computation is applied (MAC size is 4 bytes). ARPC object is used as Issuer Authentication Data || Z. In this case, the Z object is a 4-byte CSU (Card Status Update) object, which, in addition to informing the application about the result of the authorization of the transaction by the issuer, allows the issuer to change the PTC value (PIN Try Counter), block the card, block the card application, set the Go flag online on next transaction, and instruct the card to reset the app's offline limits.
Output. M / Chip 4 applications, and especially CPA, allow during the issuer authentication process to reset the parameters of the card application (for example, offline counters), thereby providing an alternative mechanism for the Script Processing procedure. This property is very useful, but not critical to the functionality and security of the card.
Transaction cryptogram transmission
All three applications support the generation of a transaction cryptogram, which serves as proof that a card transaction was performed and to ensure the integrity of the data transmitted to the issuer. The only difference in cryptograms is that the cryptogram of the CPA application, as opposed to the M / Chip 4 and VSDC applications, uses the IAD object instead of the CVR object, which includes, among other things, the CVR object.
Output. The cryptogram generated in the CPA application, in addition to its main purpose - online authentication of the card application - ensures the integrity of the offline counters of the application.
Issuer Script Processing
VSDC application can use only non-critical Script Processing procedure (Issuer Script Template has Tag '72'), M / Chip 4 and CPA applications use both non-critical (Tag '72') and critical (Tag '71') processing. The ability to use the critical Script Processing procedure obviously increases the flexibility of the card risk management procedure. For example, the issuer can change the values of CIAC objects or another parameter of the selected profile of the CPA application for a specific transaction and only then enable the card to perform the risk management procedure. At the same time, it should be recognized that the ability to use the critical Script Processing procedure in the overwhelming majority of cases is a function that is not in high demand by the issuer.
In terms of the set of commands supported by Script Processing, all applications are equivalent. The CPA application, unlike the M / Chip4 and VSDC, does not support the BLOCK APPLICATION and BLOCK CARD commands. This is because the implementation of these functions in the CPA application is possible using the CSU (Card Status Update) object.
In general, it should be recognized that the support of ARPC Response Codes and CSUs respectively by M / Chip 4 and CPA applications is an advantage of these applications. Support for these objects allows some application parameters to be changed in a safe and reliable way compared to Script Processing. The substitution of a part of the Script Processing function is especially fully implemented in the CSU object of the CPA application.
It should be noted that in all the considered applications, within the Script Processing procedure, using the UPDATE RECORD command, you can change the records in the linear application files. The PUT DATA command is used to modify data in nonlinear files. With this command, you can change all of the risk management settings for the card applications that are not normally stored in the line files of the application.
It should be noted the richer capabilities of the Script Processing procedure of the CPA application, which make it possible to modify almost all application parameters, even the parameters for selecting an application profile.
Output. VSDC can use only non-critical Script Processing, while M / Chip 4 and CPA applications use both non-critical and critical Script Processing. The ability to apply a critical procedure obviously increases the flexibility of card risk management. At the same time, this additional flexibility in most cases is not demanded by the issuer of the application. Therefore, it cannot be considered a significant advantage of applications that support the critical Script Processing procedure.
Support for contactless fashion
The M / Chip 4 and VSDC applications support contactless mode based on the unified EMV Contactless Communication Protocol version 2.0. EMVCo has also developed Type Approval testing procedures for EMV Contactless Communication Protocol version 2.0.
CPA app does not support contactless mode.
Output. The CPA application does not support contactless mode, and this is a serious limitation to its use by issuers seeking to provide their customers with contactless payment service.
VSDC and M / Chip 4 APPs support contactless mode. QVSDC application is more efficient from the point of view of the speed of execution of the transaction, each time keeping within the processing time of the operation within the limit of 500 ms. The indicator of 500 ms can also be achieved on M / Chip 4 cards using microcontrollers with the appropriate bit depth and clock frequency.
A quick summary of app functionality
Below is a brief summary of the functionality of the CPA, M / Chip 4 and VSDC applications.
In terms of functionality, the applications are of course different from each other. So the VSDC application supports only two currencies (application currency and secondary currency), can optionally transfer counters to the application issuer in clear text and provides only non-critical Script Processing procedure. M / Chip 4 does not support the choice of transaction processing method at all, and CPA lacks support for the contactless application mode.
The above comparative analysis of applications is reflected in table. 8.8.
Tab. 8.8. Comparative analysis of application functionality
The end of the table. 8.8
- - the choice of the method of processing the operation during the initialization of the application;
- - ensuring the integrity of sensitive application data;
- - offline and online authentication of the card application;
- - verification of the cardholder;
- - application risk management procedures, including:
- offline application counters used (cumulative, transactional counters, maximum transaction size, methods for resetting counters);
- supported methods for converting currencies during transaction processing;
- transactional logs;
- - issuer authentication;
- - generation of the transaction cryptogram;
- - Script Processing procedures.
8.2.1. Choosing a way to process a transaction
The choice of the transaction processing method is carried out during the card processing of the GET PROCESSING OPTIONS command. Of course, from the point of view of choosing a method of processing a transaction, the CPA application is the most advanced, far ahead of the very limited capabilities of VSDC applications and even more so M / Chip 4.
To begin with, in VSDC and M / Chip applications, the way a transaction is processed is determined by only 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 command. OPTIONS.
As described above, the AIP object "instructs" the terminal about the capabilities of the card application:
- informs the terminal of the offline authentication methods supported by the application;
- - informs the terminal that the application supports cardholder verification (there is a CVM List object on the card);
- - informs the terminal about the issuer's authentication method: using the EXTERNAL AUTHENTICATE command or the second AC GENERATE command;
- - informs the terminal about 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 AIPs and AFLs are defined in VSDC and M / Chip 4 applications when personalizing the application and are independent of transaction and terminal characteristics. In accordance with the EMV 4.2 specifications, the terminal and transaction characteristics required by the application to select how to process the transaction can be communicated to the application in the data of the GET PROCESSING OPTIONS command. The set of data cards expected by an application is defined in a PDOL object (Tag '9F38') containing the tags and lengths of data objects expected by the application. This object is specified in the FCI Template of the application ADF file during personalization of the card application.
In M / Chip 4 application, PDOL object is always empty (not in FCI Template)! This means that the M / Chip 4 application does not support the choice of how the transaction will be processed. This drawback, as we saw in Chapter 7, turned out to be especially sensitive for contactless applications, when the ability of the terminal to immediately tell the card the data it needs to make a decision at the beginning of the operation can significantly reduce the operation time.
A VSDC application can contain a non-empty PDOL. The most commonly used PDOL list includes the Terminal Country Code object (Tag '9F1A'). This object is used to check so-called Geographical Restrictions. For example, if the transaction turns out to be in-country, the card can complete processing of the selected application and the terminal can proceed to execute another card application designed to process in-country new transactions.
In the case when the card supports VLP transaction processing mode, VLP Terminal Support objects are added to the PDOL of the VSDC application
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 the standard VSDC mode or in the VLP mode (that is, it is mandatory in offline mode with the authorization of the operation against the VLP Available Fund application parameter).
In the PDOL of the qVSDC contactless application of the VISA system, a mandatory object is the Terminal Transaction Qualifiers object (Tag '9F66'), which determines the terminal's capabilities for processing a contactless transaction, as well as the terminal's proposal for further processing of the transaction after the terminal has performed preliminary processing.
In the case of using CPA, the method of transaction processing is determined by the application profile, which specifies the data set used during the operation (Fig. 8.2):
- set (AIP, AFL);
- CIAC objects used by the CPA application to decide how to proceed with transaction processing;
- Issuer Options Profile Control object;
- three offline counters;
- two cumulative offline meters;
- two cumulative cyclical offline counters;
- maximum transaction size;
- VLP processing parameters.
- - activation of the counter for this profile (used or not used);
- - resetting the counter value after an online operation;
- - including the counter in the IAD data object.
In other words, the choice of the profile completely determines the behavior of the card, that is, the composition and content of the risk management procedures for the card application, which will be performed by the CPA application when processing the transaction.
/
/
Profile control 'x'
- ? Issuer Options Profile Control ID
- ? CIACs ID
- ? Accumulator 1 Profile Control ID
- ? Accumulator 2 Profile Control ID
- ? Counter 1 Profile Control ID
- ? Counter 2 Profile Control ID
- ? Counter 3 Profile Control ID
- ? Cyclic Accumulator 1 Profile Control ID
- ? Cyclic Accumulator 2 Profile Control ID
- ? Max Transaction Amount Profile Control ID
- ? VLP Accumulator Profile Control ID
An important piece of Profile Control data is the Issuer Options object. This object determines the need for the transaction in progress:
- - transaction doping;
- - activation of additional checks according to the data of the GENERATE AC command;
- - resetting the counter of the number of days that have passed since the last online transaction;
- - encryption of data of offline meters during their transfer to the issuer in the IAD,
PROCESSING OPTIONS, Common Core Identifier and Derivation Key Index values.
The Common Core Identifier object (equal to 'A5'h for any CCD application) defines the Issuer Application Data format and version of the cryptogram.
In fig. 8.3 shows the structure of the Issuer Options Profile Control object.
Rice. 8.3. Issuer Options Profile Control structure
Important elements of the Issuer Options object are the additional checks (up to two checks) defined for the card payment application, regardless of the selected profile. The CPA application profile in this case only determines the need to perform each of the checks. Additional checks are performed based on the data received by the card in the first GENERATE AC command.
An additional check x (x = 0, 1, or 2) is defined by the Additional Check Table x, shown in Fig. 8.4.
The figure shows that the Additional Check Table x object defines:
• the number of the first byte (Position) and the number of data bytes of the GENERATE AC command (Length) extracted to perform the check;
Comparison Blocks
| L | |||||||
| Position | Length | Number of Blocks  | Bit Mask | Comparison Value 1 | Comparison Value 2 | Comparison Value (n -1) |
Rice. 8.4. The structure of the Additional Check Table x object
- the number (n - 1) of Comparison Value comparison blocks and the actual values of the comparison blocks determined by the issuer of the application;
- Bit Mask used to obtain comparison data from the extracted data of the AC GENERATE command.
The CPA application also defines three dedicated profiles:
- Default Profile (Profile ID = '01');
- Authentication Token Profile (Profile ID = * 7E ');
- VLP Profile (Profile ID = '7D').
The second profile is used to implement the function of generating one-time passwords in accordance with the Chip Authentication Program (CAP / DPA) algorithm.
Finally, the third profile (VLP Profile) is used to implement the VLP (Visa Low Value Payments) mode of processing low-value transactions. 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 against the MTA (Maximum Transaction Amount) is not checked.
The choice of an application profile for a specific transaction is based on the data of the GET PROCESSING OPTIONS command, position data
I length
Rice. 8.5. Scheme of additional verification of the CPA application
Card (Profile Selection Identifier byte) and Profile Selection File. The Profile Selection File consists of Profile Selection Entries, each of which is a building block in the process for selecting an application profile.
The Profile Selection Table Entry is shown in Fig. 8.6.
In fig. 8.6 you can see that each entry in the Profile Selection Table defines:
- - number of the first byte (Position) and the number of retrieved data bytes of the GET PROCESSING OPTIONS command;
- - the number (n - 1) of Comparison Value blocks and the actual values of the comparison blocks, defined by the issuer of the application;
- - mask (Bit Mask), used to obtain comparison data from the previously extracted data of the command GET PROCESSING OPTIONS;
- - type of comparison Check Toure;
- - 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 result of comparison for the current Profile Selection Table Entry (Negative Action).
| Bit Mask | Comparison Value 1 | Comparison Value 2 | Comparison Value (n -1) |
Check Type
Rice. 8.6. Profile Selection Table Entry structure
Positive Negative
Action Action
| Entry Length | Position | Comparison Block Length | Number of blocks |
Comparison Blocks
The Check Type element defines the type of comparison of the Comparison Value 1, ..., Comparison Value n of the Profile Selection Table Entry with the selected data of the GET PROCESSING OPTIONS command.
If the comparison type is "equal", then the number of Comparison Value blocks can be any natural number. If the comparison type is "greater than" or "less", then a single Comparison Value 1 block is used. If the comparison type is "equal", then the check is considered successful if the data selected from the GET PROCESSING OPTIONS command is equal to any of the Comparison Value blocks 1, ..., Comparison Value n.
The above algorithm is shown in Fig. 8.7.
The Positive Action and Negative Action elements of the Profile Selection Table Entry determine the further actions of the CPA application to select its profile. These elements are 1 byte in size each. If bit 8 of the Positive Action or Negative Action element is 0, then bits 7-1 define the Profile ID that the application selects. If bit 8 of the Positive Action or Negative Action element is 1, then bits 7-1 determine the number of Profile Selection Table Entries that must be skipped before accessing the next Profile Selection Table entry.
position
i length
Rice. 8.7. Algorithm for selecting a card profile
Some implementations of the CPA application may support the optional option of selecting an application profile not only by the data of the GET PROCESSING OPTIONS command, i.e. transaction and terminal data, but also based on card data. To do this, the CPA application uses a Profile Selection Diversifier (PSD) object, the data field of which is one byte in size and is associated with some issuer-defined application parameters (for example, with the AID of the CPA application).
Used by PSD as follows. It is added to the left of the data of the GET PROCESSING OPTIONS command (Figure 8.8). Then everything happens in the same way as if the PSD object was part of the data of the GET PROCESSING OPTIONS command: the data block obtained as a result of attaching the PSD is subjected to the same processing using the Bit mask,
Chapter 8. EMV COMPATIBLE APPLICATIONS COMPARISON 595
-DI
position
Rice. 8.8. Using Profile
Selection diversifier
after that, according to the Profile Selection Table, there is a CPA application profile for processing the transaction.
From the above it follows that in the CPA application it is possible to set almost any criterion for selecting an application profile according to the characteristics of a transaction, terminal and card (Profile Selection Diversifier)!
Finally, note that the CPA application can be used without being able to select the application. To do this, it is sufficient to set the value of bit 4 of byte 2 of the data field of the Application Control object to 0.
Output. Summarizing the above, it should be stated that CPA provides an almost universal mechanism for choosing the method of processing a transaction, depending on the parameters of the operation (transaction size, terminal country code, terminal type, terminal capabilities, etc.), as well as the parameters of the card application (Profile Selection Diversifier ). This allows:
- - depending on the formulation of the task by the business or for security reasons, process the transaction in the most efficient way (for example, in-country transactions should be performed only offline, and transactions from high-risk countries (Malaysia, Thailand, etc.) - only online);
- - to save on the number of card applications, which means on the occupied EEPROM memory. For example, VISA DPA application is implemented with a separate application with AID = 'A0000000038002'. In the case of using the CPA application on the card, you do not need to have an additional DPA (or CAP) application. The functionality of such an application can be implemented using the CPA Application Profile.
As for the M / Chip 4 application, it does not at all support the choice of the method of processing a transaction. The following caveat is possible here. If the MasterCard supports contact and contactless modes, then since the mods are implemented by two different applications (albeit with the same AID), each mod has its own parameters (AIP, AFL).
8.2.2. Ensuring the integrity of sensitive application data
It should be noted that all EMV applications we consider ensure the integrity of sensitive data stored in the application using two mechanisms:
- signature of sensitive data with the issuer's key and verification of this signature (Signed Static Application Data, Tag'93 ') by the terminal during transaction processing using the static authentication procedure of the card application;
- verification of the public key certificate of the card (ICC Public Key Certificate, Tag '9F46') for cards that support dynamic authentication. In accordance with EMV 4.2 Vook2, sensitive application data (Static Data to be Authenticated) are included in the data signed when creating a certificate, and thus the integrity of this data is ensured. Starting from 2011, it is this mechanism for ensuring the integrity of static data that will become the main one in the MasterCard Europe and VISA CEMEA regions (Russia belongs to these regions), since from that time on, banks will be obliged to issue DDA cards. The method of static authentication on new cards of banks in the specified regions is no longer used.
- 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 the GET PROCESSING OPTIONS and GENERATE AC commands are executed;
- makes it impossible to personalize a fake card from scratch.
8.2.3. Offline and online card application authentication
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 noted earlier, in contrast to the first two applications in CPA, when forming ARQC, instead of the CVR (Card Verification Results) object, the IAD (Issuer Application Data) object is used, which includes, in addition to CVR, offline counters (optional) and Issuer Discretionary Data.
Output. Offline application authentication is performed the same way across all applications. When performing online authentication in the CPA application, the IAD object is taken into account when generating the cryptogram, which includes, in addition to CVR, offline application counters. 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 transmitted to the issuer of the counters.
This advantage of the CPA application is, of course, not decisive. The fact is that in the M / Chip 4 application, the counters can be transferred to the issuer in encrypted form (in the CPA application, the counters can also be encrypted for transmission to the issuer, which is determined by the Issuer Options Profile Control object). Encrypting the counters makes the task of modifying the counter values in a way that is advantageous for fraudsters almost impossible to solve. By modifying encrypted counter values, fraudsters do not know how they will change as a result - increase or decrease.
8.2.4. Cardholder verification
All considered applications support cardholder verification in the same way: verification methods (CVM Code) and their application codes (Condition Code) are the same in all applications and comply with the EMV v.4.2 standard.
Output. All considered applications support cardholder verification in exactly the same way: verification methods and codes for their use are the same in all applications.
8.2.5. Card risk management procedures
The card's risk management procedures are the main component of its functionality. When using online authorization, the EMV card performs the risk management procedures twice - each time after the card receives the GENERATE AC command.
As a result of the implementation of the risk management procedure in accordance with the EMV specifications, the answers to the following questions are determined:
- - how the processed transaction should be authorized (approved offline, rejected offline, or sent for online authorization);
- - whether it is necessary for the card to generate an application authorization referral to complete the authorization through the procedure for contacting the issuer for an alternative authorization (by phone, telex, etc.);
- - whether it is necessary to send an advice message to the issuer informing him of some events related to the use of the card (the PTE limit has been exceeded, the issuer's authentication failed, the transaction was rejected offline, etc.);
- - how the parameters of card risk management are changed (CVR, offline limits).
In the VIS specification, card risk management is performed using ADA (Application Decisional Actions) data objects, internal application parameters (for example, Online Requested by Card Indicator) and CVR. In this case, the “event-driven” principle of making a decision by the card is used. In accordance with this principle, the ADA object (data field size 4 bytes) defines a set of special events that influence the adoption of a decision card by the application, and for each such event determines the application's decision regarding either how the current transaction ends, how the next transaction is processed, or about the need to generate an advice message.
To illustrate, the ADA set contains the following rule: "If the issuer authentication fails, then the next transaction must be processed online." If this rule is activated by the issuer during card personalization (the corresponding bit in the ADA object is equal to 1), then it determines the next event. If card authentication fails during the current operation, the card application must set the Online Requested by Card Indicator of the application's internal indicator to 1.
For CPA and M / Chip 4 applications, card risk management is done using CIAC (Card Issuer Action Codes) and ADR (Application Decisional Results for CPA application) / CVR (for M / Chip 4) data objects. CIAC objects have a different format in CPA and M / Chip 4 applications. However, they are used in the same way technologically.
There are three objects - CIAC-Decline, CIAC-Online, CIAC-Default. Each of the listed objects defines the same list of events that influence the decision-making of the card. If the value of some bit in CIAC is 1, then provided that the ADR / CVR element corresponding to this bit is also 1, depending on which CIAC object the check is performed for, the card:
- - rejects the transaction if verification is performed for the CIAC-Decline object;
- - Conducts a transaction online if verification is performed for the CIAC-Online object;
- - Rejects the transaction offline if validation is performed for the CIAC-Default object.
In terms of functionality, both approaches (table and event) are equivalent.
From the point of view of the criteria used to make the card decision, the considered EMV applications are also equal and allow you to respond to all the most important results of the card risk analysis. This applies to events such as PTE limit exceeded, Issuer Authentication not performed, Issuer Authentication failed, Issuer Script Processing failed, Last online transaction not completed, Set go online next transaction, Offline Authentication failed at previous transaction, PIN Offline verification failed, new card, etc.
Note that all three EMV applications do not support the application authorization referral mode.
With regard to support for advice messages, the M / Chip and CPA applications do not support these messages, and the VSDC application requests the terminal (via Cryptogram Information Data, CID, Tag '9F27') to send an advice message to the card issuer in the following cases:
- - The transaction was rejected offline and the ADA object indicates that advice should be sent.
- - the PTL (PIN Try Limit) limit has been exceeded and the ADA object indicates the need to send an advice message;
- - the transaction was rejected because the issuer authentication failed or the issuer authentication failed and the ADA entity indicates that an advice message should be sent.
- CID = '00', if the cryptogram is ААС;
- CID - '40', if the TS cryptogram;
- CID = '80' if ARQC cryptogram.
Key checks performed by the card as part of its risk management procedures relate to the use of so-called offline card counters. Let us consider these counters, their use, the possibility of transmission to the issuer and the procedure for resetting values.
Offline counters for VSDC app. As described in Section 4.10, the VSDC application uses four counters and four corresponding limits, exceeding which counters automatically require an online operation. Counters include:
- Consecutive Transaction Counter (International) - a counter that increases by 1 when performing an offline operation, the Transaction Currency of which is not the Application Currency. The counter is incremented regardless of whether the operation succeeds or is rejected. When the counter exceeds the Consecutive Transaction Counter Limit (International), the card requires a real-time transaction. This requirement is hard-coded in the VSDC application and does not require the use of ADA to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction is completed by the TS) and upon its execution the issuer authentication has been completed successfully.
- Consecutive Transaction Counter (International-Country) -a counter that increases by 1 when performing an offline operation for which the Issuer Country Code differs from the Terminal Country Code (i.e. the operation was performed in a different country). Typically, this counter is less than the Consecutive Transaction Counter (International). The counter is incremented regardless of whether the operation succeeds or is rejected. When the counter exceeds the Consecutive Transaction Counter Limit (International-Country), the card requires a real-time transaction. This requirement is hard-coded in the VSDC application and does not require the use of ADA to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction is completed by the TS) and upon its execution the issuer authentication has been completed successfully. An additional Consecutive Transaction Upper Limit International limit may be used for the two transaction counters above. If this limit is exceeded by the Consecutive Transaction Counter (International-Country) and / or by the Consecutive Transaction Counter (International), the card requires completion of the operation by rejecting the transaction (requires AAC). This limit is used in the case when a transaction must be performed online, but due to the fact that the terminal is offline or there is no connection with the issuer's host, it cannot be sent to the issuer for authorization. If this limit is exceeded by the Consecutive Transaction Counter (International-Country) and / or by the Consecutive Transaction Counter (International), the card requires completion of the operation by rejecting the transaction (requires AAC). This limit is used in the case when a transaction must be performed online, but due to the fact that the terminal is offline or there is no connection with the issuer's host, it cannot be sent to the issuer for authorization. If this limit is exceeded by the Consecutive Transaction Counter (International-Country) and / or by the Consecutive Transaction Counter (International), the card requires completion of the operation by rejecting the transaction (requires AAC). This limit is used in the case when a transaction must be performed online, but due to the fact that the terminal is offline or there is no connection with the issuer's host, it cannot be sent to the issuer for authorization.
- Cumulative counter Cumulative Total Transaction Amount (Dual Currency)represents funds spent on approved offline transactions where the Transaction Currency matches the Application Currency or the Secondary Currency. When using a secondary currency in a transaction to increase the counter value, the transaction amount is converted to the application currency (the VIS specification uses the Currency Conversion Factor object to convert from Secondary Currency to the Application Currency application currency). If the parameter exceeds the value of the Cumulative Total Transaction Amount Limit, the card requires the operation to be performed in real time. This requirement is hard-coded in the VSDC application and does not require the use of the ADA mechanism to implement it. The parameter value is set equal to O after
- The Cumulative Total Transaction Amount represents the funds spent on approved offline transactions where the Transaction Currency is the same as the Application Currency. If the parameter exceeds the value of the Cumulative Total Transaction Amount Limit, the card requires the operation to be performed in real time. This requirement is hard-coded in the VSDC application and does not require the use of ADA to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction is completed by the TS) and upon its execution the issuer authentication has been completed successfully.
The values of all the above limits can be obtained by the terminal using the GET DATA command and can be changed by the issuer using the PUT DATA command when executing the Script Processing procedure.
In some VSDC implementations, offline limit values can be transmitted to the issuer in the Issuer Discretionary Data section of the IAD object (in M / Chip 4 and CPA, the counter values are transmitted in the payment system section, i.e. they are mandatory and can be encrypted). In general, support for the transfer of offline meters to the issuer is optional (Implementer-option). However, it is supported in VSDC 2.5 and 2.7 applets.
In addition, the VSDC has an Available Offline Spending Amount data object (Tag '9F52') that indicates the amount available for offline use. This object can be retrieved by the terminal using the GET DATA command and displayed on the terminal screen or printed on a transaction receipt.
Offline counters in M / Chip 4 app. Offline counters in this app are much simpler than in VSDC. There are two counters in total, and each has an upper and lower limit.
• Cumulative Amount is funds spent on successful offline transactions performed in currencies that can be converted to Application Currency using the Currency Conversion Table (Tag 'DI'). The Cumulative Amount counter has two limits - Upper Cumulative Offline Limit and Lower Cumulative Offline Limit. These two limits can be used in different ways by the CIAC mechanism. The most common use case is as follows. If the Lower Cumulative limit is exceeded
Offline Limit, then the card requests the execution of the transaction in real time. If the Upper Cumulative Offline Limit is exceeded and the terminal is offline or is not able to process the transaction online, the card asks to reject the transaction.
• If the transaction currency is not the application currency and is not present in the Currency Conversion Table ('D1'), then a successful offline transaction is appended to the second Consecutive Offline Transaction Number counter . This counter has two limits, the Upper Consecutive Offline Limit and the Lower Consecutive Offline Limit. If the Lower Consecutive Offline Limit is exceeded, then the card requests the execution of the transaction in real time. If the Upper Consecutive Offline Limit is exceeded and the terminal is offline or is unable to process the transaction online, the card asks to reject the transaction.
Both offline counters can be transferred to the issuer in the IAD object. Whether offline meters are transferred to the IAD, as well as whether the meters need to be encrypted are determined by the issuer in the Application Control object.
The values of all offline limits can be received by the terminal using the GET DATA command and can be changed by the issuer using the PUT DATA command when executing the Script Processing procedure.
In addition, the M / Chip 4 app has an Offline Balance data object ('9F50') that indicates the amount currently available for offline use. This object can be retrieved by the terminal using the GET DATA command, if specified in the Application Control object, and displayed on the terminal screen or printed in the transaction receipt.
In addition to checking offline counters, the M / Chip 4 application also checks that the size of the processed transaction does not exceed the Maximum Transaction Amount limit . In addition, in the M / Chip 4 application, it is possible to perform one additional Check Table based on the data obtained by the card in the first GENERATE AC command. The result of the check is recorded in the CVR.
Offline counters of the CPA application. The CPA application supports a set of seven offline counters, depending on the selected profile:
- two cumulative meters;
- three transaction counters;
- two cyclic cumulative counters,
- and three counters independent of the card profile. These counters include Additional Counter, Additional Accumulator, and Additional Cyclic Accumulator.
- online operation;
- the transaction was rejected offline;
- the transaction is approved offline;
- the transaction has been attached to a cumulative meter;
- the transaction is not in-country.
- upper and lower counter limits;
- the need to use a counter for this profile;
- the need to set the counter value to 0 after performing an online operation;
- the need to send the counter value to the issuer in the IAD (in M / Chip 4 this is set through the Application Control object).
- online operation;
- the transaction is approved offline.
- upper and lower counter limits;
- the need to use a counter for this profile;
- the need to set the counter value to 0 after performing an online operation;
- the need to send the counter value to the issuer in the IAD object;
- the need to send to the terminal the counter balance value (the difference between the upper limit and the current counter value).
It should be noted that when performing checks with cumulative counters, it is possible to use up to 14 different currency conversion tables (for each counter, the table is defined at the level of the selected application profile). You have to resort to currency conversion whenever the transaction currency does not match the counter currency, which does not depend on the application profile.
In the CPA application, as part of card risk management procedures, in addition to checking offline meters, the following additional checks, depending on the selected profile, can be performed:
- checking that the size of the processed transaction does not exceed the Maximum Transaction Amount limit;
- checking that the number of days that have passed since the last online transaction exceeds the Number of Offline Days limit;
- two additional Check Table checks based on the data obtained in the first GENERATE AC command. The results of these checks are recorded in the ADR.
Up to two additional checks are applied in the CPA application (two Additional Check Table data objects can be stored on the card). Only one Additional Check Table can be used in the M / Chip 4 app. The VSDC application does not use additional checks at all.
Output. From the point of view of the card risk management procedure, by far the CPA application is the most functional. It uses ten different offline counters, allowing the issuer to monitor the card's offline activity based on a variety of criteria. Of the ten counters, seven depend on the selected application profile. Limits for each of these counters are set at the application profile level. There is a flexible system for converting the transaction currency into the currencies of cumulative meters (its own currency for each meter). In this case, the values of the elements of the conversion table are also determined at the level of the application profile.
In addition to the limits for cumulative meters, the CPA application can support other limits:
- maximum transaction size (your own at the application profile level);
- the maximum number of days that have passed since the last online transaction (different for each profile);
- three limits on the number of incorrect cryptographic card checks (described below in clause 8.3);
- VLP limits.
The M / Chip 4 application is inferior to CPA in the number of offline counters (only two for the entire application without the option to select a profile) and the number of additional checks (no more than one). In addition, in M / Chip 4, the currency of the cumulative limit and the maximum transaction size is necessarily the same as the currency of the application. At the same time, the M / Chip 4 application retains the ability to reset the offline limit values by the card issuer using the CSU (Card Status Update) object.
VSDC uses 4 offline limits with a fixed mechanism for resetting their values. The application uses only two currencies, between which the conversion ratio is set. VSDC does not support any other limits (such as maximum transaction size) and additional checks. A distinguishing feature of the VSDC application is its support for advice messages.
With all the difference in the capabilities of card risk management procedures for performing the main function - maintaining a balance between the client's offline funds on the card and his funds on the main account - the applications considered are equivalent.
Issuer Authentication
The issuer is authenticated by the card according to the value of the Issuer Authentication Data object received by it. If bit 3 of byte 1 of AIP “Issuer authentication is supported” = 0, the second GENERATE AC command is used to authenticate the issuer by the terminal. The M / Chip 4 and CPA use the GENERATE AC command, and the VSDC use EXTERNAL AUTHENTICATE.
VSDC and M / Chip 4 applications use the first ARPC generation method: ARQC is modulo 2 with (ARD || '00' 11 '00' 11 '00' 11 '00' 11 '00' 11 '00') and the resulting result is encrypted on the session key to generate a cryptogram. Here ARD (Authorization Response Data) is a 2 byte data item that is included as 9 and 10 bytes of the Issuer Authentication Data item.
In VSDC, the ARD element is a regular authorization code. In M / Chip 4, this element is called the ARPC Response Code and, in addition to informing the application about the authorization result, it allows the card issuer to change the PTC (PIN Try Counter) value, set the Go online on next transaction flag, and also instruct the card to reset the application's offline limits.
The CPA application uses Method 2 of ARPC generation. In this case, to obtain ARPC to the value Y = ARQC || Z || 00000000 Algorithm 3 of ISO / IEC 9797-1 MAC computation is applied (MAC size is 4 bytes). ARPC object is used as Issuer Authentication Data || Z. In this case, the Z object is a 4-byte CSU (Card Status Update) object, which, in addition to informing the application about the result of the authorization of the transaction by the issuer, allows the issuer to change the PTC value (PIN Try Counter), block the card, block the card application, set the Go flag online on next transaction, and instruct the card to reset the app's offline limits.
Output. M / Chip 4 applications, and especially CPA, allow during the issuer authentication process to reset the parameters of the card application (for example, offline counters), thereby providing an alternative mechanism for the Script Processing procedure. This property is very useful, but not critical to the functionality and security of the card.
Transaction cryptogram transmission
All three applications support the generation of a transaction cryptogram, which serves as proof that a card transaction was performed and to ensure the integrity of the data transmitted to the issuer. The only difference in cryptograms is that the cryptogram of the CPA application, as opposed to the M / Chip 4 and VSDC applications, uses the IAD object instead of the CVR object, which includes, among other things, the CVR object.
Output. The cryptogram generated in the CPA application, in addition to its main purpose - online authentication of the card application - ensures the integrity of the offline counters of the application.
Issuer Script Processing
VSDC application can use only non-critical Script Processing procedure (Issuer Script Template has Tag '72'), M / Chip 4 and CPA applications use both non-critical (Tag '72') and critical (Tag '71') processing. The ability to use the critical Script Processing procedure obviously increases the flexibility of the card risk management procedure. For example, the issuer can change the values of CIAC objects or another parameter of the selected profile of the CPA application for a specific transaction and only then enable the card to perform the risk management procedure. At the same time, it should be recognized that the ability to use the critical Script Processing procedure in the overwhelming majority of cases is a function that is not in high demand by the issuer.
In terms of the set of commands supported by Script Processing, all applications are equivalent. The CPA application, unlike the M / Chip4 and VSDC, does not support the BLOCK APPLICATION and BLOCK CARD commands. This is because the implementation of these functions in the CPA application is possible using the CSU (Card Status Update) object.
In general, it should be recognized that the support of ARPC Response Codes and CSUs respectively by M / Chip 4 and CPA applications is an advantage of these applications. Support for these objects allows some application parameters to be changed in a safe and reliable way compared to Script Processing. The substitution of a part of the Script Processing function is especially fully implemented in the CSU object of the CPA application.
It should be noted that in all the considered applications, within the Script Processing procedure, using the UPDATE RECORD command, you can change the records in the linear application files. The PUT DATA command is used to modify data in nonlinear files. With this command, you can change all of the risk management settings for the card applications that are not normally stored in the line files of the application.
It should be noted the richer capabilities of the Script Processing procedure of the CPA application, which make it possible to modify almost all application parameters, even the parameters for selecting an application profile.
Output. VSDC can use only non-critical Script Processing, while M / Chip 4 and CPA applications use both non-critical and critical Script Processing. The ability to apply a critical procedure obviously increases the flexibility of card risk management. At the same time, this additional flexibility in most cases is not demanded by the issuer of the application. Therefore, it cannot be considered a significant advantage of applications that support the critical Script Processing procedure.
Support for contactless fashion
The M / Chip 4 and VSDC applications support contactless mode based on the unified EMV Contactless Communication Protocol version 2.0. EMVCo has also developed Type Approval testing procedures for EMV Contactless Communication Protocol version 2.0.
CPA app does not support contactless mode.
Output. The CPA application does not support contactless mode, and this is a serious limitation to its use by issuers seeking to provide their customers with contactless payment service.
VSDC and M / Chip 4 APPs support contactless mode. QVSDC application is more efficient from the point of view of the speed of execution of the transaction, each time keeping within the processing time of the operation within the limit of 500 ms. The indicator of 500 ms can also be achieved on M / Chip 4 cards using microcontrollers with the appropriate bit depth and clock frequency.
A quick summary of app functionality
Below is a brief summary of the functionality of the CPA, M / Chip 4 and VSDC applications.
In terms of functionality, the applications are of course different from each other. So the VSDC application supports only two currencies (application currency and secondary currency), can optionally transfer counters to the application issuer in clear text and provides only non-critical Script Processing procedure. M / Chip 4 does not support the choice of transaction processing method at all, and CPA lacks support for the contactless application mode.
The above comparative analysis of applications is reflected in table. 8.8.
Tab. 8.8. Comparative analysis of application functionality
| Criteria | CPA | M / Chip | VSDC |
| Choosing a way to process a transaction | Universal selection mechanism depending on the parameters of the operation, terminal, card application | No choice | Selection based on checking geographic restrictions and for VLP cards based on terminal indicator and transaction size |
| Ensuring the integrity of static data | All applications (CPA, M / Chip4, VSDC) ensure the integrity of the static data they store and from this point of view are equivalent | ||
| Offline / Online Application Authentication | Offline application authentication is performed the same way across all applications. CPA and M / Chip support the ability to check whether authentication has been performed. With online authentication in the CPA application, the IAD is used in the formation of the cryptogram, which ensures the integrity of the offline application counters when they are transferred to the issuer | ||
| Cardholder verification | Holder verification methods and codes for their use are the same in all applications |
The end of the table. 8.8
| Criteria | CPA | M / Chip | VSDC |
| Card risk management | Up to ten different offline counters are used to monitor offline work. A flexible system for converting transaction currencies into cumulative meter currencies is supported. In addition, the maximum transaction size is supported, the maximum number of days since the last online transaction, three limits on the number of incorrect cryptographic card checks, two additional card checks | Two offline counters are used (for the entire application without the option to select a profile) and one additional check. The currency of the cumulative limit and the maximum transaction size (also supported) must be the same as the currency of the application | Four offline limits are used with a fixed mechanism for resetting their values. Only two currencies are used, between which the conversion factor is set. No other limits (such as maximum transaction size) and additional checks are supported. VSDC supports advice messages |
| Changing parameters after card issue | Applications support critical and non-critical script processing. In addition, it is possible to upgrade some parameters using CSU objects in CPA and ARPC Response Code in M / Chip 4 | Only non-critical script processing is supported | |
| Implementation of a client funds management scheme in an offline and online environment | All applications support a flexible scheme for managing available client funds | ||
| Contactless support fashion | Does not support contactless fashion | Apps support contactless fashion. QVSDC app allows faster contactless payment processing on average compared to M / Chip PayPass |
