Types of EMV cards: Software certification in the payment system

Definition of terminology and classification

There is no doubt that the main factor in choosing a particular type of emv card should be the compliance of this card product with the business tasks solved by the issuing bank. The amount of memory, processor performance, speed of information exchange with the terminal device and other technical characteristics of the card are secondary parameters designed to provide its necessary functionality. As an example, confirming the primacy of business tasks in comparison with the technical characteristics of the card, we can cite the methodology of card classification that Gemalto adopted when rebranding its product lines after the merger of Gemplus and Axalto. If earlier cards were primarily classified by the type of operating system used (Java Card or native) and the names of products were given in accordance with the name of the OS, now the name of the card first determines its functionality, and only then parametrically describes how these capabilities are met. However, in order to further bring the technical characteristics of the cards in line with the business tasks solved with their help, it is necessary to carry out a general classification of the currently used EMV cards. EMV cards can be divided into two large classes based on the type of operating system used:

with open operating systems (Java Card, Multos);
with an operating environment developed by the manufacturer for a specific product-native (or proprietary) cards.

Five or seven years ago, cards with an open operating system also included Windows for Smart Card (wfsc), but now the latter can be considered a closed project that has not received the support of card manufacturers. Cards with Multos OS have not been distributed in Russia and the CIS countries due to the complexity of administrative procedures for obtaining permission to issue them and the organizational and complex technology for generating cryptographic data. In turn, depending on the presence or absence of a crypto-coprocessor that provides asymmetric RSA cryptography, the cards are divided into:

cards with static authentication (SDA);
cards with dynamic and / or combined authentication (DDA/CDA), which usually also support verification of the encrypted PIN code on the card.

Even 5 years ago, the task of placing an RSA coprocessor in a smart card was quite difficult. Today, all smart card manufacturers have cards with a crypto-coprocessor in their product lines, however, the price of such cards is still slightly higher than cards without a coprocessor. De facto, EMV cards of international payment systems can work through a contact and / or contactless interface. Depending on the interface supported by the card to the service devices (read / write devices) cards can be divided into four types:

contact cards;
contactless cards;

• Combi card (dual interface to a single chip);

hybrid cards (cards with two chips – with contact and contactless interfaces).

Strictly speaking, contactless cards are not an independent type of EMV card, since the EMVCo specifications only describe the transport layer of interaction with a contactless card. The implementation of contactless financial applications from Visa and MasterCard currently has a number of fundamental differences. Despite the fact that EMVCo (as well as Visa) specified general rules for card personalization with EMV applications, not all cards meet the Card Personalization Specification (CPS) specifications. The vast majority of native cards do not meet these specifications. In this regard, EMV cards can be divided into:

cards and apps that support CPS;
cards and apps that require a specific personalization program.

Depending on the ability to upload applications to the card after it is made, cards can be divided into the following classes::

“static” cards (native and Java Card ” S»);

• “dynamic” card (full-featured Java Card and the multos multi-card).

“Static” cards can only be used by applications placed on the card during its production. “Dynamic” cards provide the ability to load arbitrary applications during the card issuance process (in addition to applications placed on the card during its production). So, we introduced a set of classifications EMV cards to in the future, depending on the Issuer of the task can be clearly defined, what type within each classification relevant to him card sequentially using the method of “exception” types of cards that do not meet the business requirements of the Bank.

EMV migration goals

Before choosing an emv card, it is necessary to clearly define all the business goals that the bank seeks to achieve with its issue. In other words, it is necessary to clearly state why the issuer needs EMV migration. Some banks are in this case configured to “try the water”: pass certification in the payment system, get initial experience in working with chip cards, while minimizing the cost of implementing the first stage of EMV migration. Mass emission is postponed for the foreseeable, but not quite certain period. In this case, you can recommend the simplest and, accordingly, budget card for testing. If the bank has already clearly defined the strategic goals for the development of its EMV program in the long term, and, accordingly, has formulated specific requirements for the card product, it should pay attention to the card that fully meets these requirements. You should be aware that sometimes the only result of this event will be the practical experience of the bank’s employees in issuing EMV cards. With a certain degree of probability, by the time the bank starts mass issuance of EMV cards, the type of card product with which the issuer was certified will be discontinued. In this case, the certification will need to be repeated in the payment system, and the personalization solution will need to be upgraded (simpler, often reduced to additional system settings, in the case of cards that support CPS, somewhat more complex in the case of native cards). If you are planning a mass release of EMV cards, first of all, you need to discuss the following functionality of the card:

