Payment EMV card. Payment security mechanisms

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

1. Introduction

What cards are we talking about?

Today, international payment systems (MPS) use the EMV standard for conducting bank card transactions. One of the most well-known MPSs who are at the forefront of developing this technology is VISA Inc and MasterCard Worldwide. Since the microprocessor cards of these companies are based on the general technology of EMV, we will consider the generalized EMV card without going into details of the implementation of a company.
')
It should be immediately noted that the EMV specification is quite large, so the article does not pretend to provide 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, if you wish, you can always review and understand the details on the EMVCo website.

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

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

Considering the details of the payment EMV-card, we will focus not only on the capabilities of the microprocessor. EMV technology has altered both the cards themselves and the messages exchanged between the system participants; expanded application functionality 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 this card (or the application on the card) is issued by a bank authorized by the relevant payment system.

How is the card authentication process?

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

In this process is one of the main problems of security of payments by magnetic cards. On the one hand, the data integrity of the magnetic card 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 is quite simple to copy the entire map entirely.

2.1 Magnetic card authentication based on static data

For authentication, magnetic card transactions use static card data. These card data are each time transferred to the issuing bank and do not change throughout the life of the card. In addition, the payment terminal practically does not evaluate the risks of transactions with magnetic stripe cards. As a result, in the case of a complete copy of the card, the issuing bank cannot reliably determine the authenticity of such a card. Accordingly, the likelihood of a fraudulent transaction 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 is sent to the issuer. Since a digital signature is unique to each transaction, tampering with or copying an EMV card is not a trivial task.



Let's take a closer look at how dynamic card authentication occurs during an EMV transaction. The transaction process begins at the time of installation of the card in the terminal. The terminal transmits the transaction data to the card (amount, currency, country, etc.). Then the card and the terminal perform a mutual check of the transaction risks. If both devices are “satisfied”, then the card signs the transaction data, and the terminal fills the “DE 55” field (tag or tag) with the received data and sends it to the acquiring 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 cryptogram) 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 heavily simplified EVM transaction model. However, it reveals the main security aspect of EVM payments — the use of dynamic data instead of static for authentication of a card.

It should be noted that the issuer has new opportunities:

• verification of dynamic card cryptogram
• 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, a significant role is assigned to the terminal and its risk assessment system, according to which both the terminal and the card can make decisions about the possibility of conducting a transaction.

3. Internal structure and security of an 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 a contactless one).

The EMV card can be implemented using both a JavaCard and GlobalPlatform , as well as using native smart card methods. Similar to conventional operating systems (OS), card operating systems 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 them.

What is a payment EMV application?

From the user's point of view (terminal or ATM), an EMV payment 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 a standard, payment applications of Visa and MasterCard companies have differences in implementation. Different applications of the same company may also differ. For example, "M / Chip 4" and "M / Chip Advance" by MasterCard.

Regardless of the implementation, each application has its own identifier, the so-called AID (Application Identifier). It indicates which type of payment system the application belongs to. Based on the application identifier, the AID terminal determines whether a transaction is possible or, in the case of several applications, builds a list of supported applications and offers to select one of them.

If the card has a file structure and application management, which mechanisms ensure data security from outside access?

Here it is worthwhile to divide the life time of the card until the bank issues it, and after.

The primary 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 controlled by the operating system. It also has its own key, and, accordingly, authentication is required for access.

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

After installing the application and personalizing it, the above accesses are usually closed forever. 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. In the event that during the manufacturing of a 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 can be modified after the release of the card. Changes can be made by so-called script commands. Exclusive rights to introduce changes belong to the issuer. This possibility is provided so that at any time, the issuer can block or unblock a card, update limits or card settings. The data is updated by the terminal or an ATM only after a successful online transaction (authentication with the bank). The data comes to the card from the issuer in its pure form, however, they have a digital signature analogue - 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 the offline pin-code (offline PIN) and the limit counter for unsuccessful pin-code 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 exclusively for performing the described process.

4. EMV Application Data

Similar to magnetic stripe cards, EMV applications also have public data available for reading. And although the application itself is impossible to read, as it is impossible to get to the keys and pin-code - access to the open application data is always open.


EMV application data

What data are we talking about?

The picture above shows an indicative list of data stored within the EMV application. Of course, for each application it may be slightly different. At this stage, it is important to note that customer 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, there is no personal customer information.

