Assessment of the complexity of application implementation

[Tomcat]

8.4.1. Changes in the processing systems of banks

It is obvious that today's processing systems of the issuers of VSDC and M / Chip 4 microprocessor cards are fully prepared to process transactions on these cards. This applies to both Front-End systems designed to process authorization requests in real time, and Back-office systems used to process clearing messages and personalize cards.

To support the CPA application, the bank's processing systems will need to be upgraded. The necessary changes to the processing systems of banks to support the CPA application are not significant. Assuming that the processing solution already supports the new algorithm for generating symmetric card keys for cards with a PAN longer than 16 digits defined in EMV v.4.2 Book2, the Front-End system must implement:

• a new algorithm for checking (generating) the ARQC cryptogram (when calculating the cryptogram, use the IAD object instead of the CVR object);
• new ARPC generation algorithm - ARPC Method 2, using the CSU object.

Minimal improvements are required in the Back-office system: it is necessary to implement a new algorithm for checking the TS cryptogram in financial messages (presentations) of payment systems.

As for the acceptance of CPA cards in the terminal networks of banks, today it is 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 host bank applications (the host bank interface with the VISA payment system must support field 55 instead of the third bit card, as it was before).

Even before January 1, 2006, all servicing banks of the leading payment systems in the MasterCard Europe and VISA CEMEA regions, which include

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

8.4.2. Changes in bank personalization systems

CPA introduces many new data objects that are not available in the M / Chip 4 and VSDC applications. These data objects are defined in terms of the CPS standard and are referred to as DGIs in the CPA specification.

Even if the providers of personalization and / or processing solutions do not have specific CPS implementations for the CPA standard, according to the results of preliminary discussions with some solution providers for banking personalization complexes, the development of a script for personalizing a CPA card will take about a month.

8.4.3. Compatible with used HSM modules

The HSMs most used today support basic EMV functions including:

• ARQC check;
• generation of cryptogram ARPC Method 1.

To support the generation of symmetric issuer keys on long card numbers (longer than 16 digits), as well as the generation of ARPC Method 2, it may be necessary to expand the functionality of the security modules. Leading HSM vendors Thales e-Security and SafeNet have announced new releases of HSM applications that provide all of these features.

Banks wishing to use CPA should check with their HSM vendors if they support the functionality listed above and upgrade their HSMs if necessary.

8.4.4. Microprocessor selection

Today, cards from all leading vendors contain M / Chip 4 and VSDC applications in ROM cards. As a result, these applications use the most scarce and most expensive EEPROM memory only for storing application configuration data.

If the CPA application is selected, its implementation is available today only in the form of an applet loaded into the EEPROM memory. This is a standard practice for card suppliers, when an application new to the market is first implemented as an applet loaded into the EEPROM in order to "test" the applet when solving practical problems of the bank. As a result, application developers implement feedback. Only after the specifications for the application are settled do vendors begin to create a mask for implementing the application in ROM.

Today there are several EMVCo certified CPA solutions in the form of applets loaded into the EEPROM of the card. The EEPROM used as a result of loading the CPA application is approximately 40 KB.

As a result, the use of CPA requires the use of an expensive card with 40 Kb or more EEPROM memory.

8.4.5. Application selection

As previously noted, the advantages of using the CPA application over the M / Chip 4 and VSDC applications are as follows:

• More advanced functionality compared to M / Chip 4 and VSDC:
  • - the ability to select the method of processing the operation (application profile) and risk management parameters, depending on the selected application profile;
  • - a more developed card risk management procedure;
  • - using Issuer Authentication Data for modifying parameters, blocking / unblocking the application as an alternative to the Script Processing procedure;
  • - richer possibilities of the Script Processing procedure of the CPA application, which allow modifying almost all application parameters, even the parameters for selecting an 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 application;
• - cyclical parameters of risk management - for a month, a week, a day;
• - check for exceeding the maximum size of the operation (available only in CPA and M / Chip);
• - checking the number of days that have passed since the last online transaction.
• • Ability to implement individual applications as a CPA application profile (eg CAP / DPA, VLP scheme).

But the main advantage of CPA is that CPA is the only EMV application supported by leading payment systems, which makes life easier for banks that issue cards of both payment systems. As a result, from the bank's support for the CPA application, the possibility of using:

• • a unified risk management system (CIAC, unified algorithms for calculating session keys, card keys and cryptograms) in MasterCard and VISA systems;
• • a unified system for personalization of cards of various payment systems (for example, based on the Common Personalization Specification (CPS) for CPA).

The disadvantages of choosing a CPA solution from the bank's point of view are as follows:

• 1. Large amount of EEPROM memory occupied by the CPA applet, and, as a result, high cost of the card.
• 2. In addition to the certification of the CPA application in EMVCo, when using the card as a solution for international payment systems, it will be necessary to undergo emission certification in payment systems. Obviously, the staff of the Ministry of Railways is not sufficiently prepared for the certification of CPA cards (there are no precedents), although the procedures for certification of CPA in the leading payment systems are formalized. In other words, certification of emissions in the MPS using CPA will take more time and take more effort than using the “standard” MPS applications.
• 3. The need to modernize the issuers' processing solutions for personalization and work with the CPA application.
• 4. Inability to work with the CPA application through a contactless interface.

Now let's consider the advantages of using standard MPS applications:

• 1. VSDC or M / Chip 4 applications and their certification procedures are well proven.
• 2. Readiness of processing solutions of the issuer's hosts to work with VSDC and M / Chip cards 4.
• 3. VSDC and M / Chip 4 applications on most cards are located in ROM, not requiring large EEPROM memory and reducing the cost of the card.

The disadvantages of using standard MPS applications are as follows:

• 1. Less functionality of VSDC and M / Chip 4 applications in comparison with CPA.
• 2. The need to configure risk management systems and personalization of cards for each application separately.

A summary of the results of the above analysis is presented in table. 8.9.

Tab. 8.9. Comparison results for EMV applications

Criteria / Applications	CPA	M / Chip	VSDC
Functionality (risk management)	Excellent	Good	Good
Transactional security	High for all applications. CPA and M / Chip also support IDN / DAC and cryptographic counters
Support for contactless fashion	Not supported	Supported by both apps
Issuer Host Upgrade Requirements	It is necessary to implement a new ARQC cryptogram verification algorithm and a new ARPC generation algorithm	No changes required
Requirements for modernization of the personalization system	Development of new personalization scripts is required	No changes required
Terminal requirements	No changes required
Card requirements	EEPROM must be over 40KB	Minimum EEPROM requirements: more than 2.5 KB
Requirements for certification	It is desirable that the application be certified by EMVCo	The application must be certified by the Ministry of Railways