• Should the card support offline operation as well as pre-authorized debit? Payment systems strongly recommend implementing dynamic data authentication (DDA/CDA) for cards with this functionality);

• Does the bank plan to provide customers with a home banking service and a similar one, using the CAP/DPA one-time password generation technology on the card? If the answer is yes, you must set the CAP/DPA application support requirement on the card.

• In the case of issuing cards containing additional applications of a standard other than EMV, for example:

loyalty;
fuel app;
an application of the “electronic wallet” type»;
social apps;
transport application, you should make sure that the technological features of the selected card will allow you to place the required applications on it and ensure that they work together.

• If some applications are planned to be placed or personalized after the card is issued to its owner, the card must support the post-issue mode of applications and have enough memory to accommodate new applications;

Card service via contactless interface using MasterCard PayPass or Visa payWave technology. Cards that support the contactless interface are more expensive than contact cards, and before making a decision about choosing a card with a contact/contactless interface, it is necessary to clearly define the scope of the contactless interface.

Map features and operation of the EMV application

The technical documentation for a card with an EMV application always specifies the EMVCo and payment system specifications that the financial application of the card corresponds to. However, this does not provide support for all the functionality described in the specification, but only guarantees that there are no contradictions between the application and the specified specification. As a rule, the supplier’s documentation contains sufficient information about the functionality of the card and the EMV application on it, but sometimes undocumented “properties” of the product are also found, so the only criterion of truth remains practice: only after checking the performance of the test card in all the required modes can you be sure that the card really meets the requirements. When migrating from one card type to another with similar functionality, changes to the list of personalized data may often also be required. In other words, the set of parameters required to implement the same functionality may depend on the card type. Let’s say a bank migrates from a Java card with a card provider applet that meets the VSDC 1.4.0 specification and supports:

data authentication in DDA/CDA mode;
logging of transactions in the card;
transfer of offline counter values to the issuer’s host, to a card with the Visa v. 2.5.1 applet (the latter implements similar functionality). At the same time, the Visa applet supports a 4-byte ADA length, and the “old” card supported a 2-byte length, since the transaction types (offline/online/decline) logged by the applet were not configured by the applet.

The values of other card parameters may also differ in the same way. On the other hand, from time to time banks are offered EMV cards “exactly the same as the manufacturer N, but 30% cheaper.” When testing, it may indeed turn out that the presented card exactly repeats the entire functionality of the manufacturer’s card.However, if this card is not included in the list of card products approved by the payment system (Approval ID), then, most likely, the bank will not be able to pass certification in the payment system with such a card. It is also recommended to check the Renewal Date of the card’s approval by the payment system. If the payment system does not extend the renewal period after it expires, it is likely that the manufacturer will soon stop issuing these cards as outdated, and the bank will have to migrate to another type of card. In the Visa payment system, the list of approved products is publicly available on the website partnernetwork.visa.com In turn, MasterCard provides this information to banks upon request. Of course, any recommendations on the analysis date for the re-approval of the card payment system is difficult to formulate clearly: if there is uncertainty about the future extension of the terms of approval of the card payment system in the question can help, or technical support specialists payment system or a private fair view of the Bank about how the functionality cards to meet the requirements of the payment systems and EMVCo bulletins. Summarizing the above, it can be noted that when choosing a card type with an emv application, you should take into account:

features of the card and the EMV application hosted on it (restrictions imposed by the card manufacturer);
the issuer’s requirements for the functionality of the card and its applications – both financial (online/offline, control of international and foreign currency transactions on the card, geographical restrictions on card maintenance) and additional (loyalty, fuel, etc.);
payment system requirements (availability of an Approval ID card with a specific application and an up-to-date Renewal Date).

Approaches to choosing a card

The criteria for selecting a card are:

EMV application functionality;
nomenclature of additional applications on the card;
cost of the EMV project (issue and maintenance).

Solving the problem of minimizing the cost of an EMV solution, provided that the formulated business requirements are met and taking into account the further development of the system, we can not limit ourselves to estimating the cost of the cards themselves. The cost of an emv solution includes the following main components:

• the cost of the EMV card;

• cost of card certification in the payment system;

the cost of a personalized solution;
the cost of supporting EMV cards in the processing center.

