CarderPlanet
Professional
Payment cards have become part of our life. Until recently, only magnetic stripe cards were commonly used. Today you won't surprise anyone with a chip card. Everyone knows that a chip, microprocessor or, more consonant, an EMV payment card is a modern and reliable way of accessing a current account. It is safer than a magnetic stripe card and is nearly impossible to counterfeit. However, the details of the implementation of the "internals" of an EMV card are little known. Anyone who is interested in how an EMV card works, why EMV technology ensures the security of payments and how much it is worth trusting all of this - welcome under cat.
1. Introduction
What cards are we talking about?
Today, international payment systems (IPS) use the EMV standard to conduct transactions with bank cards. Some of the most famous MPSs, which are at the origin of the development of this technology, are the companies "VISA Inc" and "MasterCard Worldwide". Since the microprocessor cards of these companies are based on a common EMV technology, we will consider a generalized EMV card without going into the implementation details of a particular company.
It should be noted right away that the EMV specification is quite large, so the article does not claim to be a complete description of the standard. Many things will be presented in a simplified form without using specific terminology. Since the standard is open, if you wish, you can always familiarize yourself with and understand the details on the EMVCo website.
When describing payment transactions and the functionality of an EMV card, we will refer to other members of the system. In addition to the payment system itself, the following are involved in the transaction process:
Considering in more detail the EMV payment card, 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. Authentication of magnetic and EMV cards
One of the main tasks of the bank that issued the card is to authenticate the card during its use. In this case, authentication is understood as the process of proving that a given card (or an application on a card) has been issued by a bank authorized for this by the appropriate payment system.
How does the card authentication process take place?
In general, after reading the card details, the terminal sends them through the acquiring bank and the payment system to the issuing bank. The issuer determines its authenticity on the basis of the card data.
This process is one of the main security concerns of magnetic card payments. 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 easy to copy the entire card.
2.1 Authentication of a magnetic card based on static data
Static card data is used for authentication in magnetic card transactions. These card details are transmitted to the issuing bank every time and do not change during the entire validity period of the card. In addition, the payment terminal practically does not assess the risks of transactions with magnetic stripe cards. As a result, if the card is completely copied, the issuing bank will not be able to reliably determine the authenticity of such a card. Accordingly, the likelihood of a fraudulent transaction is quite high.
2.2 Authentication of EMV card based on dynamic data
How do EMV cards solve this issue?
The solution to the above problem is to digitally sign the static card data and transaction data that are sent to the issuer. Since the digital signature is unique for each transaction, forging 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 starts when the card is inserted into the terminal. The terminal sends the transaction data (amount, currency, country, etc.) to the card. Then the card and the terminal mutually check the risks of the transaction. If everything "suits" both devices, the card signs the transaction data, and the terminal fills in the received data field (tag or tag) "DE 55" 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 above process is a highly simplified EVM transaction model. However, it does cover 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:
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 a transaction.
3. Internal structure and security of EMV card
By and large, an EMV microprocessor card is a regular smart card, which is based on the ISO / IEC 7816 or ISO / IEC 14443 (for contactless) standards.
The EMV card implementation can be performed both on the basis of 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 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. Details can be found in the EMV Book 3 Application Specification. Despite the existence of the standard, the payment applications of Visa and MasterCard differ in implementation. Also, different applications of the same company may 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. By the application identifier AID, the terminal determines the possibility of a transaction or, in the case of several applications, builds a list of supported applications and offers to select one of them.
If the file structure and application management are implemented on the card, what mechanisms ensure the safety of data from outside access?
Here it is worth dividing the life time of the card before the moment of issue by the bank, and after.
Primary access to a blank 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 therefore requires authentication for access.
Next, the installed application goes through the card personalization process. Personalization is the loading of application parameters and keys that determine the security of EMV transactions. Access to this process also requires application key authentication.
After installing the application and personalizing it, the above access is usually closed forever. That excludes the possibility of penetration "inside" after the release of the card.
In total: the card key, OS key and application key protect the card from third-party interference at various stages of its production. In the event that part of the cards is discredited during production (for example, stolen), these keys will protect the cards from outside interference. And without knowing the keys, the cards become almost completely useless.
Some of these applications can be modified after the card is issued. Changes can be made with so-called script commands. The exclusive rights to implement 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. 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 its pure form, however, it has an analogue of a digital signature - MAC, which guarantees the integrity of the data. To calculate 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 counter for the limit of unsuccessful PIN-code entries (PinTryLimit). These changes are also performed by a MAC-signed script command. 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 open data readable. And although the application itself is impossible to read, just as it is impossible to get to the keys and pin-code - access to the open data of the application is always open.
EMV application data
What data are we talking about?
The picture above is an approximate list of data stored inside an EMV application. Of course, it may differ slightly for each specific application. At this stage, it is important to note that the client's personal information is not stored in the EMV application. Indeed, a larger amount of chip memory 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 a lot of technical data is stored on the card, which is necessary for efficient transactions 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), lists of card verification methods (CVM list - Card Verification Methods list) and many other information. Reading these records is very similar to reading tracks from a magnetic stripe. Card technical settings data, counters and limits can be obtained by the “Get Data” command, specifying the required type.
Interestingly, almost all data about the cardholder's account and application settings can be deducted from the card without any difficulties. The only thing you can't get to 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" (not personalized) application, then it 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, lack of keys will prevent CDA / DDA authentication. The only flaw is SDA offline. However, this method is deprecated as the only authentication method at this time. Next, it will be discussed in detail how the EMV transaction is protected.
Can EMV application data be copied to magnetic stripe?
The EMV application data can be used to compose tracks for a magnetic stripe card, 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 made 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 it is 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 from all sides. However, one trivial possibility is known. For compatibility mode, manufacturers release EMV cards of a combined type - that is, with a microprocessor and a magnetic stripe. It is possible to copy the magnetic stripe data to another combined card with a non-working chip (clean or burnt) 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). At the moment, such transactions are not welcomed by payment systems, and the risk for these transactions lies with the acquirer or the issuer.
5. Security of EMV transactions
There are two different (although performing the same function) options for conducting a payment transaction - online and offline. Above, we have outlined an online transaction that 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 low-risk transactions or in case, for example, there is no connection with the issuing bank.
For these two types of transactions, there are respectively two types of authentications - online and offline. In the 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 clarifying 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 which mode the transaction will proceed.
The procedure for executing a card - terminal transaction
The security features discussed below are only part of an EMV transaction. In addition to authentication, security functions include: risk assessment of a transaction and cardholder verification (online and offline pin, transaction amount, country, currency, etc.).
5.1 Online EMV Transaction
The main method of authenticating a card in online transactions is online card authentication. This method is based on the generation of the ARQC (Authorization Request Cryptogram) cryptogram by the card for each payment operation. Let's take a closer look at this process.
The generation and verification of cryptograms is based on the 3DES algorithm. The issuer and the card have a shared secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates a SKac session key (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 the transaction data.
In the course of the transaction, the ARQC cryptogram generated by the card is sent to the issuing bank, the Bank will verify the received ARQC with the cryptogram which 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 the own (issued by the issuer) ARQC and ARQC cards converge - the card is genuine.
Next, the issuer uses a similar algorithm to generate an ARPC (Authorization Response Cryptogram) based on dynamic transaction data and response data and sends this cryptogram back to the card. The moment the card confirms 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, to keep things simple, let's look at 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 card and terminal operations, 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 the payment system of how the transaction takes place 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 a card and a terminal without contacting 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 information to the bank later on schedule, or when a connection with the bank appears. These 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 is the card authenticated in an offline transaction?
It was mentioned earlier that online and offline authentication uses different technologies. If online uses the 3DES cryptographic algorithm, then in the case of offline it uses RSA with asymmetric keys. Why use such different technologies? The thing is that with online authentication, only the card and the bank store the keys. In the case of offline, the key must be entrusted 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.
Because the detailed description of offline card authentication is quite large, let's consider a simplified model.
At the head of everything is the payment system (more precisely, the certification center), 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 public key of the issuer. This certificate is signed (encrypted) with the private key of the payment system. During the personalization process, this certificate is loaded onto the card.
When the payment terminal is installed in a merchant and connected to the system, the public key of the payment system is loaded into the terminal through the acquiring bank.
In the course of an offline transaction, the terminal performs offline card authentication. First, the terminal reads the Issuer Public Key Certificate from the card, and using the public key of the payment system checks the correctness of the certificate signature (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 card's critical data is verified, which confirms its authenticity.
The above method is for 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 travels between the terminal and the card. The data is signed with 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 has not been modified. However, it does not allow to fully identify the authenticity of the card (it is possible to copy the 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 with the issuer's private key (the issuer's certificate (its public key) is signed with the private key of the payment system).
SDA, DDA and CDA charts, EMV Book 2
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 loop of the transaction process. CDA is performed in the main cycle of the transaction, and the cryptogram of the card is additionally used as the signed data. In general, DDA technology is more prevalent today, although CDA is more preferred.
In addition to the digital signature, the terminal and the card are able to assess the risks of a 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), thus determining the level of risk.
For each of the implementations of the application of a specific 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 solution process may involve the results of previous transactions, offline counters, pin verification results, etc.
6. Cardholder verification method CVM (Cardholder verification method)
Almost 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 much. Currently, the most popular verification methods are: PIN verification (online and / or offline) and the cardholder's signature. It so happened that with the arrival 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 can also be limited in their capabilities. Therefore, the terminal and the card have to choose the appropriate method for verifying the cardholder. For this, the so-called CVM lists are used. The CVM-list defines the methods of cardholder verification and their priorities. And a payment application, and the 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 cardholder.
An example of such a list is shown in the picture above. For example, if the card is inserted into an ATM, an online pin will be requested, if in the terminal - an offline pin. If the device does not have a pin-pad, a signature verification will be requested. In all other cases, verification of the cardholder will not be performed.
Conclusion
In this article, we briefly reviewed the EMV payment application and the data stored in it, described the main differences in the processes of conducting transactions using magnetic and EMV cards. The procedures for conducting online and offline transactions and mechanisms for ensuring their security were also considered. Of course, every aspect of EMV technology is of much greater depth and complexity. However, I hope that the article gave a general understanding of how EMV payment cards work and how to make payments using them.
In conclusion, we can say that an EMV payment card is a complex and high-tech product that reliably protects access to your bank account. The microprocessor EMV card is almost impossible to copy, and each transaction is protected by a unique digital signature. Any actions that take place inside the card are governed by a strict set of rules with instructions on how to proceed in each 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 take more than one article.
Thank you for the attention!
P.S. I will be glad to answer your questions in the comments.
habrastorage.org
1. Introduction
What cards are we talking about?
Today, international payment systems (IPS) use the EMV standard to conduct transactions with bank cards. Some of the most famous MPSs, which are at the origin of the development of this technology, are the companies "VISA Inc" and "MasterCard Worldwide". Since the microprocessor cards of these companies are based on a common EMV technology, we will consider a generalized EMV card without going into the implementation details of a particular company.
It should be noted right away that the EMV specification is quite large, so the article does not claim to be a complete description of the standard. Many things will be presented in a simplified form without using specific terminology. Since the standard is open, if you wish, you can always familiarize yourself with and understand the details on the EMVCo website.
When describing payment transactions and the functionality of an EMV card, 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 with this bank
- acquiring bank - a bank that services a payment point terminal
- payment terminal - a device that provides work with a payment card
Considering in more detail the EMV payment card, 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. Authentication of magnetic and EMV cards
One of the main tasks of the bank that issued the card is to authenticate the card during its use. In this case, authentication is understood as the process of proving that a given card (or an application on a card) has been issued by a bank authorized for this by the appropriate payment system.
How does the card authentication process take place?
In general, after reading the card details, the terminal sends them through the acquiring bank and the payment system to the issuing bank. The issuer determines its authenticity on the basis of the card data.
This process is one of the main security concerns of magnetic card payments. 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 easy to copy the entire card.
2.1 Authentication of a magnetic card based on static data
Static card data is used for authentication in magnetic card transactions. These card details are transmitted to the issuing bank every time and do not change during the entire validity period of the card. In addition, the payment terminal practically does not assess the risks of transactions with magnetic stripe cards. As a result, if the card is completely copied, the issuing bank will not be able to reliably determine the authenticity of such a card. Accordingly, the likelihood of a fraudulent transaction is quite high.
2.2 Authentication of EMV card based on dynamic data
How do EMV cards solve this issue?
The solution to the above problem is to digitally sign the static card data and transaction data that are sent to the issuer. Since the digital signature is unique for each transaction, forging 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 starts when the card is inserted into the terminal. The terminal sends the transaction data (amount, currency, country, etc.) to the card. Then the card and the terminal mutually check the risks of the transaction. If everything "suits" both devices, the card signs the transaction data, and the terminal fills in the received data field (tag or tag) "DE 55" 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 above process is a highly simplified EVM transaction model. However, it does cover 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 the dynamic cryptogram of the card
- mutual authentication: the issuer can send its cryptogram to the card
- the ability to update the card data after authentication (for example, to block the 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 a transaction.
3. Internal structure and security of EMV card
By and large, an EMV microprocessor card is a regular smart card, which is based on the ISO / IEC 7816 or ISO / IEC 14443 (for contactless) standards.
The EMV card implementation can be performed both on the basis of 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 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. Details can be found in the EMV Book 3 Application Specification. Despite the existence of the standard, the payment applications of Visa and MasterCard differ in implementation. Also, different applications of the same company may 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. By the application identifier AID, the terminal determines the possibility of a transaction or, in the case of several applications, builds a list of supported applications and offers to select one of them.
If the file structure and application management are implemented on the card, what mechanisms ensure the safety of data from outside access?
Here it is worth dividing the life time of the card before the moment of issue by the bank, and after.
Primary access to a blank 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 therefore requires authentication for access.
Next, the installed application goes through the card personalization process. Personalization is the loading of application parameters and keys that determine the security of EMV transactions. Access to this process also requires application key authentication.
After installing the application and personalizing it, the above access is usually closed forever. That excludes the possibility of penetration "inside" after the release of the card.
In total: the card key, OS key and application key protect the card from third-party interference at various stages of its production. In the event that part of the cards is discredited during production (for example, stolen), these keys will protect the cards from outside interference. And without knowing the keys, the cards become almost completely useless.
Some of these applications can be modified after the card is issued. Changes can be made with so-called script commands. The exclusive rights to implement 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. 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 its pure form, however, it has an analogue of a digital signature - MAC, which guarantees the integrity of the data. To calculate 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 counter for the limit of unsuccessful PIN-code entries (PinTryLimit). These changes are also performed by a MAC-signed script command. 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 open data readable. And although the application itself is impossible to read, just as it is impossible to get to the keys and pin-code - access to the open data of the application is always open.
EMV application data
What data are we talking about?
The picture above is an approximate list of data stored inside an EMV application. Of course, it may differ slightly for each specific application. At this stage, it is important to note that the client's personal information is not stored in the EMV application. Indeed, a larger amount of chip memory 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 a lot of technical data is stored on the card, which is necessary for efficient transactions 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), lists of card verification methods (CVM list - Card Verification Methods list) and many other information. Reading these records is very similar to reading tracks from a magnetic stripe. Card technical settings data, counters and limits can be obtained by the “Get Data” command, specifying the required type.
Interestingly, almost all data about the cardholder's account and application settings can be deducted from the card without any difficulties. The only thing you can't get to 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" (not personalized) application, then it 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, lack of keys will prevent CDA / DDA authentication. The only flaw is SDA offline. However, this method is deprecated as the only authentication method at this time. Next, it will be discussed in detail how the EMV transaction is protected.
Can EMV application data be copied to magnetic stripe?
The EMV application data can be used to compose tracks for a magnetic stripe card, 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 made 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 it is 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 from all sides. However, one trivial possibility is known. For compatibility mode, manufacturers release EMV cards of a combined type - that is, with a microprocessor and a magnetic stripe. It is possible to copy the magnetic stripe data to another combined card with a non-working chip (clean or burnt) 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). At the moment, such transactions are not welcomed by payment systems, and the risk for these transactions lies with the acquirer or the issuer.
5. Security of EMV transactions
There are two different (although performing the same function) options for conducting a payment transaction - online and offline. Above, we have outlined an online transaction that 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 low-risk transactions or in case, for example, there is no connection with the issuing bank.
For these two types of transactions, there are respectively two types of authentications - online and offline. In the 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 clarifying 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 which mode the transaction will proceed.
The procedure for executing a card - terminal transaction
The security features discussed below are only part of an EMV transaction. In addition to authentication, security functions include: risk assessment of a transaction and cardholder verification (online and offline pin, transaction amount, country, currency, etc.).
5.1 Online EMV Transaction
The main method of authenticating a card in online transactions is online card authentication. This method is based on the generation of the ARQC (Authorization Request Cryptogram) cryptogram by the card for each payment operation. Let's take a closer look at this process.
The generation and verification of cryptograms is based on the 3DES algorithm. The issuer and the card have a shared secret key MKac (Application Cryptogram Master Key). At the beginning of the transaction, the card generates a SKac session key (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 the transaction data.
In the course of the transaction, the ARQC cryptogram generated by the card is sent to the issuing bank, the Bank will verify the received ARQC with the cryptogram which 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 the own (issued by the issuer) ARQC and ARQC cards converge - the card is genuine.
Next, the issuer uses a similar algorithm to generate an ARPC (Authorization Response Cryptogram) based on dynamic transaction data and response data and sends this cryptogram back to the card. The moment the card confirms 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, to keep things simple, let's look at 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 card and terminal operations, 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 the payment system of how the transaction takes place 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 a card and a terminal without contacting 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 information to the bank later on schedule, or when a connection with the bank appears. These 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 is the card authenticated in an offline transaction?
It was mentioned earlier that online and offline authentication uses different technologies. If online uses the 3DES cryptographic algorithm, then in the case of offline it uses RSA with asymmetric keys. Why use such different technologies? The thing is that with online authentication, only the card and the bank store the keys. In the case of offline, the key must be entrusted 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.
Because the detailed description of offline card authentication is quite large, let's consider a simplified model.
At the head of everything is the payment system (more precisely, the certification center), 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 public key of the issuer. This certificate is signed (encrypted) with the private key of the payment system. During the personalization process, this certificate is loaded onto the card.
When the payment terminal is installed in a merchant and connected to the system, the public key of the payment system is loaded into the terminal through the acquiring bank.
In the course of an offline transaction, the terminal performs offline card authentication. First, the terminal reads the Issuer Public Key Certificate from the card, and using the public key of the payment system checks the correctness of the certificate signature (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 card's critical data is verified, which confirms its authenticity.
The above method is for 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 travels between the terminal and the card. The data is signed with 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 has not been modified. However, it does not allow to fully identify the authenticity of the card (it is possible to copy the 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 with the issuer's private key (the issuer's certificate (its public key) is signed with the private key of the payment system).
SDA, DDA and CDA charts, EMV Book 2
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 loop of the transaction process. CDA is performed in the main cycle of the transaction, and the cryptogram of the card is additionally used as the signed data. In general, DDA technology is more prevalent today, although CDA is more preferred.
In addition to the digital signature, the terminal and the card are able to assess the risks of a 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), thus determining the level of risk.
For each of the implementations of the application of a specific 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 solution process may involve the results of previous transactions, offline counters, pin verification results, etc.
6. Cardholder verification method CVM (Cardholder verification method)
Almost 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 much. Currently, the most popular verification methods are: PIN verification (online and / or offline) and the cardholder's signature. It so happened that with the arrival 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 can also be limited in their capabilities. Therefore, the terminal and the card have to choose the appropriate method for verifying the cardholder. For this, the so-called CVM lists are used. The CVM-list defines the methods of cardholder verification and their priorities. And a payment application, and the 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 cardholder.
An example of such a list is shown in the picture above. For example, if the card is inserted into an ATM, an online pin will be requested, if in the terminal - an offline pin. If the device does not have a pin-pad, a signature verification will be requested. In all other cases, verification of the cardholder will not be performed.
Conclusion
In this article, we briefly reviewed the EMV payment application and the data stored in it, described the main differences in the processes of conducting transactions using magnetic and EMV cards. The procedures for conducting online and offline transactions and mechanisms for ensuring their security were also considered. Of course, every aspect of EMV technology is of much greater depth and complexity. However, I hope that the article gave a general understanding of how EMV payment cards work and how to make payments using them.
In conclusion, we can say that an EMV payment card is a complex and high-tech product that reliably protects access to your bank account. The microprocessor EMV card is almost impossible to copy, and each transaction is protected by a unique digital signature. Any actions that take place inside the card are governed by a strict set of rules with instructions on how to proceed in each 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 take more than one article.
Thank you for the attention!
P.S. I will be glad to answer your questions in the comments.
habrastorage.org
Last edited by a moderator:
