Generating a cryptogram of the EMV transaction

All three applications support the generation of a transaction cryptogram, which acts as proof that the card operation was performed, as well as to ensure the integrity of the data transmitted to the Issuer. The only difference in cryptograms is that the CPA application cryptogram, unlike the M/Chip 4 and VSDC applications, uses the IAD object instead of the CVR object, which includes the CVR object, among other things.
Conclusion. 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.

Issue Script Processing Procedure
The VSDC application can only use non-critical Script Processing (the Issuer Script Template has Tag ‘ 72’), while the M/Chip 4 and CPA applications use both non-critical (Tag ‘72’) and critical (Tag ‘71’) processing. The ability to apply a critical Script Processing procedure obviously increases the flexibility of the card’s risk management procedure. For example, the Issuer can change the values of CIAC objects or another parameter of the selected CPA application profile for a specific transaction and only then allow 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 is in the vast majority of cases a function that is not in demand by the Issuer.
From the point of view of the set of commands supported within Script Processing, all applications are equivalent. The block APPLICATION and BLOCK CARD commands are not supported in the CPA application, unlike M/Chip4 and VSDC. This is because these functions can be performed in a CPA application using the CSU (Card Status Update) object.
In General, it should be recognized that the support of ARPC Response Code and CSU objects by M/Chip 4 and CPA applications, respectively, is an advantage of these applications. Support for these objects allows you to change some application parameters in a safe and reliable way compared to the Script Processing procedure. A particularly complete substitution of part of the Script Processing function is implemented in the CSU object of the CPA application.
Note that in all the applications under consideration, you can use the UPDATE RECORD command to change entries in linear application files as part of the Script Processing procedure. To change data in non-linear files, use the PUT DATA command. You can use this command to change all the card application risk management parameters that are not usually stored in the application’s line files.
At the same time, we should note the richer features of the Script Processing procedure of the CPA application, which allow you to modify almost all the application parameters, even the parameters for selecting the application profile.
Conclusion. The VSDC application can only use a non-critical Script Processing procedure, while the M/Chip 4 and CPA applications use both non-critical and critical Script Processing procedures. The ability to apply a critical procedure obviously increases the flexibility of the card’s risk management. At the same time, this additional flexibility is not required by the application Issuer in most cases. Therefore, it cannot be considered a significant advantage for applications that support the critical Script Processing procedure.

Contactless mode support
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.
The CPA app does not support contactless fashion.
Conclusion. The CPA app does not support the contactless mod, and this is a serious restriction on its use by issuers seeking to provide their customers with a contactless payment service.
The VSDC and M/Chip 4 applications support contactless mode. The qVSDC application is more efficient in terms of transaction execution speed, each time keeping the transaction processing time within the 500 MS limit. The 500 MS indicator can also be achieved on M/Chip 4 cards when using microcontrollers with the appropriate bit rate and clock frequency.

A brief summary of the app’s functionality
Below is a brief summary of the functionality of the CPA, M/Chip 4, and VSDC applications.
In terms of functionality, of course, the apps differ from each other. For example, the VSDC application supports only two currencies (the application currency and the secondary currency), can optionally transmit counters to the application Issuer in plain text, and only provides a non-critical Script Processing procedure. M/Chip 4 does not support selecting the transaction processing method at all, and CPA does not support the contactless application mode.

Criteria CPA M/Chip, VSDC
The choice of method of processing a Universal transaction mechanism of choice in addiction
from the operation parameters, terminal, and card application Selection there is no Choice based on checking geographical restrictions and for VLP cards based on the 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 are equivalent from this point of view
Offline / online application authentication Offline application authentication is performed in all applications in the same way. CPA and M / Chip support the ability to verify that authentication has been performed.
For online authentication in the CPA application, IAD is used to generate the cryptogram, which ensures the integrity of the application’s offline counters when transmitting them to the Issuer
Cardholder verification methods of cardholder verification and their application codes are the same in all applications

