Clone EMV card protection

Clone DDA/CDA card protection

Service code 2xx. In our right hand we have a card with only a magnetic stripe, to which information is transferred from the magnetic stripe of the card located in the left hand. We are trying to use the card in a hybrid terminal that accepts microprocessor cards and magnetic stripe cards. The terminal must check the value of the service code on the magnetic strip, and if it is equal to 2XX, it must require the transaction to be performed using the chip.
The terminal should not allow magnetic stripe operations if the value of the service code is 2XX and the terminal has not made a decision to switch to Fallback mode after trying to use the card chip to perform the operation. It is necessary to have a clear instruction for the cashier and a clear message on the terminal display that the transaction must necessarily be performed using a chip or be rejected.
In some implementations of the terminal application, despite the warnings, the seller still has the opportunity to circumvent the rule formulated above and perform an operation using a magnetic stripe. In this case, the responsibility for possible fraud from the point of view of the payment system lies with the servicing bank.

Despite the fact that the responsibility in this case lies with the servicing bank, the issuer is still recommended to reject transactions in which, in MasterCard terms, the POS data element (DE 061) indicates that the terminal can perform an operation on the chip, but conducts it along the magnetic stripe and at the same time POS Entry mode (DE022) is not equal to 80X (fallback case), but is equal, for example, 90X (magnetic stripe) or 05X (chip).
Let’s now consider “Case 1. Option 1. Magnetic terminal”. In our right hand we have the same card as in the previous case. In this case, a non-personalized chip may additionally be located on the card for greater persuasiveness. We are trying to use this card in a terminal that accepts only magnetic stripe cards.

If the transaction was authorized by the issuer, fraud will occur, and the following will be responsible for it:
• the servicing bank, if this bank and the issuer of the fake card are located in the area of the chip liability shift accepted in the payment system;
* issuer — in all other cases.