However, when making a decision on the implementation of an EMV project, you can not limit yourself even to such an important indicator as its total cost. As a rule, when migrating, there are a number of restrictions – the host (back office and front office) system was purchased by the bank earlier, and it is hardly worth changing it, based only on the need to implement this project. Also, the bank already has a network of terminal devices (terminals, ATMs) and personalized equipment, and it is often more expedient to upgrade it than to buy new ones. The experience of specific supplier companies in solving the tasks set is also important. The lack of experience in implementing such projects leads to delays in commissioning, re-certifications of cards, and problems in maintenance. The loss of time can be up to a year. On what scales can you weigh the savings of 20% of the project, on the one hand, and the loss of time (instead of the required 2-3 months, it turned out 10) – on the other?! The simplest of the cost criteria is the price of the card. But here, in addition to the price, there are indicators such as timing, the quality of the card body and printing, the reliability of the chip, etc. When choosing a card and a personalized solution, it should be remembered that after the launch, the period of operation, maintenance, and development of the system will begin. For example, migrating from one card type to another may require additional costs in the future. If the bank plans to issue cards of different manufacturers or different types, then the issue of cards that support a common personalization technology (for example, CPS) will reduce the cost of a personalized solution. At the same time, it is important that the personalized solution is easily modifiable to support new types of cards and new equipment. Let’s consider which types of cards meet certain functional requirements of the bank. If the bank wants to issue cards to work only in online mode, then any type of card approved for use by the payment system will suit it. The only limitation in choosing a card is the need to place additional applications on the card. If the cards are intended to work both online and offline, or the bank implements cards with an application that works in the pre-authorized debit mode, then the range of card products under consideration should be limited to cards that support dynamic data authentication (DDA/CDA) that meet the specifications of EMV 2000, Visa VIS 1.4.0 or MCI M/Chip4. International payment systems strongly recommend using dynamic data authentication for offline cards. Native cards used for online / offline authorization do not require a large amount of memory for data storage (EEPROM from 4 KB). As an example, you can use the following types of cards:

Gemalto Optelio D4 V14 (formerly e-Galleon G2 DDA 4K) ;

• Sagem Orga EMV Pro Y;

• Oberthur MonetIC Chrysalis.

All of the above cards come with pre-installed VCDS or M/Chip payment applications. Global Platform cards (EEPROM from 18 KB) used for online / offline authorization are Java Cards with Visa v applets.2.4.1, v. 2. 5. 1 (recommended), or similar applets from certified card manufacturers. Cards with the Visa v 2.4.0 applet also support dynamic data authentication, but do not meet Visa’s other security requirements and are currently removed from the approved list. Cards for the MasterCard payment system must meet the M/Chip4 Select specification. As an example of Global Platform cards, you can use:

Gemalto Optelio Java Dxx V14-VSDC, M/Chip4 applets;
KEBT Kona 20-VSDC, MasterCard M/Chip4 applets;
JCOP 21, 31-VSDC applets;

• Oberthur Cosmo DDA MonetIC – applets VSDC, MasterCard M/Chip4.

I would like to pay special attention to the cards belonging to the Java Card “S” type. The technology, called Java Card “S”, was proposed by SUN in 2003.However, it has only recently received mass implementation on cards. Java Card ” S ” cards (or static Java cards) do not allow you to download and remove applications from the card. Thanks to this, the Global Platform add-in has a minimum volume (for example, there is no support for additional Security Domain), which allows you to reduce the cost of the card. Unlike native cards, the Java Card “S” developer does not need to develop the card software (OS, applications, etc.) from scratch, it has the ability to place a standard EMV applet on the card, saving on its development and debugging. Due to the fact that these cards meet the requirements of the Global Platform specifications, their release is carried out using a universal personalized solution. The cost of static Java cards is equivalent to the price of native cards of the same class, but in the face of Java Card “S”, the bank acquires a carefully debugged product with standard personalization technology. Java Card “S” chip suppliers are currently:

Samsung Electronics Co. Ltd — KEBT-Kona 22S, 23S (SDA only);

• NXP Semiconductors — JCOP U-10, JCOP U-20, JCOP-U30 (SDA/DDA/CDA);

• Sharp Corporation – SJCard222 (SDA/DDA/CDA).

The main disadvantage of Java Card ” S ” is the inability to load additional applications on them. On some cards of this class, in addition to the financial application, the manufacturer pre-installs the loyalty application.

