Payment EMV-card. Payment Security Mechanisms

Payment cards are firmly embedded in our lives. More recently, only cards with a magnetic strip were used everywhere. Today you will not surprise anyone with a card with a chip. Everyone knows that a chip, microprocessor, or, more consonant, payment EMV card is a modern and reliable way to access a current account. It is safer than a magnetic stripe card and it is almost impossible to fake. However, the details of the implementation of the "insides" of the EMV card are little known. Everyone who is interested in how the EMV-card works, why EMV technology ensures the security of payments and how much it is worth trusting all this, welcome to cat.

1. Introduction

What cards will we talk about?

Today, international payment systems (MPS) use the EMV standard to conduct bank card transactions. One of the most famous MPS, which is at the origins of the development of this technology, are VISA Inc and MasterCard Worldwide. Since the microprocessor cards of these companies are based on the common EMV technology, we will consider a generalized EMV card without going into details of the implementation of a company.

It should be noted right away that the EMV specification is quite large, so the article does not claim to be a full description of the standard. Many things will be presented in a simplified form without the use of specific terminology. Since the standard is open, you can always read and understand the details on the EMVCo website if you wish .

Describing payment transactions and the functionality of an EMV card, we will refer to other participants in the system. In addition to the payment system itself, the transaction process involves:

• issuing bank - the bank that issued the payment card, and whose account is in this bank
• acquiring bank - a bank that serves a payment terminal
• payment terminal - a device that provides work with a payment card

Considering the EMV payment card in more detail, we will focus not only on the capabilities of the microprocessor. EMV technology has changed both the cards themselves and the messages exchanged between system participants; expanded the functionality of applications for terminals, acquiring banks and issuers.

2. Magnetic and EMV card authentication

One of the main tasks of the bank that issued the card is to authenticate the card during its use. In this case, authentication refers to the process of proving that a given card (or application on a card) is issued by a bank authorized for this by the relevant payment system.

How does the card authentication process work?

In general, after reading the card data, the terminal sends them through the acquiring bank and the payment system to the issuing bank. Based on the card data, the issuer determines its authenticity.

This process is one of the main problems of the security of payments by magnetic cards. On the one hand, the integrity of the magnetic card data is reliably protected by the CVV / CVC code (CVC - Card Verification Code, CVV - Card Verification Value) and it is useless to modify them. On the other hand, it’s pretty easy to copy the entire map.

2.1 Magnetic card authentication based on static data

For authentication in magnetic card transactions, static card data is used. This card data is transmitted to the issuing bank each time and does not change throughout the card's validity period. In addition, the payment terminal practically does not assess the risks of transactions with magnetic stripe cards. As a result, in the case of a complete copying of the card, the issuing bank will not be able to reliably determine the authenticity of such a card. Accordingly, the probability of a fraudulent operation is quite high.

2.2 EMV Card Authentication Based on Dynamic Data

How do EMV cards solve this issue?

The solution to the above problem is to digitally sign static card data and transaction data that are sent to the issuer. Since a digital signature is unique for each transaction, faking or copying an EMV card is not a trivial task.



Let us consider in more detail how dynamic authentication of a card occurs during an EMV transaction. The transaction process begins when the card is installed in the terminal. The terminal transmits transaction data to the card (amount, currency, country, etc.). Then the card and the terminal mutually verify the risks of the transaction. If both devices are “satisfied”, then the card signs the transaction data, and the terminal fills in the received field (tag or tag) “DE 55” and sends it to the acquirer bank. That, in turn, sends a message to the issuing bank.

The issuer, having received the “DE 55” field, verifies the authenticity of the signature (hereinafter cryptograms) of the card, which is calculated based on the dynamic data of the current transaction, thereby verifying the authenticity of the card itself.

The process described above is a highly simplified model of an EVM transaction. However, it reveals the main security aspect of EVM payments - the use of dynamic data instead of static data for card authentication.

It should be noted that the issuer has new opportunities:

• checking dynamic cryptograms of a card
• mutual authentication: the issuer can send its cryptogram to the card
• the ability to update card data after authentication (for example, block a card or change the limit).

Also in EMV transactions, the terminal and its risk assessment system play a significant role, according to which both the terminal and the card can make decisions about the possibility of conducting a transaction.

3. The internal structure and security of the EMV card

By and large, the EMV microprocessor card is an ordinary smart card (read one , two , three ), which is based on the ISO / IEC 7816 or ISO / IEC 14443 standards (for contactless).