Criteria CPA M/Chip, VSDC
Risk management cards are Used up to ten different counters for off-line control off-line operation. A flexible system for converting the transaction currency into the currencies of cumulative counters is supported.
In addition, the maximum transaction size, the maximum number of days since the last online transaction, and three limits on the number of invalid cryptographic card checks are supported,
two additional card checks Use two offline counters (for the entire app without the ability to select a profile)
and one additional check. The currency of the cumulative limit and maximum transaction size (also supported) must match the currency of the app. four offline limits are Used with a fixed reset mechanism
their values. Only two currencies are used, and the conversion rate is set between them.
No other limits (such as the maximum transaction size) or additional checks are supported.
VSDC supports advice messages
Changing parameters after the card is released, Applications support critical and non-critical script processing. In addition, you can upgrade some parameters using CSU objects
in CPA and ARPC Response Code, only non-critical script processing is Supported in M/Chip 4
Implementation of the client’s funds management scheme
in offline and online environments All applications support a flexible management scheme for the client’s available funds
Support for contactless fashion Does not support contactless fashion Apps support contactless fashion. The qVSDC app on average allows faster contactless payment processing compared to M/Chip PayPass

Operation security
It should be noted that all three applications use Script Processing procedures for generating cryptograms, ensuring data integrity, encrypting some data that circulates between the card and its Issuer (offline counters, PIN code), and EMV CSK method for generating card keys and session keys. This method is described in detail in EMV V. 4. 2.
In addition to the EMV CSK method, M/Chip 4 and VSDC applications support their own algorithms for displaying card keys and session keys. From the point of view of cryptographic strength, the internal algorithm for displaying session keys in the VSDC application looks somewhat weaker. According to this algorithm, the first component of the corresponding key for Secure Messaging is added modulo 2 with the ATC value supplemented on the right by 6 null bytes, and the second component is added modulo 2 with the inverted ATC value supplemented on the right by 6 null bytes. As a result, compromising the session key leads to compromising the card key, and the meaning of entering session keys is largely lost.
As for the internal VSDC algorithm for output of the session key of cryptogram generation, according to it, the session key matches the card key.
In M/Chip 4, the internal session key output algorithm for cryptogram generation and Secure Messaging is more reliable from the cryptanalysis point of view than the EMV CSK algorithm (for example, a diversification mode is used to output the session key for cryptogram generation, which uses not only ATC, as in the case of EMV CSK, but also a random variable UN generated by the terminal).
The CPA application uses a new more “diversified” algorithm for displaying the application key, if the card number contains more than 16 digits.
The CPA, M/Chip 4 and VSDC applications have a reliable mechanism for verifying by the Issuer that the terminal performed offline authentication of the application. For this purpose, in the case of the SDA card, the DAC value (Data Authentication Code) calculated by the Issuer is used, and in the case of the DDA/CDA card, the IDN value (ICC Dynamic Number) output during the operation is used, which can only be calculated by the card and its Issuer. In the VSDC application, the use of DAC and IDN is optional and often not implemented (for example, in the VISA CEMEA region). In CPA and M/Chip4 applications, the IDN value is calculated by the card when the GET PROCESSING OPTIONS command is processed (when the ATC transaction counter is increased by 1).

The CPA and M/Chip 4 applications support a number of security-friendly counter cards, including:
AC Session Counter-counter for the number of session key generation by the card for calculating the cryptogram since the last successful check of the ARPC value by the card. This counter protects the card from fraudsters trying to pick up the card key to generate a cryptogram;
Secure Messaging for Integrity Counter-the counter for the number of session key generation by the card for secure messaging for integrity since the last successful verification of the MAC code by the card. This counter protects the card from fraudsters trying to find the card key to generate MAC codes;
PIN Decipherment Counter-counter for the number of incorrect decryptions of PIN code values by the card.
The CPA and M/Chip 4 applications support additional
checks (in CPA — up to two checks, in M/Chip 4 — no more than one) to improve the security of the transaction. For example, the card may reject transactions that come from a “dangerous” country, and / or transactions of a certain type. Additional checks are not supported in the VSDC application.
The CPA and M/Chip 4 applications support the ability to manage offline counters depending on who authorized the transaction — the Issuer or the Stand-In Processor.
The CPA and M/Chip 4 applications support checking the Maximum Transaction Amount for an offline operation. The VSDC application does not have this check.
In the CPA app, you can block the card/app without using the Script Processing procedure. This increases the reliability of blocking the card/app.
In the CPA and M/Chip 4 applications, it is possible to unblock PIN verification (reset the PTC value) without using the Script Processing procedure (using the CSU and ARPC Response Code objects, respectively).
Conclusion. It should be recognized that, despite the great “advanced” applications of CPA and M/Chip4, in General, with the current state of Affairs in the field of card fraud, all applications are approximately equivalent in terms of the transactional security they provide.

