EMV

Another article is devoted to human stupidity and laziness, namely those who are unable to understand obvious things on their own.

Very often, I am approached in the hope of finding EMV software, with which to write data on a card chip, so that in the future I can cashlessly cash 201 cards.

I will express my opinion on this at the end of the article, and in the meantime let us understand what EMV is and how this beast works, because only knowing how the castle works, you can find a key to it.

1. Introduction

Today, international payment systems use EMV to conduct credit card transactions. VISA Inc and MasterCard Worldwide are among the most prominent MEAs at the origin of this technology. Since the microprocessor cards of these companies are based on common EMV technology, we will consider a generalized EMV card without going into the details of a company 's implementation.

It is worth noting immediately 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 simplified form without using specific terminology. Since the standard is open, if desired, you can always familiarize yourself with and understand the details on the EMVCo website.

In describing payment transactions and EMV card functionality, we will refer to other members 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 - bank that serves payment point terminal
• Payment terminal - a device that works with the payment card

Considering the EMV 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 by system members; Expanded the functionality of applications for terminals, acquisition 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) has been issued by a bank authorized to do so by the appropriate payment system.

How is card authentication going?

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 determines its authenticity based on the card data.

This process is one of the major security concerns for magnetic card payments. On the one hand, the integrity of data of a magnetic card is reliably protected by the CVV/CVC code (CVC - Card Verification Code, CVV - Card Verification Value) and to modify them is useless. On the other hand, it 's pretty easy to copy the whole card.

2.1 Static Card Authentication

Card static data is used to authenticate magnetic card transactions. This card data is sent to the issuing bank each time and does not change throughout the validity of the card. In addition, the payment terminal hardly estimates the risks of transactions on cards with a magnetic strip. As a result - in case of full copying of the card - the issuing bank will not be able to reliably determine the authenticity of such card. Accordingly, the likelihood of a fraudulent transaction is quite high.

2.2 Dynamic EMV card authentication

A solution to the above problem is to digitally sign the static card data and transaction data that are sent to the issuer. Because a digital signature is unique to each transaction, faking or copying an EMV card is a non-trivial task.

Let 's take a closer look at how dynamic card authentication occurs during an EMV transaction. The transaction process begins when the card is installed in the terminal. The terminal transmits transaction data (amount, currency, country, etc.) to the card, and then the card and the terminal perform a mutual transaction risk check. If both devices "suit" everything, the card signs the transaction data, and the terminal fills the received data field (tag or tag) "DE 55" and sends it to the acquiring bank. He, in turn, sends a message to the issuing bank.

The issuer, having received the field "DE 55," verifies the authenticity of the signature (hereinafter cryptogram) of the card, which is calculated on the basis of dynamic data of the current transaction, thus verifying the authenticity of the card itself.

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

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 carrying out the transaction.

3. EMV Card Internal Structure and Security

By a larger account, the EMV microprocessor card is a regular smart card (I will later write articles on how they are arranged), based on ISO/IEC 7816 or ISO/IEC 14443 (for contactless).

Implementation of the EMV card can be done on the basis of JavaCard and GlobalPlatform, as well as 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, EMV card payment applications are the most interesting. So we will consider them.

What is an EMV payment application?