Implementation of EMV-cards can be performed both on the basis of JavaCard and GlobalPlatform , and using native smart-card methods. Similar to conventional operating systems (OS), card OS also have a file structure and applications. In the context of this article, it is the EMV card payment applications that are most interesting. Therefore, we will consider just them.

What is an EMV payment application?

From the point of view of the user (terminal or ATM), a payment EMV application is a software product with an interface described in detail in the EMV standard.

The interface is a series of commands for conducting transactions and managing EMV applications. Detailed information can be found in the EMV Book 3 Application Specification . Despite the existence of the standard, Visa and MasterCard payment applications have differences in implementation. Different applications of the same company may also differ. For example, “M / Chip 4” and “M / Chip Advance” from MasterCard.

Regardless of the implementation, each application has its own identifier, the so-called AID (Application Identifier). It indicates what type of payment system the application belongs to. Using the application identifier AID, the terminal determines the possibility of conducting a transaction or, in the case of several applications, builds a list of supported applications and suggests choosing one of them.

If the file structure and application management are implemented on the card, what mechanisms ensure data security from external access?

It is worth dividing the life time of the card until the bank issues it, and after.

Initial access to a clean card is usually regulated by the chip manufacturer. Most often, each batch of cards has its own card key, with which it is necessary to authenticate with the card during its flashing.

In the next step, access to the file system and applications is usually regulated by the operating system. It also has its own key, and, accordingly, authentication is required for access.

Next, the installed application goes through the process of personalizing the card. Personalization is the loading of application parameters and keys that determine the security of EMV transactions. Access to this process also requires authentication with the application key.

After installing the application and its personalization, the above accesses are usually closed permanently. Which excludes the possibility of penetration "inside" after the release of the card.

Total: the card key, the OS key and the application key protect the card from third-party interference at various stages of its production. If during the manufacturing part of the cards will be discredited (for example, stolen), these keys will protect the cards from outside interference. And without knowing the keys of the card, it becomes almost completely useless.

Some application data may be modified after the release of the card. Changes can be made by so-called script commands. The exclusive rights to introduce changes belong to the issuer. This possibility is provided so that at any time, the issuer can block or unblock the card, update the limits or settings of the card. Data is updated by the terminal or ATM only after a successful online transaction (authentication with the bank). The data comes to the card from the issuer in its pure form, but it has an analogue of a digital signature - MAC, which guarantees data integrity. To calculate the MAC, the corresponding application key is used (one of the three DES keys loaded into the application).

Separate items are the modification of an offline PIN code (offline PIN) and a limit counter for failed PIN entries (PinTryLimit). These changes are also performed by a script command with a MAC signature. However, when changing the PIN code, these commands are additionally encrypted using a special key designed solely to perform the described process.

4. EMV Application Data

Like magnetic stripe cards, EMV applications also have open readable data. And although it is impossible to read the application itself, it is impossible to get to the keys and pin code - access to open application data is always open.


EMV application

data What kind of data is it?

The picture above is an indicative list of the data stored inside the EMV application. Of course, for each specific application, it may be slightly different. At this stage, it is important to note that the client’s personal information is not stored in the EMV application. Indeed, the larger memory capacity of the chip allows payment systems and banks to store more information on the card - however, the client’s personal information is not there.

The previous picture clearly illustrates the fact that the card stores a lot of technical data necessary for efficient operations and access to the account. EMV application data is placed in records (records or tracks). A list of them can be obtained in response to the Get Processing Options command. A specific record can be read using the Read Record command. Inside may be: key certificates, card number (PAN - Primary Account Number), CVM list– Card Verification Methods list, and a lot of other information. Reading these records is very similar to reading tracks from a magnetic strip. The technical settings of the card, counters and limits can be obtained using the “Get Data” command, indicating the required type.

Interestingly, almost all data on the cardholder’s account and application settings can be subtracted from the card without any difficulties. The only things that can’t be reached are the application keys and the value of the pin code.

Can I copy data from one chip card to another?

If you have a card with a “clean” (not personalized) application, then this is technically feasible. However, due to the lack of the ability to make a copy of the card keys, the application will generate incorrect transaction signatures. As a result, the issuer will reject any online transactions. Also, the lack of keys will not allow CDA / DDA authentication. The only flaw is SDA offline. However, at the moment, this method as the only authentication method is considered obsolete. Next, we will consider in detail how the EMV transaction is protected.

Can I copy EMV application data to a magnetic strip?

