EMV technology implementation
In addition to dynamic card authentication, the CDA method also ensures the integrity of the most critical information exchange data in the “card โ terminal” dialog (CID and transaction details). This is achieved by combining the card authentication procedure with the GENERATE AC command, during which the most important data is exchanged between the card and the terminal.
The offline authentication method is selected by the terminal based on the AIP data and the terminal capabilities defined by the value of the third byte of the Terminal Capabilities element (Tag ‘9F33’).
In accordance with the rules of payment systems, all cards and terminals (except for the so-called “ATM only” cards and “Online only” terminals) must support the SDA method. In addition, the General trend is that terminals and cards are beginning to move towards DDA support (since January 1, 2005 all chip terminals in Europe according to VISA and MasterCard rules must support DDA). There is also interest in CDA cards. At the moment, a number of German banks already issue such cards, and about 50% of the application SOFTWARE cores of terminals certified under the approval Level 2 Tour in EMVCo in 2004 support CDA.
As previously explained, dynamic authentication methods automatically include static authentication, which is performed as part of the verification procedure for the card’s public key certificate. Therefore, a number of French banks now issue dynamic authentication cards that do not directly support the SDA method (bit 5 of byte 1 of AIP is 0). As a result, if the terminal supports only the SDA method, it will most likely process the transaction made using the Bank’s card online. Since January 1, 2006, DDA cards are mandatory for issuing in France.
Since the Issuer only learns about the result of card authentication based on TVR data ultimately received from the merchant, the EMV standard provides a mechanism for the Issuer to verify that the terminal has completed the card authentication procedure. This mechanism protects the Issuer from unscrupulous merchants/service banks who claim that the card authentication is present if this procedure is not followed during transaction processing. The reason for this deception may be the unwillingness of the servicing Bank/outlet to upgrade the terminals to support the RSA algorithm used for card authentication.
Support for the RSA algorithm requires additional expenses for upgrading the terminal. These costs are associated at least with changing the terminal’s software, and often with upgrading its hardware platform. To support RSA, the terminal must have a sufficiently high-performance processor (preferably a 32-bit RISC processor) and / or a cryptographic coprocessor in order to perform verification procedures for the Issuer’s and card’s certificates, as well as the Signed Dynamic Application Data element, quickly enough (1-3 seconds). The RSA software implementation can be used to perform these checks. A cryptographic coprocessor is required if the terminal supports the method of verification of the cardholder Enciphered Offline PIN. In this case, the PIN block is encrypted, which in accordance with the requirements of payment systems must be performed by specialized processors.
The mechanism for the Issuer to verify that the terminal has completed the card authentication procedure is as follows. When describing the card authentication methods, it was already mentioned that the terminal stores the DAC values when using SDA and IDN when using DDA/CDA in data objects with the tags ‘9F45′ and’ 9F4C’, respectively. If the Issuer includes the values of these tags in the CD0L1 and CD0L2 objects, the card gets the DAC and IDN values when it processes the GENERATE AC command. The received values can be sent by the card to the Issuer in the Issuer Application Data object. In the case of an online transaction, the Issuer can verify that the card was authenticated during transaction processing and take the verification results into account when deciding how to complete the transaction. In the case of an offline transaction, the card authentication is verified by the Issuer using a clearing message. Payment systems should provide for the possibility of the Issuer’s refusal to make a payment if the Issuer denies the fact of card authentication.
Thus, in order for the Issuer to verify that the card authentication terminal has been performed, it is necessary to:
include the ‘9F45’ and ‘9F4C’ tags in the CD0L1 and CD0L2 lists;
include the ‘9F45’ and ‘9F4C’ tags in the data object of the Issuer Application Data returned in the response to the GENERATE command.;
provide for checking the DAC and IDN values in the Issuer’s system (in the transaction processing subsystem and / or clearing messages).
For a prepaid card application, the mechanism for verifying that the Issuer has completed the card authentication procedure is particularly relevant. If the fraudster knows the terminals where the card authentication is not performed, then by cloning the DDA / CDA card as an SDA card, he can achieve the desired result in such a terminal.
Along with offline authentication, all cards and terminals are required to support the so-called online authentication of the card or, as it is sometimes called, online mutual authentication of the card and the Issuer (Online Mutual Authentication). The meaning of mutual authentication is that the card and terminal authenticate each other using the ARQC and ARPC cryptogram verification mechanism. Cryptograms are formed on the basis of random data provided to the card by the terminal, and therefore the fact of their correct calculation proves that the card and the Issuer have the” correct ” secret key, which can only be possessed by a genuine card and a genuine Issuer.
Online authentication is the most reliable way to authenticate a card, since it is performed directly by the Issuer, without an intermediary in the form of a terminal. In addition, the 3DES algorithm is used for online authentication, which is cryptographically strong, and corresponds to the RSA algorithm with a key length of more than 1700 bits. Using keys of this length on the card is still quite rare. Keys with a module length of 1024 bits are usually used.
Due to the high reliability of online authentication, payment systems allow the use of so-called “Online only” terminals (ATMs and POS terminals), which process all transactions in real time and may not support offline card authentication procedures.
When choosing the offline authentication method for a card, you must imagine the scope of the card. If the card is only used in ATMs, then you may not implement offline authentication methods on the card at all. If the offline limits of the card are such that all operations on the card are authorized in real time, then you can support a cheap method of static authentication on the card.
From the above, it follows that from the point of view of ensuring the security of a card transaction, the most reliable offline authentication method is CDA. Next come the methods of the DDA and SDA. The SDA method does not even protect the IPC from being cloned for use in offline operations.
A cloned card is a card issued by an unauthorized person on behalf of an authorized payment system Issuer. However, the terminal cannot determine that the card is cloned if the transaction is processed offline.
To clone an SDA card, you only need a blank MPC with a programmer for it and a General knowledge of the EMV standard. For example, a widely available card with a PIC16F84 microprocessor can be considered as a card.
Next, data from the real SDA card is “transferred” to the “clean” MPC, including data from FCI Template, AIP, AFL, and records from files defined in the AFL. Among the line file data, there is a Signed Static Application Data object, which represents the application’s critical data signed by the Issuer.
The card supports the standard SELECT, GET PROCESSING OPTIONS, and READ RECORD commands. In response to the VERIFY command, the card always responds by confirming that the PIN code entered is correct.
In response to the GENERATE command, the card responds as follows:
if the terminal requests ARQC or AAC, the card responds with an AAC cryptogram, which is an arbitrary 16-bit hexadecimal number;
if the terminal requests a vehicle, the card responds to the vehicle and uses an arbitrary 16 – bit hexadecimal number as the cryptogram.
Thus, if the terminal believes that a transaction can be approved offline, the cloned card transaction will be approved. In all other cases, the cloned card will insist on rejecting the transaction offline. Note that the cloned card does not support Script Processing and therefore cannot be blocked.
The cost of cloning a single card is approximately 5-10 dollars (you need to purchase MPC blanks and a programmer for the chip selected for cloning). Real card data required for cloning can be collected on POS terminals in exactly the same way as it is collected today for magnetic stripe cards.
Note the following. Let’s assume that the card was cloned from a real card that supports offline dynamic authentication. In this case, the same data is transferred to the cloned card that is used for cloning the SDA card. Obviously, if such a cloned card is used in a terminal that supports only the SDA method, it has an absolute chance of success if the terminal approves the transaction in offline mode (the terminal requests a cryptogram of the vehicle in the GENERATE AC command). This is why payment systems are increasingly demanding that DDA support be mandatory for POS terminals (the exception is “Online Only” terminals, for which support for offline card authentication is optional).
Similarly, if DDA/CDA card on cloned SDA card and the terminal does not support offline authentication of the card, in the case of the lack of support card verification mechanism of the fact of its authentication by the Issuer, the terminal can cheat the Issuer, stating the conduct of dynamic offline card authentication, without actually doing it. At the same time, deception on the part of the merchant is not committed for the purpose of fraud, but in order to confirm the fulfillment of the payment system’s requirements. This deception can be used by fraudsters who successfully use cloned cards in such terminals.
Then another question arises: “is it Possible to clone a DDA / CDA card to a card with static authentication when using a cloned card in a terminal that supports dynamic DDA/CDA authentication methods?ยป The answer to this question is generally negative, because to clone a DDA / CDA card when using it under the above conditions, you need to know the card’s secret key.
At the same time, in some cases, cloning of DDA/CDA cards is possible. If, for example, a DDA / CDA card directly (via AIP) supports the SDA method and does not support (does not contain in its file structure) the SDA Tag List data object, such a card can be cloned. Indeed, with open card data at your disposal, you can modify the AIP object for a cloned card by specifying that the card only supports the SDA method. As a result, the cloned card will be successfully used for offline transaction processing. Modification of the AIP object will pass unnoticed for the terminal, since the AIP object is not included in the list of signed data, the integrity of which is checked as part of the card authentication procedure using the SDA method. We remind the reader that the AIP data object (’82’) can only get to the list of signed data via the SDA Tag List object.
Note that to avoid cloning a DDA card, it is better if such a card does not directly support the SDA method (indirectly, SDA is supported during the card key certificate verification process), i.e., in particular, it does not contain a Signed Static Application Data object! In this case, even if the card does not contain the SDA Tag List element, it is not possible to clone it to the SDA card, because the necessary data is missing (Signed Static Application Data).
If the card does not directly support the SDA method, it will not significantly affect its usability. If the terminal does not support DDA, but only supports the static authentication method, then the transaction will most likely be processed online, so the breadth of receiving DDA cards will not be affected by the lack of support for the SDA method.
Despite the fact that DDA cards do not allow cloning when properly personalized, they do not ensure the integrity of information exchange between the card and the terminal. Possible attacks, called “two-chip attacks” and consisting of the following. A printed circuit Board containing two chips is used: one is a Bank chip, and the second is an emulator chip. A Bank chip is a chip personalized by the Bank for a DDA card. The chip emulator controls the data exchange between the Bank chip and the terminal, modifying it if necessary. This chip is inserted into the card reader of the terminal and exchanges information with it. It analyzes the data received from the terminal, and if necessary, modifies them in a way that is beneficial to the fraudster.
Here are the simplest examples of possible data modification. If the terminal in the GENERATE AC command requested a cryptogram of the vehicle, and the card in the person of the Bank chip decides to process the transaction online or reject it offline, the chip emulator changes the unprotected cryptogram Information Data in such a way that the card responds to the terminal with the cryptogram of the vehicle. Thus, the transaction is approved, provided that the Issuer’s decision must either reject it or pass it to the Issuer for authorization.
Another example. The chip emulator receives the transaction size value from the terminal and changes it to a smaller value, at which the card is ready to approve the transaction in offline authorization mode.
Such a chip emulator is called “wedge device”in the literature. The wedge device can be implemented not only in the printed circuit of the card, but also on the POS terminal. The main thing is that it serves as an intermediary for information exchange between the Bank chip and the terminal.
The problem of ensuring the integrity of information exchange between the card and the terminal is solved by using CDA cards. These cards include the CID, ICC Dynamic Number, cryptogram (TC or ARQC), Transaction Data Hash Code, and Unpredictable Number objects that are signed by the card. The Transaction Data Hash Code element is a hash function of information that circulates between the card and the terminal during transaction processing. Therefore, it is not possible to modify the information exchange in a way that is invisible to the terminal.
CDA cards have several weaknesses. First, as already noted, the size of the CDA card key module may not exceed 205 bytes under certain circumstances. To date, this restriction is not burdensome, since mostly smaller card keys are used. However, the situation may change in the future. Payment systems have already started distributing their 248-byte keys, allowing issuers and cards to use keys of comparable sizes.
The second weakness of SOA cards is related to the fact that when the servicing Bank/payment system manages the loading of system keys to terminals with care, it may happen that the servicing Bank did not implement (or rather, did not implement it in time) any of the system keys on its terminals. In this case, all CDA cards of issuers whose keys are certified on the missing system key will simply not be able to be serviced on such a terminal.
Indeed, after receiving a response from the card to the GENERATE AC command, the terminal will not be able to restore data from Signed Dynamic Application Data and will have to reject the transaction. This will happen even if the card responds to the GENERATE command and sends the arqc cryptogram to the terminal to process the transaction in real time. Without knowledge of the system key, it is not possible to restore the ARQC cryptogram from the Signed Dynamic Application Data object, and the transaction will have to be rejected.
Note that in the case of a DDA card, the transaction could be performed online if the corresponding system key is not present on the terminal.
Summarizing the second weakness of the CDA card, we note that the CDA method, in the event of a failure of authentication, unlike all other authentication methods, makes it impossible to apply for authorization to the Issuer.
Now we will formulate General recommendations regarding the choice of the card authentication method.
SDA cards should be used primarily in online authorization mode. Sometimes they can be used in offline authorization mode if the transaction size is small.
Even more stringent requirements are applied to international transactions (cross-boarder transaction) performed using SDA cards. This is due to the fact that the risks for international transactions are much higher than for domestic (domestic) transactions. Therefore, we recommend that you perform most of these operations in real time.
Another possibility for an application that supports SDA is to use it in the SAR/TVA program. In this program, offline card authentication is performed using the AAS cryptogram, not the offline authentication mechanism.
CDA cards should be preferred to DDA cards, since they ensure the integrity of information exchange between the card and the terminal in addition to card authentication. CDA cards are now issued by all major card providers. In terms of cost, CDA cards are equivalent to DDA cards, since both offline authentication methods require a cryptographic RSA coprocessor, and the requirements for eepr0m memory in both types of cards are the same. In this regard, it is advisable to choose a card that supports both of these authentication methods simultaneously and does not directly support the SDA method (only through the card key certificate verification procedure). At the current level of EMV technology implementation, simultaneous support for DDA and CDA methods will avoid a situation when the terminal cannot perform offline dynamic card authentication due to the fact that it does not support the CDA method.
As noted in the previous paragraph, it is preferable that cards with dynamic authentication do not directly support the SDA method. This will avoid the possibility of cloning DDA / CDA cards to SDA cards, since the card does not have a Signed Static Application Data object. Thus, it is possible to avoid cloning a DDA / CDA card not only if the SDA Tag List card is not supported, but also if the card is received in a terminal that only supports the SDA method.
If the card with dynamic authentication does support the SDA method directly (it contains Signed Static Application Data), it must store the SDA Tag List object (Tag ‘9F4’).
The online card authentication method should be used as a backup method for offline authentication: you need to define the Issuer Action Codes tables in this way, so that if offline card authentication failed or failed, the transaction could not end in offline mode unless it was rejected.
For prepaid schemes, you should use cards that implement dynamic authentication (DDA/CDA) and support verification of the card’s authentication by ICC Dynamic Number. This will avoid cases when fraudsters clone a DDA/CDA card to an SDA card and use such a card at pre-installed retail outlets that do not support offline authentication methods.
EMV V. 4. 1 standard Issuer keys and cards can only have two values of the open exponent-3 and 216 +1. Without compromising security, it is recommended that you select the value of the open exponent of the card and the Issuer equal to 3. This will reduce the time required for card authentication. The time of verification of the card signature by the terminal, as shown in Appendix B, behaves as <9 (LogAr x log2n) from the length of the open exponent K and the module l of the card’s public key. Reduced signature verification time for dynamic card authentication is due to the fact that today the card performs the RSA algorithm significantly faster than the POS terminal. The average RSA signature time on a card with a public key module l = 1024 bits and a closed exponent of the order l is 20-800 milliseconds(this time is 0 (1od3l)), and even on a 32-bit terminal it takes several seconds. Thus, to minimize the total time for performing dynamic authentication, it is better to use the value of the open exponent of the card and the Issuer equal to 3.
The amount of computation required to implement the SDA, DDA, and CDA authentication methods.
Amount of calculations for implementing various methods of card authentication
Authentication method
SDA 2 x RSA + 2 x SHA-1 โ
DDA 3 x RSA + 3 x SHA-1 1 x RSA+1 x SHA-1
CDA 4 x RSA + 4 x SHA-1 2 x RSA+2 x SHA-1
The last row of the table corresponds to the case when a transaction made using a CDA card was approved by the Issuer. If the transaction was rejected by the Issuer or approved offline, the indicators shown in the second row of the table are correct for it. If the transaction is rejected, offline operations using the RSA algorithm are not performed by the terminal and the card, unless the transaction is rejected due to a failure of the CDA.
About the cardholder verification method
After completing the card authentication procedure, you must make sure that the card is presented for payment by its authorized holder (the person to whom the Issuer has transferred its card for use). To date, the most reliable way to solve this problem is to verify the cardholder’s PIN code. There are reports that some banks are beginning to use biometric methods to identify the cardholder (fingerprints)
Experts have a dual attitude to the feasibility of using PIN-code in POS-terminals when using the technology of cards with a magnetic stripe. On the one hand, the PIN code is the only secret that is not available to fraudsters from the card details with a magnetic stripe, since it is not stored on the card. Therefore, the use of a PIN code is the most reliable means of securing operations performed using magnetic stripe cards. On the other hand, many experts rightly believe that there are many ways to compromise PIN codes in POS terminals, including installing false terminals, whose tasks include recording card details and PIN values.
If the IPC is used without a magnetic stripe, the situation changes radically. In this case, knowing the value of the PIN code and other card data available to the terminal does not allow the fraudster to make a fake card, which can be used to make a successful operation. However, in today’s transition situation, when most microprocessor-based Bank cards are hybrid, the mass use of PIN verification can cause an increase in cases of its compromise and subsequent use in terminals that accept only magnetic stripe cards.
When using the IPC, there are two ways to verify the PIN code: by the card itself in offline mode and by the card Issuer when processing the transaction in real time.
Obviously, the first method has a number of advantages. The main one is that offline PIN verification allows you to reliably verify the cardholder even in the case of offline transactions. It should also be recognized that in General, the security of checking the PIN code in this case is higher than when it is checked by the Issuer, since there are no risks of compromising the PIN code at the stages of its processing on the host of the servicing Bank and during the transfer to the Issuer.
At the same time, processing a transaction in offline mode imposes additional requirements on the terminal. Although this allows for unsecured PIN transfer to the card, many issuers require the PIN block to be closed (sometimes this is required by the legislation of the issuing country). In clause 3.13, we have already described how this is done using the card’s public key and the RSA algorithm. Support for the RSA algorithm by cryptographic ATM modules is still exotic. Therefore, PIN verification by card is still not used for these devices. Although in the relatively short term, everything may change, as banks ‘ interest in applications that require RSA support on ATMs increases. One of the
the purpose of this application is to transfer new master keys to ATMs (today this function is performed by security officers who have to go to the ATM to install/change the master key of the device).
An important note should also be made regarding the security of transmitting the encrypted PIN code value when it is verified by the card. Here, the situation with pin block encryption is radically different from the situation with its encryption during online verification of the pin code by the Issuer. The essence of the difference is that the potential fraudster knows the encryption key of the PIN block, since this key is the public key of the card. In addition, the fraudster may know all the encrypted data except for the value of the PIN block. This data includes a random number of the card (ICC Unpredictable Number) received by the terminal from the card in response to the GET CHALLENGE command, as well as a random sequence formed by the terminal (Random Pad Pattern). Having access to this terminal data, the fraudster is able to search through no more than 10,000 different versions of the PIN code values (in the vast majority of cases, the PIN code is 4 digits long) to find its value. Indeed, knowing the value of the encrypted PIN-block, a random number card and random sequence of terminal crook enumerates the possible values of PIN-code, encoding the known data known to him the key as long as the resulting value of the encrypted block do not coincide with the well-known fraudster value of the encrypted block. The value of the PIN block at which this result will be achieved will give the fraudster the desired PIN value.
Thus, from the point of view of cryptanalysis, transmitting the PIN code in encrypted and open form is equivalent in this case. From the point of view of practice, of course, it is necessary to make it impossible for the fraudster to get a random number of the card and a random sequence of the terminal at his disposal.
An effective way to deal with PIN code compromise is to generate a random sequence of the terminal by the cryptographic module of the terminal. However, to date, the “native” cryptographic modules used in terminals of well-known manufacturers do not implement the PIN block encryption function in accordance with the EMV standard at all.
Usually, the PIN block encryption algorithm is implemented in SAM (Security Application Module) modules. In this case, as a rule, the terminal itself prepares a random sequence and passes it to SAM for encryption of the PIN block using the RSA algorithm. From the above, it is obvious that this method of encrypting the PIN block is vulnerable, since the random number of the card and the random sequence of the terminal are open to a potential fraudster.
Many of the modules contain SAM the random number. Therefore, with appropriate programming of the SAM module, it is possible to ensure that a random sequence of the terminal is generated in this module. Generating a random terminal sequence in a cryptographic module is the only correct approach to pin block encryption. The procedure for generating a random number by the SAM module does not take much time. For example, if the Sam module’s random number sensor generates a random number of 8 bytes in 10 milliseconds (actually faster), then generating the terminal sequence may require generating about 15 such random numbers, which will take 150 milliseconds. This indicator will not have a noticeable effect on the operation execution time in the terminal. Entering the PIN code value by the cardholder will take much longer.
Pin confidentiality is important in a hybrid card acceptance network where cards with a magnetic stripe and chip are accepted. In the case of an exclusively microprocessor-based card acceptance environment (i.e., when accepting cards with a magnetic stripe is excluded), knowing the PIN code does not give the fraudster anything. To commit fraud, in addition to knowing the PIN code, you must have the IPC itself. Therefore, when accepting only IPC, the card holder may not hide the PIN code value that they enter on the terminal.
International payment systems actively recommend issuers to use offline PIN verification as the main method of cardholder verification. In particular, they are gradually introducing a liability shift called the Chip&PIN Liability Shift across regions.
To formulate it, we introduce the following definitions. We will call the IPC a Cheese & RS card if the PIN verification method is PIN Offline (regardless of the PIN transfer method โ protected or unprotected) is the highest priority in the CVM List when this operation is performed. We will still say that the terminal supports the PIN Offline method, if it supports secure and open PIN code transfer to the card.
Then the Chip & PIN Liability Shift is formulated as follows: if the Chip&PIN card is used in a terminal that does not support PIN Offline, then all responsibility for lost/Stolen (Lost/Stolen) cards and non-received (NRI) cards is transferred to the servicing Bank.
As a result, the order recommended by payment systems for placing the cardholder verification rules in the CVM List when performing an operation using a DDA / CDA card in a POS terminal is as follows:
Enciphered Offline PIN;
Plaintext Offline PIN;
Online PIN;
Signature;
No CVM.
This order of CVER rules is recommended for all VISA card products. For MasterCard credit products, the payment system recommends swapping rules 3 and 4, and for Maestro cards, it requires removing rule 5 from the list.
Note that a card that supports offline authentication and PIN Offline is a really well-protected payment tool that can cope with almost all known types of fraud.
On the choice of the terminal
Today, most POS terminals have approximately the same characteristics and performance indicators. A modern terminal is a device with a 32-bit RISC processor, RAM from 512 KB to 2 MB and higher, and FLash memory of 1 MB or more. Applications and even terminal operating systems are written in a high-level language and loaded into the terminal’s Flash memory. Application parameters are stored in RAM, which is provided with a battery in case of power failure of the terminal.
Cryptographic operations are performed in an HSM module, which can be inside a separate device called a PIN PAD, or inside a terminal (a variant of combining a PIN PAD with a terminal). Some cryptographic functions, such as the RSA algorithm, are sometimes performed in a separate programmable security module (SAM).
A modern POS terminal usually has a combined reader that can read information from the magnetic stripe of the card and exchange data with the chip of a hybrid card.
Almost all terminal providers declare that their terminals support telecommunications protocols X. Z/X. 28, SDLC, TCP/IP/Ethernet, GSM/GPRS, Wi-Fi (IEEE 802.11 b).
Due to the fact that POS terminals have about the same features and performance, the selection of the terminal is affected by several factors: the cost, the conditions for its support, functionality of the applications and certifications for EMVCo levels Type Approval Level 1 and Level 2 Type Approval.
The terminal application that can serve the EMV MPC must support processing the following commands: SELECT, GET PROCESSING OPTIONS, GET DATA, GENERATE AC (the PI parameter’s bit b is 0), EXTERNAL AUTHENTICATE. In addition, depending on the terminal’s capabilities, its application can support the commands VERIFY (for offline PIN verification), GET CHALLENGE (with the terminal’s support for the cardholder’s verification method Enciphered PIN Offline), INTERNAL AUTHENTICATE (with the terminal’s support for the DDA card authentication method), GENERATE AC with the b bit of parameter P1 equal to 1 (with the terminal’s support for the CDA card authentication method and direct selection of this method).
The terminal application must also parse the publisher Script Template templates into separate script processing procedure commands and pass these commands to the card for processing.
We will divide all POS-terminals into two classes: terminals that work only in online mode( Online Only Terminals), directing any operation to the Issuer for authorization, and all other terminals.