To protect against fraud, when there is no chip on a fake card, a message should appear on the display of magnetic terminals in the event of a card with service code=2XX indicating the need for the cashier of a trading company to check the presence of a chip on the card. If there is no chip, the cashier must reject the card acceptance.
Case 1, option 2. Service code 1xx. The data of the first and second tracks of the hybrid credit card are copied to the card with a magnetic stripe only, with the service code value changed to 1XX. The card is used offline to perform unlimited operations (the size of the operation is less than the value (terminal floor limit). Using the card in real time has little chance of success, since when the service code is changed, the integrity of the recording of the second track of the magnetic card is violated, and checking the CVV/CVC value in the issuer’s processing center will detect this fact. In this case, there are all possibilities to successfully use a fake card, regardless of whether the terminal is hybrid or accepts only cards with a magnetic stripe.

If a fake card is used in a hybrid terminal, then the entire responsibility for fraud lies with the card issuer. This is by far the most serious gap in the concept of migration to the chip.
Indeed, both the card and the terminal support the new technology, and yet card forgery is possible without any violations of the card acceptance rules by the merchant. To avoid this type of fraud, payment systems have introduced a rule according to which all transactions on magnetic stripe cards in terminals that support online operation must be sent to the issuer for authorization.
If a fake card is used in a terminal that accepts only cards with a magnetic stripe, then it is responsible for fraud:
* the servicing bank, if this bank and the issuer of the card that was forged are located in the area of the shift of responsibility accepted in the payment system;
* issuer — in all other cases.

Case 2. Hybrid card with a “crooked” chip (initialization of a Fallback to a fake magnetic stripe). A hybrid card blank with a “crooked” (for example, burned or incorrectly personalized) chip is used. In this case, the blank will cost more (by about 50 cents), but information copied from the magnetic track of a real hybrid card can be applied to the magnetic strip and used in both magnetic and hybrid terminals.
If a fake card is used in a hybrid terminal, then the entire responsibility for fraud lies with the card issuer.
If the terminal accepts only cards with a magnetic stripe, then the following is responsible for fraud
• * the servicing bank, if this bank and the issuer of the card that was forged are located in the area of the shift of responsibility accepted in the payment system;
* issuer — in all other cases.

The only countermeasure to combat this type of fraud is the organization in the issuer’s processing center of monitoring the number of fallback transactions performed on each card of the issuer. If the number of fallback operations for some card turned out to be higher than the threshold value, then this is a signal to the issuer to conduct an investigation in order to make sure that the operations were performed by a legitimate cardholder.
Payment systems are also taking measures to limit the use of Fallback mode in countries where the level of compliance of terminals and cards with the EMV standard is quite high. In particular, in Europe, this mode has already been abandoned when processing ATM transactions. In the near future, today the mandatory requirement to support fallback in POS terminals will become optional and at the country level it will be determined whether to consider backup authorization by magnetic stripe mandatory or not.

Fake chip. A cloned card is a card issued by an unauthorized person on behalf of an authorized issuer of the payment system. At the same time, the fact that the card is cloned cannot be determined by the terminal in the case of offline transaction processing.

To clone an SDA card, you just need to have a microprocessor card 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 a real SDA card is “transferred” to a “clean” microprocessor card, including FCI template, AIP, AFL data and records from files defined in AFL. Among these linear files there is a signed static application data object, which represents the critical card data signed by the issuer.

The card supports SELECT, GET PROCESSING OPTIONS, and READ RECORD commands in a standard way. In response to the VERIFY command, the card always responds with confirmation of the correctness of the entered PIN code.
In response to the GENERATE AC command , the card responds as follows:
• if the terminal asks for ARQC or AAC, the card responds with an AAC cryptogram, which takes an arbitrary hexadecimal 16-bit number;
• if the terminal asks for TC, the card responds with TC and uses an arbitrary hexadecimal 16-bit number as a cryptogram.
Thus, if the terminal believes that the transaction can be approved offline, the transaction with the cloned card will be approved. In all other cases, the cloned card will insist on rejecting the transaction offline. It follows that the cloned card cannot be blocked by the issuer through the script processing procedure.

The cost of cloning one card is several dollars (it is necessary to purchase blanks and a programmer for the chip selected for cloning). The data of real cards required for cloning can be collected on POS terminals in exactly the same way as they are collected today for magnetic stripe cards.

Note the following. Let’s assume that the card is 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 when cloning the SDA card. Obviously, if such a cloned card is used in a terminal that supports only the SDA method, then it has a 100% chance of success, provided that the terminal approves the transaction offline. That is why payment systems have made the support of the DDA method on POS terminals mandatory (the exception is “Online Only”-terminals for which support for offline card authentication is optional).
Similarly, if the DDA/CDA card is cloned to an SDA card and the terminal does not support offline authentication of the card at all, then if the card does not support a mechanism for verifying the fact of its authentication by the issuer, the terminal can deceive the issuer by declaring offline dynamic authentication of the card, without actually performing it. At the same time, fraud on the part of a trading company is committed not for the purpose of fraud, but in order to confirm the fulfillment of a payment system requirement. Fraudsters can take advantage of this deception by successfully using 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 DDA/CDA dynamic authentication methods?” The answer to this question is generally negative, since for cloning a DDA/CDA card, provided it is used under the conditions mentioned, it is necessary to know the card’s secret key.

At the same time, in some cases, cloning a DDA/CDA card is possible. If, for example, the DDA/CDA card directly (via AIP) supports the SDA method and does not support (does not contain in its file structure) of the SDA tag list data object, then such a card can be cloned. Indeed, having open card data at your disposal, it is easy to modify the AIP object on the cloned card, indicating in it that the card supports only the SDA method. In this case, the cloned card will be successfully used during offline transaction processing. Note that the modification of the AIP object will pass unnoticed for the terminal, since the AIP object does not fall into 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 get into the list of signed data only through the SDA tag list object.

Note that in order to avoid cloning a DDA card, it is better when such a card does not directly support the SDA method (indirectly, SDA is supported during the verification of the card key certificate), i.e., in particular, it does not contain a signed static application data object! In this case, even if the card does not contain an SDA tag list element, it is impossible to clone it to an SDA card, since the necessary data (signed static application data) is missing for this.
It should be noted that the lack of direct support for the SDA method by the card will not affect its prevalence, since all terminals support DDA.

Despite the fact that DDA cards, with proper personalization, do not allow cloning, they do not ensure the integrity of information exchange between the card and the terminal. Possible attacks are called “two-chip attacks” and consist of the following. A printed circuit board containing two chips is used: one is a bank chip, and the other is an emulator chip. A bank chip is a chip personalized by the bank for a DDA card. The emulator chip controls the data exchange between the bank chip and the terminal, modifying the card’s dialogue with the terminal if necessary. It is this chip that is inserted into the terminal’s card reader and exchanges information with the terminal. It analyzes the data of commands received from the terminal and, if necessary, modifies them in a way beneficial to the fraudster.