From the data of the EMV application, it is possible to compose tracks for a card with a magnetic strip, with the exception of one small parameter - the Service Code. As data for the EMV application, the service code indicates to the terminal that the transaction should be conducted using the card application. If you take this code “as is” and copy it onto the magnetic track, the terminal will try to complete the transaction using the application. It would seem that you can edit the service code, but data integrity is protected by the CVV / CVC code. It is the closest analogue to a digital signature.

It feels like the EMV card is copy protected on all sides. Although one trivial opportunity is still known. For compatibility mode, manufacturers produce a combined type of EMV card - that is, with a microprocessor and a magnetic strip. It is possible to copy the magnetic stripe data to another combined card with an inoperative chip (clean or burned) and try to carry out the so-called fallback (if it is impossible to read the chip, the terminal performs an operation on the magnetic stripe). Currently, such operations are not welcomed by payment systems, and the risk of these operations lies with the acquirer or issuer.

5. EMV Transaction Security

There are two different (although they perform the same function) options for conducting a payment transaction - online and offline. Above, we broadly considered an online transaction, which the issuer confirms in real time. An offline transaction is carried out by the terminal without immediate confirmation by the bank. Such transactions are used for operations with low risk or in the case of, for example, lack of communication with the issuing bank.

For these two types of transactions, there are two types of authentications, respectively - online and offline. In the case of online authentication, the operation is performed with the participation of the issuer, and offline authentication is confirmed by the payment terminal. It should be clarified that during an online transaction, both online and offline authentication can be performed simultaneously (if both the card and the terminal support this). Despite the redundancy of the scheme, at the authentication stage it is not always clear in what mode the transaction will take place.


The order of the transaction card - terminal

The security features discussed below are only part of the EMV transaction. In addition to authentication, the security functions include: risk assessment of the transaction and verification of the card holder (online and offline pin, transaction amount, country, currency, etc.).

5.1 Online EMV Transaction

The main method of confirming the authenticity of the card in online transactions is the authentication of the card online. The basis of this method is the generation of the ARQC (Authorization Request Cryptogram) cryptogram for each payment transaction. Let's take a closer look at this process.


Online EMV transaction

Generation and verification of cryptograms is based on the 3DES algorithm. The issuer and the card own a shared secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates an SKac (Application Cryptogram Session Key) based on MKac. An 8-byte ARQC cryptogram is generated by the card using the MAC algorithm on the SKac session key using transaction data.

During the transaction, the ARQC cryptogram generated by the card is sent to the issuing bank, the Bank will verify the incoming ARQC with the cryptogram that it calculated on its own. For this operation, the bank generates a session key, then, based on the received transaction data, its own ARQC is calculated. If your own (generated by the issuer) ARQC and ARQC cards converge - the card is genuine.

Next, the issuer, using a similar algorithm, generates ARPC (Authorization Response Cryptogram) based on dynamic transaction data and response data and sends this cryptogram back to the card. At the moment when the card is confirmed by the incoming ARPC, mutual authentication of the card and the issuer is completed.

The above describes the basic card authentication mechanism that is used for online transactions. As already mentioned, offline authentication may be present in an online transaction. However, in order not to complicate, consider a detailed description of offline authentication in the context of an offline transaction.

The next security method is the extended data in Field / DE 55 which is transmitted to the issuing bank. Field / DE 55 contains the results of the card and terminal, risk assessment and transaction analysis.



As shown in the image above, Field / DE 55 contains important information. For example, Terminal Verification Result, Card Verification Result, which, together with the rest of the data, help the issuer and the payment system understand how the transaction occurs and provide many additional details for assessing the risks of the transaction.

5.2 Offline EMV Transaction

The peculiarity of an offline transaction is that the transaction is carried out by card and terminal without contacting the bank and the payment system. During such a transaction, the card can approve the transaction within the established limit, and the terminal, in turn, sends information to the bank later on schedule, or when a connection with the bank appears. Such offline transactions provide additional benefits to both the issuing bank and the card holder. For example, the owner may pay even if there is no connection with the bank. Or, if the amount is small, the operation will be much faster.

How does card authentication occur in an offline transaction?

It was mentioned earlier that online and offline authentication use different technologies. If online uses the 3DES cryptographic algorithm, then in the case of offline, RSA with asymmetric keys is used. Why use such different technologies? The thing is that with online authentication, only the card and bank store the keys. In the case of offline, the key must be entrusted to the terminal. Given the large number of terminals, it is likely that the secret key trusted to the terminals will not remain secret for long.

Because the detailed description of offline card authentication is quite large, consider a simplified model.


Static Data Authentication