From the point of view of the user (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. See EMV Book 3 Application Specification for details. Despite the existence of the standard, payment applications of Visa and MasterSad have differences in implementation. Different applications of the same company may also differ. For example, "M/Chip 4" and "M/Chip Advance" of the MasterCard company.

Regardless of implementation, each application has its own identifier, the so-called AID (Application Identifier). It indicates which type of payment system the application belongs to. According to the application ID of the AID, the terminal determines whether the transaction can be carried out 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 control, what mechanisms do you want to protect data from external access?

Here it is worth dividing the life of the card until the moment of issue by the bank, and after.

• 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 firmware.
• In the next step, access to the file system and applications is typically controlled by the operating system. It also has its own key, and accordingly, authentication is required for access.
• The installed application then goes through the card personalization process. Personalization is the loading of application parameters and keys that determine the security of EMV transactions. Authentication using an application key is also required to access this process.
• Once the app is installed and personalized, the above accesses are usually closed permanently. Which prevents the possibility of entering "inside" after the card is issued.

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

Some application data can be modified after the card is issued. Changes can be made by so-called script commands. Exclusive rights to implement changes belong to the issuer. This option allows the issuer to block or unlock the card, update limits, or update card settings at any time. The 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 pure form, but has an analogue of digital signature - MAC, which guarantees data integrity. The corresponding application key (one of the three DES keys loaded into the application) is used to calculate the MAC.

Separate items are modification of offline PIN and PinTryLimit limit counter. These changes are also performed by a script command with a MAC signature. However, when the PIN code is changed, these instructions are further encrypted using a special key designed solely to perform the described process.

4. These EMV-applications

Similar to magnetic stripe cards, EMV applications also have open data readable. And although the application itself cannot be read, as it is impossible to reach keys and PIN-access to public data of the application is always open.

What data are we talking about?

The picture above provides an approximate list of data stored within the EMV application. Of course, it may vary slightly for each particular application. At this point, it is important to note that the customer 's personal information is not stored in the EMV application. Indeed, more chip memory allows payment systems and banks to store more information on the card - but the customer 's personal information is not there.

The previous picture clearly illustrates the fact that the map contains many technical data necessary for efficient operations and account access. These EMV-applications are placed in records (records or tracks). They are listed in response to the Get Processing Options command. You can read a specific record using the Read Record command. Inside can be key certificates, Primary Account Number (PAN), CVM list- Card Verification Methods list and many other information. Reading these records is very similar to reading tracks from a magnetic strip. The data of technical settings of the map, counters and limits can be obtained by "Get Data" command, specifying the required type.

Interestingly, virtually all data about the cardholder 's account and app settings can be subtracted from the card without any difficulty. The only thing you can 't get to is the app keys and PIN value.

Can I copy data from one chip card to another?

If you have a card with a "clean" (not personalized) app, it 's 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 absence of keys will not allow CDA/DDA authentication. The only gap is SDA offline. However, this method is currently considered obsolete as a single authentication method. Next, we will discuss in detail how the EMV transaction is protected.

Can I copy EMV application data to a magnetic strip?

From the EMV application data, you can make tracks for a magnetic stripe map, except for one small parameter, the Service Code. As data for the EMV application, the service code indicates to the terminal that the transaction is to 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 perform the transaction using the application. It would seem possible to edit the service code, but the data integrity is protected by the CVV/CVC code. It is the closest analogue of a digital signature.

It feels like the EMV card is copy protected on all sides. Although one trivial possibility is still known. For compatibility mode, manufacturers produce combination-type EMV cards - that is, with a microprocessor and magnetic band. It is possible to copy magnetic strip data to another combined card with a non-working chip (clean or burned) and try to carry out the so-called fallback (if it is impossible to read the chip, the terminal carries out operation on the magnetic strip). At the moment, such transactions are not welcome by payment systems, and the risk under these transactions falls on the acquirer or issuer.

5. Safety of EMV transaction

There are two different (though performing the same function) options for carrying out a payment transaction - online and offline. Above, we have outlined an online transaction that the issuer confirms in real time. The offline transaction is carried out by the terminal without instant confirmation by the bank. Such transactions are used for low-risk transactions or in the case of, for example, no communication with the issuing bank.

For these two types of transactions, there are two types of authentications, online and offline, respectively. In case of online authentication, the transaction is performed with the participation of the issuer, and offline authentication is confirmed by the payment terminal. It is worth specifying that both online and offline authentication can be performed at the same time during an online transaction (if both the card and the terminal support it). Although the scheme is redundant, it is not always clear in the authentication step in which mode the transaction will take place.

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

5.1 Online EMV transaction

The main method of card authentication in online transactions is online card authentication. This method is based on the card generating an ARQC (Authorization Request Cryptogram) cryptogram for each payment transaction. Let 's take a closer look at this process.

The generation and verification of cryptograms is based on the 3DES algorithm. The issuer and card own the common secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates an Application Cryptogram Session Key (SKac) based on the MKac. The 8 byte long ARQC cryptogram is generated by the map 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, calculated by itself. The bank generates a session key for this transaction, then calculates its own ARQC based on the incoming transaction data. If your own (issuer generated) ARQC and ARQC cards converge - the card is genuine.

The issuer then generates ARPC (Authorization Response Cryptogram) based on dynamic transaction data and response data and sends this cryptogram back to the map. At the moment when the card confirms the incoming ARPC, mutual authentication of the card and the issuer is performed.

The main card authentication mechanism that is used for online transactions is described above. As already said, offline authentication may be present in an online transaction. However, in order not to be complicated, 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 sent to the issuing bank. Field/DE 55 contains the results of map and terminal operation, 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 to understand the issuer and payment system how the transaction occurs and provide many additional details to assess the risks of the transaction.

5.2 Offline EMV transaction

The feature of offline transaction is that the transaction is carried out by the card and terminal without reference to the bank and payment system. In the course of such a transaction, the card can approve the transaction within the established limit, and the terminal, in turn, sends the information to the bank later as scheduled, or when there is a communication with the bank. 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 to the bank. Or if the amount is small, the operation will go much faster.

How does an offline transaction authenticate your card?

It was previously mentioned that online and offline authentications use different technologies. If the online uses a cryptographic 3DES algorithm, in the case of offline, RSA with asymmetric keys is used. Why use such different technologies? The whole thing is that in online authentication, the keys are stored only by the card and the bank. In the case of an offline - the key needs to be entrusted to the terminal. Given the presence of a large number of terminals, there is a possibility that the secret key trusted to the terminals will remain secret for a short time.

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

At the head of everything is the payment system (more precisely the 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 specifically generates a certificate (Issuer Public Key Certificate) that contains the issuer 's public key. This certificate is signed (encrypted) by the private key of the payment system. This certificate is uploaded to your card during personalization.

When the payment terminal is set to a point of sale and connected to the system, the public key of the payment system is loaded into the terminal through the bank-acquirer.

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

The method described above refers to Static Data Authentication (SDA). Currently, dynamic authentications are 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. The data is signed by a private card key, 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 map has not been 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 allow to confirm authenticity of the card because the card is the carrier of a unique private key whose certificate (a public key) is signed with a private key of the issuer (the certificate of the issuer (his public key) is signed with a private key of payment service provider).

Charts SDA,DDA и CDA, EMV Book 2

• SDA

• DDA/CDA

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 runs until the main cycle of the transaction process. The CDA is executed in the main cycle of the transaction, and the card cryptogram is additionally used as the signed data. Overall, today, DDA technology is more common, although CDA is more preferred in use.

In addition to digital signature, the terminal and card are able to assess transaction risks. For offline transactions, the card can operate multiple types of offline transaction counters and batteries, currencies and countries, offline pin and its limits, and additional rules. During 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 application implementations 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 adjusted differently by the issuer for each card product. The solution process can involve the results of previous transactions, offline counters, pin checking results, etc.

6. CVM card holder verification

Virtually the entire article focused on transactions and the card authentication process, and little attention was paid to the card user. With the advent of EMV technology, card holder verification has not changed too much. Currently, the most popular verification methods are PIN verification (online and/or offline) and cardholder signature. Thus, with the arrival of EMV, not all payment terminals have the same ability to verify the cardholder (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 select a suitable method of checking the card holder. So-called CVM lists are used for this purpose. The CVM list defines the methods of checking the cardholder and their priorities. Both the payment application and the terminal have their own lists. The resulting list is determined by combining the terminal and application lists. From the resulting list, the terminal selects the common CVM method with the highest priority and checks the cardholder.

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

Conclusion

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

And as I promised in the beginning, I will give my opinion on EMV software, which everyone is looking for. A microprocessor EMV card is almost impossible to copy, and each transaction is protected by a unique digital signature. Any actions that occur within a card are governed by a strict set of rules with instructions on how to proceed on a case-by-case basis. In the process of creation, EMV payment applications undergo mandatory multilevel certification and receive permission from the payment system to use them. Programming such cards is difficult.

• If you get certificates and keys (will not cost without bank employees for a very good bribe),
• Understand how to make CVM-list for offline transactions,
• Find points with POS terminals supporting offline transactions with cards of those banks for which you have obtained certificates and keys,

Then you can cash cards in these places for some time, exactly until the bank sees fraud transactions and updates certificates and keys.

Now the question is, will you sell such information and software?

The answer is obvious.

Success in business...