Evaluating the complexity of application implementation
Changes in banks ‘ processing systems
It is obvious that today’s processing systems of issuers of VSDC and M/Chip 4 microprocessor cards are fully ready to process operations on these cards. This applies to both Front-End systems designed for processing authorization requests in real time, and Back-office systems used for processing clearing messages and card personalization.
To support the CPA application, the Bank’s processing systems will need to be upgraded. The necessary changes to banks ‘ processing systems to support the CPA application are not significant. Assuming that the processing solution already supports the new algorithm for generating symmetric card keys defined in EMV V. 4.2 Book2 for cards with PAN longer than 16 digits, the Front-End system should implement:
new algorithm for checking (generating) the ARQC cryptogram (when calculating the cryptogram, use the IAD object instead of the CVR object);
the new ARPC generation algorithm is ARPC Method 2, which uses a CSU object.
Minimal improvements are also required in the Back-office system: it is necessary to implement a new algorithm for verifying the TC cryptogram in financial messages (segments) of payment systems.
As for the acceptance of CPA cards in the terminal networks of banks, it is now provided automatically by the fact that the Bank has the status of a participant in the VISA or/and MasterCard payment system. A sufficient condition for accepting CPA cards is:
CCD compatibility of Bank terminal applications;
CCD-compatibility of application hosts of servicing banks (the interface of the host of the servicing Bank with the VISA payment system must support field 55 instead of the third bit card, as it was previously).
Even before January 1, 2006, all banks serving the leading payment systems in the regions MasterCard Europe and VISA CEMEA, which include

Russia, have passed the appropriate certification and today every Russian EMV-compatible terminal and servicing Bank must support the CCD standard. In other words, no changes are required on the host side of the servicing Bank to support the CPA.

Changes in Bank personalization systems
Many new data objects appear in the CPA that are not present in the M/Chip 4 and VSDC applications. These data objects are defined in terms of the CPS standard and DGI is allocated for them in the CPA specification.
Even if there are no specific implementations of CPS under the CPA standard for the providers of personalization and/or processing solutions, according to the results of preliminary discussions with some providers of solutions for Bank personalization complexes, the development of a script for personalization of a CPA card will take about a month.

Compatibility with used HSM modules
The most used HSM modules today support the main EMV functions, including:
ARQC verification.
Generating the ARPC Method 1 cryptogram.
To support generating symmetric Issuer keys on long card numbers (longer than 16 digits), as well as generating ARPC Method 2, you may need to extend the functionality of security modules. Leading HSM manufacturers Thales e-Security and SafeNet announced the existence of new releases of HSM applications that implement all of the above features.
Banks that want to use CPA should check with their HSM providers to ensure that their modules support the features listed above and upgrade their HSM modules if necessary.