Placing additional applications on the EMV card

In addition to the financial EMV application, other business applications, including non-bank business applications, can be placed on EMV cards. Such applications can be placed during chip manufacturing (native and Java “S” cards) or during emission and post-emission (Java Card, Multos). Let’s look at the main types of additional applications and issues related to their placement on the card and maintenance. OTP applications. Applications that support One Time Password (OTP) technology and meet the DPA/CAP specifications can be used to authenticate the cardholder by generating a one-time password in home banking systems and any other banking applications that provide access to banking services to bank customers. Actually, the generation of a one-time password can also be provided by a financial emv application, but the values of offline transaction counters will be modified in the application on the card. Therefore, payment systems recommend placing a separate specialized EMV application on the card to generate one-time passwords. The OTP application can be placed on any type of card, it requires only a small amount of free memory (about 4 KB of EEPROM). The application does not use RSA algorithms and, accordingly, does not need a crypto coprocessor. On native cards, the OTP application must be personalized at the time the card is issued. On Java Card and Java Card “S”, the OTP application can be placed on the card and in post-issue mode. As practice shows, when implementing EMV projects related to placing additional applications on the card that do not comply with the EMV standard, significant problems arise. The authors of this article strongly recommend taking them into account before making a final decision on the feasibility of such a project and, accordingly, before choosing the type of card that can support these applications. At the same time, it is necessary to clearly formulate the following points:

Feasibility study and technical and economic analysis of the project;
Determining the card’s ability to host an additional (non-EMV) application;
Building a host system and updating terminal hardware software to support an additional application;
Defining the roles of all project participants in the use of an additional application (application issuer, terminal solution provider, retail network, fuel companies, etc.);
Creating a technology that ensures the management of the” life cycle ” of cards and applications.