The previous picture clearly illustrates the fact that the map contains a lot of technical data necessary for effective operations and access to the account. These EMV applications are placed in records (records or tracks). Their list can be obtained in response to the “Get Processing Options” command. The specific record can be read using the “Read Record” command. Inside can be: key certificates, card number (PAN - Primary Account Number), lists of card verification methods (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 data of the technical settings of the card, the counters and limits can be obtained by the command “Get Data”, 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 thing you can’t get is the application keys and the pin-code value.

Can I copy data from one chip card to another?

If you have a card with a “clean” (non-personalized) application, then this is technically feasible. However, due to the inability 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 for CDA / DDA authentication. The only flaw is SDA offline. However, at the moment this method in the form of a single authentication method is considered obsolete. Next will be discussed in detail how the EMV transaction is protected.

Is it possible to copy EMV application data to a magnetic strip?

From the data of the EMV application, you can compile tracks for a magnetic stripe card, with the exception of one small parameter - the Service Code. As data for an EMV application, the service code indicates to the terminal that the transaction should be carried out using the card application. If you take this code "as is" and copy it to 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 the integrity of the data is protected by a CVV / CVC code. It is the closest analogue of a digital signature.

It seems that the EMV card is copy-protected. Although still known one trivial opportunity. For compatibility mode, manufacturers produce EMV cards of the combined type - that is, with a microprocessor and a magnetic strip. It is possible to copy the magnetic strip data to another combined card with a non-working chip (clean or burned) and try a so-called fallback (if you cannot read the chip, the terminal performs an operation on the magnetic strip). At the moment, such operations are not welcomed by payment systems, and the risk of these operations falls on the acquirer or issuer.

5. Security EMV transactions

There are two different (albeit performing the same function) options for conducting a payment transaction - online and offline. Above, we outlined the online transaction, which the issuer confirms in real time. An offline transaction is performed by the terminal without instant confirmation by the bank. Such transactions are used for transactions with low risk or in the case of, for example, a lack of communication with the issuing bank.

For these two types of transactions, there are respectively two types of authentication - 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 it). 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 an EMV transaction. In addition to authentication, security features include: risk assessment of the transaction and verification of the cardholder (online and offline pin, the amount of the transaction amount, country, currency, etc.).

5.1 Online EMV Transaction

The main method of authenticating a card in online transactions is to authenticate the card online. The basis of this method is the generation of an ARQC (Authorization Request Cryptogram) cryptogram by the card for each payment transaction. Let's look at this process in more detail.


Online EMV Transaction

The 3DES algorithm is at the heart of the generation and verification of cryptograms. The issuer and the card own the shared secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates a session key SKac (Application Cryptogram Session Key) based on the 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 checks the incoming ARQC with the cryptogram which it has calculated on its own. For this operation, the bank generates a session key, then, based on the incoming transaction data, its own ARQC is calculated. If the own (generated by the issuer) ARQC and ARQC cards converge - the card is genuine.

Further, the issuer, using a similar algorithm based on dynamic transaction data and response data, generates an ARPC (Authorization Response Cryptogram) and sends this cryptogram back to the map. At the moment when the card is confirmed by the incoming ARPC, the 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 transactions may be present in the online transaction. However, to keep things simple, consider a detailed description of offline authentication in the context of an offline transaction.

The next security method is 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, important information is contained in the Field / DE 55. For example, Terminal Verification Result, ard Verification Result, which together with the rest of the data, help the issuer and the payment system to understand how a transaction takes place and provide many additional details to assess the risks of a transaction.

5.2 Offline EMV Transaction

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

How does the card authenticate during offline transactions?

It was previously mentioned 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 fact is that with online authentication, keys store only the card and the bank. In the case of offline, the key must be trusted to the terminal. Given the presence of a large number of terminals, there is a possibility that the secret key entrusted to the terminals will not remain secret for long.

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


Static Data Authentication

At the head of everything is the payment system (more precisely, a certification authority), which 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 downloaded to the card.

When a payment terminal is installed in a point of sale and connected to the system, the public key of the payment system is loaded into the terminal through the acquiring bank.

During an offline transaction, the terminal performs offline card authentication. First, the terminal reads the Issuer Public Key Certificate from the card, and with the help of 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 extracted. Further, using the issuer's public key, the signature of the card’s critical data is verified, which confirms its authenticity.

The method described above relates to static authentication SDA (Static Data Authentication). Currently, dynamic authentication is more commonly used: DDA (Dynamic Data Authentication) and CDA (Combined Data Authentication), which include SDA and additionally, by analogy with online, sign data that runs between the terminal and the card. The data is signed by the card's private key, which is loaded onto the card during the personalization process. The signature is verified by the terminal using the 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, the DDA and CDA technologies allow you to confirm the authenticity of the card, because the card is the carrier of a unique private key, whose certificate (public key) is signed by the issuer's private key (the issuer's 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 performed in the main transaction loop, and a card cryptogram is additionally used as the data to be signed. In general, today, DDA technology is more common, although CDA is more preferable to use.

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

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

6. Verify Cardholder CVM Card Holder

Virtually the entire article was devoted to transactions and the card authentication process, and little attention was paid to the card user. With the advent of EMV technology, cardholder verification has not changed too much. At the moment, the most popular verification methods are: checking the pin-code (online and / or offline) and the cardholder's signature. It so happened that with the advent of EMV, not all payment terminals have the same cardholder verification capabilities (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, so-called CVM lists are used. The CVM list defines the methods for checking the cardholder and their priorities. , . . CVM- .



. , – -, – -. , - – . .

Conclusion

EMV- , EMV-. - . , EMV, . , , EMV- .

, EMV- , . EMV- , . , , . EMV- . . , .

Thanks for attention!

PS