Choosing a microprocessor
Today, cards from all leading vendors contain M/Chip 4 and VSDC applications in the card’s ROM memory. As a result, these applications use the most scarce and expensive EEPROM memory only for storing application configuration data.
If you select a CPA application, its implementation is only available today as an applet loaded into EEPROM memory. This is a standard practice of card providers, when a new application for the market is first implemented as an applet uploaded to EEPROM in order to “run-in” the applet when solving practical tasks of the Bank. As a result, the application developers implement the feedback. Only after the application specifications are settled, vendors begin to manufacture a mask for implementing the application in ROM memory.
Today, there are several EMVCo-certified solutions for CPA in the form of applets uploaded to EEPROM cards. The EEPROM memory used as a result of loading the CPA application is approximately 40 KB.
As a result, using a CPA requires an expensive card with an EEPROM memory size of 40 KB or more.

Selecting an app
As previously noted, the advantages of using the CPA application compared to the M/Chip 4 and VSDC applications are as follows:
More advanced functionality compared to M/Chip 4 and VSDC:
ability to select the operation processing method (application profile) and risk management parameters depending on the selected application profile;
a more developed risk management procedure for the card;
using the Issuer Authentication Data to modify parameters, lock / unlock the application as an alternative to the Script Processing procedure;
richer features of the CPA application Script Processing procedure, allowing you to modify almost all application parameters, even the parameters for selecting the application profile.
The most advanced card risk management system:
each profile has its own risk management parameters and even its own sets of keys;
up to two additional checks for each card app;
cyclical risk management parameters – for a month, week, or day;
checking for exceeding the maximum operation size (available only in CPA and M / Chip).
checks the number of days that have passed since the last online transaction was completed.
The ability to implement individual applications as a CPA application profile (for example, CAP/DPA, VLP scheme).
But the most important advantage of CPA is that CPA is the only EMV application supported by leading payment systems, which makes life easier for banks issuing cards from both payment systems. As a result, the Bank’s support for the CPA application makes it possible to use:
unified risk management system (CIAC, unified algorithms for calculating session keys, card keys, and cryptograms) in MasterCard and VISA systems;
unified card personalization system for various payment systems (for example, based on Common Personalization Specification (CPS) for CPA).
The disadvantages of choosing a CPA solution from the Bank’s point of view are currently as follows:
The large amount of EEPROM memory used by the CPA applet, and as a result, the high cost of the card.
In addition to certification of the CPA application in EMVCo, when using the card as a solution for international payment systems, you will need to pass the issue certification in payment systems. Obviously, the IPU staff is not sufficiently prepared for certification of CPA cards (there are no precedents), although the CPA certification procedures in the leading payment systems are formalized. In other words, it will take longer and more effort to certify the issue in the MPC when using CPA than when using “standard” MPC applications.
The need to modernize issuers ‘ processing solutions to personalize and work with the CPA application.
It is not possible to work with the CPA application via the contactless interface.
Now let’s take a look at the advantages of using standard IPS applications:
VSDC or M/Chip 4 applications and their certification procedures are well-tested.
Availability of processing solutions of the Issuer’s hosts for working with VSDC and M/Chip 4 cards.
VSDC and M/Chip 4 applications on most cards are located in the ROM, without requiring a large amount of EEPROM memory and reducing the cost of the card.
The disadvantages of using standard IPS applications are as follows:
Lower functionality of VSDC and M/Chip 4 applications compared to CPA.
The need to configure risk management systems and personalize cards for each application separately.

Criteria/application CPA M/Chip, VSDC
Functionality (risk management) Great Good Good
Transactional security is High for all applications. CPA and M / Chip also support IDN/DAC and cryptographic counters
Contactless mode support is Not supported Supported by both apps
to upgrade the issuing host you need to implement a new cryptogram verification algorithm ARQC and a new ARPC generation algorithm No changes are required
to upgrade the personalization system you Need to develop new personalization scripts No changes are required
no changes are required to the terminals
EEPROM card requirements must be more than 40 KB Minimum EEPROM requirements: more than 2.5 KB
for certification, it is Desirable that the application be certified by EMVCo the Application must be certified by the IPU