For item 4, I want to emphasize that in the case of separate download, personalize, and manage additional system application card security needs to ensure a strict separation of Bank access to the financial EMV application and access a third party additional application. Paragraph 5 implies the need to develop procedures for restoring and / or blocking the card if it is lost, procedures for transferring additional application data when the card is reissued due to the expiration of the financial application, as well as in many other similar situations. Loyalty apps. Loyalty applications or discount applications placed on an EMV card not only “link” the cardholder to a certain retail network, but also encourage them to use the card more actively as a means of payment in retail outlets. Formally, these applications are supported by a number of native cards, but due to the limited possibilities for configuring loyalty schemes on such cards and the lack of generally recognized specifications, they have not received a noticeable distribution, despite a number of launched projects. Java Card ” S ” cards usually also contain a pre-installed loyalty app, but as with native cards, such apps have a number of limitations in their functionality. Cards with an open architecture allow you to download additional applications of arbitrary functionality, including loyalty applets. However, the application can only be personalized if there is free memory (EEPROM) on the card – from 6 KB or higher, depending on the specific application. The last note applies to all types of cards. Fuel applications. This is currently the most common type of add-on applications on EMV cards. Fuel applications can be supported by a number of native cards (for example, Gemalto Optelio MPCOS R1 (formerly MPCOS EMV R5), which contain an additional application of the “electronic wallet” type. When ordering large batches of cards, the manufacturer can place a custom application on the card at the request of the issuing bank. Java Card ” S ” cards generally do not provide support for such applications (unless an additional instance of the EMV application is used as a fuel application). Cards with an open architecture allow you to download additional applications with functionality defined by the issuer. The requirements for the amount of free memory (EEPROM) in the case of fuel applications are similar to the requirements for hosting loyalty applications. Applications for secure storage of arbitrary data. The appeal of such applications is that they are developed based on the specifications of payment systems:

• Visa – Visa Smart Secure Storage (V3S);

• MasterCard – MasterCard Open Data Storage (MODS).

Accordingly, the application documentation is available to participants of each of these payment systems and is a defacto intra-industry standard. Applications can be used to store owner identification data, cardholder loyalty history, cryptomaterial, etc. Applications can be pre-installed by the manufacturer on native cards or downloaded as additional applets to Java cards. The amount of memory used by the application depends on the amount of data stored in it. Social app. A very broad interpretation of this term does not allow us to accurately state on which types of cards it can be implemented. In many cases, nativecards that have an e-wallet application are able to support the functionality of a social application. In other cases, you can use MODS or V3S applications. Obviously, full-featured Java Cards allow you to load a social application of any type, as long as the amount of free memory of the card (EEPROM) allows it. Transport applications. In Russian projects for transport applications, as a rule, contactless cards with Mifare technology are used. There are 2 options for combining the transport contactless application with the contact EMV application. Hybrid cards (2 chips, 2 interfaces) are easier to manufacture. In particular, it can be any contact EMV chip that is implanted on a Mifare contactless card. Contactless applications MasterCard PayPass and Visa payWave. These applications are designed for making “fast” payments, can be used on transport and in retail service points that require fast customer service, for example, in fast-food restaurant chains. There are several types of contactless cards. The simplest is contactless cards with the image of a magnetic stripe on the chip. There are also combined Javacards (2 interfaces, 1 chip). For example, Gemalto has Optelio Contactless cards (GCX-4 for PayPass and Palmera Air for payWave). The cost of these cards is significantly higher than cards with a single contactless interface, but they can be fully personalized through the contact interface, which minimizes investment in the personalization system (both in hardware and software). Using a special applet that emulates Mifare, such cards can ensure the functioning of the transport application using previously implemented technology.

Price ratio for different types of cards

It is very difficult to give absolute price values on cards, because in many cases this information is confidential. Absolute figures depend on the size of the delivery batch and many other reasons. However, we will try to illustrate the ratio of prices for different types of cards (see Figure 1). Due to the fact that the presence of a crypto coprocessor significantly affects the price of an EMV card, in our diagram, the prices for native and Java “S” cards are shown separately for products without a coprocessor (SDA) and for cards with a coprocessor (SDA/DDA/CDA). Full-featured Java-cards, as a rule, have a crypto-coprocessor (the exception is 3-4 types of cards, including JCOP V10), and in the diagram, the division of this type of cards into subclasses is performed by another parameter – the amount of EEPROM memory. Java cards with 18 KB of memory allow you to implement a basic financial application and, possibly, an additional application. In fact, the capabilities of such a card are equivalent to those of Java Card “S”cards. Cards with a memory of 32 KB or more allow you to upload any additional applications to the card, but their price also differs dramatically in a big way from all other types of cards. As the diagram shows, currently the prices for native cards and Java Card ” S “cards of the same functionality are almost identical, which should encourage the spread of Java Card” S ” cards on the world market. We deliberately excluded cards with a contactless interface from consideration, as this would reduce the visibility of the diagram. It can only be noted that the use of two interfaces in the card, contact and contactless, almost doubles the price of the card.

The effect functionality of the cards on the certification procedures

Features of the emv application functioning on a certain type of card must be taken into account when filling out the certification forms of the payment system. When passing certification, it is necessary to fill out the appropriate forms-Visa Personalization Assistant (VPA) or CPV Issuer Form (MasterCard), which primarily defines the basic functionality of the card and how it is serviced by the issuing bank. When defining a set of card parameters, it is necessary to control their nomenclature by consulting the documentation of the card provider. In VPA (Visa), the user defines the class to which the card belongs: native or Java Card, then lists the functions supported by the card (AIP). The subsequent set of questions asked in the VPA largely depends on the previously given answers. The generated VPA output files do not contain all the data required for personalization, but only those values that are controlled during certification. In addition to comparing the results of filling out the VPA with the test card, the card is checked using the Card Validation Tool (currently used by Collis) for data sufficiency and consistency. In the CPV form (MasterCard), the key is the type of payment product placed on the card and the set of checks on the cardholder’s authority. The templates described in MasterCard documents allow from 1 to 4 sets of checks, depending on the type of payment product. Some data elements have predefined values depending on the selected template. Certification in MasterCard is carried out in two stages (which can be combined in time):

control of data filled in the cpv form;
check the performance of the test card and its compliance with the CPV form.

The process of certification of EMV cards in the payment system requires special care. We strongly recommend that before sending the card for certification, you test the card for compliance with the parameters specified in the certification form and the necessary business requirements.

Conclusion

It is obvious that within the framework of a journal publication, it is impossible to give recommendations on choosing the type of EMV card for all occasions. In each particular case, many factors have an impact on the final decision. Therefore, the purpose of the authors of this article was to share with issuers the practical experience gained over 5 years on dozens of implemented projects, to suggest some ways to choose a rational solution and to warn against mistakes often repeated by banks.