At the head of all is a payment system (more precisely, a certification authority) that issues a pair of keys: a private key (red) and a public key (blue). The issuing bank also has its own key pair. For its keys, the issuer in a special way generates a certificate (Issuer Public Key Certificate), which contains the issuer's public key. This certificate is signed (encrypted) with the private key of the payment system. In the process of personalization, this certificate is uploaded to the card.

When the payment terminal is installed at a point of sale and connected to the system, the public key of the payment system is downloaded to the terminal through the acquirer bank.

During the offline transaction, the terminal performs offline authentication of the card. First, the terminal deducts the Issuer Public Key Certificate from the card, and using the public key of the payment system checks the signature of the certificate (i.e. decrypts). If the signature is correct, the issuer's public key is retrieved. Further, using the issuer's public key, the signature of the critical card data is verified, which confirms its authenticity.

The method described above relates to Static Data Authentication (SDA). Currently, dynamic authentication is more commonly used: DDA (Dynamic Data Authentication) and CDA (Combined Data Authentication), which include SDA and additionally, similar to online, sign data that runs between the terminal and the card. Data is signed with the private key of the card, which is uploaded to the card during personalization. The signature is verified by the terminal using a public key recovered from the corresponding certificate.

SDA technology allows the terminal to verify that the data on the card is not modified. However, it does not allow to fully identify the authenticity of the card (it is possible to copy SDA data). In turn, DDA and CDA technologies make it possible to confirm the authenticity of the card, because the card is a carrier of a unique private key whose certificate (public key) is signed by the issuer's private key (issuer certificate (its public key) is signed by the private key of the payment system).


DDA and CDA technologies already contain SDA and are generally similar. Both algorithms use a unique card key and dynamic data. DDA authentication is a separate operation and is performed before the main cycle of the transaction process. CDA is executed in the main transaction cycle, and a card cryptogram is additionally used as signed data. In general, today, DDA technology is more common, although CDA is more preferable to use.

In addition to digital signatures, the terminal and the card are able to assess the risks of the transaction. For an offline transaction, the card can operate with several types of transaction counters and accumulators of offline amounts, currencies and countries, offline pin and its limits, as well as additional rules. In the process of personalizing the card, the issuer has the ability to limit the maximum number of consecutive offline transactions and / or the maximum transaction amount (lower and upper limits), thereby determining the level of risk.

For each implementation of the application of a particular payment system, there is a set of rules on the basis of which the card can make decisions to conduct offline, online or reject the transaction. The list of these rules is quite flexible and can be configured differently by the issuer for each card product. The decision process may involve the results of previous transactions, offline counters, pin verification results, etc.

6. Cardholder verification method

Almost the entire article was devoted to transactions and the process of card authentication, and little attention was paid to the card user. With the advent of EMV technology, cardholder verification has not changed too much. Currently, the most popular verification methods are: verification of the pin code (online and / or offline) and the signature of the card holder. It so happened that with the advent of EMV, not all payment terminals have the same verification capabilities of the card holder (for example, due to the age of the equipment). In turn, different EMV applications may also be limited in capabilities. Therefore, the terminal and the card have to choose the appropriate method of checking the card holder. For this, the so-called CVM lists are used. The CVM list defines the cardholder verification methods and their priorities. And a billing application, and terminal have their own lists. The final list is determined by combining the terminal and application lists. From the resulting list, the terminal selects the general CVM method with the highest priority and checks the card holder.



An example of such a list is presented in the picture above. For example, if a card is inserted into an ATM, an online pin will be requested, if an offline pin is sent to the terminal. If the device does not have a pin pad, a signature verification will be requested. In all other cases, verification of the card holder will not be performed.

Conclusion

In this article, the EMV payment application and the data stored in it were examined superficially, the main differences in the transaction processes for magnetic and EMV cards are described. The procedures for conducting online and offline transactions and mechanisms for ensuring their security were also considered. Of course, every aspect of EMV technology has much greater depth and complexity. However, I hope that the article gave a general understanding of the principle of operation of payment EMV cards and making payments with their help.

In conclusion, we can say that a payment EMV-card is a complex and high-tech product that reliably protects access to your bank account. Microprocessor EMV-card is almost impossible to copy, and each transaction is protected by a unique digital signature. Any actions taking place inside the card are regulated by a strict set of rules with instructions on what to do in each particular case. In the process of creation, payment EMV applications undergo mandatory multi-level certification and receive permission from the payment system to use them. It is difficult and interesting to program such cards. However, the description of this process may stretch to more than one article.

Thanks for attention!

PS I will be glad to answer your questions in the comments