The EMV standard is still very young. In addition to the fact that it only recently celebrated its 10th anniversary, we must admit that the truly mass implementation of the standard began only 5 years ago.
Experience-the “son of difficult errors” – is the main source of numerous technical refinements of the EMV standard. The incompatibility of cards and terminals due to the ambiguous understanding of certain provisions of the standard by card equipment and card suppliers, or the presence of contradictions within the standard, leads to the fact that it continues to undergo small changes even today. This process is natural, and it can be stated that the peak of technical refinements of the standard has already passed and the intensity of their appearance is on the wane.
The EMV standard has also undergone a number of more significant changes of a technological nature during its existence. These include defining a new method for dynamic authentication of the CDA card that ensures the integrity of data exchange between the card and the terminal, using a new Card Status Update data element that is an alternative to the script processing procedure and supports the integrity of data exchange between the card and the terminal when using the ARPC cryptogram Format 2, changes in key output procedures, and so on.
Of course, the appearance of Common Core Definitions specifications in the penultimate version of the EMV 4.1 standard, approved in may 2004, is significant. the common Payment Application (CPA) was developed on the basis of these specifications.
Of great importance is also the appearance of the EMV Card Personalization Specification, which allows to significantly standardize the process of personalization of Bank cards of the EMV standard. In turn, this standard was projected by payment systems and EMVCo on m/Chip 4, VSDC and CPA applications, taking into account the data structure of these applications.
Finally, we should mention the rapid development of contactless payments. Here, EMVCo has so far approved the communication Protocol for working with the card reader, the Entry Point Specification, which defines the General format of contactless operations, and the procedure for selecting a contactless application. It is expected that the trend towards increasing the use of contactless microprocessor cards will only increase.
It should be noted that changes in the standard are caused not only by new technological needs of the market, but also by new capabilities of microprocessors. Today, MPCs with RAM of 4-8 KB, non-volatile rewritable memory EEPROM of 32-72 KB, with 16/32-bit processors running at a clock frequency of up to 33-66 MHz are not a novelty. New features of the card allow you to implement mechanisms that were previously impossible to dream of.
There were changes in the first book of the EMV standard, which defines the physical characteristics of the card and terminal. For example, the world continues to move towards chips that consume less power and operate using a supply voltage of 3 V or even 1.8 V. This is reflected in the EMVCo policy. By July 1, 2009, the migration of cards that support only 5 V supply voltage to cards that support two voltage values — 5 V and 3 V, and cards that support three voltage values — 5 V, 3 V and 1.8 V. was completed unnoticed. Cards that support a single 5 V supply voltage are no longer used.
The EMV standard still needs to be changed. First of all, they will concern changes in the field of telecommunications protocols. The t = 0 and T = 1 protocols are outdated and do not meet today’s business requirements. They are replaced by high-speed physical layer protocols based, for example, on the use of the USB standard. In addition, the card will support network and transport layer protocols. The IP and TCP protocols will be selected as the latter. Moreover, VISA promotes the concept of Smart Card Web Server, which involves the use of application-level protocols on the card in the open systems interconnection model.
Implementing the entire Protocol stack on the card will create an independent secure General-purpose hardware and software platform based on the microprocessor card and expand the scope of application of microprocessor cards. In particular, the card will become an independent device that can work with network computers over the Internet, including playing the role of a web server.
Over time, with the growing capabilities of the card, the EMV standard will still undergo changes related to the card’s support for payment terminal authentication. It is expected that at some stage of card migration to the new technology, payment terminals will become a target for fraudsters. It would be useful to prevent fraudsters from intending to do this by implementing card authentication of the terminal or, at least at first, making it mandatory to use the procedure for reliable authentication of the terminal by the servicing Bank.
Speaking about incentives for banks to migrate to the EMV standard, we must admit that in the coming years, the main driver of this migration will remain the fight against card fraud. At the same time, the possibility of contactless cards, biometric authentification of the card holder, application megapikselnyj cards with secure remote loading of some apps, after issuing the card the Bank will not remain in the shadows, and will stimulate banking technology and banking businesses to introduce innovations.
In any case, it is obvious that migration to the IPC is a natural stage in the development of card technology, and all of us in the coming decades will have to become more familiar with this technology and increasingly apply it in our work.